敏捷開發(fā)的常見誤區(qū)（精編版）

1、. . . . 1 / 8 敏捷開發(fā)的常見誤區(qū)1.誤區(qū)：敏捷項目沒有計劃由于產(chǎn)品需求的不確定性、甚至是未知的， 敏捷項目團隊很少能在項目之初建立一份類似于wbs 任務(wù)分解的進度表和甘特圖，但敏捷項目依然是有計劃的，和傳統(tǒng)的進度計劃不同，敏捷的計劃不是關(guān)注在完成項目的一個個活動或者說任務(wù)，比如說需求分析、概要設(shè)計、 詳細設(shè)計， 模塊一編碼等等，而是關(guān)注在客戶的需要，關(guān)注客戶價值的優(yōu)先級，其計劃的對象是用戶要求的功能， 例如用戶故事， 計劃活動的產(chǎn)出是一個設(shè)置了優(yōu)先級的用戶需要的功能列表。敏捷計劃分為以下幾個層次：愿景制定產(chǎn)品的長遠目標；路線圖制定實現(xiàn)長遠目標的分步實施計劃；發(fā)布制定一次發(fā)布的目標

2、，包含在一個發(fā)布中希望交付的需求清單，并設(shè)置了優(yōu)先級；迭代制定一次迭代的目標，包含了在一個迭代中團隊承諾交付的需求清單與為了達成目標而設(shè)置的工作任務(wù)；每日計劃制定每天的工作目標，包含了團隊中每個成員的工作任務(wù)。其計劃的過程是一個持續(xù)的過程，從項目開始時制定產(chǎn)品的愿景，到每個迭代開始時制定迭代計劃，敏捷項目的計劃不斷的細化，不斷的根據(jù)變化而調(diào)整，是just-in-time的計劃。2.誤區(qū)：敏捷就是追求速度一次在和幾個朋友聊天的時候，有朋友說最近裝了有線數(shù)字電視，他覺得開發(fā)數(shù)字電視頻道服務(wù)的團隊應(yīng)該是采用了敏捷的團隊，因為每隔一段時間，就會有新的功能發(fā)布，只是系統(tǒng)不穩(wěn)定，不得不經(jīng)常的重新啟動機頂盒

3、。這無疑是個非常有趣的關(guān)于敏捷的理解，似乎敏捷就是關(guān)注軟件功能的投放市場速度，而往往忽略質(zhì)量。 這是很多有關(guān)敏捷的理解中，比較典型的一種誤識。如果我們重讀一下敏捷的四句宣言以與12 條敏捷原則，應(yīng)該不難看出，敏捷實際是關(guān)注實現(xiàn)客戶的價值，而這一價值表達在“可工作的軟件”之中，這其實是對質(zhì)量的要求，它意味著交付的軟件是客戶需要的并且質(zhì)量穩(wěn)定的，是同時對需求質(zhì)量和開發(fā)質(zhì)量提出要求。另外， 因為市場的變化會促使客戶重新調(diào)整需求，以獲取最大的價值，因此敏捷強調(diào)“響應(yīng)變化”，迅速調(diào)整策略，以幫助客戶迅速對市場變化做出響應(yīng)。3.誤區(qū)：敏捷是放之四海而皆準的開發(fā)模式敏捷開發(fā)模式被互聯(lián)網(wǎng)企業(yè)廣泛采用的最重要的

4、原因有兩個：1)產(chǎn)品的功能升級更新?lián)Q代非?？?，大家都必須要在最短的時間搶占市場，吸引用戶， 而需求往往又不是非常的明確，甚至有時只是一個idea ，需要市場的反饋；2)產(chǎn)品的升級是可控的，即便是帶著一定缺陷的產(chǎn)品發(fā)布（又稱為“灰度發(fā)布”） ，我們都. . . . 2 / 8 可以在后臺悄悄的升級系統(tǒng)或修改bug ，對于用戶來說，任何時間打開瀏覽器都可以看到最新的產(chǎn)品，因此對用戶的影響是最小的，甚至用戶是不感知的。對于那些需要安裝到用戶使用的終端（電腦、手機、平板等）的應(yīng)用來說，這樣的升級方式可能就會導(dǎo)致客戶的反感、投訴和客戶流失。對于軟件提供商來說，還必須要考慮客戶拒絕升級情況下， 后臺系統(tǒng)必

5、須要同時支持多個版本的運行，否則就會遭到客戶的投訴，甚至?xí)l(fā)負面影響的廣泛傳播。因此對于不同形式、不同需求階段、 不同質(zhì)量要求的產(chǎn)品，對于敏捷開發(fā)的實際應(yīng)用是需要謹慎研究的，而不是絕對的生搬硬套和教條主義。4.誤區(qū)：敏捷是“一個”過程敏捷不是一個過程，是一類過程的統(tǒng)稱，它們有一個共性，就是符合敏捷價值觀，遵循敏捷的原則。 敏捷的價值觀如下：個體和交互勝過過程和工具可以工作的軟件勝過 面面俱到的文檔客戶合作勝過合同談判響應(yīng)變化勝過遵循計劃由價值觀引出的12 條敏捷原則：1)我們最優(yōu)先要做的是通過盡早的、持續(xù)的交付有價值的軟件來使客戶滿意。2)即使到了開發(fā)的后期， 也歡迎改變需求。 敏捷過程利用

6、變化來為客戶創(chuàng)造競爭優(yōu)勢。3)經(jīng)常性地交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。4)在整個項目開發(fā)期間，業(yè)務(wù)人員和開發(fā)人員必須天天都在一起工作。（注：這并不是地理位置上要求雙方在一起，否則跨國公司的協(xié)同開發(fā)就成了空話）5)圍繞被激勵起來的個體來構(gòu)建項目。給他們提供所需的環(huán)境和支持，并且信任他們能夠完成工作。6)在團隊部，最具有效果并且富有效率的傳遞信息的方法，就是面對面的交談。7)工作的軟件 是首要的進度度量標準。8)敏捷過程提倡可持續(xù)的開發(fā)速度。責任人、開發(fā)者和用戶應(yīng)該能夠保持一個長期的、恒定的開發(fā)速度。9)不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計會增強敏捷能力。1

7、0)簡單使未完成的工作最大化的藝術(shù)是根本的。11)最好的構(gòu)架、需求和設(shè)計出自于自組織的團隊。. . . . 3 / 8 12)每隔一定時間， 團隊會在如何才能更有效地工作方面進行反省，然后相應(yīng)地對自己的行為進行調(diào)整。建立敏捷聯(lián)盟的17 位大師所創(chuàng)立的敏捷方法包括：極限編程， scrum，特征驅(qū)動開發(fā)，動態(tài)系統(tǒng)開發(fā)方法，自適應(yīng)軟件開發(fā)，水晶方法，實用編程方法。這些方法統(tǒng)稱為敏捷方法。每個人都可以從敏捷宣言和原則出發(fā)，明確問題，找出一些解決方法，形成自己的過程。要實用而不是要機械式的規(guī)。讓開發(fā)人員理解并實施，體驗到敏捷的好處，而不是盲目機械地實施規(guī)。 cmmi的最高境界（level 5 ）也是要求

8、組織有足夠的靈活性適應(yīng)外界環(huán)境的變化，靈活的運用規(guī)，而不是教條主義。5.誤區(qū)：敏捷只適用于小型項目和團隊敏捷實踐確實很多發(fā)源于小型的項目團隊，但并不是說敏捷只適合小型項目團隊。其實， 早期的 scrum項目就已經(jīng)有在500 多人的大型項目中成功實施的案例?？赡苁怯捎诖蠖鄶?shù)的敏捷團隊一般都希望在59 人的規(guī)模，并且希望團隊成員在同一個工作區(qū)域，所以很多時候被認為不適合跨地域，跨團隊的大型項目的開發(fā)。其實， 59 人的團隊規(guī)模是一個類似于一個戰(zhàn)斗小組的規(guī)模，這個團隊小組負責完成一個共同的目標。 對于一個小型的項目而言，可能只需要一個這樣的戰(zhàn)斗小組就可以了，而對于一個大型的項目，我們就可以建立多個這

9、樣的戰(zhàn)斗小組來完成項目目標。在 scrum中，就有scrum scaling，通過把一個大型項目團隊合理分解為多個小型的scrum 團隊，每個團隊都負責一個相對獨立的模塊或者功能，再配合其他的敏捷實踐，比如持續(xù)集成， scrum of scrums等，加強團隊之間的協(xié)作，從而確保項目的成功。所以，將敏捷實踐應(yīng)用于大型的、復(fù)雜的項目是完全可以的。6.誤區(qū)：敏捷開發(fā) = 簡化流程敏捷開發(fā)不一定能簡化工作流程，而且簡化流程也并非提出敏捷開發(fā)的初衷。敏捷開發(fā)最重視的是擁抱變化，至于怎么擁抱，只能隨機應(yīng)變。實際應(yīng)用中，既有流程相當簡單的經(jīng)典scrum過程，也有極為冗繁、不亞于cmmi的 rup ，根據(jù)應(yīng)

10、用場景不一樣，項目組應(yīng)該使用最適合的流程。選擇敏捷開發(fā)流程時也應(yīng)帶著敏捷開發(fā)的思維去選擇，即快速響應(yīng)項目實際的流程需求、擁抱流程應(yīng)用過程中遇到的各種變化。沒有銀彈， 也沒有長期適合的項目流程，生搬硬套某個看似成熟的敏捷開發(fā)流程是大忌。7.誤區(qū)：敏捷開發(fā) = 快速開始編碼敏捷開發(fā)強調(diào)迭代，鼓勵開發(fā)人員用代碼說話，不過絕對不鼓勵沒想明白就寫代碼。符合敏捷開發(fā)思想的流程往往主在一個穩(wěn)定的基礎(chǔ)之上迭代完成各種功能。如果基礎(chǔ)都不牢固，迭代就無法進行，整個開發(fā)過程就退化成不斷重寫的過程，浪費開發(fā)時間。敏捷開發(fā)實際非常重視“設(shè)計” ，并且對開發(fā)人員的設(shè)計水平提出了極高的要求，既要“持續(xù)重構(gòu)”又. . . .

11、 4 / 8 不能“過度設(shè)計” ，稍有不慎就會陷入反復(fù)推翻已有代碼的窘境。對于功不夠的開發(fā)人員最好還是想好再寫代碼，設(shè)計的時候慢一點沒關(guān)系，盡量少的做無用功才是最重要。8.誤區(qū)：敏捷是徹底革命的。敏捷，特別是xp ，讓人有耳目一新的感覺，覺得以前的所有軟件工程理論，設(shè)計方法都可以拋棄掉了，推翻一切，從頭再來。抱著這種想法實施敏捷，那就錯了，敏捷不是“石頭里蹦出個大圣” ，以前的軟件過程中也有敏捷的影子，只是沒有像敏捷一樣上升到價值觀和原則的高度， 比如快速原型法。敏捷是在對已有的軟件過程方法的改進，拋棄的是傳統(tǒng)軟件工程低效的外表， 以往的軟件過程中很多技巧都是很實用的。實施敏捷應(yīng)該以現(xiàn)有的軟件

12、過程為基礎(chǔ)，從敏捷宣言和原則出發(fā)，利用敏捷的方法來改善過程。9.誤區(qū)：敏捷是反文檔的。文檔只是為了達成目標的一種手段，如果這種手段是低效的，那就換一種手段?？墒峭耆珤仐壛宋臋n， 怎樣解決溝通的問題？難道你想每次溝通都完全用手比劃，用嘴說， 跟不同的人重復(fù)表述同樣的想法，那樣更是低效的。應(yīng)該清楚 文檔的本質(zhì)是把知識顯性化。在一個項目中存在很多需要溝通的知識，知識具備兩種形態(tài)，顯性的和隱性的，傳統(tǒng)的觀念是盡量把隱性知識顯性化，即文檔化，而忽略了這其中的代價（特別是更新同步文檔的代價）。因此， 在實施敏捷的時候，需要在團隊明確哪些知識是必須顯性的，這些知識可以通過文檔交流。 哪些知識是可以隱性的，這

13、些知識則完全可以通過口頭的方式進行交流，以達到溝通的最正確效率。文檔不是目的，有效溝通才是目的。就工作量而言， 不寫文檔，減少寫文檔時間，看起來確實可以加快開發(fā)速度，但實際會嚴重傷害項目。 互聯(lián)網(wǎng)應(yīng)用開發(fā)不需要似傳統(tǒng)大型軟件開發(fā)那樣，按照軟件工程， 花大量時間去寫文檔。 不要為了寫文檔而寫文檔，而是為了開發(fā)而寫文檔。例如需求文檔（或者功能文檔- 可以含有版本信息，業(yè)務(wù)流程文檔， 互通操作文檔） ，無論具體形式如何，需要清晰地給出你的應(yīng)用針對什么，提供什么， 解決什么。需求文檔有時也可以作為測試的指導(dǎo)。如果是client+server，你需要給出本期目標的性能，可以簡單到一兩頁紙，但是絕對不能缺

14、。在迭代開發(fā)中，你不斷地修改它，它是你開發(fā)的軌跡。例如開發(fā)文檔， 不一定要什么概要設(shè)計、詳細設(shè)計這類學(xué)院派的東東，但是你 需要有文檔能夠清晰描述開發(fā)對象的架構(gòu)，模塊劃分，client和 server的交互流程，以與關(guān)鍵的核心技術(shù)，例如，如何避免client和 server中過多連接造成的server壓力， 為何采用長連接tcp而非 upd （反之亦然） ，如何制定心跳， 是否需要通過使用底層的socket 進行特定優(yōu)化等等。你至少需要從架構(gòu)師的角度對產(chǎn)品進行梳理，描述實現(xiàn)的架構(gòu)、采用的機制和關(guān)鍵技術(shù)。開發(fā)文檔或繁或簡，甚至可以在代碼過注釋說明，利用javadoc 生產(chǎn) html ，格式不論。.

15、 . . . 5 / 8 不要讓文檔成為開發(fā)的負擔，而是成為幫助。現(xiàn)在工作的流動性很大，沒有文檔， 當中一兩個開發(fā)人員離職，如何后續(xù)處理。沒有開發(fā)文檔，在架構(gòu)和關(guān)鍵技術(shù)上沒有想清楚，貿(mào)然而上，開發(fā)的永遠只是個demo產(chǎn)品。沒有任何文檔，極容易導(dǎo)致推出后，疲于奔命地修修補補，每天一個版本。敏捷開發(fā)是快，但是快不等于敏捷開發(fā)。10.誤區(qū)：敏捷是自由的，無約束的。敏捷強調(diào)的是自組織團隊，發(fā)揮人的能動性，以動力代替壓力，讓人有絕對自由的錯覺。但是應(yīng)該清楚， 凡事都是要講究一個平衡，人也是兩面的， 消極的一面和積極的一面同時并存，絕對的自由會放縱人消極的一面。敏捷并非是絕對自由，無約束的。作為管理者，有

16、一個職責，就是引導(dǎo)團隊成員用自己積極的一面去壓制消極的一面，不能放任團隊中出現(xiàn)搭便車的現(xiàn)象， 否則將打擊整個團隊的士氣。如果實在無效，那就只能將其排除出團隊了，這個懲罰夠有約束力吧？11.誤區(qū)：為了敏捷而敏捷“嗯，敏捷這么好，我們也敏捷吧”，可能很多人會有這種想法。忘了以前是在哪兒看的大師采訪錄：q ： “我們現(xiàn)有的過程很好，不知道怎么用敏捷改進？”a： “既然很好，那就不要用敏捷”。做什么事情都要有明確目標的，敏捷雖好， 得看你需不需要， 能不能解決你現(xiàn)在頭疼的問題，如果不是，那就不要給自己找麻煩了。12.誤區(qū)：傳統(tǒng)開發(fā)能隨時轉(zhuǎn)變成敏捷開發(fā)敏捷開發(fā)過于誘人， 很容易讓深受傳統(tǒng)軟件開發(fā)思想折磨

17、的開發(fā)人員感覺敏捷開發(fā)就是靈丹妙藥。 要想轉(zhuǎn)變，首先需要從思想上正確認識敏捷開發(fā)的含義，了解它能解決什么問題、會帶來什么新的問題、對現(xiàn)有軟件/ 硬件資源有什么要求等。例如在原先采用cmm 的團隊中， 想利用敏捷開發(fā)簡化冗余的文檔、降低溝通成本， 那么敏捷開發(fā)確實能在一定程度上緩解這些問題，但也會造成部文檔缺失、溝通不夠深入的問題，在應(yīng)用敏捷開發(fā)之前需要先確定適合團隊的新的文檔流程（代碼注釋能夠自動/ 半自動的變成團隊需要的文檔么？） ，并且確定溝通的一些原則（比如，對于一些重要的溝通，是否還是用來進行，不要過于“敏捷”？） 。有趣的是，有可能在回答這幾個問題之后會發(fā)現(xiàn)，敏捷開發(fā)并不能解決項目中

18、遇到的問題，反倒是其他方面出了問題。舉例來說。如果此前的開發(fā)方法是簡單的目標管理，遇到的問題是項目進度不可控、開發(fā)+測試的周期較長、不能與時響應(yīng)需求變化，那么敏捷開發(fā)能解決的是快速響應(yīng)需求變化，對項目進度和開發(fā)測試周期幫助不大（沒有一種流程能夠承諾改善項目的開發(fā)效率！） ，但前提. . . . 6 / 8 是開發(fā)人員必須懂得怎樣正確的去迭代開發(fā)，并且必須認識到一次迭代的完畢是以完成測試為標準的 。在這個例子中可以看到，敏捷開發(fā)能帶來的好處非常有局限性，如果開發(fā)人員達不到一定的層次是很難受益的。與其號召使用敏捷開發(fā)，不如想想如何增加執(zhí)行力，以與找到周期偏長的根本原因（是因為設(shè)計不充分而返工？還是

19、因為沒有可以快速回歸的測試用例？等等）。13.誤區(qū)：敏捷是cmm 的反義詞cmm 只是一種衡量軟件成熟度的標準，并非過程，和敏捷不是一類概念。如果要給敏捷找一個反義詞，傳統(tǒng)的瀑布式開發(fā)應(yīng)該更適宜一些。14.誤區(qū)：敏捷開發(fā) = 極限編程 /scrum/ 敏捷開發(fā)是一種方法論，只是一些基本原則的集合，并非具體流程。極限編程、 scrum 等流程是具體的實施方法，它們都聲稱符合敏捷開發(fā)的思想，但執(zhí)行起來是否真的“敏捷” ，還得看參與者究竟思想上是否真的承受敏捷開發(fā)的原理。如果把結(jié)對編程、daily scrum 當做是敏捷開發(fā)的表現(xiàn)，那更是本末倒置，可悲的是，不少人還真是這么認為的。15.誤區(qū)：迭代就

20、是敏捷，up屬于敏捷。up 是重型的過程，雖然引入了迭代，但是其原則和價值觀與敏捷是不同的。敏捷注重的是反饋，迭代周期盡量的短，重在客戶的參與，通過客戶的參與，獲取持續(xù)的反饋，不斷調(diào)整使整個項目走在正確的方向上。同時也給客戶一個感受和思考的機會，因為對于大多數(shù)客戶而言，目標是明確的（不排除有些客戶目標也不明確），但是具體怎么做，開始時是沒有想法的，只有看到具體的東西的時候，才知道“噢，原來可以這樣，那我想把這里調(diào)整一下”。16.誤區(qū)：重做就是重構(gòu)重做不等于重構(gòu)，很多場合這兩個概念是混淆的。但是在敏捷中， 重構(gòu)的一個特征是必須可控的。當對系統(tǒng)結(jié)構(gòu)進行大的調(diào)整時，如果沒有測試驅(qū)動輔助的話，那么可控

21、性就會很差，這不能叫做重構(gòu)。17.誤區(qū)：版本更新很快，甚至每天都有新版本。每天一個新版本。這種情況，最大可能是產(chǎn)品沒有經(jīng)過嚴格的測試，根本不穩(wěn)定，就直接放出來， 結(jié)果在實際使用中bug 漫天飛， 開發(fā)人員不斷地推出版本來補窟窿。這種情況，別說商用版本，用戶無法承受如此頻繁的升級（升級畢竟耗時麻煩， 而且流量是用戶自己掏的錢），即便是測版本，也絕不應(yīng)該如此頻繁和隨意。測版本或試用版本也是經(jīng)過開發(fā)人員驗證和測試后放出來，通過實際使用情況，收集用戶對. . . . 7 / 8 功能和操作中的意見，并對實際使用中測試案例無法覆蓋的可能異常情況進行驗證。不是發(fā)現(xiàn)一個 bug，就改一個，發(fā)布一個，而是收集

22、反饋，統(tǒng)一修訂后，再釋放新版本（而這，通常時間是按周來計算的），除非這個bug 是個極其嚴重，必須馬上更正。每天一個版本，混亂。在android 上，你可以自行發(fā)布更新，但如果基于ios 的，在 apple的 app store 上發(fā)布，別說每天一個版本，就算每周一個版本，apple 的軟件審核流程還沒走完，就又扔一個新的版本，這就很容易造成下游工作根本沒常進行。將版本更新速度視為敏捷開發(fā)，是完全錯誤的。 敏捷開發(fā)在于你能夠準確抓住市場，在時間窗口快速推出產(chǎn)品。由于市場的不確定性和用戶喜好/ 需求的不確定性，用戶通常不清楚需要什么，你先給他，他再去判斷，這需要在需求- 開發(fā) - 市場驗證中進行

23、循環(huán)迭代，以用戶為最終目標， 而不是機械地將敏捷視為快， 而判斷什么為快， 又機械地用版本推出速度來說明，每天推一個版本，只能說明開發(fā)流程出了問題，整個學(xué)生小作坊。敏捷開發(fā)也仍然是和版本更新有一定的關(guān)系。但這個版本， 不是小修小補的小版本，而是有新功能，新ui，新互動方式，在用戶體驗上有新的感受。這樣的版本，不可能一兩天就升級。另外， 你推給客戶的都應(yīng)該是個穩(wěn)定的版本。18.誤區(qū)：沒有分析和設(shè)計敏捷開發(fā)強調(diào)簡單設(shè)計，團隊每個成員都從接觸客戶到分析設(shè)計，到編碼， 全部承當。 但是實際上團隊成員的素質(zhì)參差不齊，如果只有簡單設(shè)計、立即編碼， 而沒有后續(xù)的持續(xù)重構(gòu)等實踐， 將導(dǎo)致設(shè)計混亂不一致，尤其是

24、對老系統(tǒng)的功能升級，如果對原有系統(tǒng)的影響分析不夠，弱化了分析設(shè)計，將導(dǎo)致很多工作在后期頻繁變更，使得團隊的挫折感增強，產(chǎn)生較多的重復(fù)工作和浪費。必要的系統(tǒng)架構(gòu)和設(shè)計從來都是非常重要的。只是這里的分析設(shè)計有別于傳統(tǒng)的開發(fā)模式，應(yīng)該應(yīng)用敏捷的思想，簡單設(shè)計，持續(xù)重構(gòu)，盡快反饋等。19.誤區(qū)：敏捷擁抱變化，因此前期需求可以隨意簡單因為敏捷的導(dǎo)向，可能造成的問題是，前期需求比較隨意，對需求質(zhì)量的控制弱化，需求變更更加頻繁，但是這并不意味著對需求可以不做深究，甚至可以隨意變更需求。（1）需求質(zhì)量的審核，仍然需要改進，需求方向性的錯誤將導(dǎo)致后續(xù)一系列的工作浪費，所以團隊部應(yīng)該設(shè)定里程碑和review 標準，從