Scrum vs Waterfall vs Agile vs Lean vs Kanban

軟件開發行業有許多不一樣的方法 - 一些是舊方法的新方法，另外一些方法採用了相對較新的方法。該領域中最經常使用的兩種方法是敏捷，如Scrum，Kanban和Lean等，以及傳統的瀑布模型，如結構化方法或更新的RUP。

大多數遵循這兩種模式的軟件公司都認爲他們選擇的方法在方面是優越的，因此在咱們回答這個問題以前，「哪個更成功？咱們應該看看它們的主要區別。

瀑布方法

瀑布是軟件開發過程的線性方法。這些都表明了軟件開發的一個獨特階段，每一個階段一般在下一個階段開始以前完成。每一個開發階段之間一般也有一個里程碑。

• 結構化爲順序過程當中的一個大項目
• 適合變化不常見的狀況
• 一個須要預先明肯定義的需求的流程

所以，瀑布模型保持只有在檢查並驗證其前一階段時才應移動到階段，以下圖所示：

例如：

在Royce的原始瀑布模型中，按順序遵循如下階段：

• 系統和軟件要求：在產品需求文檔中捕獲
• 分析：產生模型，架構和業務規則
• 設計：產生軟件架構
• 編碼：軟件的開發，證實和集成
• 測試：缺陷的系統發現和調試
• 操做：完整系統的安裝，遷移，支持和維護

敏捷方法

敏捷使用精益思想衍生出來，在信息技術環境中應用「精益」概念。精益方法的關鍵重點是：

• 消除流程中的浪費
• 最大限度地減小業務非增值活動
• 從消費者的角度最大化附加值

敏捷方法是通過驗證的項目管理方法，它鼓勵如下關鍵概念：

• 常常檢查和調整
• 鼓勵團隊合做，自我組織和問責制的領導哲學
• 一套工程最佳實踐，能夠快速交付高質量的項目
• 一種將開發與客戶需求和公司目標相結合的業務方法

敏捷開發 - 迭代生命週期

敏捷開發階段包括傳統規劃，分析需求，設計，編碼，測試和部署，但它們造成一個循環而不是一條線。這意味着流程靈活，可重複，能夠按任何順序和並行發生。這容許收集用戶反饋，針對不一樣環境的連續測試以及在運行時更改項目的範圍。

敏捷方法的基礎

• 經驗主義 - 可以在逐步提升生產力的過程當中執行，中止，反思，改進和繼續
• 肯定優先級 - 根據業務價值提供工做
• 自組織 - 團隊最瞭解如何根據資源和約束提供工做
• Time-Boxing - 團隊須要在規定的時間內完成指定的任務。
• 協做 - 團隊承諾在給定的時間內交付最終產品，這將鼓勵跨團隊協做和完成任務的首創性。

敏捷與瀑布 - 範圍，時間和成本三角

瀑布方法的最大優點是固定成本和可預測性。你知道價格，何時交付。其最重要的弱點是其缺少靈活性。敏捷方法很是靈活，能夠演變成與最初設想的產品大相徑庭的產品。

傳統的瀑布方法創建在時間，成本和範圍三重約束的基礎上。調整這些變量中的任何一個都會強制改變至少其中一個變量。交付成功的項目取決於平衡這三個競爭變量。但正如咱們所知，簡單地爲項目添加資源並不總能帶來預期的目標。事實上，若是在軟件項目的後期添加資源，它實際上會產生不利影響。

敏捷方法採用不一樣的方法，將三重約束顛倒過來。敏捷方法不是將範圍視爲一開始就是固定的，而是將時間（迭代）和成本（團隊成員）設置爲固定; 而後調整範圍以關注最高優先級。創建敏捷是由於指望範圍會隨着時間的推移而發展。目標是在預算成本和時間內知足客戶最重要的要求。隨着項目的進展，敏捷容許新的需求或從新肯定優先級。

敏捷仍是瀑布？見圖

Standish Group的最新報告涵蓋了他們在2013年至2017年間研究的項目。在這段時間內，敏捷和瀑布的成功，挑戰和失敗的總體突破以下所示，敏捷項目成功的可能性大約是後者的2倍，失敗的可能性下降1/3。

（來源：vitalitychicago.com - 比較瀑布和敏捷項目成功率）

敏捷方法傘

自2001年「敏捷宣言」誕生以來，敏捷就有不少嗡嗡聲。事實上，敏捷方法只是一種思惟方式，可使團隊和組織進行創新，快速響應不斷變化的需求，同時下降風險。組織能夠靈活地使用許多可用的框架，如Scrum，看板，精益，XP等等。

精益方法

精益組織瞭解客戶價值，並關注其關鍵流程以不斷提升客戶價值。最終目標是經過一個零浪費的完美價值創造過程爲客戶提供完美的價值。

5步精益方法

指導精益方法實施的五步思考過程很容易記住，但並不老是很容易實現：

1. 從最終客戶的角度按產品系列指定值。
2. 肯定每一個產品系列的價值流中的全部步驟，儘量消除那些沒法創造價值的步驟。
3. 使價值創造步驟按順序進行，使產品順利流向客戶。
4. 隨着流量的引入，讓客戶從下一個上游活動中獲取價值。
5. 在指定值時，識別值流，刪除浪費的步驟，引入流和拉，再次開始流程並繼續，直到達到完美狀態，其中建立完美值而沒有浪費。

Scrum方法

Scrum是一種管理項目的敏捷方式，一般是軟件開發。使用Scrum進行敏捷軟件開發一般被視爲一種方法論; 但不是將Scrum視爲方法論，而是將其視爲管理流程的框架。

看板方法

看板是日本的「視覺信號」或「卡片」。豐田線路工人使用看板來表示製造過程當中的步驟。做爲精益的一部分，該系統的高度視覺性使得團隊能夠更輕鬆地溝通須要完成的工做和什麼時候完成。它還標準化了線索和精煉過程，有助於減小浪費和最大化價值。與scrum sprint board相似，看板跟蹤「作 - 作 - 完成」活動，但它限制了「正在進行的」活動的數量（該數量由團隊經理定義，不能超過）。

有四個基本的看板原則：

• 可視化工做以增長溝通和協做。
• 限制正在進行的工做，以免無限的非優先打開任務鏈。
• 衡量和優化流量，收集指標，預測將來問題。
• 旨在經過分析得到持續改進。

初學者的其餘Scrum指南

• 綜合Scrum指南
• 什麼是Scrum團隊？
• 什麼是Scrum工件？
• 什麼是5個Scrum值？
• 敏捷宣言和十二項原則
• Scrum中最常常提到的10個基本規則
• 什麼是Scrum的三大支柱？