敏捷開發和迭代開發是一回事么？

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

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

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

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

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

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

1、不要全想好了再做。

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

2、有想法，快速上線。

51%成熟了就去做。去試錯。錯了，快速迭代修改；對了，你就是先抓住第一批用戶了。當年騰訊內部做微信產品的有3個團隊，最後就是最快做出來的QQ郵箱團隊勝出了。

3、不怕錯，就怕慢。

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

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

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

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

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

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

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

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

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

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

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

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

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

有思考，閱讀才有價值。

有碰撞，思考才會沉澱！

概括來講，敏捷開發就是一種以用戶的需求進化為核心，迅速迭代、循序漸進地進行軟體開發的方法，核心是快速響應和持續迭代。要保證在迭代周期內，團隊成員思想保持高度一致、以共同的節奏和共同的周期完成周期性運轉，保證在每一個周期的同一時間點，團隊中的每一個人做的事情是相對一致的。迭代也讓團隊內外有著共同的預期，知道什麼時間點該做什麼，該交付什麼出來。

或許這樣理解起來仍有些抽象，那麼讓我們來看傳統的開發是怎樣進行的。傳統的開發有個專有名詞叫「瀑布式開發」，分為5個階段：需求分析、設計、編碼、測試和維護。這套方法定義了很完備的過程規範、嚴格遵從這種方式會使得研發運作過程十分嚴謹。但是，在瞬息萬變的互聯網和移動互聯網時代，市場環境、用戶需求、競爭對手等因素都在時時發生著改變。傳統的瀑布式開發要求針對客戶需求寫出詳細的分析說明書，僅僅這一點就耗費了大量時間，嚴格遵循規範但不夠靈活的流程管理的結果可能是研發人員在開發過程中按部就班，產品技術上沒有太多瑕疵，但是正式推出市場時可能部分功能已經落伍。

和瀑布式開發相比，敏捷開發的特點就是「小步快跑、儘早交付」。在市場環境和客戶需求變更非常迅速的情況下，為了讓需求方儘早地看到結果，並給出反饋，以小步快跑進行開發並儘早地交付新的版本不失為一種好的解決方式。畢竟在互聯網時代，可用的產品一定勝過完備的文檔，並且及時的迭代可以不斷修正問題。

而要做到「小步快跑、儘早交付」，對團隊也提出了一定要求：

（1）準確分析市場需求

這一點也是很多人對敏捷開發的誤區。敏捷並不意味著不做項目計劃，只是不一定拘泥於形式，一定要拿出完備規範的開發計劃書，有時候敏捷開發的計劃就是團隊人員在白板上畫出的原型和點、甚至是口頭計劃。這種計劃不代表分析不嚴謹，事實上，敏捷開發比瀑布式開發更加註重需求的分析和計劃的制定。因為敏捷開發的核心就是為了及時響應用戶和市場的需求，所以並不會死守著計劃不進行調整。一旦市場發生變化，即使到了開發後期，敏捷團隊也應該對需求的改變持歡迎態度，對原先的計划進行調整，利用變化來為產品創造競爭優勢。

（2）迭代周期儘可能短，且周期固定

「小步快跑」意味著產品的交付時間間隔越短越好，通常是2-4周，頻繁地迭代能保證不斷修正BUG，而迭代周期固定則能和用戶形成良好的合作關係，便於客戶及時反饋，不斷地完善和提高產品的用戶體驗。小米就是一個很好的例子，MIUI開發版一周更新一次，至今已連續363周進行更新。

（3）團隊規模最好也能敏捷

敏捷開發對團隊的溝通要求很高，過多的人數會造成溝通成本的增高，信息在傳達過程中很可能會有偏差，使團隊難以保持步調一致。通常情況下，敏捷團隊的人數少於20人，超過的話可以再進行團隊分割。比如騰訊在管理200人或者更大規模團隊時，就會按照產、研、運的組織結構進行複製，把大規模團隊拆分為10個20人的團隊，或20個10人的團隊，分別負責產品的子模塊。拆分時會保證子團隊人員仍以產、研、運三駕馬車組成，具備交付功能，可獨立工作，再通過子團隊之間的協作，完成整個大產品的研發和交付。

謙啟將企業案例解析與專題研究結合，前期以讀書會形式帶領大家拆解相關企業書籍，並附以獨有專題研究進行解析，關注我們，私信留言，或搜索關注「謙啟學堂」，並在後台回復「研企社」，小謙將與各位一起解讀企業案例。

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

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

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

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

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

問題1：項目組內部人員問題

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

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

其次，按照之前我和老闆的討論，由研發出流程圖和文檔，但真正執行的時候，卻沒有人做這項工作，後果就是在開發的過程中，不斷的找我重新梳理流程，不斷的聊場景，聊功能，這樣一來二去時間就浪費了。

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

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

問題2：銷售過早介入

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

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

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

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

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

內部復盤

我們內部在面對這些問題時也進行了復盤和討論：

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

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

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

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

在這敏捷開發橫行的時代中，人人都在談敏捷，人人都在談迭代，似乎大家好像都嘗到了敏捷帶來的甜頭，記得有一次跟朋友吃飯，說他們現在的項目用敏捷開發，每個迭代都能看到不斷完善的產品，非常有成就感，客戶的滿意度也提升了不少；另一個朋友說，我們用迭代開發，也是這樣，而且客戶想加什麼需求就加什麼，直接按照優先順序排到迭代周期就行，也不用為改需求而煩躁。當時我就想，敏捷開發不就是分迭代周期的嗎，他倆好像說的是一回事吧。回去過了好長一段時間，突然想起這件事了，在網上一查，還真不是一回事…

迭代開發流程:

什麼叫迭代開發？在迭代開發中，整個開發工作被組織為一系列的短小的、固定長度（如3周）的小項目，被稱為一系列的迭代，這叫迭代開發。每一次迭代都包括了定義、需求分析、設計、實現與測試。而敏捷開發是以用戶的需求進化為核心，採用迭代、循序漸進的方法進行軟體開發。前者是軟體開發的生命周期模型，是一種開發過程；後者是多種軟體開發項目管理方法的集合，是一種開發方法。這是兩者最根本的區別。與迭代開發對應是瀑布模型，螺旋模型等，而與敏捷開發對應的是Scrum，XP（極限編程），Crystal（水晶編程）等開發方法，所以它倆根本就不是一回事！那麼它們倆有沒有關係呢？答案是：有…

敏捷-Scrum開發流程:

敏捷開發的定義就已經說明，採用迭代的方法進行軟體開發。那麼有人會問，敏捷開發為什麼要採用迭代開發呢？不要忘了敏捷開發的核心原則是擁抱變化，和遞增的變化。迭代式開發正適合在那些需求信息不明確的項目，這樣在開發過程中遇到需求的變化時，所帶來的影響要比其他模型小。而現在的很多項目中，需求在項目進行中變化的事兒經常見，所以顯得迭代式開發的優勢更明顯一些，這正符合敏捷開發的擁抱變化。而且迭代開發是不要求每一個階段的任務做的都是最完美的，明明知道還有很多不足的地方，卻偏偏不去完善它，而是把主要功能先搭建起來，以最短的時間，最少的損失先完成一個「不完美的成果物」直至提交，然後再通過客戶或用戶的反饋信息，在這個「不完美的成果物」上逐步進行完善，這正符合敏捷開發的遞增變化。當然，敏捷開發只是一個總體概念，而迭代式開發只是幾乎所有敏捷開發所採用的一個主要的基礎實踐。敏捷開發除迭代式開發外，還包含了其他許多管理與工程技術實踐，如演進式架構設計、敏捷建模、重構、自動回歸測試（ART）等等。總而言之，就是敏捷開發與迭代開發是整體與局部的關係，前者就像大家庭，而後者是大家庭中的一員。

敏捷發展歷史

敏捷和迭代雖然不一樣，但是它們也是分不開的，迭代和敏捷開發方式的結合，既保證了產品的質量又在項目產品的持續改進中具有一定的優勢。吸取精華,破其糟粕，只有這樣，項目才會達到趨於完美的程度。現在市面上也恰好有一款這樣的項目管理工具-華為軟體開發雲（http://t.cn/RohXAxI），它就很好的把敏捷和迭代完美的融合到一起了，並且還配備代碼管理，代碼檢查，編譯構建，部署和發布等一站式的流水線開發流程，大大提高了我們管理和開發人員的工作效率，這也是我們所有IT人，做任何項目都想達到的目標。

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

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

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

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

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

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

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

很多人都對敏捷理解存在誤區，在沒有完全明白敏捷的精髓是什麼的情況下就瞎幾把搞，最後搞成邯鄲學步，啥也不是的地步。(包括那些推廣公司，大多拿敏捷的話題來賺錢而已)。

現在說說個人對敏捷的理解，敏捷是在程序員具有高度設計分析能力，軟體功能具有高度自主的基礎之上的，通過實時溝通而進行的軟體開發實踐活動。它講究的是知識共享與協同合作(把小步迭代也算成敏捷的精髓的話，我不太認可)。

再談談什麼類型的項目適合敏捷。

敏捷開發與迭代開發是兩個不同維度的東西，正如有位答者所說，敏捷開發是開發方法，迭代開發是開發過程。舉個簡單的例子，比如你要蓋一棟高樓，敏捷開發就是各方確定這個樓應該用傳統蓋樓方法，先打地基，再往上蓋，最後封頂。而不是按照新的蓋樓方法，一層層做好了疊加上去。而迭代開發就是確定好蓋樓方法之後，蓋地基的時候具體應該怎麼做，蓋樓體的時候具體應該怎麼做，封頂的時候具體應該怎麼做。所以敏捷開發是戰略層面的，迭代開發是具體實施的。

我認為，敏捷開發的包含並大於迭代開發。

我的認知中，開發分為敏捷開發和非敏捷開發。敏捷開發的開發生命周期模型的典型代表是迭代開發。非敏捷的典型代表是瀑布開發。

舉個例子。做一個產品，從需求到可行性到立項到開發到測試到上線，如果每一步的依賴都是前面一步的輸出，例如要想做好可行性必須要做好需求並輸出相應的文檔，這種叫瀑布式開發。好處是每一步都有據可依，會把前期因為需求不明確或設計失誤降到最低。每一步只有通過評審才能進行下一步。帶來的問題是開發周期長，需求一旦確定，後期再變化，可能會造成項目失敗。

做一個產品，將需求分解，確定的需求和不確定的需求，先做確定的需求，進行一個完整的開發周期，向客戶交付，然後進一步確定不確定的需求，按照迭代升級不斷的完善產品。這種方法的好處是產品可迅速出原型，可根據市場反應比較快的調整需求。同時它也就要求對產品的開發要有一個好的架構或模型，甚至要犧牲成本，有可能最後的成品需要重新迭代硬體，也就是每一次的迭代有可能只適應於當前需求，後期的迭代就要根據需求更新硬體。當然，如果產品規劃的好，迭代思路明確，可以減少這方面的問題。

敏捷和非敏捷沒有更好，只有更適合。工業品的開發應該更適合非敏捷，因為需求明確且不容易變，產品開發更注重穩定。消費品的開發應該更適合敏捷開發，迅速開發出原型機去驗證市場或交付客戶，之後一步步完善，更注重功能。或者說，可以不穩定，但一定可以不斷升級。

以上

迭代和敏捷都是概念或者叫統稱，說不同，只有實例級別才可以說，概念級別只是歸納，可以說迭代是敏捷（雖然片面），也可以說敏捷是迭代（雖然也片面）。

為什麼有迭代？是為了里程碑還是為了生命周期？為什麼有敏捷？是為了和迭代區分嗎？顯而易見不是。

迭代是概念，敏捷也是概念，即使說SCRUM是迭代（由於迭代是概念，而SCRUM有了自己的實踐）也沒啥不對。