【PM】關於敏捷，瀑布流，文檔

引子

昨日和朋友討論了一些關於開發模式的問題。以前曾糾結於對敏捷開發來說，文檔是應該幾乎不存在的東西，由於敏捷的核心彷佛是擁抱變化，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顧問，他跟咱們的建議是，模型和後端部分能夠作瀑布流，前端能夠作敏捷來不斷地知足客戶的需求。我認爲這是一個很不錯的點子，團隊能夠根據不一樣部分的需求變化頻率來部署不一樣類型的模式，而不是要讓敏捷與瀑布流「你死我活」。