全面解析瀑布式開發和敏捷式開發
很多人畢業後，都在從事跟所學專業不同的工作，有的人一籌莫展，有的人習以爲常。
我是一名編導生，畢業後去做抗戰紀錄片，工作中接觸更多的是曆史、影像與表達。但一個偶然的契機，讓我轉戰 向 互联网産品行业，工作中对接的是産品经理、開發和測試，用户画像、CDN 、 UV 、 PV 等一大堆新概念也扑面而来。后来又从産品逐渐深入到軟件行业，有朋友认为这是新世界的大门；也有朋友觉得这是當下社会的缩影，各行各业的发展牵动着人性的各种追求与欲望，毕竟人们总想要追求新事物。于我而言，每天推陈出新，不断收获，享受當下就好，然而，接纳新事物其实没那麽简单。
最開始接觸軟件行業，最常聽到的就是瀑布式開發、敏捷開發，于是心裏就有了疑問，我翻閱了各大網站查找相關的資料，去B 站上觀看圖文結合的相關視頻， 結合自己的理解，以剛入行的視角現給大家整理了一份有關敏捷式開發與瀑布式開發的概念解析。
參考資料推薦： 禅道官網、 CSDN博客、 B站視頻
一、什麽是瀑布式開發
瀑布式開發的基本流程是 需求 → 設計 → 開發 → 測試 ， 是一個更傾向于嚴格控制的管理模式 。 要求有明確的需求，大家按照需求一步步做好規劃，每一階段工作的完成是下一階段工作開始的前提，每一階段都要進行嚴格的評審，保證各階段的工作做得足夠好時才允許進入下一階段。這種模式一般適用于需求比較明確、to B 端的項目。
不得不說瀑布項目失敗率會比較高，因爲它有一個很大的缺陷， 就是受各種條件的制約。当産品研发完成后， 到了産品測試阶段 萬一發現問題 ，或者發現其無法滿足市場需求， 那麽就需要重新開發，甚至需要重新规划産品，这 間接导致了産品延期发布的高发性 與不確定性。
微軟 的瀑布式開發模式就是个很好的例子。随着用户对軟件的需求越来越苛刻，微軟的軟件産品曾经遭受了大家的不满，原因并非是産品的使用问题，而是其更新周期太过漫长 。 比如微軟Office 、 Windows 等主打産品的更新周期长达 3 年左右，軟件延期发布实属家常便饭，此时微軟的瀑布式開發模式已经难以满足新型軟件的開發要求，不得不改变産品的研发策略。
隨著網絡的逐漸興起，軟件交付模式發生了巨大變化，也正是在 那 個時候，“敏捷開發”模式被國外的軟件先行者们探索出来了。
二、什麽是 敏捷 式 開發
简单的说，敏捷開發是一种以用户需求进化为核心、迭代、循序渐进的開發方法。首先把 用戶（客戶 ）最關注的軟件原型做出來，交付或上線，在實際場景中去 快速 修改彌補需求中的不足，再次發布版本。通過一些敏捷實踐方式，細化story ，提供更小的迭代。如此循环，直到用戶（客戶）满意。适用于需求不明确、创新性或者需要抢占市场的项目。
还是拿微軟来说，微軟的Visual Studio 2010是公司内部首个因敏捷開發模式而受益的Visual Studio版本，该軟件发布于2010年4月，耗费了两年的时间完成開發，但随后研发团队发现軟件中的许多模板对于敏捷開發者来说太过笼统，几乎没有太大的实际意义，微軟的軟件研发策略也就从此开始发生了巨大变化。以往的産品更新周期为两到三年，目前的版本更新速度已经缩短至一个季度左右，这在瀑布式開發模式下是难以想象的。
敏捷式開發在 國外大放異彩， 當然在國內也不例外，國內很多研發者們結合 當下軟件市場環境，也有了新的研發策略。
国产开源的禅道項目管理軟件，2009 年開始 遵循Scrum （ 敏捷式開發中比较流行的一种方式）的管理思想，發布了第一個 産品版本 。自發布以來，禅道 连续四年荣膺国内外軟件測試行业最常用測試管理工具第一名 ，也算是國産軟件 的驕傲了。
在産品開發过程中， 禅道 研發團隊認爲Scrum方法 雖然 注重实效，操作性强，非常适合軟件研发项目的快速迭代開發 ， 但它只規定了核心的管理框架，還有很多細節流程沒有完善。于是禅道團隊結合國內研發現狀，整合了bug管理、測試用例管理、发布管理、文档管理等功能，完整的覆盖了軟件研发项目的整个生命周期。在禅道軟件中，明确将産品、项目、測試三者概念区分开，産品人员、開發团队、測試人员，三者分立，互相配合，又互相制约，通过需求、任务、bug来进行交相互动，终通过项目拿到合格的産品，是敏捷式開發的优秀案例。
（禅道軟件界面图）
三、瀑布式開發与敏捷式開發对比
|
|
瀑布式開發 |
敏捷式開發 |
|
工作方式 |
1.重视和强调过程文档，以文档驱动项目,将軟件项目開發周期严格划分为几个固定阶段（需求分析，系统設計，軟件設計，编码，測試，交付），每个阶段结束都有对应的详细文档作为输出；
2.上一个阶段的输出就是下一个阶段的输入,直至完成整个開發流程。
|
1.更加强调人的协作（团队之间，客戶与团队之间），在高度协作的环境中使用迭代方式进行增量開發；
2.客戶可对每次迭代的成果提出修改意见，開發人员进行调整和完善；
3.进行多次迭代直至完成完整産品交付。
|
|
優點 |
1.每個階段目的明確，階段人員完全專注于該階段的工作，有助于提高階段效率；
2. 由于存在详细的过程文档，在早期就能明确出项目的范围和概况，能够更有效的组织和调配资源开展项目。
|
1.阶段性成果可以在開發过程中被客戶查验，从而降低项目開發的风险性；
2.靈活性高，需求的變更可在任何時候進行。
|
|
缺點 |
1.開發过程中大量的文档，极大的增加了工作量；
2.项目后期才能展示成果给客戶，增加了项目開發的风险
（例如项目最终与客戶预期差别很大，若要修复会造成项目的延期和成本增加）；
3.需求變更的成本較高
（需求的變動理論上也會嚴格按照各個階段去實施,導致時間成本過高）
|
1.最終交付的內容無法預測，預期和實際完成的內容經常會有很大差異；
2.敏捷需要高水平的协作以及開發人员和用户之间的定期沟通。业务和IT人员在沟通前需要做大量的准备工作，但很多情况下业务的沟通时间无法保证。
|
|
適用項目 |
軟件需求十分明确并且不会有频繁变化的项目 |
需求不明確、具創新性或者需要搶占市場的項目 |
很显然，敏捷式開發与瀑布式開發有着质的区别，但总的来说，在管理项目过程中，都不会严格的按照完全的敏捷或者完全的瀑布模式进行開發，而是各自掺杂了其他的方式。可见，項目管理过程中，过于强调模式并没有意义，重要的是要能预防问题的发生，在问题发生之后，能用最小的成本解决，模式起到的更多是一個参考作用。
接受新事物的過程雖說不易，但每天有所收獲是件多麽幸運的事兒啊。但願不論何時的我們，都擁有一顆擁抱新事物的心，對這個世界永遠保持好奇，這樣我們就不會變老吧。
