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

2、單，并設(shè)置了優(yōu)先級(jí);迭代-制定一次迭代的目標(biāo)，包含了在一個(gè)迭代中團(tuán)隊(duì)承諾交付的需求清單與為了達(dá)成目標(biāo)而設(shè)置的工作任務(wù)；每日計(jì)劃-制定每天的工作目標(biāo)，包含了團(tuán)隊(duì)中每個(gè)成員的工作任務(wù)。其計(jì)劃的過程是一個(gè)持續(xù)的過程，從項(xiàng)目開始時(shí)制定產(chǎn)品的愿景，到每個(gè)迭代開始時(shí)制定迭代計(jì)劃，敏捷項(xiàng)目的計(jì)劃不斷的細(xì)化，不斷的根據(jù)變化而調(diào)整，是Just-In-Time的計(jì)戈限2 .誤區(qū)：敏捷就是追求速度一次在和幾個(gè)朋友聊天的時(shí)候，有朋友說最近裝了有線數(shù)字電視，他覺得開發(fā)數(shù)字電視頻道服務(wù)的團(tuán)隊(duì)?wèi)?yīng)該是采用了敏捷的團(tuán)隊(duì)，因?yàn)槊扛粢欢螘r(shí)間，就會(huì)有新的功能發(fā)布，只是系統(tǒng)不穩(wěn)定，不得不經(jīng)常的重新啟動(dòng)機(jī)頂盒。這無疑是個(gè)非常有趣的關(guān)于敏

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

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

5、廣泛傳播。因此對于不同形式、不同需求階段、不同質(zhì)量要求的產(chǎn)品，對于敏捷開發(fā)的實(shí)際應(yīng)用是需要謹(jǐn)慎研究的，而不是絕對的生搬硬套和教條主義。4 .誤區(qū)：敏捷是“一個(gè)”過程敏捷不是一個(gè)過程，是一類過程的統(tǒng)稱，它們有一個(gè)共性，就是符合敏捷價(jià)值觀，遵循敏捷的原則。敏捷的價(jià)值觀如下：個(gè)體和交互勝過過程和工具可以工作的軟件勝過面面俱到的文檔客戶合作勝過合同談判響應(yīng)變化勝過遵循計(jì)劃由價(jià)值觀引出的12條敏捷原則：1）我們最優(yōu)先要做的是通過盡早的、持續(xù)的交付有價(jià)值的軟件來使客戶滿意。2）即使到了開發(fā)的后期，也歡迎改變需求。敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢c3）經(jīng)常性地交付可以工作的軟件，交付的間隔可以從幾個(gè)星期

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

7、于自組織的團(tuán)隊(duì)。12）每隔一定時(shí)間，團(tuán)隊(duì)會(huì)在如何才能更有效地工作方面進(jìn)行反省，然后相應(yīng)地對自己的行為進(jìn)行調(diào)整。建立敏捷聯(lián)盟的17位大師所創(chuàng)立的敏捷方法包括：極限編程，Scrum,特征驅(qū)動(dòng)開發(fā)，動(dòng)態(tài)系統(tǒng)開發(fā)方法，自適應(yīng)軟件開發(fā)，水晶方法，實(shí)用編程方法。這些方法統(tǒng)稱為敏捷方法。每個(gè)人都可以從敏捷宣言和原則出發(fā)，明確問題，找出一些解決方法，形成自己的過程。要實(shí)用而不是要機(jī)械式的規(guī)。讓開發(fā)人員理解并實(shí)施，體驗(yàn)到敏捷的好處，而不是盲目機(jī)械地實(shí)施規(guī)。CMM的最高境界（Level5）也是要求組織有足夠的靈活性適應(yīng)外界環(huán)境的變化，靈活的運(yùn)用規(guī)，而不是教條主義。5 .誤區(qū)：敏捷只適用于小型項(xiàng)目和團(tuán)隊(duì)敏捷實(shí)踐確實(shí)

8、很多發(fā)源于小型的項(xiàng)目團(tuán)隊(duì)，但并不是說敏捷只適合小型項(xiàng)目團(tuán)隊(duì)。其實(shí)，早期的Scrum項(xiàng)目就已經(jīng)有在500多人的大型項(xiàng)目中成功實(shí)施的案例。可能是由于大多數(shù)的敏捷團(tuán)隊(duì)一般都希望在59人的規(guī)模，并且希望團(tuán)隊(duì)成員在同一個(gè)工作區(qū)域，所以很多時(shí)候被認(rèn)為不適合跨地域，跨團(tuán)隊(duì)的大型項(xiàng)目的開發(fā)。其實(shí)，59人的團(tuán)隊(duì)規(guī)模是一個(gè)類似于一個(gè)戰(zhàn)斗小組的規(guī)模，這個(gè)團(tuán)隊(duì)小組負(fù)責(zé)完成一個(gè)共同的目標(biāo)。對于一個(gè)小型的項(xiàng)目而言，可能只需要一個(gè)這樣的戰(zhàn)斗小組就可以了，而對于一個(gè)大型的項(xiàng)目，我們就可以建立多個(gè)這樣的戰(zhàn)斗小組來完成項(xiàng)目目標(biāo)。在Scrum中，就有ScrumScaling,通過把一個(gè)大型項(xiàng)目團(tuán)隊(duì)合理分解為多個(gè)小型的Scrum團(tuán)隊(duì)

9、，每個(gè)團(tuán)隊(duì)都負(fù)責(zé)一個(gè)相對獨(dú)立的模塊或者功能，再配合其他的敏捷實(shí)踐，比如持續(xù)集成，ScrumofScrums等，加強(qiáng)團(tuán)隊(duì)之間的協(xié)作，從而確保項(xiàng)目的成功。所以，將敏捷實(shí)踐應(yīng)用于大型的、復(fù)雜的項(xiàng)目是完全可以的。6 .誤區(qū)：敏捷開發(fā)=簡化流程敏捷開發(fā)不一定能簡化工作流程，而且簡化流程也并非提出敏捷開發(fā)的初衷。敏捷開發(fā)最重視的是擁抱變化，至于怎么擁抱，只能隨機(jī)應(yīng)變。實(shí)際應(yīng)用中，既有流程相當(dāng)簡單的經(jīng)典Scrum過程，也有極為冗繁、不亞于CMMI的RUP根據(jù)應(yīng)用場景不一樣，項(xiàng)目組應(yīng)該使用最適合的流程。選擇敏捷開發(fā)流程時(shí)也應(yīng)帶著敏捷開發(fā)的思維去選擇，即快速響應(yīng)項(xiàng)目實(shí)際的流程需求、擁抱流程應(yīng)用過程中遇到的各種變

10、化。沒有銀彈，也沒有長期適合的項(xiàng)目流程，生搬硬套某個(gè)看似成熟的敏捷開發(fā)流程是大忌。7 .誤區(qū)：敏捷開發(fā)=快速開始編碼敏捷開發(fā)強(qiáng)調(diào)迭代，鼓勵(lì)開發(fā)人員用代碼說話，不過絕對不鼓勵(lì)沒想明白就寫代碼。符合敏捷開發(fā)思想的流程往往主在一個(gè)穩(wěn)定的基礎(chǔ)之上迭代完成各種功能。如果基礎(chǔ)都不牢固，迭代就無法進(jìn)行，整個(gè)開發(fā)過程就退化成不斷重寫的過程，浪費(fèi)開發(fā)時(shí)間。敏捷開發(fā)實(shí)際非常重視“設(shè)計(jì)”，并且對開發(fā)人員的設(shè)計(jì)水平提出了極高的要求，既要“持續(xù)重構(gòu)”又不能“過度設(shè)計(jì)”，稍有不慎就會(huì)陷入反復(fù)推翻已有代碼的窘境。對于功不夠的開發(fā)人員最好還是想好再寫代碼，設(shè)計(jì)的時(shí)候慢一點(diǎn)沒關(guān)系，盡量少的做無用功才是最重要。8 .誤區(qū)：敏捷是

11、徹底革命的。敏捷，特別是XP,讓人有耳目一新的感覺，覺得以前的所有軟件工程理論，設(shè)計(jì)方法都可以拋棄掉了，推翻一切，從頭再來。抱著這種想法實(shí)施敏捷，那就錯(cuò)了，敏捷不是“石頭里蹦出個(gè)大圣”，以前的軟件過程中也有敏捷的影子，只是沒有像敏捷一樣上升到價(jià)值觀和原則的高度，比如快速原型法。敏捷是在對已有的軟件過程方法的改進(jìn)，拋棄的是傳統(tǒng)軟件工程低效的外表，以往的軟件過程中很多技巧都是很實(shí)用的。實(shí)施敏捷應(yīng)該以現(xiàn)有的軟件過程為基礎(chǔ)，從敏捷宣言和原則出發(fā)，利用敏捷的方法來改善過程。9 .誤區(qū)：敏捷是反文檔的。文檔只是為了達(dá)成目標(biāo)的一種手段，如果這種手段是低效的，那就換一種手段?？墒峭耆珤仐壛宋臋n，怎樣解決溝通的

12、問題？難道你想每次溝通都完全用手比劃，用嘴說，跟不同的人重復(fù)表述同樣的想法，那樣更是低效的。應(yīng)該清楚文檔的本質(zhì)是把知識(shí)顯性化。在一個(gè)項(xiàng)目中存在很多需要溝通的知識(shí)，知識(shí)具備兩種形態(tài)，顯性的和隱性的，傳統(tǒng)的觀念是盡量把隱性知識(shí)顯性化，即文檔化，而忽略了這其中的代價(jià)（特別是更新同步文檔的代價(jià)）。因此，在實(shí)施敏捷的時(shí)候，需要在團(tuán)隊(duì)明確哪些知識(shí)是必須顯性的，這些知識(shí)可以通過文檔交流。哪些知識(shí)是可以隱性的，這些知識(shí)則完全可以通過口頭的方式進(jìn)行交流，以達(dá)到溝通的最正確效率。文檔不是目的，有效溝通才是目的。就工作量而言，不寫文檔，減少寫文檔時(shí)間，看起來確實(shí)可以加快開發(fā)速度，但實(shí)際會(huì)嚴(yán)重傷害項(xiàng)目?；ヂ?lián)網(wǎng)應(yīng)用開發(fā)

13、不需要似傳統(tǒng)大型軟件開發(fā)那樣，按照軟件工程，花大量時(shí)間去寫文檔。不要為了寫文檔而寫文檔，而是為了開發(fā)而寫文檔。例如需求文檔（或者功能文檔-可以含有版本信息，業(yè)務(wù)流程文檔，互通操作文檔），無論具體形式如何，需要清晰地給出你的應(yīng)用針對什么，提供什么，解決什么。需求文檔有時(shí)也可以作為測試的指導(dǎo)。如果是client+server,你需要給出本期目標(biāo)的性能，可以簡單到一兩頁紙，但是絕對不能缺。在迭代開發(fā)中，你不斷地修改它，它是你開發(fā)的軌跡。例如開發(fā)文檔，不一定要什么概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)這類學(xué)院派的東東，但是你需要有文檔能夠清晰描述開發(fā)對象的架構(gòu)，模塊劃分，client和server的交互流程，以與關(guān)鍵的核

14、心技術(shù)，例如，如何避免client和server中過多連接造成的server壓力，為何采用長連接tcp而非upd（反之亦然），如何制定心跳，是否需要通過使用底層的socket進(jìn)行特定優(yōu)化等等。你至少需要從架構(gòu)師的角度對產(chǎn)品進(jìn)行梳理，描述實(shí)現(xiàn)的架構(gòu)、采用的機(jī)制和關(guān)鍵技術(shù)。開發(fā)文檔或繁或簡，甚至可以在代碼過注釋說明，利用javadoc生產(chǎn)HTML格式不論。不要讓文檔成為開發(fā)的負(fù)擔(dān)，而是成為幫助?，F(xiàn)在工作的流動(dòng)性很大，沒有文檔，當(dāng)中一兩個(gè)開發(fā)人員離職，如何后續(xù)處理。沒有開發(fā)文檔，在架構(gòu)和關(guān)鍵技術(shù)上沒有想清楚，貿(mào)然而上，開發(fā)的永遠(yuǎn)只是個(gè)demo產(chǎn)品。沒有任何文檔，極容易導(dǎo)致推出后，疲于奔命地修修補(bǔ)補(bǔ)，

15、每天一個(gè)版本。敏捷開發(fā)是快,但是快不等于敏捷開發(fā)。10 .誤區(qū)：敏捷是自由的，無約束的。敏捷強(qiáng)調(diào)的是自組織團(tuán)隊(duì)，發(fā)揮人的能動(dòng)性，以動(dòng)力代替壓力，讓人有絕對自由的錯(cuò)覺。但是應(yīng)該清楚，凡事都是要講究一個(gè)平衡，人也是兩面的，消極的一面和積極的一面同時(shí)并存，絕對的自由會(huì)放縱人消極的一面。敏捷并非是絕對自由，無約束的。作為管理者，有一個(gè)職責(zé)，就是引導(dǎo)團(tuán)隊(duì)成員用自己積極的一面去壓制消極的一面，不能放任團(tuán)隊(duì)中出現(xiàn)搭便車的現(xiàn)象，否則將打擊整個(gè)團(tuán)隊(duì)的士氣。如果實(shí)在無效，那就只能將其排除出團(tuán)隊(duì)了，這個(gè)懲罰夠有約束力吧？11 .誤區(qū)：為了敏捷而敏捷“嗯，敏捷這么好，我們也敏捷吧”，可能很多人會(huì)有這種想法。忘了以前是

16、在哪兒看的大師采訪錄：Q“我們現(xiàn)有的過程很好，不知道怎么用敏捷改進(jìn)？”A：“既然很好，那就不要用敏捷”。做什么事情都要有明確目標(biāo)的，敏捷雖好，得看你需不需要，能不能解決你現(xiàn)在頭疼的問題，如果不是，那就不要給自己找麻煩了。12 .誤區(qū)：傳統(tǒng)開發(fā)能隨時(shí)轉(zhuǎn)變成敏捷開發(fā)敏捷開發(fā)過于誘人，很容易讓深受傳統(tǒng)軟件開發(fā)思想折磨的開發(fā)人員感覺敏捷開發(fā)就是靈丹妙藥。要想轉(zhuǎn)變，首先需要從思想上正確認(rèn)識(shí)敏捷開發(fā)的含義，了解它能解決什么問題、會(huì)帶來什么新的問題、對現(xiàn)有軟件/硬件資源有什么要求等。例如在原先采用CMM勺團(tuán)隊(duì)中，想利用敏捷開發(fā)簡化冗余的文檔、降低溝通成本，那么敏捷開發(fā)確實(shí)能在一定程度上緩解這些問題，但也會(huì)造

17、成部文檔缺失、溝通不夠深入的問題，在應(yīng)用敏捷開發(fā)之前需要先確定適合團(tuán)隊(duì)的新的文檔流程（代碼注釋能夠自動(dòng)/半自動(dòng)的變成團(tuán)隊(duì)需要的文檔么？），并且確定溝通的一些原則（比如，對于一些重要的溝通，是否還是用來進(jìn)行，不要過于“敏捷”？）。有趣的是，有可能在回答這幾個(gè)問題之后會(huì)發(fā)現(xiàn)，敏捷開發(fā)并不能解決項(xiàng)目中遇到的問題，反倒是其他方面出了問題。舉例來說。如果此前的開發(fā)方法是簡單的目標(biāo)管理，遇到的問題是項(xiàng)目進(jìn)度不可控、開發(fā)+測試的周期較長、不能與時(shí)響應(yīng)需求變化，那么敏捷開發(fā)能解決的是快速響應(yīng)需求變化，對項(xiàng)目進(jìn)度和開發(fā)測試周期幫助不大（沒有一種流程能夠承諾改善項(xiàng)目的開發(fā)效率！），但前提是開發(fā)人員必須懂得怎樣正確

18、的去迭代開發(fā)，并且必須認(rèn)識(shí)到一次迭代的完畢是以完成測試為標(biāo)準(zhǔn)的。在這個(gè)例子中可以看到，敏捷開發(fā)能帶來的好處非常有局限性，如果開發(fā)人員達(dá)不到一定的層次是很難受益的。與其號(hào)召使用敏捷開發(fā)，不如想想如何增加執(zhí)行力，以與找到周期偏長的根本原因（是因?yàn)樵O(shè)計(jì)不充分而返工？還是因?yàn)闆]有可以快速回歸的測試用例？等等）C13 .誤區(qū)：敏捷是CMM勺反義詞CMW是一種衡量軟件成熟度的標(biāo)準(zhǔn)，并非過程，和敏捷不是一類概念。如果要給敏捷找一個(gè)反義詞，傳統(tǒng)的瀑布式開發(fā)應(yīng)該更適宜一些。14 .誤區(qū)：敏捷開發(fā)=極限編程/Scrum/敏捷開發(fā)是一種方法論，只是一些基本原則的集合，并非具體流程。極限編程、Scrum等流程是具體的

19、實(shí)施方法，它們都聲稱符合敏捷開發(fā)的思想，但執(zhí)行起來是否真的“敏捷”，還得看參與者究竟思想上是否真的承受敏捷開發(fā)的原理。如果把結(jié)對編程、dailyscrum當(dāng)做是敏捷開發(fā)的表現(xiàn)，那更是本末倒置，可悲的是，不少人還真是這么認(rèn)為的。15 .誤區(qū)：迭代就是敏捷，UP屬于敏捷。UP是重型的過程，雖然引入了迭代，但是其原則和價(jià)值觀與敏捷是不同的。敏捷注重的是反饋，迭代周期盡量的短，重在客戶的參與，通過客戶的參與，獲取持續(xù)的反饋，不斷調(diào)整使整個(gè)項(xiàng)目走在正確的方向上。同時(shí)也給客戶一個(gè)感受和思考的機(jī)會(huì)，因?yàn)閷τ诖蠖鄶?shù)客戶而言，目標(biāo)是明確的（不排除有些客戶目標(biāo)也不明確），但是具體怎么做，開始時(shí)是沒有想法的，只有看

20、到具體的東西的時(shí)候，才知道“噢，原來可以這樣，那我想把這里調(diào)整一下”16 .誤區(qū)：重做就是重構(gòu)重做不等于重構(gòu)，很多場合這兩個(gè)概念是混淆的。但是在敏捷中，重構(gòu)的一個(gè)特征是必須可控的。當(dāng)對系統(tǒng)結(jié)構(gòu)進(jìn)行大的調(diào)整時(shí)，如果沒有測試驅(qū)動(dòng)輔助的話，那么可控性就會(huì)很差，這不能叫做重構(gòu)。17 .誤區(qū)：版本更新很快，甚至每天都有新版本。每天一個(gè)新版本。這種情況，最大可能是產(chǎn)品沒有經(jīng)過嚴(yán)格的測試，根本不穩(wěn)定，就直接放出來，結(jié)果在實(shí)際使用中bug漫天飛，開發(fā)人員不斷地推出版本來補(bǔ)窟窿。這種情況，別說商用版本，用戶無法承受如此頻繁的升級(jí)（升級(jí)畢竟耗時(shí)麻煩，而且流量是用戶自己掏的錢）即便是測版本，也絕不應(yīng)該如此頻繁和隨意

21、。測版本或試用版本也是經(jīng)過開發(fā)人員驗(yàn)證和測試后放出來，通過實(shí)際使用情況，收集用戶對功能和操作中的意見，并對實(shí)際使用中測試案例無法覆蓋的可能異常情況進(jìn)行驗(yàn)證。不是發(fā)現(xiàn)一個(gè)bug,就改一個(gè)，發(fā)布一個(gè)，而是收集反饋，統(tǒng)一修訂后，再釋放新版本(而這，通常時(shí)間是按周來計(jì)算的)，除非這個(gè)bug是個(gè)極其嚴(yán)重，必須馬上更正。每天一個(gè)版本，混亂。在Android上，你可以自行發(fā)布更新，但如果基于iOS的，在Apple的AppStore上發(fā)布，別說每天一個(gè)版本，就算每周一個(gè)版本，Apple的軟件審核流程還沒走完，就又扔一個(gè)新的版本，這就很容易造成下游工作根本沒常進(jìn)行。將版本更新速度視為敏捷開發(fā)，是完全錯(cuò)誤的。敏捷

22、開發(fā)在于你能夠準(zhǔn)確抓住市場，在時(shí)間窗口快速推出產(chǎn)品。由于市場的不確定性和用戶喜好/需求的不確定性，用戶通常不清楚需要什么，你先給他，他再去判斷，這需要在需求-開發(fā)-市場驗(yàn)證中進(jìn)行循環(huán)迭代，以用戶為最終目標(biāo)，而不是機(jī)械地將敏捷視為快，而判斷什么為快，又機(jī)械地用版本推出速度來說明，每天推一個(gè)版本，只能說明開發(fā)流程出了問題，整個(gè)學(xué)生小作坊。敏捷開發(fā)也仍然是和版本更新有一定的關(guān)系。但這個(gè)版本，不是小修小補(bǔ)的小版本，而是有新功能，新UI,新互動(dòng)方式，在用戶體驗(yàn)上有新的感受。這樣的版本，不可能一兩天就升級(jí)。另外，你推給客戶的都應(yīng)該是個(gè)穩(wěn)定的版本。18 .誤區(qū)：沒有分析和設(shè)計(jì)敏捷開發(fā)強(qiáng)調(diào)簡單設(shè)計(jì)，團(tuán)隊(duì)每個(gè)成

23、員都從接觸客戶到分析設(shè)計(jì)，到編碼，全部承當(dāng)。但是實(shí)際上團(tuán)隊(duì)成員的素質(zhì)參差不齊，如果只有簡單設(shè)計(jì)、立即編碼，而沒有后續(xù)的持續(xù)重構(gòu)等實(shí)踐，將導(dǎo)致設(shè)計(jì)混亂不一致，尤其是對老系統(tǒng)的功能升級(jí)，如果對原有系統(tǒng)的影響分析不夠，弱化了分析設(shè)計(jì)，將導(dǎo)致很多工作在后期頻繁變更，使得團(tuán)隊(duì)的挫折感增強(qiáng)，產(chǎn)生較多的重復(fù)工作和浪費(fèi)。必要的系統(tǒng)架構(gòu)和設(shè)計(jì)從來都是非常重要的。只是這里的分析設(shè)計(jì)有別于傳統(tǒng)的開發(fā)模式，應(yīng)該應(yīng)用敏捷的思想，簡單設(shè)計(jì)，持續(xù)重構(gòu)，盡快反饋等。19 .誤區(qū)：敏捷擁抱變化，因此前期需求可以隨意簡單因?yàn)槊艚莸膶?dǎo)向，可能造成的問題是，前期需求比較隨意，對需求質(zhì)量的控制弱化，需求變更更加頻繁，但是這并不意味著對需求可以不做深究，甚至可以隨意變更需求。(1)需求質(zhì)量的審核，仍然需要改進(jìn)，需求方向性的錯(cuò)誤將導(dǎo)致后續(xù)一系