在產(chǎn)品開發(fā)過程中，敏捷開發(fā)和瀑布模型都是常用的流程和開發(fā)方法，這兩種方法是什么？細(xì)節(jié)是什么？這篇文章，為我們進(jìn)行了解答。

成本、時(shí)間和質(zhì)量是項(xiàng)目管理的鐵三角，項(xiàng)目管理的核心目標(biāo)是平衡好這三者之間的關(guān)系，盡量確保軟件項(xiàng)目能夠在可控的成本范圍之內(nèi)，符合質(zhì)量要求地按期交付。

這里的質(zhì)量我覺得包含了兩方面：

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

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

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

本篇先講下“敏捷開發(fā)”與“瀑布開發(fā)”的工作流程、適用場景、各自優(yōu)缺點(diǎn)，然后將二者融合，談一下在實(shí)際項(xiàng)目交付過程中的應(yīng)用思考。

一、瀑布模式

瀑布模式是一種經(jīng)典的線性開發(fā)模式，在傳統(tǒng)的軟件項(xiàng)目交付過程中被大量使用。

瀑布模式的整個(gè)項(xiàng)目周期是確定的，按照項(xiàng)目開發(fā)的時(shí)間可以分為規(guī)劃階段、需求分析階段、軟件設(shè)計(jì)階段、編碼階段、測試驗(yàn)收階段、上線階段運(yùn)維階段等若干里程碑。

下面這張圖生動(dòng)地描述了瀑布開發(fā)的模式：

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

做到这三点挑战，产品经理只会不断升值

好的产品经理是很稀缺的，懂用户、懂商业、懂数据的产品经理走出互联网，依然是抢手货。相反，如果只做简单传话、低效执行、浅层思考的产品经理，恐怕走不过未来3-5年的洪流。

查看详情 >

前期的方案是足夠好，但在此過程中客戶無法盡早體驗(yàn)產(chǎn)品，最終交付后產(chǎn)品可能不是客戶實(shí)際想要的，從這個(gè)角度看風(fēng)險(xiǎn)很高。

一個(gè)典型的瀑布模式的產(chǎn)品研發(fā)流程

適用場景：

瀑布模式比較適合需求比較清晰的項(xiàng)目開發(fā)，比如簽訂合同的項(xiàng)目制交付，一般情況下合同內(nèi)的需求都是確定的，乙方按照合同內(nèi)的需求，按時(shí)交付即可。

理論上需求和設(shè)計(jì)方案確定后，在開發(fā)過程中需要嚴(yán)格執(zhí)行，需求變動(dòng)需要執(zhí)行變更流程，或者另簽一個(gè)補(bǔ)充協(xié)議。

優(yōu)點(diǎn)

1. 由于需求相對比較明確，在前期可以對系統(tǒng)整體架構(gòu)、擴(kuò)展性進(jìn)行整體、全面的設(shè)計(jì)；
2. 團(tuán)隊(duì)的目標(biāo)相對明確，按照里程碑節(jié)點(diǎn)順序推進(jìn)，向目標(biāo)前進(jìn)的效率會比較高，易于管理和監(jiān)督；
3. 每個(gè)階段投入的人力不同，不同崗位的人員可以分批投入項(xiàng)目。

缺點(diǎn)

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

二、敏捷模式

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

下面這張圖生動(dòng)地描述了瀑布開發(fā)的模式。

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

在此過程中將產(chǎn)品快速投入市場，根據(jù)市場反饋，調(diào)整方向，雖然一開始提供的不是最優(yōu)解決方案，但是一直在正確的方向上前進(jìn)，不至于跑偏。

敏捷的核心關(guān)鍵詞包括快速響應(yīng)、迭代、增量交付、漸進(jìn)式、面對面溝通、快速反饋與調(diào)整等。

敏捷項(xiàng)目管理通常采用Scrum敏捷框架進(jìn)行實(shí)施，以固定時(shí)間盒的方式快速迭代，在實(shí)踐中比較常用的是雙周迭代的模式，在一個(gè)沖刺內(nèi)完成增量開發(fā)的交付。

“增量開發(fā)主要是一塊接著一塊地構(gòu)建一個(gè)系統(tǒng)。一部分功能先被開發(fā)出來，然后另一部分功能被加入前一部分功能，以此類推。”

《敏捷宣言》中的價(jià)值觀：

個(gè)體和互動(dòng)高于流程和工具；

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

客戶合作高于合同談判；

響應(yīng)變化高于遵循計(jì)劃。

Scrum作為一個(gè)輕量級的團(tuán)隊(duì)協(xié)同工作方式，一個(gè)沖刺從開始準(zhǔn)備到完成主要由以下幾個(gè)關(guān)鍵活動(dòng)組成：

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

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

產(chǎn)品負(fù)責(zé)人和開發(fā)團(tuán)隊(duì)要對當(dāng)前沖刺準(zhǔn)備實(shí)現(xiàn)的需求及沖刺目標(biāo)達(dá)成一致意見，在此期間產(chǎn)品負(fù)責(zé)人需要完成產(chǎn)品方案、編寫需求說明，并與需求方確認(rèn)。

2. 需求澄清會（沖刺計(jì)劃）

產(chǎn)品經(jīng)理將當(dāng)前Sprint中的需求向研發(fā)團(tuán)隊(duì)澄清，在澄清的過程中可以根據(jù)實(shí)際情況對需求的范圍、方案進(jìn)行調(diào)整。

每個(gè)需求澄清完畢，具體模塊的研發(fā)人員可對需求的進(jìn)行工作量的估算（故事點(diǎn)、規(guī)劃撲克牌具體的估算方法這里不再具體說明）。

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

3. 任務(wù)分解

一般需求澄清回后，開發(fā)人員會將每個(gè)需要完成的需求（特性）分解成一組任務(wù)，這組任務(wù)及相關(guān)的PBI組成了“沖刺列表”，開發(fā)團(tuán)隊(duì)給出完成每項(xiàng)任務(wù)所需工作量的估算值（通常以小時(shí)計(jì)）。

4. 沖刺執(zhí)行（開發(fā)實(shí)施與測試）

在團(tuán)隊(duì)沖刺的內(nèi)容達(dá)成一致意見后，研發(fā)團(tuán)隊(duì)需要根據(jù)產(chǎn)品方案進(jìn)行技術(shù)方案的設(shè)計(jì)，執(zhí)行為了完成特性而所需的所有任務(wù)開發(fā)的工作。

5. 每日例會

在沖刺開始的每一天，研發(fā)團(tuán)隊(duì)會每天早上進(jìn)行站會（通常不會超過15分鐘）。

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

通過每日站會，每個(gè)人都能了解全局，知道發(fā)生了什么，沖刺目標(biāo)的進(jìn)展如何，是否需要幫助團(tuán)隊(duì)解決一些問題，實(shí)現(xiàn)一個(gè)沖刺內(nèi)快速、流動(dòng)的工作流。

6. 沖刺評審

沖刺周期的后期，團(tuán)隊(duì)給產(chǎn)品負(fù)責(zé)人和其他業(yè)務(wù)需求干系人、客戶演示完成的成果，讓各方了解已經(jīng)交付的增量，檢視和調(diào)整產(chǎn)品，同時(shí)業(yè)務(wù)互相交流，收集反饋并及時(shí)調(diào)整。

7. 沖刺回顧會

沖刺回顧會是檢視并調(diào)整過程的時(shí)機(jī)，開發(fā)團(tuán)隊(duì)、產(chǎn)品負(fù)責(zé)人、ScrumMaste一起討論，在上個(gè)沖刺中哪些過程是需要改進(jìn)的。

需要注意的是沖刺回顧會不是吐槽、追責(zé)的會議，目的是幫助Scrum團(tuán)隊(duì)成長、下一個(gè)沖刺能夠持續(xù)的改進(jìn)。

適用場景

敏捷項(xiàng)目管理適用于業(yè)務(wù)需求變化頻繁、比較適合創(chuàng)新型項(xiàng)目、市場需求變化快速的項(xiàng)目，主打一個(gè)“快速迭代”，在一些互聯(lián)網(wǎng)公司、自研產(chǎn)品的公司比較常用。

優(yōu)點(diǎn)

能夠快速響應(yīng)變化、提高客戶滿意度、減少項(xiàng)目風(fēng)險(xiǎn)，同時(shí)還能提高團(tuán)隊(duì)協(xié)作能力、加快產(chǎn)品上市時(shí)間。

缺點(diǎn)

對于一些成熟業(yè)務(wù)，由于追求快速響應(yīng)，前期在系統(tǒng)架構(gòu)設(shè)計(jì)上并不一定那么完美，另外對團(tuán)隊(duì)協(xié)作能力、敏捷理念的認(rèn)可度要求比較高。

三、在項(xiàng)目交付過程中的思考

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

從實(shí)際經(jīng)驗(yàn)來看，有如下原因?qū)?dǎo)致成本、質(zhì)量、時(shí)間陷入三難的境地。

外部原因：

• 甲方業(yè)務(wù)比較新，存在邊用邊發(fā)現(xiàn)新問題的情況，合同外的、變更需求時(shí)有發(fā)生；
• 甲方不配合，如不配合調(diào)研、系統(tǒng)使用不積極、不提供數(shù)據(jù)等等；
• 實(shí)施過程中非研發(fā)類工作耗費(fèi)太多時(shí)間，如數(shù)據(jù)處理、甲方匯報(bào)文件、配合業(yè)務(wù)開展等臨時(shí)性工作安排、業(yè)務(wù)代運(yùn)營等。

內(nèi)部原因：

1. 合同簽訂前銷售的對需求的過渡承諾，初設(shè)方案的不完善；
2. 系統(tǒng)規(guī)劃設(shè)計(jì)階段對整體應(yīng)用架構(gòu)、技術(shù)架構(gòu)設(shè)計(jì)的不合理；
3. 需求分析不合格，設(shè)計(jì)出來的系統(tǒng)未能徹底解決甲方的問題，導(dǎo)致重復(fù)返工、打補(bǔ)??；
4. 缺乏有效的項(xiàng)目管理流程，多人協(xié)作變得混亂失控，缺少風(fēng)險(xiǎn)跟蹤，研發(fā)過程變得脆弱，導(dǎo)致研發(fā)效率和質(zhì)量不高。

原因很多，本篇僅從項(xiàng)目管理的角度探討，如何平衡成本、質(zhì)量、時(shí)間的矛盾，達(dá)到甲乙雙方共贏的目的。

有一種方式我叫做“大瀑布下的小敏捷”，將“敏捷開發(fā)”與“瀑布開發(fā)”相結(jié)合，發(fā)揮各自的優(yōu)勢，是一個(gè)實(shí)際可用的手段。

“大瀑布下的小敏捷”既能夠按照“瀑布模式”的里程碑節(jié)點(diǎn)，交付目標(biāo)相對明確，又能發(fā)揮“敏捷開發(fā)”快速響應(yīng)需求的變化、持續(xù)交付的優(yōu)勢，提升客戶滿意度。

在大的項(xiàng)目周期內(nèi)有明確的啟動(dòng)、需求調(diào)研、系統(tǒng)設(shè)計(jì)、編碼開發(fā)、上線交付的里程碑節(jié)點(diǎn)，整體上看是瀑布模式的開發(fā)。

對于實(shí)際交付過程中頻繁變更的新需求和合同內(nèi)的老需求統(tǒng)一放進(jìn)“產(chǎn)品代辦清單”（Product Backlog），按照敏捷開發(fā)的模式拆分成一個(gè)個(gè)固定時(shí)間盒的沖刺，當(dāng)下的沖刺內(nèi)為優(yōu)先級最高的需求，通過一個(gè)個(gè)沖刺完成增量產(chǎn)品的交付，直至項(xiàng)目交付。

敏捷開發(fā)是為了讓團(tuán)隊(duì)達(dá)成一種在固定時(shí)間內(nèi)持續(xù)交付的共識，一般一個(gè)沖刺開始時(shí)，該沖刺內(nèi)的需求一般不允許變更。

但有些特殊情況，為了配合甲方匯報(bào)（一些G端項(xiàng)目常見），這些臨時(shí)需求優(yōu)先級會變得非常高。

此時(shí)研發(fā)團(tuán)隊(duì)可能正處在當(dāng)前沖刺的開發(fā)中，不得不將主要精力投入配合匯報(bào)。

無論“敏捷開發(fā)”還是“瀑布開發(fā)”，流程是死的，人是活的，不同的公司、不同的業(yè)務(wù)可以根據(jù)實(shí)際情況靈活調(diào)整，切不可生搬硬套。

參考資料：《Scrum精髓》