作者丨K L Krithika

編譯丨諾亞

在過去的幾年裡，Scrum的受歡迎程度明顯下降，尤其是那些親身經歷過該框架的低下效率的工程師們，越來越不喜歡它。

僵化的框架，在短時間的密集衝刺中執行，每個衝刺之後都有長時間的會議，正是它不受歡迎的原因。Scrum不能用於所有類型的項目，這就催生了更多的敏捷方法，如看板，XP（極限編程）和精益方法(Lean Methodology)等等。

Scrum的最初設計迎合了小型團隊，在將其應用於更大的項目時導致了一些複雜性。某種程度上，它只適用於範圍清晰、定義良好的項目。

1、為什麼Scrum不夠敏捷

有很多關於Scrum優缺點的文章，有些人信誓旦旦地說，「如果Scrum不適合你，那就是你做錯了!」，其他人則指出該論點的謬誤。Scrum的成功案例證明,明確的職責和分工有助於更好地協調和集中注意力。

當團隊可以致力於框架的角色、儀式和疊代性質時，Scrum運行良好。當團隊成員、利益相關者和客戶之間需要明確的責任和溝通時，Scrum比看板工作得更好，看板的任務分配不那麼嚴格。

問題在於Scrum的使用規模。雖然對該方法的優點有一些共識，但它並不適用於所有項目。工程師面臨的一個常見情況是，在構建多個應用程式的團隊中，在所有正在進行的故事完成之前，個人無法開始一個新的故事。已經完成任務的團隊成員一直處於空閒狀態，直到團隊每個人都完成了他們的故事，這完全是低效的。

長時間的會議是用戶的另一個痛點，在計劃和會議方面投入了大量資金。大量時間被耗費在用於討論有時只需要30分鐘即可完成的故事。只涉及兩個人的會議最終會波及整個團隊。

2、替代敏捷方法

看板是流行的敏捷方法之一。它是一個可視化的工作流程管理系統，專注於持續交付和靈活性。工作項在看板上表示為卡片，通過不同的開發階段進行。與Scrum的固定長度衝刺不同，看板允許連續的工作流程，沒有預定義的時間盒。

換言之，看板方法是連續不間斷的，而Scrum是不斷重複一個流程來達到疊代。看板方法更適合那些需要在開發周期中處理很多不確定的工作的團隊，通常用於突發請求、售後支持和優先級不斷變化的項目。與Scrum不同，看板沒有固定的角色或儀式，使其更適應不同的場景。

另一個流行的是XP（極限編程），它專注於工程實踐以提高軟體質量。它強調測試驅動開發、結對編程和頻繁發布等實踐。XP 鼓勵開發人員、測試人員和客戶之間的密切合作。

顧名思義，XP專注於軟體開發的技術方面，在實踐中常被那些採用其他敏捷框架的團隊揉和在各自的框架中去最大限度地發掘團隊成員的開發潛力。和看板方法一樣，極限編程也在追求減少浪費，專注於眼下的代碼開發而不是考慮明天的計劃或者下個月的安排等等。

Scrum強調角色之間的劃分，功能驅動開發（FDD）更專注於首席程式設計師，開發經理等。它適用於可以分解為明確定義的功能的項目。FDD以增量方式構建軟體為中心，專注於特定於客戶需求的功能或用例。它使用功能列表來指導開發。

即使有種種缺點，Scrum仍然非常受歡迎。大約56%的公司使用Scrum作為獨立方法，其中約83%的公司將其與XP或看板或其他敏捷方法一起使用為混合模型。

最近，不得不注意到有些變化也在悄然發生。今年年初，美國第一資本投資國際集團（Capital One）解僱了整個敏捷部門，將這些角色合併到現有的產品經理中。Scrum Master監督團隊的時代很可能會悄然逝去，而企業可能會在團隊中接受敏捷實踐，或者選擇類似於Capital One實施的模型。

參考連結：https://analyticsindiamag.com/scrum-is-not-agile-enough/