你如何理解敏捷開發？

12-26

今天你敏捷了沒有？「敏捷」在互聯網和軟體開發領域從涓涓細流逐漸演變為行業潮流，往小了說是改進了開發方法，往大了說是革了瀑布流式的命——把產品開發引向了快速迭代、小步快跑的路線上。

我們使用tapd（是騰訊內部的敏捷項目管理系統）寫 feature，流轉、跟蹤任務，言必談敏捷，然而我們是否真的走對了敏捷？

小編在此給大家推薦騰訊產品經理薄玉桴的《你大概走了假敏捷：認真說說敏捷的實現和問題（手繪版）》

此文從以下六點與大家認真剖析什麼是敏捷，以及現存的敏捷開發問題。

1.朋友，你聽說過敏捷么？

2.離開敏捷工具，我們怎麼敏？

3.設計也要介入敏捷流程？

4.敏捷跟文檔是對立的？

5.我這有個幾百億的大項目，怎麼敏？

6.盡信書，不如無書。

文章圖片很多，知乎的編輯器確實不太好用，還請大家到原文頁面閱讀吧（求別打臉(⊙o⊙)…）

你大概走了假敏捷：認真說說敏捷的實現和問題（手繪版）

做了這麼多年的產品以及團隊管理，理論性的東西到處都講得很多了，結合自己的一些實際工作和體會談一談對於敏捷開發的粗淺認識。

不斷交付軟體以滿足客戶需要

很多年前從最開始的瀑布流開發模式開始，我們已經開始認識到需要壓縮版本迭代的時間周期了，但是那個時候軟體規模都比較大，用戶場景和現在的互聯網軟體及服務都有很大的差別，研發離用戶是比較遠的。直到我加入多看之後，才逐漸認識到一點：「快」是行動準則。

小米的創業之初，雷總就提出互聯網思維的七字訣：專註、極致、口碑、快，這也真正映射到了我們的研發模式中，多看閱讀的Kindle版本，一開始就是嚴格執行的每周迭代，每周三發升級預告，周四內測，周五發包。（當然，有時候周五發不出去，或者出現問題，就只好周末加班搞了。）

後來多看閱讀擴展到了iOS/Android等平台，也堅持了快速的迭代模式，一般周期都是1-2周，除非是一個重要的大版本可能耽擱的時間會稍長一些，但這些版本也會不斷的有內測版提供給部分用戶。版本迭代周期壓縮後帶來的好處是顯而易見的，可以不斷試錯，及時獲取用戶反饋，產品的發展路徑不至於出現太大的偏差，這樣的產品，是容易形成口碑效應的。

歡迎需求的變化

迭代周期的壓縮會帶來需求範圍的縮小，但也不是說在同一個迭代周期中需求就是一成不變的，同時由於迭代周期的縮短，用戶反饋頻度也增加了，因此我們對於需求的把握也需要及時進行調整。

站在產品經理的角度，一個非常重要的原則是優先處理浮出水面的需求，其中很大一部分來自於用戶的反饋，因此對於所有可能出現用戶反饋的地方，都需要重視起來。在小米初期，全員上論壇是很重要的一件事情，而我自己也一直堅持每天在論壇上和用戶進行交流。

在確定了需求的範圍後，建立統一的需求文檔是非常必要的，我們的確出現過類似用戶提的需求A，產品經理寫成了B，開發成了C，發布出去時是D的情況。這也迫使我們尋找適合的工具來完成這件事情，目前我用的最多的是Confluence，通過Confluence可以建立高質量的需求模型，並且不斷的進行修改和完善。我們可以從Sprint的一開始就全員進行討論，不管是產品經理、工程師還是測試人員，都能夠在一份精準的需求文檔上建立對產品的認知，很好的避免了溝通上的偏差和遺漏。

需求的變化可怕嗎？並不，我們需要去擁抱需求的變化，並採用正確的方式去響應這種變化，不要視需求變化為洪水猛獸，而是不斷積累自身的經驗，在各個層面去高效的應對。

可以工作的軟體是進度的主要衡量標準

研發工作往往是比較難以量化的，對於研發管理來說，即使把迭代周期壓縮到了1-2周，對於進度的控制粒度也是遠遠不夠的。我一般會要求團隊從第一天開始就儘可能的實現持續集成（每日構建），哪怕產品啥都沒有，不僅僅是工程團隊，產品所有相關的人從第一天開始就可以真實的運行產品，這比什麼都更直觀的反應了產品進度到哪裡了。

在持續集成中還有很多相關的規範需要團隊執行，比如自動化測試，對於一些核心代碼尤為重要，有了自動化測試的用例覆蓋，對於每天構建的版本質量就有了更清晰和量化的數據。自動構建的結果會每天發送郵件的團隊所有人，每個人都可以清楚的了解到項目的進展情況。

對卓越技術與良好設計的不斷追求將有助於提高敏捷性

首先，我會非常推薦團隊每個人都認真學習Martin Fowler的這本經典之作：《Refactoring - Improving theDesign of Existing Code》。在我們的開發過程中，重構是無處不在的，這甚至是一種生活方式。對於代碼的壞味道，我們要零容忍，並且鼓勵團隊的成員去閱讀優秀的代碼，通過重構讓代碼走在變好的路上。

可能有人會感覺重構降低了開發速度，但其實不是，當代碼結構越來越複雜，產品功能越來越多，重構的必要性就越來越大。我在現實的工作中，就發現有不少的案例，比如一個函數改到後來，可能函數名和實際代碼完成的工作已經完全不一致了，這種代碼，不但非常影響其他人的閱讀理解，還經常造成Bug，甚至會到導致後續功能擴展時花費大量的時間。

又比如，現在的前端開發技術，已經發展得非常不同，可能若干年前，我們還在使用jQuery，還沒有組件化的概念，而我現在的創業團隊，已經在大規模使用React and TypeScript進行構建了。新技術帶來的好處是非常明顯的，既安全，可擴展性也非常棒。

簡單——儘可能減少工作量的藝術至關重要

合理的使用工具，可以讓團隊溝通更順暢，管理成本也隨之降低，同時，我們儘可能的讓工作流程簡單，去除一切沒有必要的環節。在今年年初，我開始在團隊中嘗試引入Workplace來解決日常溝通的信息流問題，郵件太慢，QQ和微信對於工作溝通來說就是一個災難（我個人比較反感用微信討論工作）。對於PDF這個團隊來說，效果還不錯，對於大多數需要用郵件或者內部即時通訊軟體的場景都可以替換掉。現在，在一個更小規模的創業團隊，我推薦使用Slack，這種源自於IRC的團隊協作軟體可能更容易贏得程序員的好感。而Workplace的Feed流和Chat簡直就是兩個產品，無法融合，是非常要命的事情。

關於敏捷開發，還有非常多的方面可以去探討，不同的團隊，不同的產品，敏捷的具體實踐方式都是有不同的。不過，有一件事情應該是相同的，就是每隔一段時間，都要進行自我總結和調整，通過各種數據反饋，找到流程中壞的味道，逐步改進。最後用一句話總結我對敏捷開發的理解：敏捷是態度而不是流程，是氛圍而不是方法。

首先，敏捷開發是一種過程式控制制論，通俗的說，就是一種做事情的方法。

1. 它適用於軟體，因為軟體是軟的，可以改。要是硬體，改起來就沒那麼方便了
2. 它適用於客戶不知道自己要啥的情況，其實，這樣的客戶占絕大多數。因為客戶不知道要啥，所以你需要不斷幫客戶弄明白他到底想要啥。。。換句話說，你需要和客戶溝通，合作，傾聽反饋，持續改進。。。
3. 它適用於競爭激烈的市場，這樣的情況下，趕在競爭對手前交付一個不完美但至少能用的產品非常重要。
4. 它適用於快速變化的市場，你在埋頭造一輛汽車的時候，客戶已經想開飛機滿天飛了，這就需要你能一步步的把汽車改成飛機，還能按時交付。
5. 它適用於在一個地方辦公的小團隊，一般10個人以內。這樣能使敏捷中主要的溝通方式「Face to Face」是可行的。

其次，敏捷開發是一套工具集，裡面有形形色色的工具，你可以不搞敏捷，但可以用那麼一兩個來提高工作效率。

比如：
1. 站會：三個問題，簡潔有效的小團隊溝通方式
2. 看板：直觀反映工作進度，反映流程遵守情況，反映流程缺陷
3. 演示，計劃，反思會：適合於小團隊的協作和優化反饋方式
4. 用戶故事：站在用戶的角度講需求
5. 持續集成：隨時高質量交付的基礎，有利於應對變化劇烈的市場

再其次，敏捷開發是一種企業管理方式

比如：
1. 一線員工可以同時是架構師，Scrum Master，開發工程師，測試工程師，發揮了他的主觀能動性，有利於創新和效率
2. 敏捷不專註于敏捷團隊中個人的績效考核，而更多的側重於整個團隊的績效，更好的避免了KPI驅動模式。
3. 把大項目拆分成小項目去做（每個Sprint都是一個迭代，需要輸出一個高質量的版本，相當於完成一個小項目），把bug的生存期控制在一個迭代以內，降低了風險，也減少了後期改bug的工作量。
4. 把數十人的大team 分成幾個敏捷團隊，這幾個敏捷團隊的Scrum Master/PO再組成一個更高一級的敏捷團隊，利用站會，反思，看板等等敏捷元素，可以避免數十份郵件也不能解決一個小問題，大家互相踢皮球，溝通不暢的大企業病。
5. 老闆可以是最大的PO，他給下面的高管講idea(User Story)，定期檢查Demo，把控產品用戶體驗，負責和外界的溝通合作-----比如喬布斯，360的周鴻禕等

就敏捷開發，我學校做過一個簡單的研究專題，主要總結了Martin Fowler 這位敏捷宣言的概念提出者之一，也是主要的Thoughtworks創始人提出的敏捷開發理念。希望這個帖子能對於敏捷理念與傳統理念，預測性（傳統工程）與適應性（敏捷），以人為本的敏捷理念，敏捷的架構以及自適應方式，以及敏捷的具體實例，應用場景都會有一點理解上的幫助吧。最後還有核心問題：你是否需要敏捷？畢竟自己需不需要才是最重要的，其他的都是方法論。
唯一有個小問題，我所做的總結是英文的PPT，鑒於時間有限，還望大家海涵。以後有機會，我可以簡單翻譯一個自己的中文版。希望圖文結合，療效好：）
核心觀點來自於他的宣言：The New Methodology

擁抱變化，輕量文檔，團隊合作，多個短的衝刺周期

短周期迭代交付，可視化，自適應調整，開放式及時溝通，所有的敏捷實踐基本都是圍繞這些核心展開，如果再要對敏捷的核心抽象就是迭代+自適應。

敏捷並不是快，而是靈活；
敏捷不要求面面俱到的文檔但離不開文檔；
敏捷開發要求最小化驗證、項目透明、及時調整、增量迭代。
敏捷開發在我看來並不是沒有缺點，它強調自組織，對人的要求太高；其次是強調溝通，對技術人員的打斷太多，影響工作效率。

看不清的話可以去這裡下載：資源下載

為什麼要提倡敏捷開發

人口紅利時代的結束，互聯網流量增量停滯，互聯網行業整體由增量市場轉為存量市場，創業的競爭壓力變大

資源的有限性，我們應該盡量先做最優先順序最高的事情，快速地試驗和學習

敏捷提倡自我總結和改進，不斷提高團隊成員的能力和素質

中國特色的敏捷

極限編程

每天只工作8小時？還沒到你『極限』嘛，工作量嚴重不飽和，來來，多給你分配點任務；

擁抱變化

產品、策劃需求頻繁變更，常常自打嘴巴，昨天說好的今天又變卦。

「我的需求有一個很『簡單』的改動……怎麼要花這麼久才搞好？你的代碼架構一點都不靈活，根本就不夠敏捷嘛！你懂得擁抱變化不？」

迭代式開發

做完了就趕緊先上線，出問題了就再修復一版更新上去

持續集成

哥天天提交幾百行代碼，不用編譯，不用自測，沒有Test Case，哥就是這麼自信。

測試驅動

我點了兩下，沒發現什麼明顯問題，可以發布出去了

sprint衝刺

版本明天就要上線了，今晚大伙兒來個通宵大作戰，努力衝刺一把。

迭代回顧

那誰，版本剛上線問題肯定很多，這兩天辛苦一下，手機24小時開機待命

結對編程

開玩笑，一份事情兩個人輪流干，每人只領一半工資可以不？

mvp最小可驗證產品——用一個最小的可實現模型去驗證你的需求，即最小的代價

產品

項目的特點

臨時性

獨特性

目的是為了結束

運營的特點

持續性

重複性

目的是為了延續

mvp的目的

降低風險

why

需求的不確定性

資源的有限性

做產品圍繞的兩個要點

用戶需求

互聯網行業通常並不是真實的用戶需求，是需要驗證的

互聯網——沒有永遠的真理，只有快速的迭代

如何實現

point估算

目的

評估故事的需要的點數，了解這個故事的大小

評估一個sprint完成的點數（團隊效率）

以歷史的角度分析團隊每個sprint完成的點數，從而量化團隊當前的效率

在燃盡圖中分析當前sprint的運行情況

根據團隊每周完成的平均點數和backlog需求的總點數計算項目需要的工期

實施

pm 閱讀story條目，講解這個條目中可能會有的問題及需要注意的事項，發起討論。

大家都理解這個story後開始做點數評估，按照：0,0.5,1,2,3,5,8,13,20,40,?,∞ 中的一個數字做為你對這個story的評估，這時你並不知道別人評估了多少，別人也不知道你評估了多少。

當大家都完成評估後，開始公開評估結果，這時我們要觀注結果的差異性。比如有人評估了1，而有人評估了8，顯然這裡面的差異是明顯的，這個時候我們需要考慮：為什麼有這麼大的差異，是不是有什麼我們遺漏了的？這時大家應該重新認識這個問題並評估。如果大家的意見比較一致，則可以進行下一個story的評估。

完整的總結腦圖，看不清的話可以去 http://pmowner.com 的資源下載中下載原圖：資源下載

快速迭代+快速嘗試+快速改進 + 充分交流+簡化流程

快速迭代：產品通過短周期的迭代交付，通過不斷迭代完善產品
快速嘗試：避免過長時間的需求分析及調研，快速嘗試。
快速改進：在迭代周期過後根據客戶反饋快速改進。
充分交流：團隊成員無縫的交流，如每天短時間的站立會議。
簡化流程：拒絕使用一切形式化的東西，使用簡單易用的工具開始工作。扔掉建模工具，word,ppt，使用白板+wiki。

我想試著從敏捷與傳統開發的不同入手來說明敏捷的本質。

傳統開發方式和敏捷的不同首先是世界觀（軟體開發的世界）的不同。

在傳統開發方式的世界觀里，軟體開發過程是確定的、可測的，只要在一開始努力收集到需要的信息並制定好計劃，然後忠實的執行計劃就應該可以成功。如果不成功一定是你在一開始就沒有做好，沒收集到必要的信息，計劃做的不好或者執行不到位。然後傳統開發方式就試圖引入更多的流程，文檔，試圖讓每一步都做到萬無一失。

而在敏捷的眼裡世界可不是這樣的，敏捷認為在軟體開發中，世界是變化的，有很多不確定性的。一方面，從認知角度來說，我們是無法在一開始就收集到確保成功所需要的所有信息的，必然是隨著開發的進行，我們對正在做的東西的認識才越來越深刻。因而做一段時間後常常有發現需求需要調整，或之前的設計不是最合適的情況發生。另一方面，世界本來就是在快速變化中，我們不得不隨之做出調整。因此敏捷的很多實踐主要針對如何應對變化。

我很喜歡把傳統開發方式比喻成普通火炮，而把敏捷開發比喻成導彈。兩種武器打擊目標的過程很形象的說明了兩種軟體開發過程的區別。火炮打擊目標時，要想打的准，則要寄希望於一開始瞄的夠准，而且對目標運動軌跡估計的夠准。一旦炮彈發射出去，就無法對速度、方向進行控制了。任何瞄準偏差，沒有預料到的目標移動軌跡變化，甚至風向的變化都會導致炮彈打偏。而導彈就不一樣了，只要設定好目標方位，並不需要一開始就精確瞄準。導彈發射出去後，會持續的收集自己的位置、方向、速度並根據目標的方位不斷的調整，最終能夠較精確的長距離命中目標。

其實這一切的根源都在於軟體開發是一個複雜的過程，複雜到各種基於預測式的（predictive）軟體開發方法和流程都不是太好使，因為這樣的成功要依賴於你在一開始就什麼都想到了、都做對了。更何況既定的流程很難應對好這種複雜帶來的不確定性。反而基於自適應式的（adaptive）方法，比如敏捷，不依賴於在一開始就什麼都想對、做對，而是依靠團隊緊密協作並不斷地在向前摸索中根據實際情況做出調整以適應現實情況，小步快跑，反而像導彈一樣，更容易命中目標。我在這裡並不是說流程不重要，而是在敏捷開發中，和流程相比，團隊成員的自發協作更重要。

那麼敏捷主要是靠什麼來應對這種變化的呢？下面再來說說敏捷的核心實踐方法：

增量加迭代式開發

要想應對變化就要能夠快速感知變化並作出反應。增量加迭代式開發就是定期增量產出可工作的軟體並收集反饋，然後做出相應的調整。即形成所謂的快速反饋循環，以迅速應對變化。

自組織團隊

團隊成員目標一致、緊密合作、自我組織和管理，並根據現實情況及時調整，而不是只能嚴格遵照計劃和流程來開發。遇山開山，遇河架橋。從而能高效的應對變化。即所謂的自適應。

大概就是這樣。

廣聯達對敏捷的理解：在精益的思想下，通過優秀的管理實踐和優秀的開發實踐來保證目標和客戶價值，不斷追求最佳的投入產出比。通過以人為本，持續優化來完善整個開發流程。

從一隻產品汪的角度出發，在我看來，敏捷開發就是一種保守主義的產品思維。

先說說建構VS擴展的二元分析框架：

建構論相信，存在一個全知的設計者，能夠掌握人類社會的所有知識，然後設計出一個完美的方案，讓人們各取所需、良性運轉。

而擴展論呢，它認為知識是分散掌握在一個一個具體的人手中，所有的這些人和知識匯聚在一起，才構成了知識的全部。

建構論的產品經理們，會認為開發好產品的方法是可以被完全學習和掌握的，只要有足夠優秀的設計者們聚集在一起，只要有足夠牛逼的idea，假以時日，就能設計開發出足夠優秀的產品。

擴展論的產品經理們，認為開發好產品的方法是不能被完全學習和掌握的，產品不可能覆蓋用戶的所有使用場景並預解決用戶的所有問題，一切的一切，只有讓產品直接面向用戶，到海量用戶中去尋求產品改進的方法。開發一個好產品的知識是分散在一個一個具體的用戶手上。

毫無疑問，保守主義站在了擴展論這一邊。

埃德蒙·伯克，保守主義的開山祖師說過：「我們擔憂人們會依照自身的理性主導其生活和交易，因為我們懷疑每個人的理性其實是相當有限的。」

應用到產品思維身上，我把它翻譯為：「我們擔憂產品經理們會依照自身對用戶和社會的想像，來固執地設計產品，因為我們懷疑每個人產品經理對用戶的理解其實都是相當有限的。」

這其實就是敏捷開發的出發點。一點一點往前拱，尋求漸進式改進，而不是革命式重建，不要求一步到位解決用戶的全部問題，不要貪多求全，而是小步快跑，快速檢驗，在實踐和迭代中去發現問題，解決問題，積累寶貴的經驗。

我相信每一位信奉敏捷的產品經理，同時也是一名保守主義者，不相信有什麼必然通往成功的道路，不相信有什麼全知全覺的產品大牛，只相信每一次過往經驗的成功和失敗，只相信用戶才是檢驗的唯一標準。

我們永遠無法找到真理，我們的每一次努力只是想離它更近一些。

看大家說了好多都非常有道理，我個人理解：

敏捷的核心是更早更多的獲得投資回報，降低投資風險。
敏捷適用於需求變化不可預測的場景
敏捷的兩大核心是價值驅動和快速迭代
敏捷來源於精益思想，是精益思想在IT行業的一種應用

原則：快速驗證，價值驅動，團隊自組織

少bb多干

敏捷的團隊，應該是一個充分溝通的團隊，工作內容的溝通、公司管理的溝通、職業發展和規劃的溝通甚至生活上的溝通，那種只會閉門造車，事不關己高高掛起的團隊，必然是一個沒有凝聚力的團隊，沒有效率的團隊，註定是一個失敗的團隊

小（迭代周期短），快（按照不同情況快速自適應調整），靈（人員之間的合作關係及協作流程靈活）

可以從多個層面、多個角度來理解敏捷開發。

「敏捷」是兩個字，我用最簡單的話來形容敏捷軟體開發就是四個字：

更好更快（或又好又快）

如果敏捷開發不能讓一個團隊、產品的開發比已有的基於 ISO 9001、SEI 的 CMM 與 CMMI、PMI 的 PMBOK 等等標準體系的開發更好更快，那麼請問，實施 Agile 到底有什麼意義？人們喜歡敏捷，僅僅是因為政治偏好、宗教崇拜？如果相比傳統方法沒有一點點的先進性和差異性，那麼 Agile 的存在就毫無意義，我想這是一個基本的邏輯。

下面先說說什麼是快，然後再說說什麼是好。

快

看到有人說「敏捷不是快」，這顯然是錯誤的。敏捷中的「捷」字不正是「快捷」的意思么？難道是語文不好？

查一下詞典，例如必應詞典中關於 agile 的解釋（http://cn.bing.com/dict/search?q=agile）如下：

1. able to move quickly and easily
2. able to think quickly, solve problems, and have new ideas

讀懂了敏捷的英文解釋，你就能明白西方的敏捷專家們為什麼把他們的一套方法統稱為 Agile methods，這還是非常貼切的，比 Light-weight 更好。

顯然，敏捷開發的一個基本要求首先就是團隊的行動要迅速，反應要快、要靈敏，相反地，那些反應遲鈍、緩慢，客戶響應拖拖拉拉，錯失市場良機的，自然不是敏捷開發。

除了反應快，響應快，軟體開發中的各種快（Quickness）還包括：交付快，發布快，開發快，糾錯快，收效快等等，這些快都與時間有關，代表了開發的速度與高效。

那麼，軟體開發怎樣才能快起來？一個很容易想到的答案是：輕裝上陣。

一個開發團隊怎樣才能輕裝上陣？減少不必要的環節與各種開銷、浪費（Eliminate waste）。

好

正確實施的敏捷開發理論上還應該帶來更好的效果，然而對於什麼是「好」，分歧是最大的，因為不同位置、不同背景，擁有不同價值觀的人群對於「好」的定義常常有著不同（有時甚至截然相反）的理解。

。。。

敏捷開發，我的理解是幾個層面：從商業的角度，敏捷開發可以在紛雜的市場環境中為企業主動的創造新的機會，例如更早的發布，發布的是更符合市場口味的功能；從流程的角色，敏捷開發更強調基於實際的持續改進的流程，而不是基於某種理論事先定義好的一套流程；從管理的角度，敏捷開發強調團隊結構、溝通、自管理、消除浪費

我的理解是，敏捷開發在三個方面優於傳統的瀑布模式：相應需求變化、團隊創造力、軟體交付質量。

1，敏捷開發使用固定長度的短迭代周期，每個迭代周期都會安排完成最有價值的，特性數量的功能特性，因此，響應需求變化的平均時間是1.5個迭代周期（最悲觀的情況就是，一個新的迭代剛開始就出現需求變化，那麼在下個迭代完成的時候，也能夠交付這個最新出現的需求）；

2，敏捷開發依賴於自組織團隊，依靠團隊所有成員的力量完成每個迭代中的開發工作。強調團隊對交付物有集體責任，需要團隊成員擁有T型技能（既有專精的一項技能，還有廣博的知識範圍）和人人為我，我為人人的原則。團隊成員關注的是交付物完成的如何，而不是自己的工作完成的如何。自組織團隊的創造力來源於每個成員的貢獻，必然好於傳統的由領導進行命令加控制模式的團隊；

3，為積極響應變化的需求，敏捷開發提倡多種工程實踐來提高交付物質量，如自動化測試、持續集成、重構、代碼的集體所有權等，比傳統的設計--開發--測試--修改流程能夠有更好的效果。

我覺得最早我以為敏捷就是擁抱變化，但其實他們都沒告訴我敏捷特別特別重要的是測試的敏捷。
也可能我所在的傳統行業企業級IT系統更依賴這個東西吧。