在產品開發過程中，敏捷開發和瀑布模型都是常用的流程和開發方法，這兩種方法是什么？細節是什么？這篇文章，為我們進行了解答。

成本、時間和質量是項目管理的鐵三角，項目管理的核心目標是平衡好這三者之間的關系，盡量確保軟件項目能夠在可控的成本范圍之內，符合質量要求地按期交付。

這里的質量我覺得包含了兩方面：

1. 功能的完成度與穩定性；
2. 用戶需求的滿足程度。

在一些大型項目的交付過程中，面對交付過程中頻繁變化的需求，按照既定合同內的需求以瀑布模式開發，雖然能發揮瀑布開發的優勢，但在用戶需求滿意度方面肯定會有所損失，更嚴重的會導致返工改造、驗收不通過。

相對“瀑布”模式的重，“敏捷開發”是一種應對頻繁需求變化、快速響應的輕量開發模式，在以“瀑布模式”開發的項目中，將“敏捷”的理念引入，發揮各自優勢，會對整個項目順利的交付起到積極的作用。

本篇先講下“敏捷開發”與“瀑布開發”的工作流程、適用場景、各自優缺點，然后將二者融合，談一下在實際項目交付過程中的應用思考。

一、瀑布模式

瀑布模式是一種經典的線性開發模式，在傳統的軟件項目交付過程中被大量使用。

瀑布模式的整個項目周期是確定的，按照項目開發的時間可以分為規劃階段、需求分析階段、軟件設計階段、編碼階段、測試驗收階段、上線階段運維階段等若干里程碑。

下面這張圖生動地描述了瀑布開發的模式：

客戶需要一輛代步工具，需要按照事先規劃的方案，經過漫長的研發，最終給客戶交付一輛汽車。

前期的方案是足夠好，但在此過程中客戶無法盡早體驗產品，最終交付后產品可能不是客戶實際想要的，從這個角度看風險很高。

一個典型的瀑布模式的產品研發流程

適用場景：

瀑布模式比較適合需求比較清晰的項目開發，比如簽訂合同的項目制交付，一般情況下合同內的需求都是確定的，乙方按照合同內的需求，按時交付即可。

理論上需求和設計方案確定后，在開發過程中需要嚴格執行，需求變動需要執行變更流程，或者另簽一個補充協議。

優點

1. 由于需求相對比較明確，在前期可以對系統整體架構、擴展性進行整體、全面的設計；
2. 團隊的目標相對明確，按照里程碑節點順序推進，向目標前進的效率會比較高，易于管理和監督；
3. 每個階段投入的人力不同，不同崗位的人員可以分批投入項目。

缺點

• 對業務需求的快速變化，靈活性不足，尤其是對于處于摸索階段的新業務，這種變化是不可避免。
• 比如系統試運行、業務推進過程中會產生很多新的需求，我們之前按照合同內需求規劃的設計可能要推翻或者有較大的修改，尤其在項目中后期，很可能將會導致項目延期，超出合同成本預算。
• 由于產品從研發到上線是一個線性的推進過程，在此期間客戶沒有真正看到過、體驗過產品，最后上線，客戶很可能對最終的產品不滿意，重新改造的成本較高。

二、敏捷模式

敏捷模式是針對瀑布模式太重提出的一種小步迭代、快速反饋的開發模式，能有效的提高軟件的開發效率，應對市場的快速變化。

下面這張圖生動地描述了瀑布開發的模式。

客戶想要一輛代步工具，為了快速滿足可以出行的需求，按照敏捷的理念會先提供滑板、然后通過快速迭代逐步提供自行車、摩托車、小汽車。

在此過程中將產品快速投入市場，根據市場反饋，調整方向，雖然一開始提供的不是最優解決方案，但是一直在正確的方向上前進，不至于跑偏。

敏捷的核心關鍵詞包括快速響應、迭代、增量交付、漸進式、面對面溝通、快速反饋與調整等。

敏捷項目管理通常采用Scrum敏捷框架進行實施，以固定時間盒的方式快速迭代，在實踐中比較常用的是雙周迭代的模式，在一個沖刺內完成增量開發的交付。

“增量開發主要是一塊接著一塊地構建一個系統。一部分功能先被開發出來，然后另一部分功能被加入前一部分功能，以此類推?！?/p>

《敏捷宣言》中的價值觀：

個體和互動高于流程和工具；

工作的軟件高于詳盡的文檔；

客戶合作高于合同談判；

響應變化高于遵循計劃。

Scrum作為一個輕量級的團隊協同工作方式，一個沖刺從開始準備到完成主要由以下幾個關鍵活動組成：

1. 需求梳理，挑選需求并編寫需求說明

一般由產品經理在沖刺開始之前從Product Backlog(類似需求池，Scrum中叫Product Backlog）中按照優先級挑選在本次沖刺（Sprint）內需求（這些需求可能為特性、用戶故事、缺陷等，在Scrum中被稱為PBI）。

產品負責人和開發團隊要對當前沖刺準備實現的需求及沖刺目標達成一致意見，在此期間產品負責人需要完成產品方案、編寫需求說明，并與需求方確認。

2. 需求澄清會（沖刺計劃）

產品經理將當前Sprint中的需求向研發團隊澄清，在澄清的過程中可以根據實際情況對需求的范圍、方案進行調整。

每個需求澄清完畢，具體模塊的研發人員可對需求的進行工作量的估算（故事點、規劃撲克牌具體的估算方法這里不再具體說明）。

如估算的工作量過高，研發人員需要說明原因，最終會議結束確定本沖刺內交付范圍，正式開啟沖刺。

3. 任務分解

一般需求澄清回后，開發人員會將每個需要完成的需求（特性）分解成一組任務，這組任務及相關的PBI組成了“沖刺列表”，開發團隊給出完成每項任務所需工作量的估算值（通常以小時計）。

4. 沖刺執行（開發實施與測試）

在團隊沖刺的內容達成一致意見后，研發團隊需要根據產品方案進行技術方案的設計，執行為了完成特性而所需的所有任務開發的工作。

5. 每日例會

在沖刺開始的每一天，研發團隊會每天早上進行站會（通常不會超過15分鐘）。

團隊成員每天輪流回答下面三個問題，昨天我完成了什么？今天計劃做什么工作？有什么障礙讓我無法取得進展？

通過每日站會，每個人都能了解全局，知道發生了什么，沖刺目標的進展如何，是否需要幫助團隊解決一些問題，實現一個沖刺內快速、流動的工作流。

6. 沖刺評審

沖刺周期的后期，團隊給產品負責人和其他業務需求干系人、客戶演示完成的成果，讓各方了解已經交付的增量，檢視和調整產品，同時業務互相交流，收集反饋并及時調整。

7. 沖刺回顧會

沖刺回顧會是檢視并調整過程的時機，開發團隊、產品負責人、ScrumMaste一起討論，在上個沖刺中哪些過程是需要改進的。

需要注意的是沖刺回顧會不是吐槽、追責的會議，目的是幫助Scrum團隊成長、下一個沖刺能夠持續的改進。

適用場景

敏捷項目管理適用于業務需求變化頻繁、比較適合創新型項目、市場需求變化快速的項目，主打一個“快速迭代”，在一些互聯網公司、自研產品的公司比較常用。

優點

能夠快速響應變化、提高客戶滿意度、減少項目風險，同時還能提高團隊協作能力、加快產品上市時間。

缺點

對于一些成熟業務，由于追求快速響應，前期在系統架構設計上并不一定那么完美，另外對團隊協作能力、敏捷理念的認可度要求比較高。

三、在項目交付過程中的思考

在實際的項目交付過程中甲乙雙方立場的不一樣，甲方期望乙方能在合同周期內盡可能多的滿足需求，解決更多問題，而乙方期望能控制成本，如期交付，迫于甲方交付驗收的壓力，又不得不接受頻繁的需求變更。

從實際經驗來看，有如下原因將導致成本、質量、時間陷入三難的境地。

外部原因：

• 甲方業務比較新，存在邊用邊發現新問題的情況，合同外的、變更需求時有發生；
• 甲方不配合，如不配合調研、系統使用不積極、不提供數據等等；
• 實施過程中非研發類工作耗費太多時間，如數據處理、甲方匯報文件、配合業務開展等臨時性工作安排、業務代運營等。

內部原因：

1. 合同簽訂前銷售的對需求的過渡承諾，初設方案的不完善；
2. 系統規劃設計階段對整體應用架構、技術架構設計的不合理；
3. 需求分析不合格，設計出來的系統未能徹底解決甲方的問題，導致重復返工、打補??；
4. 缺乏有效的項目管理流程，多人協作變得混亂失控，缺少風險跟蹤，研發過程變得脆弱，導致研發效率和質量不高。

原因很多，本篇僅從項目管理的角度探討，如何平衡成本、質量、時間的矛盾，達到甲乙雙方共贏的目的。

有一種方式我叫做“大瀑布下的小敏捷”，將“敏捷開發”與“瀑布開發”相結合，發揮各自的優勢，是一個實際可用的手段。

“大瀑布下的小敏捷”既能夠按照“瀑布模式”的里程碑節點，交付目標相對明確，又能發揮“敏捷開發”快速響應需求的變化、持續交付的優勢，提升客戶滿意度。

在大的項目周期內有明確的啟動、需求調研、系統設計、編碼開發、上線交付的里程碑節點，整體上看是瀑布模式的開發。

對于實際交付過程中頻繁變更的新需求和合同內的老需求統一放進“產品代辦清單”（Product Backlog），按照敏捷開發的模式拆分成一個個固定時間盒的沖刺，當下的沖刺內為優先級最高的需求，通過一個個沖刺完成增量產品的交付，直至項目交付。

敏捷開發是為了讓團隊達成一種在固定時間內持續交付的共識，一般一個沖刺開始時，該沖刺內的需求一般不允許變更。

但有些特殊情況，為了配合甲方匯報（一些G端項目常見），這些臨時需求優先級會變得非常高。

此時研發團隊可能正處在當前沖刺的開發中，不得不將主要精力投入配合匯報。

無論“敏捷開發”還是“瀑布開發”，流程是死的，人是活的，不同的公司、不同的業務可以根據實際情況靈活調整，切不可生搬硬套。

參考資料：《Scrum精髓》