引子
昨日和朋友討論了一些關於開發模式的問題。之前曾糾結於對敏捷開發來講，文件是應該幾乎不存在的東西，因為敏捷的核心似乎是擁抱變化，encourages to be rapid and flexiable. 而在這其中，文件屬於最“重”的東西，應該是被快速的站會所取代的。而瀑布流恰恰相反，完整的文件記錄，嚴格的設計，開發，測試流程是對於我來講的第一印象。但我在公司中看到的實際是，大家在PRD中寫的是敏捷下的Story List，整體的開發流程卻更像是瀑布流：有著嚴格的設計、稽核、開發流程。
因此，我在思考一個問題，公司裡到底是敏捷還是瀑布流？為什麼會有兩種形式並存的狀況？
敏捷 (Agile)
Agile software development is an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s).
--- wikipedia
從定義來看，重點在於需求或解決方案不確定的狀態下，通過敏捷的開發方法來完成專案。所以說，這其中的文件也好，站會也好，都只是實現這一目的方法，而非必要的條件。對於中大型公司來講，由於專案規模通常會越來越大，需要有很強的擴充性，所以良好的文件對於以後的發展來說是必要的。同時，清晰的文件也有利於以後對於開發流程上的反思和迭代，通過強化流程來縮小人員帶來的不確定性和風險，進而減小錯誤發生的概率。這應該是公司理想的狀態，即任何人都可以替換。
瀑布流(waterfall)
The waterfall model is a relatively linear sequential design approach for certain areas of engineering design. In software development, it tends to be among the less iterative and flexible approaches, as progress flows in largely one direction ("downwards" like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance.
-- wikipedia
重點在於單向性，即更少的迭代和靈活性。與敏捷相反，瀑布流所適應的場景多為需求或解決方案較為確定的情況下，我的想象中更像B端產品的開發模式（常見的如各類軟體開發商或外包）。
根據我的經驗來講，還有一種情況可能也會用到瀑布流，就是research方面較重的時候，很難迭代起來，至少在初期的時候是這樣。例如，開發涉及到ML方面的模型時，我們需要把各個模型一點一點的開發訓練出來，這一塊是順序性的，而且初期的建設很費時間，就只能先做好一個計劃，一步一步地來進行開發了。當然，到了後期模型完全建立好，最小价值產品（MVP）已經產出的時候，其實就可以開始進行快速的迭代了。對於模型方面來講，常見的迭代即為調整引數，融合新的模型這種能相對較快地出結果的東西。
總結
- 開發模式無所謂好壞，總有一些人會覺得瀑布流過於老舊，敏捷才是王道。其實非也，我們更應該從需求和質量控制能力出發，看看我們的需求是否是明確的，質量控制是否有很高的要求，再來做決定。
- 敏捷=996？，我個人認為敏捷是一種模式，而非是工作方式，所以朝九晚五也可以敏捷，996並不一定能帶來更高的團隊進度效率，這是PM和管理人員個人能力的問題，也取決於業務的競爭壓力
- 敏捷!=無文件，尤其對於大公司和網際網路這種迭代註定很多的公司來講，文件有助於今後的發展，同時也能夠有效抵消人員流動性比較大的問題，所以敏捷下仍應該有文件
- 敏捷可以與瀑布流並存，上課的時候我們的tutor是一位有幾十年開發管理經驗的IT顧問，他跟我們的建議是，模型和後端部分可以做瀑布流，前端可以做敏捷來不斷地滿足客戶的需求。我認為這是一個很不錯的點子，團隊可以根據不同部分的需求變化頻率來部署不同型別的模式，而不是要讓敏捷與瀑布流“你死我活”。