《啟示錄》流程篇：敏捷方法VS瀑布式開發(fā).jpg
一、合理運用敏捷方法
定義：敏捷方法是一種應對快速變化的需求的一種軟件開發(fā)能力（只適用于產品軟件，不適用于定制軟件）。相對于"非敏捷"，它更強調程序員團隊與業(yè)務專家之間的緊密協作、面對面的溝通(認為比書面的文檔更有效)、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟件開發(fā)中人的作用。敏捷方法包括Scrum和極限編程。
敏捷方法優(yōu)于瀑布式開發(fā)。
十大訣竅
- PM即是產品負責人，它代表了客戶需求，與開發(fā)溝通，協助督促開發(fā)進度，及時解決出現的問題。
- 敏捷環(huán)境里，規(guī)劃周期應該適度縮短，反復迭代，采用輕量級的機會評估方法（即產品原型圖），替代冗長的市場需求文檔。
- PM和設計師的工作進度，應該比開發(fā)團隊領先一兩個迭代周期。
- 盡量把產品設計工作拆分成獨立的部分，分而治之（但也不能拆得太細）。設計師必須加快工作速度，采用迅速制作原型的方法更適應敏捷環(huán)境。
- 用產品原型和用戶故事替代厚厚的產品需求文檔和功能說明文檔。好的原型可以提高估算工作量和開發(fā)時間的精度。
- 讓開發(fā)人員自主劃分迭代周期——因為有的產品功能可以在一個迭代周期完成，有的要好幾次迭代；開發(fā)團隊必須考慮產品的質量、性能、擴展性。
- 每日晨會，開始一天關于產品的溝通討論（PM和交互設計師必須出席）。
- 除非達到了PM的要求，否則不要輕易發(fā)布新版本；
- 每次迭代完成后，PM應該向團隊展示產品現狀（成果），及下次迭代的產品原型（加深大家對產品的理解，團隊的信心）。
- 團隊內開展敏捷培訓（需敏捷教練）。只有團隊成員都正確理解敏捷方法，PM才能把工作重心放在執(zhí)行上。
敏捷方法唯一不適合產品軟件團隊的地方，是在架構設計方面——敏捷方法相信簡單重構和快速重新設計架構的優(yōu)勢，這不適用于產品軟件。
注意：迭代初期的產品不能用作產品原型。
二、瀑布式開發(fā)方法
這是大多數團隊仍在使用的、最常見的開發(fā)方法，但并不好用。（很傳統(tǒng)）
- 定義：瀑布式開發(fā)方法也叫持續(xù)改進方法/里程碑式開發(fā)方法。它采用階段式開發(fā)，階段式評審。流程具有可預測性（但過于理想化，以為人們能預見所有問題、全面把握需求，除非是規(guī)模很小的項目，否則很難順利執(zhí)行），每個階段結束都會提交書面材料。
- 存在問題：產品驗證嚴重滯后，變更計劃代價不菲，無法適應快速的市場變化，交付時間通常比預期的晚，產品常常存在缺陷需要花大量時間和資金修補完善。
- 如果不得不使用瀑布式開發(fā)方法，需要在定義產品階段制作產品原型，請目標用戶試用，確保產品有價值可用可行。
