→ NDark: 先卡 07/21 15:08
→ MOONY135: 工時就是用來delay的 （誤 07/21 15:20
推 irvingray: 真正落實敏捷也是種神話 07/21 15:20
推 rhox: 預估工時可以用來評估開出的規格是否可行 07/21 15:22
→ pttworld: 估工時是因為成本和報價，通常只有縮短 07/21 15:29
推 abccbaandy: 工時本來就是參考用阿...delay是正常的 07/21 15:38
→ abccbaandy: 看那些遊戲大作整天coming soon就知道了吧XD 07/21 15:39
推 art1: 因為是用在管理上，高層就是看這些東西 07/21 16:00
→ fgh81113: 工時就是拿來壓榨你用的 做不出來你的問題 07/21 16:00
推 anandydy529: 就是一個半套的工作流搞的程式很爆炸 07/21 16:21
→ landlord: 敏捷一般常見的是fixed deadline, 但scope是變動的 07/21 16:44
→ landlord: 一般公司最大的誤解就是time跟scope都不可變動 07/21 16:45
→ landlord: 那當然穩死的，這不是敏捷的問題，是濫用的問題 07/21 16:45
→ landlord: 還有一個大前提，簽敏捷宣言的大神們，其實都是技術大神 07/21 16:46
→ landlord: 他們發現要解決人跟協作的問題，避免流程冗重浪費的問題 07/21 16:47
→ landlord: 所以用敏捷宣言來補上這一塊，因為他們已經沒啥技術問題 07/21 16:47
→ landlord: 現在搞敏捷的公司，技術跟工程基底能力普遍不足 07/21 16:47
→ landlord: "為什麼 Scrum 害你們產能下降、品質低落、時程 delay" 07/21 16:49
→ landlord: 講個結論，從你的描述看來，你公司只是把敏捷當銀彈用 07/21 16:50
→ landlord: 跟人家在追求潮流詞彙而已，但結果會比原本的瀑布還差 07/21 16:50
實際上我們公司的規格也幾乎都是口傳 文件只是當參考註記用 沒有common lang
更沒有什麼user story的概念 或sprint的名詞
只是一直講產品要迭代 規格會改 進到QA後規格調整功能追加也是常態
※ 編輯: yukimatoi (1.163.98.5 臺灣), 07/21/2019 16:54:41
→ MOONY135: 工程師能力不一跟對專案了解度不一 跑敏捷真的是會絕頂 07/21 16:56
→ MOONY135: 昇天 07/21 16:56
→ landlord: 恩，所以只是被「buzzword形式的agile」強暴了 07/21 16:56
→ JingJing00: 工時是拿來讓pm排開發功能的優先順序 07/21 17:47
→ JingJing00: 一個功能複雜度13 另一個3 無相依 看pm是想先做13還是 07/21 17:48
→ JingJing00: 先做3的 07/21 17:48
→ keyboard56: 工時主要就用在管理 上面喜歡看到有在前進的感覺，二 07/21 17:56
→ keyboard56: 來就是報價用讓上面知道要開發這個東西大約需要多少 07/21 17:56
→ keyboard56: 成本。但預估歸預估實際上很難估得準，需求規格的不確 07/21 17:56
→ keyboard56: 定是主因，會壓縮到後續相關的時程。 07/21 17:56
→ SimonAllen: 敏捷只做半套就是在壓榨工程人員.. 07/21 18:07
推 TheOneisNEO: 遇過很有趣的 工時不能估太長 太長的話強制拆成兩個 07/21 20:27
→ TheOneisNEO: 以上的排程 但根本就還沒做也沒確認規格 07/21 20:28
→ MOONY135: 樓上那個我遇過喔 07/21 20:39
噓 tx50xyz: 你能說不嗎？工時估多一點，馬上就說要這久，估少，你天 07/21 21:28
→ tx50xyz: 天要加班加到死，估時程是對老闆超有利的，反正工時開多 07/21 21:28
→ tx50xyz: 老闆會點頭嗎？跟本就是有依據讓你加班不給加班費的 07/21 21:28
推 oopFoo: 推landlord大 07/21 21:48
推 anandydy529: 我也遇過只有一句話就要你估工時的，估完還不能改 07/21 21:49
→ neo5277: 通常壓辦年或是八個月上線然後會延兩次 07/21 21:50
推 overhead: 你的抱怨超寫實超有既是感哈哈哈 07/21 22:02
→ MOONY135: 我遇過可能工程師裡面那段只有一個人碰過 要其他人盲估 07/21 23:36
→ MOONY135: 的 這種我就覺得很微妙 07/21 23:36
推 molopo: 壓久了 人都走光 07/22 03:08
推 expup: 會問這個問題的估計是連預估都不會或常常預估錯誤 07/22 04:12
→ expup: 但也不能怪妳啦因為預估時間這東西沒人會教你 07/22 04:13
→ bndan: 估工時 目前看到最經典的還是 公司老工程師估完新工程師承 07/22 08:22
→ bndan: 擔 這種絕頂升天的程度不亞於實力或認知不同時實跑scrum 07/22 08:22
推 doranako: 不估時程，誰知道大概做多久，蓋個房子也要估時程阿， 07/22 09:07
→ doranako: 敏捷跟瀑布一樣，前面需求分析架構做足，時程變動少， 07/22 09:07
→ doranako: 除非中間又更動到功能跟規格 07/22 09:07
我們就是三餐在改啊
→ WunoW: 都說是估了，當然不會準啊 07/22 09:17
※ 編輯: yukimatoi (1.163.98.5 臺灣), 07/22/2019 09:25:33
→ firtaily: 跟小弟公司碰到的蠻像的 公司甚至sa跟pg是同步的 很常pg 07/22 09:28
→ firtaily: 這邊開發完了sa寫出來發現不一樣pg這又要再改 07/22 09:28
推 hakama99: 我們公司還發生新產品評估階段 業務已經賣出去好幾套 07/22 10:24
推 dong531: 1掌握進度避免無法如期交付而被罰錢 07/22 10:55
→ dong531: 2計算人力估價報價 07/22 10:56
→ dong531: 比如我現在的維護案，需求來了先評估人力、工時，然後回 07/22 10:56
→ dong531: 報這個需求需要多少人力做多久所以報價是多少，要做就開 07/22 10:56
→ dong531: 單不做就不開單 07/22 10:56
推 sirius65482: 簡單啦 預估完的時間全部乘以1.5 這樣就準多惹 07/22 12:37
推 b6byc: 改動頻率也太常了吧. 這個應該是規格溝通問題. 一直改啥 07/22 17:48
→ b6byc: 方法都沒用, 做一做, 反正還要改. 07/22 17:49
→ b6byc: 壓時間壓久了, 受不了走人, 然後loop, 公司沉淪下去. 07/22 17:50
推 lordmi: 講這麼多，幾個字就定義完了：隕石式開發 07/22 18:00
→ dancedolf: 評估的時候 最好是能多花點時間 另外在評估之前 需求 07/22 21:29
→ dancedolf: 應該已經有至少八成的確定 如果推倒重來 那時間肯定要 07/22 21:29
→ dancedolf: 重估 返工肯定是往需求推 07/22 21:29
→ dancedolf: 如果需求連讓你想像功能畫流程圖都不行 那就退貨吧 另 07/22 21:31
→ dancedolf: 外需求通常都會比當前sprint 提早 最好還有人能夠 rev 07/22 21:31
→ dancedolf: iew 07/22 21:31
→ viper9709: 推同感~有一樣的疑問+1 07/22 22:14
推 Tatum0119: 卡 07/23 00:18
推 shooter555: 估時間只能竟量估長0.0 有時候時間真的很難估 07/23 10:55
→ shooter555: *儘量 07/23 10:56
噓 b81314: 加油! 07/24 17:14
推 sa0124: 這是好問題耶 但如果都不估時程 功能隨意做做個一年 這樣 07/25 18:58
→ sa0124: 公司會倒吧 估時程主要還是讓公司判斷這個產品成本多少錢 07/25 18:58
→ sa0124: 啊 07/25 18:58
→ sa0124: 我們是工程師自己估，其實估久了真的就越來越準了，有時 07/25 19:00
→ sa0124: 候發現自己估很準其實也蠻有成就感的XD 07/25 19:00
推 zased: 這什麼問題 RD看世界？你換個角色重新思考專案就知道預估工 07/26 01:25
→ zased: 時的重要性，而且預估工時是RD的基本功... 07/26 01:25
推 JingX: RD自估最準 但高層一句"這麼簡單哪要這久你能力不足"就... 07/28 09:16