大家好，新人第一次發(fā)文可能存在諸多問題求輕噴求輕噴，閑話不多說我們這就進入正題。相信大家都聽過在開發(fā)過程中的“敏捷式開發(fā)與瀑布流的開發(fā)”，可是具體在實際工作過程中我們應該選用哪種方式呢？請大家來隨我看看這其中的各種利弊…

一. 敏捷式開發(fā)的限制

目前已經(jīng)有不少產(chǎn)品團體通過以“敏捷式開發(fā)”的方式去管理與完成自己的產(chǎn)品，盡管在我看來“敏捷式開發(fā)”有諸多優(yōu)點，但是我們始終要謹記敏捷式開發(fā)的源頭是定制軟件服務，最早的敏捷開發(fā)誕生于1986年的日本；

所有流程的初衷也并非完全適用于用戶產(chǎn)品軟件開發(fā)，如果初創(chuàng)團隊決定使用一套完整的敏捷式開發(fā)流程來完成自己產(chǎn)品的話，這個團隊需有明確了解何為敏捷開發(fā)的人員；如若沒有，那么整個團隊將面臨一些空前的磨難，只有經(jīng)歷不斷忍過這些陣痛才能體會到“敏捷式開發(fā)”所帶來的優(yōu)勢。

本本文僅列出需要敏捷開發(fā)過程中所注意的事項，如果大家想與我一起了解后續(xù)，會另開文章詳細介紹如何組建一個真正的敏捷開發(fā)團隊，具體的敏捷開發(fā)過程也需要根據(jù)公司的實際情況進行調(diào)整。

二. 在敏捷開發(fā)過程中的注意事項

我將其歸類為8點：

1.?產(chǎn)品經(jīng)理就是項目負責人

在敏捷開發(fā)過程中產(chǎn)品需要做好代表整個用戶需求的作用，需要與開發(fā)團隊保持密切溝通，及時解決開發(fā)過程中的問題，如果有些產(chǎn)品經(jīng)理認為采用敏捷開發(fā)可以使工作變得更加輕松，那么就大錯特錯了。其實如果產(chǎn)品經(jīng)理與項目負責人不是同一個人，通常會使整個產(chǎn)品留下非常嚴重的隱患，產(chǎn)品在整個敏捷開發(fā)過程中必須始終都要是第一責任人；

2.?使用敏捷方式不等于不做產(chǎn)品規(guī)劃

使用敏捷開發(fā)的過程中產(chǎn)品仍需要明確定義整個產(chǎn)品的方向和目標，設定產(chǎn)品里程碑，只不過在敏捷迭代過程中所有的里程碑可以盡可能縮短其周期，通過使用反復迭代與輕量級的機會評估方法代替冗長的市場機會文檔等紙面材料；

3.?產(chǎn)品經(jīng)理與設計師的工作應領先團隊1-2兩個版本以上

為了確保在項目推進過程中有足夠的時間攻克技術上的難題，需要讓產(chǎn)品與交互設計和視覺設計師提前完成產(chǎn)品設計，充分發(fā)揮三者在產(chǎn)品設計過程中的主導作用，同時保證開發(fā)人員在產(chǎn)品設計與交互設計階段始終處于參與狀態(tài)及時反饋關于產(chǎn)品的可行性、成本與解決方案的建議在問題的出發(fā)點就將其解決；

4.?盡量把產(chǎn)品設計拆分成獨立的部分

雖然將產(chǎn)品拆分成多個模塊，但是也不能將其拆分的過于細碎，好比建造一座房子，你不能每次只建造一件房子，目標是設計出符合所有基本需求的產(chǎn)品，在這一過程中要求設計師需有更快的響應速度，去做經(jīng)過市場驗證后的調(diào)整；

5.?產(chǎn)品主要的工作是定義有價值、可用的產(chǎn)品原型作為產(chǎn)品基礎

在敏捷開發(fā)過程中產(chǎn)品更需要注意，每次交付到技術同學手里的原型是經(jīng)過測試與目標用戶驗證的，避免浪費任何資源，哪怕是一個開發(fā)迭代周期；

6.?讓開發(fā)人員自主控制所有迭代周期

有的產(chǎn)品功能可以在一個迭代周期內(nèi)完成，而有些需求確需要多個版本的迭代才能完成，而這些迭代周期應該盡可能的讓技術同學去規(guī)劃，產(chǎn)品只需把控最終的判斷是否與規(guī)劃相符合；

7.?除非達到預定目標否則絕不輕易發(fā)版

產(chǎn)品經(jīng)理必須保證給到用戶手中的產(chǎn)品是正常符合預期的，過度而過度頻繁的更迭會讓用戶失去安全感，所以沒有達到產(chǎn)品預期里程碑與階段預期時絕不可妥協(xié)上線；

8.?每次迭代之后需向整個團隊展示下個版本的需求設計與上個版本的數(shù)據(jù)回歸

讓大家看到工作成果可以極大的加深整個團隊的信心，在敏捷開發(fā)過程中每一個產(chǎn)品即是一個小團隊的領袖，產(chǎn)品經(jīng)理需要讓這個團隊有更加積極的狀態(tài)。

三. 瀑布式開發(fā)

傳統(tǒng)瀑布式開發(fā)，至今為止應該已經(jīng)有不少于30年的歷史，瀑布式開發(fā)流程也分為正式流程與非正式流程，正式的瀑布式開發(fā)流程可以追溯到美國國防部軟件開發(fā)標準2176A及后續(xù)修正的498，在網(wǎng)上有詳細的闡述每一個階段所需要提供的必要性文檔，本文想說明重點在于非正式流程，也就是我們很多公司的開發(fā)流程；

非正式瀑布流程，也是目前很多互聯(lián)網(wǎng)公司依舊在使用的方法：由市場/運營進行需求收集，交由產(chǎn)品對需求進行產(chǎn)出文檔，統(tǒng)一進行研發(fā)和設計評審，評審之后由開發(fā)制制定開發(fā)計劃、設計軟件架構，由設計進行交互與視覺設計等細節(jié)設計，最后正式進入開發(fā)、測試與部署上線。

四. 瀑布開發(fā)的優(yōu)劣

瀑布式開始是目前大多數(shù)團隊仍然在使用的一套開發(fā)流程，雖然無論是開發(fā)還是產(chǎn)品同學都對其十分的不滿，但其仍能在不斷擁抱變化的互聯(lián)網(wǎng)公司被推崇使用必定有其優(yōu)勢。所以在討論瀑布式開發(fā)的局限性前，我們需要先聊下瀑布式開發(fā)的基本準則與優(yōu)勢

瀑布式開發(fā)的基本原則：

1. 采用階段式開發(fā)，即軟件開發(fā)過程中分為固定幾個階段：完成需求文檔、設計軟件架構、完成交互細節(jié)、編寫代碼、測試、部署；
2. 采用階段式評審，每個階段結束由上到下進行相應的評審，評審通過后進入下一階段。

瀑布式開發(fā)的優(yōu)勢：

（1）對于管理層而言有可預測性，在理論上只要在產(chǎn)品評審階段前將所有產(chǎn)品細節(jié)確認并完善，且不再更改需求，那開發(fā)團隊就可以為超大型及復雜項目制定相應的開發(fā)計劃，雖然不進行需求變更這種情況很少見，但是并非不能做到，相反迭代性開發(fā)的迭代次數(shù)無法預估，很難讓管理者做到心中有數(shù)；

（2）在瀑布式開發(fā)過程中每個階段都會由對應的負責人員提供相對完善翔實的文檔及其他書面材料，這會讓項目在開發(fā)過程中給人一種感覺，這些項目都經(jīng)過了所有人的深思熟慮才會進行的相應推進，但是問題在于使用書面材料當作穩(wěn)定劑多少都會有些靠不住，因為他并不能實際的在你面前演示。
瀑布式開發(fā)的劣勢的劣勢：

（1）產(chǎn)品驗證滯后

產(chǎn)品驗證滯后是瀑布式開發(fā)過程中最讓產(chǎn)品頭疼的部分，產(chǎn)品人員必須等到項目進程尾聲的時候才可以對產(chǎn)品進行驗證，也就是說在投入大量的人力物力之前所有的產(chǎn)品概念都是無法得到充分的驗證的，驗證滯后也意味著所有階段不能出現(xiàn)任何紕漏否則將導致整體項目變得失控；

（2）需求變更困難

在瀑布式開發(fā)過程中，任何對之前決策的修改與調(diào)整都將打亂原本的開發(fā)流程，大量已完成工作需要重新評估與推進嚴重耗費整個團隊的精力，產(chǎn)品經(jīng)理在跟蹤用戶需求的過程中，難免會產(chǎn)生需求的變更，如果發(fā)生需求變更那修改需求必定在所難免，只是早晚的問題，而且延遲到下一個版本開發(fā)也只是一個權宜之計，無論從成本或是用戶體驗上考慮肯定都是越早改動越好；

（3）難以適應變幻的市場

瀑布式開發(fā)過程中的所有工作都嚴重依賴于流程與文檔，任何一點改動都會牽一發(fā)而動全身，也使得產(chǎn)品經(jīng)理壓力倍增，產(chǎn)品經(jīng)理在這一流程下提交給開發(fā)的所有產(chǎn)品必須確保通過嚴格的驗證且沒有缺陷，另一方面發(fā)布過后產(chǎn)品也會提心吊膽，隨時做好快速線上修復的準備。

五. 實際推進項目過程中，我們該如何選擇

在了解了瀑布式開發(fā)過程中的缺陷就不難理解為什么要改用各種敏捷開發(fā)，瀑布式開發(fā)流程過于理想化，需要人們在開始的時候就預見到所有的問題，全面的把握需求；最終實踐證明，往往瀑布式開發(fā)只適用于規(guī)模很小的項目開發(fā)，對于大型項目來說，瀑布式開發(fā)就顯得難以順利推進且如果采用瀑布式開發(fā)，產(chǎn)品的交付時間通常都會比一開始所預計的時間晚，而且常常是產(chǎn)品上線后發(fā)現(xiàn)各種缺陷，產(chǎn)品與整個技術團隊不得不花費更多的精力去進行修補。

通過這些說明，我也更希望文章前的你看到兩種方式的局限性，并選擇一個真的適合你團隊的開發(fā)流程。

希望本文可以幫助那些還在猶豫的人，以后也會更多的深入各個問題進行探究~

作者：Lonny，公眾號：gatf_yl

本文由 @Lonny 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 Pexels，基于 CC0 協(xié)議