1、本文旨在引導產品從業人員關注和重視開發模式問題，隱去了各模式的實施細節和管理復雜性。文章介紹了常見的 5 種開發模式，并對各模式進行了分析，與大家分享。我一個產品經理（本文泛指產品人員）為何要關注開發模式，開發的事不是技術的事嗎？那不是技術團隊該關心的事嗎？首先我們要達成一個共識：產品經理除了收集分析需求、拋出草案、定方案、輸出原型、prd、流程圖、架構圖等專業工作之外，還需要負責協調資源、 上傳下達等保障整個研發順利進行的工作。產品經理是貫穿始終從頭走到尾并對最終結果負責的人。互聯網軟件研發周期中的各團隊參與情況和當前項目所處的階段，大略劃分的話可以有如下關系：完成軟件開發所要進行的工作和各

2、團隊之間大致有如下關系：為什么有交叉？各團隊之間看起來相互獨立，各司其職，實則緊密相連，不可分割。無論開發模式是不是技術團隊該關心的事，它都不可避免地會影響整個研發過程。各團隊為了消除這種影響，需要調整工作方式去配合，這樣才能釋放出相應模式的優勢力量，達到整體最佳。第一：加入一個新團隊，能識別出當前團隊正在采用的開發模式，可以快速適應節奏展開工作，更順利更少犯錯。試想如果人家在采用敏捷開發，而你帶著瀑布開發的思維投入工作并產出，團隊首秀上來就挖坑，想想都覺得可怕。第二：清楚團隊當前工作模式的優勢和局限，在局限性方面就可以提前做好準備，不至于當問題發生時措手不及，處于被動的局面被牽制住。問題的產

3、生很有可能是團隊工作方式的弊端帶來的而非你個人能力的問題，這個鍋不能背。第三：以第二點為基礎，清楚局限可以有意識盡所能去優化，無論對個人發展還是公司效率，都是極好的。一款產品不是孤立的，它是和自身、公司、競品、行業、用戶群等相互關聯的，共同作用下的一個結果，我們研發一款產品，是基于一定需求痛點，服務于特定人群的。在信息過載、要求快速響應的互聯網世界里，開發過程的靈活性和用戶參與程度被越來越多的關注和利用。當下公司所采用的開發方式有N 多種，每一種都是特定場景下的特定產物，沒有絕對的優劣，適合最重要。我們先從操作靈活性、用戶參與度兩個維度對當下流行的開發模式做一下全局預覽。我們選取了 4 種典型

4、的開發模式進行說明，這4 種模式有的是默認選擇的，可能你在用但是你自己沒意識到；有的是當下熱議的；有的是用于增加項目透明度可以隨時引入新的變更需求的；有的是應對老板一聲令下要求即刻上線的。各個階段從上到下，一步一步地走，是不是很像瀑布，水從上流淌而下。瀑布模型式是最典型的預見性的方法，是開發方法論的老大哥，嚴格遵循預先計劃的需求、分析、設計、編碼、測試的步驟順序進行。只能一個階段一個階段的執行，不可回溯。每個階段都需要獨立評估，準確無誤的輸出，完整的文檔。上一個階段結束前，下一個階段不能開始。直到最后部署交付，期間都拿不到切實可應用的項目。這是大多數團隊默認采用的一種模式，甚至常用到自己在用它

5、，但是都不知道它就是瀑布式開發。采用瀑布開發方式的用戶常見于新負責的項目經理因為這種方式對項目的估計非常方便。項目開發中涉及到的幾乎一切都預先計劃，從而便于確定預期的開發成本和開發時間，非常方便地把整個項目置于自己的掌握之下。缺點也很明顯，任何人都不能預知未來，做出來的方案也都不是完美無瑕，計劃趕不上變化，每個階段環環相扣，任何一個階段出問題，都可能導致延期甚至項目失敗。另外對于開發人員而言就可能顯得太嚴酷了。因為測試過程在開發階段之后實施，子系統測試所暴露的問題可能需要立即修改代碼，而開發人員一般在同一階段也會從事其他的開發任務，而所需要的軟件修改可能會降低開發人員的生產率和工作質量，這樣就

6、顯著增加了計劃架構的成本。增量和迭代其實是兩種開發方式。增量開發是把項目切割成N 個相對獨立的模塊。像堆積木一樣，每次迭代會增加新的軟件模塊，而在先前添加的模塊中幾乎沒有變化。開發過程可以順序進行，也可以并行進行，并行開發提高了交付速度。這就要求產品經理在分析設計階段，要充分考慮研發資源問題。如果研發資源有限，我們把項目切分成塊后勢必要按緊急、重要程度進行排序，業務人員會牽扯進來。如果研發資源充足，分析設計階段產品經理會很忙，我們要在設計階段過后輸出的是供好幾個研發組并行開發的子模塊原型、PRD、流程圖等，當然如果你是個產品leader的話，就可以授權下面人去分頭行動了。迭代開發和增量開發類似

7、，也是把一個大任務切分成N 個子任務。與增量模式各模塊間相對獨立不同，迭代開發的每次迭代任務都是以上一次迭代為基礎進行的。由于軟件是分部分交付的，因此從項目開始就不需要完整的規范，并且在開發過程中可能會對需求進行少量更改。但是，需求不能根本改變，必須在開始時就定義主要需求。這就要求產品經理每次迭代都要留下足夠清晰的文檔，供后來人能接著繼續迭代開發，后來人可能是公司其他產品經理，也可能是新來的產品經理。如果你是一個產品leader,如果你們公司項目采用的是迭代開發模式，如果你不想因為某個人的離職導致開發組陷入一團糟的話，就提前要有這方面的要求和準備。如果把增量開發看作是橫向開發的話，那迭代模式就

8、是縱向開發。增量迭代模式的優點是如果失敗，影響的只是一部分而非整個項目，降低了損失。軟件更容易成功，通過先前的上線版本收集用戶反饋，結合反饋作出下一次迭代方案，小步快跑更容易成事。缺點是因為增量開發是拆開成塊，如果開發過程中沒有溝通好，或者文檔不清晰，會導致后期合在一起的時候出問題。大家經常聽到敏捷開發，其實敏捷開發不是一個模式，而是一組模式的統稱。本節講的看板開發和下節的極限編程都屬于敏捷開發，除此之外還有Scrum。如果說瀑布模式是一種自上而下的驅動方式，那么看板模式就是一種自下而上的驅動方式。后道工序在需要時，通過看板向前道工序發出信號，請給我需要數量的輸入。前道工序只有得到相應看板后，

9、才啟動任務。用戶需求為其中的原始驅動力。看板模式沒有明顯的迭代過程，沒有單獨的計劃階段，可以隨時引入新的變更需求。看板上的內容堅持 “即來即增加”和 “即變即更新”的原則，團隊中的每個人都可以根據實際情況增加或者流動自己負責的任務。可以清晰地看到所有項目活動，任務數量，負責人和進度。這種增加的透明度有助于更準確地估計最緊要的任務，項目組也更加趨向于自動化。站立會是看板開發方式的一個顯著特征，每天開發組主要成員，一人一兩分鐘，交代下自己當前已完成的任務，正在進行的任務，有沒有遇到問題。之所以采用站立的形式，是因為不要在會上討論復雜的問題，產品經理需要把控好站立會的時間。復雜問題如需討論，單約專項

10、會議進行。開發是環環相扣的，站立會會把問題提前拋出來，避免之前流程環節上的浪費。能帶來一種類似“ Stop and Fix的氛圍，出現問題時，能立刻暫停，分析根本原因，并加以解決，防止問題的再次發生。但是這種方式，容易讓大家的注意力集中到某個點上而忽略其他點，不利于思維的發散。極限編程和傳統開發模式的本質不同在于它更強調可適應性以及面臨的困難，去掉了條條框框，更強調專注問題，快速解決。也可以理解為這是一種更“隨意 ” 的開發方式，但是設計、編碼、測試環節依然存在，只是不拘泥于形式和流程。所以除了團隊成員之間需要相互熟悉、默契之外，在團隊文化方面也是有一定要求的，它的基礎和價值觀是交流、樸素、反

11、饋、勇氣和尊重。適用于經常發生變化的項目、緊急上線任務和封閉開發等。項目組人數也要進行控制，建議在210人之間。在極限編程式開發中，經常見到結對編程，即代碼由兩個人坐在一臺電腦前一起完成。一個程序員寫代碼關注編碼細節，另外一個人主要關注整體結構性的東西，不斷地對第一個程序員寫的代碼進行評審。團隊成員能夠長期維持努力工作的狀態，他們保存精力，他們把項目看作是馬拉松長跑，而不是全速短跑。代碼權限集體所有，每個人都可以更改代碼的任意部分，每個人都對所有的代碼負責。在XP 中，沒有那種傳統開發模式中一次性的、針對所有需求的總體設計，設計過程幾乎一直貫穿著整個項目開發，而且實現方式簡單，能滿足需求、通過

12、測試即可。不推諉不扯皮，有話直說，對事不對人，勇于承擔任務，不逃避責任。這個 “極限 ”就體現在把交流、反饋、勇氣、尊重這些最樸素的東西發揮到了極致。這種模式的弊端除了挑團隊之外，由于不拘泥形式，后期在文檔完整性上也會有所欠缺。如果項目組成員有流動也會給開發帶來很大問題。因強調的是簡單設計簡單開發，更關注當下的需求滿足情況，所以后期重構的幾率會更大。但是這種模式所帶來的效率提升，結果導向性，在某些場景下是其他模式所不能取代的。每個公司，每個團隊，每個項目都有自身的獨特情況，以下關系基于各開發模式本質特征進行推薦，實際情況需實際分析，也可以集合多種模式優點組合使用。無論使用何種開發模式，想要有效實施都依賴于對原理的理解、對原則的堅持和實踐時的隨機應變。大型關鍵企業應用程序，最好由松散耦合的部分組成，比如微服務或 web服務類故障和停機時間不可接受的項目，比如醫療軟件、航空管理軟件大型和高風險項目，尤其是基于用例的開發和高質量軟件的快速開發各種開發模式的產生是因為現實開發中遇