為什麼Scrum變得不那麼重要了？ - LogRocket

Scrum的目的是什麼？
Scrum 應該是關於定義一個可實現的兩週衝刺目標。Scrum 應該鼓勵團隊從經驗中學習，在解決問題的同時自組織，並反思他們的得失以不斷改進。
根據我的經驗，不幸的是，Scrum 最終破壞了敏捷的核心原則，即人高於流程。這在很大程度上歸結為管理不善和經過認證的 Scrum Master 的興起。
 

站立會議是為管理者準備的
每日 Scrum 應該是一個 15 分鐘的、有時間限制的活動，供開發團隊計劃接下來的 24 小時。不幸的是，站立會議已成為關注 JIRA ticket全面移動的媒介。在一組泳道上移動icket有點像將程式碼行數作為成功的衡量標準。開發人員可以僅僅因為他們移動工單的速度有多快而顯得富有成效。另一方面，對董事會的關注會使處理具有挑戰性的問題的優秀開發人員看起來很普通。
 

自組織團隊
如果做得好，Scrum 鼓勵團隊從經驗中學習，在解決問題的同時自組織，並反思他們的得失以不斷改進。
在臭名昭著的 scrum master 所提倡的 scrum 中，您需要清除tickets，而且也沒有對工作質量進行實際檢查，這往往是由非技術專案所有者決定的。這會激勵人們進入空靈狀態並專注於輸出程式碼。
 

神話般故事點不是神話
故事點是用於表達對完全實施產品待辦列表項所需的總體工作量的估計的度量單位。或者，至少，他們應該是這樣定義。
根據我的經驗，故事點可以鼓勵團隊對系統進行遊戲。在幾次衝刺中都未能實現目標後，精明的專案經理會害怕在衝刺中投入太多。
對失敗的恐懼導致了小故事衝刺，其中只使用小票tickets專案以確保它們的完成。大局變得無關緊要，專注於小事最終會使專案脫軌。
我在一個專案中親眼目睹了這一點，其中每個故事都必須進行自動化測試。這些測試伴隨著高昂的維護預算，而該專案的自動化測試使開發速度幾乎停滯不前。當自動化測試成為焦點時，將開發和維護過程調整到兩週的視窗中將持續整合構建時間升級到兩個小時。管道停頓，被迫改變。
另外一個極端：開發人員和測試人員在累積技術債務的同時偷工減料。債務永遠無法償還，旋轉的盤子最終會掉到地上，導致大規模且代價高昂的重新思考。
我們應該跟蹤完成的工作而不是我們估計的工作，而不是依賴故事點。我覺得這令人震驚。如果我想知道類似的工作需要多長時間，我想知道實際時間而不是估計時間。如果您的所有故事都足夠小，那麼您就不需要估算。
 
Scrum 的前提不應該是一個千篇一律的工具適合地球上的每個開發團隊。許多團隊只是死記硬背，而其有效性的證據為零。讓優秀的開發團隊根據他們的環境自組織。跟蹤什麼被運送到生產中，在事後加上它花費的時間（以天為單位！），並跟蹤它。