為什麼“敏捷”會浪費這麼多時間？ - Reddit

banq發表於2022-05-27
敏捷

階段性工作、回顧、完善和類似的工作所花費的時間是瘋狂的。如果我假設每天有15分鐘的停頓，兩個小時左右的完善和回顧（我曾在一個地方有四個小時的完善），那簡直就是把一天的衝刺時間浪費在了會議上。

如果團隊中的人只是在電子郵件中告訴經理/主管 "我被這個擋住了"，或者 "下次我們能這樣做嗎？"，這反而會真的可以解決問題。

敏捷真正挑戰了 "效率 "的普遍觀念。

我們對什麼是高效的想法大多來自制造業，但這些想法往往不適用於知識工作者。在工廠裡看到一個翹著腳盯著天花板的人？他顯然是個懶人，解僱他吧。在軟體公司看到有人翹著腳盯著天花板？他們在想，別他媽的打擾他們。

許多開發人員認為，效率意味著每天都要寫出儘可能多的程式碼行。測試？這是別人的問題。如果你要衡量軟體開發的效率（我不建議這樣做），至少要全面衡量。當然，編碼的時間，還有測試的時間，讓別人解讀你的編碼風格的時間，修復錯誤的時間，解開你因為擔心時間而匆忙做出的有問題的設計決定的時間，以及解決客戶因為介面模糊而抱怨的時間。有很多開發人員認為他們是 "高效 "的，同時每天都在編寫大量的低劣程式碼。

最後，雖然大多陣列織說他們想要速度，但他們會用速度來換取一週中的每一天和週日的兩次可預測性。敏捷意識到，軟體不是衝刺，而是一場馬拉松（是的，Scrum稱其為衝刺，這很諷刺）。它不是關於個人的生產力，而是關於滿足客戶的需求。

現在，如果你相信你已經最大限度地滿足了客戶的需求，唯一缺少的就是你每天多寫幾行程式碼，那麼你就真的是在一個快樂的地方。我是持懷疑態度的。

敏捷，以及在你的案例中聽起來像Scrum的東西，是以人為本的，是一種技能，需要培訓和有意的練習才能學會。

因此，要進入它的核心是，如何有效地做知識工作是超級反直覺的。成本是顯而易見的，但回報卻不是。你在一次設計會議上能獲得多少收益？基本上無法判斷。但成本是顯而易見的：工資。

為了給出一個公認的例子，我們可以轉向佇列理論。當你的利用率接近100%時，你的產出就會變成零。你的最佳利用率是80%左右。這是違反直覺的，因為如果你看到有人不做工作，你會認為這是一種浪費。但是，佔用這些時間會使你的速度減慢！你需要這些計劃外的時間來完成工作。你需要這些計劃外的時間來對意外情況作出反應。

因此，Scrum的所有會議都在做一個無聲的假設，即從這些會議中獲得的收益遠遠超過了會議成本帶來的低效率。我發現這絕對是可以證明的事實。規劃會議就是一個很好的例子。是的，它可能需要很長的時間，但作為一個團隊，通過走訪和任務分配來完成工作，為你的實際打字程式設計做準備。



 

相關文章