開發就是開發。由於許多專案需要長時間持續更新調整與整合測試，為了支援線上更新，降低風險等複雜要求一些輔助工具應運而生。開始，這類工具集中在程式碼管理、編譯、測試、打包、分發等階段，並逐漸擴充套件。一些諮詢機構、獨立顧問、教授從各自的角度選擇或重新整理包裝，並以“高大上”演講、文章向全世界終端使用者、系統整合商等推廣。敏捷開發和迭代開發作為工具集理解，不同點可能主要是名稱。作為方法論範疇迭代開發更緊湊。

其實，運營商的運維人員和整合商的應用實施顧問可能更喜歡議論這類東西。至於真正的開發人員特別是架構設計者關注的重點是如何為應用系統提供持續更新、整合、測試的支撐能力，將需求變更作為系統的基本功能。當前普遍的做法是開發專用的指令碼語言或與有種指令碼語言整合。

總之，開發者不必糾結於這些虎人的說辭中。

敏捷開發是從效果角度看問題:開發流程快，無效文件少。迭代開發是從實施角度看問題，系統透過迭代逐步完善。

與迭代對應的是瀑布模型，就是把開發劃分為需求、設計、編碼、測試等階段，前階段為後階段基礎，透過高質量前階段保證後續開發工作有效。所謂瀑布模型本身就是一種理想化概念，本來是作為批.評物件提出來的，陰差陽錯之下居然被奉為了經典。真實情況下可以說任何新開發系統都一定是迭代的，因為實際系統永遠存在需求變動。

敏捷是相對傳統軟體工程化而言的。CMM等方法按瀑布模型設計，大量的過程管理流程拖延了專案進度，但真實世界廣泛存在的需求模糊和變動又讓大量積累的文件快速失效，專案被迫進入迭代過程，瀑布模型很快就讓開發團隊失去耐性，各種應付性文件被成員偽造出來，CMM引以為傲的資產也失去了價值。因此，除非團隊有極高的自律和充足的人月，瀑布模型永遠都是夢想。

敏捷實際只是多種提高開發效率的實踐方法組合:簡化需求提取過程，簡化文件記錄(程式碼即文件)，自動化測試……

自從開始做產品以來，負責的幾個產品都是採用傳統的瀑布流開發模式，需求分析——頁面設計——開發——測試——上線。我本人除了負責需求分析外，還要負責專案管理的工作。幾個產品做下來，對於這套流程還算駕輕就熟，公司的開發們也都樂此不疲的寫著程式碼。不過最近一個專案，我們嘗試了敏捷開發的工作流程，結果卻不堪回首。

這次的專案並不是一個網際網路產品，而是一個解決方案，甲方是一家擁有很多運動場的商業公司，希望我們能為其提供一套球場的智慧化升級方案。但甲方的需求並不清晰，也不知道自己想要什麼，唯一的目標就是讓自己的運動場變得更“屌”，更科技化，能吸引更多的人來玩。

也正是因為甲方的這個特點，我們決定採用敏捷開發，先做出幾個核心功能，交付到甲方，在甲方場地運營之後，再根據甲方的意見進行改進，逐步迭代，當整體做完之後，就可以把該專案內容打包成一個產品，對類似的客戶進行銷售。

在和領導分析了這個專案之後，我們決定採用敏捷開發的模式，我的任務就是需求分析，主要就是要多“走出去”，多和客戶交流，把產品的其他事情，如流程圖啊，文件啊……直接給研發們搞定，也算是試驗一種新的開發模式。

怎奈理想很豐滿，現實很骨幹……整個開發過程多次返工，中斷，這期間夾雜了無數次撕逼……

問題1：專案組內部人員問題

我和甲方溝通了需求之後，拉著開發們開會，所有人大開腦洞從甲方的基本需求中暢想了無數的延伸，無數的功能。彷彿做完這單，就可以覆蓋全國……

但真正開工之後，問題一個接一個來了，首先，有的開發人員在之前的會上根本沒有專心，我們所聊的場景，功能，他完全不知道，還停留在之前的瀑布流工作狀態中，等著產品經理把詳細的需求給到他……

反思：敏捷開發和傳統的瀑布式開發相差還是很多的，瀑布式開發只要在前期將使用者需求，產品功能都想清楚，流程理順，那後期只需要一個牛逼的專案經理把控專案進度，就不會出什麼大問題。

敏捷開發則對團隊內的所有人要求很高，至少在我們這個專案裡面，無論你是UI，還是前端，後端都要對場景瞭如指掌，這樣會省去很大的麻煩。

問題2：銷售過早介入

我們這個專案出現的第二個問題，就是在開發的過程中，領導過早的讓銷售介入了。

領導的本意是希望銷售能將我們這個專案變成產品，賣給更多人，但實際的情況確實，甲方雖然都是球場主，但他們的基本需求卻相差很多，我們設計的能滿足第一個客戶的功能，卻不是第二個客戶的基本需求。

當銷售帶著客戶需求找到我們，並提出要試用時我們的產品時，那場面別提多尷尬了……但銷售已經把大話說出去了，我們拿不出東西的話那是丟公司的臉啊……沒辦法，硬著頭皮上吧。

一方面讓銷售儘量拖一拖客戶，另一方面我們快速的開發一個應急版本。

但在這麼緊張的時間裡，又怎麼會做出好的產品，最終的結果當然是客戶飛了，而原定的開發計劃也被打斷了。

內部覆盤

1.我們認為敏捷開發確實是滿足第一個客戶需求的最好的方式，只不過我們團隊的成員要負起責任，需要每個人都對業務十分了解。不能做到這點的請你離開。

2.銷售的目的就是把東西賣出去，他們才有提成拿，他們不會在乎使用者需求什麼的。所以只有完整的，可複製的產品才可以讓銷售拿出去賣。

3.我們現在是在為一個客戶做解決方案，還沒有被證明能否應用於其他場景，只有當我們做了足夠多的專案，當我們為5家乃至更多的客戶做了解決方案之後，這一批解決方案才能變成一個產品打包賣出去。這時，我們針對不同使用者只需要在做過的解決方案中挑選合適的功能模組即可。

我參與了“來簡書聊聊你的產品之路｜@產品專題徵文”，也來說說你的產品故事吧。

敏捷開發是去除開發流程中的一些環節，包括文件，以最快速的方式完成最終產品，代表語言是ruby on rails，寫了個網站http://雙排鍵.com就是用敏捷開發，從學習語言到，架構到完成一個人用了6個月時間（當然機器有點爛，開啟百度用了6秒鐘）。迭代是每次更新在前一次基礎上新增新的內容。

理論脫離實踐，生搬硬套書本上的概念，沒有親身體驗過是無法深刻理解一種管理思維的。

所以，有過從0到1做產品，而且團隊就是敏捷開發模式的人來回答這個問題，能更接地氣。

敏捷開發的精髓，就在於：快速響應 + 快速上線 + 快速更新；

而迭代開發，其實也有與敏捷類似的思想在裡面，但不夠突出，核心沒有敏捷開發那種“再快一點”的節奏感。

敏捷開發的核心

BAT裡被公認產品做得最好的騰訊，就一直強調“小步快跑，快速迭代”。

萬法歸一，大道至簡。敏捷開發的誕生與生存土壤，其實與其是一致的。精煉一下，就是：

1、不要全想好了再做。

建一個網站平臺，等所有產品細節都想好了，已經過去2個月了（更別說是否真的想清楚了），再開發、測試，週期拉得太長。

2、有想法，快速上線。

網際網路產品和企業越來越多，初始的流量紅利佔有時間也越來越短。錯了沒關係，有誠意夠新意，使用者還是記得你，怕就怕你想做共享單車，但小紅和小黃已經遍地都是這兩家的了。敏捷開發的成員

敏捷開發的成員，往往人數都不會太多。

通常，敏捷模式的迭代稱之為sprint。一個sprint，就是一個迭代。

團隊裡會有產品、前端、開發、測試組成，互動和視覺資源一般以共享為主（重大專案除外）。這個團隊間的成員，溝通方式應該以結果為導向，快速響應，避免冗長的郵件、會議形式導致拖慢工作效率。能一句話敲定的，就不需要一個會。

整個團隊裡面，會有一個PO，即產品負責人，這個崗位一般有程式設計師的天敵——產品經理擔任。對，就是老改需求的那個。

此外，還會有一個master，負責研發進度的整體把控與技術難題拍板。人選通常以候選人的眼鏡片厚度來決定。。。不不不，是通常讓有經驗的開發人員擔任，比如研發經理。當然，從長遠考慮，在整個團隊磨合的較好之後，可以有其他開發或測試人員擔當master，起到一個鍛鍊的作用，作為人員儲備。

敏捷開發的節奏

一般敏捷迭代以2周為主，這樣一個月會有2次迭代。

迭代開始，會有一個技術評審會。這個會有2個重點，一個是產品和技術間對需求實現的確認，另一個就是開發和測試對需求的工時預估。工時預估是非常重要的一環，一方面對每個需求的開發成本有一個認知，另一個就是多少需求能排進當前迭代就以此決定了。如果週一開始一個新迭代的話，通常下週四釋出。

然後，每天早上不超過15分鐘的站立會。每個小組的成員輪流當做主持人，會上需要大家把昨天的工作進展和問題描述一下，做到全組成員資訊對稱。然後，會看一下燃盡圖，該圖的重點就是直觀反應剩餘的工作量。

等到開發新迭代拉分支之後，測試可以根據實際情況，開始測試工作，並不需要等到開發都完成後再介入。

敏捷開發的總結

綜上，敏捷開發更適合小團隊、新產品的專案組。

不怕試錯，快速調整。能把想法快速的轉化為上線內容，後續再進一步最佳化。

PS：由於迭代時間短，產品經理當前迭代“忍痛”留下的bug或需求，2周後新迭代就有希望加入。從而減少了產品與程式猿的互相傷害。（當然，他們的戰爭不會熄滅，永遠都在繼續。。。）

有思考，閱讀才有價值。

有碰撞，思考才會沉澱！