敏捷開發(Agile development)

敏捷開發概述

　　敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。在敏捷開發中，軟體專案的構建被切分成多個子專案，各個子專案的成果都經過測試，具備整合和可執行的特徵。換言之，就是把一個大專案分為多個相互聯絡，但也可獨立執行的小專案，並分別完成，在此過程中軟體一直處於可使用狀態。

敏捷開發的路線^[1]

　　圖：敏捷開發的路線圖

　　Test-Driven Development，測試驅動開發。

　　它是敏捷開發的最重要的部分。在ThoughtWorks，我們實現任何一個功能都是從測試開始，首先對業務需求進行分析，分解為一個一個的Story，記錄在Story Card上。然後兩個人同時坐在電腦前面，一個人依照Story，從業務需求的角度來編寫測試程式碼，另一個人看著他並且進行思考，如果有不同的意見就會提出來進行討論，直到達成共識，這樣寫出來的測試程式碼就真實反映了業務功能需求。接著由另一個人控制鍵盤，編寫該測試程式碼的實現。如果沒有測試程式碼，就不能編寫功能的實現程式碼。先寫測試程式碼，能夠讓開發人員明確目標，就是讓測試通過。

　　Continuous Integration，持續整合。

　　在以往的軟體開發過程中，整合是一件很痛苦的事情，通常很長時間才會做一次整合，這樣的話，會引發很多問題，比如 build未通過或者單元測試失敗。敏捷開發中提倡持續整合，一天之內整合十幾次甚至幾十次，如此頻繁的整合能儘量減少衝突，由於整合很頻繁，每一次整合的改變也很少，即使整合失敗也容易定位錯誤。一次整合要做哪些事情呢？它至少包括：獲得所有原始碼、編譯原始碼、執行所有測試，包括單元測試、功能測試等；確認編譯和測試是否通過，最後傳送報告。當然也會做一些其它的任務，比如說程式碼分析、測試覆蓋率分析等等。在我們公司裡，開發人員的桌上有一個火山燈用來標誌整合的狀態，如果是黃燈，表示正在整合；如果是綠燈，表示上一次整合通過，開發人員在這時候獲得的程式碼是可用而可靠的；如果顯示為紅燈，就要小心了，上一次整合未通過，需要儘快定位失敗原因從而讓燈變綠。在持續整合上，我們公司使用的是自己開發的產品CruiseControl。

　　Refactoring，重構。

　　相信大家對它都很熟悉了，有很多很多的書用來介紹重構，最著名的是Martin的《重構》，Joshua的《從重構到模式》等。重構是在不改變系統外部行為下，對內部結構進行整理優化，使得程式碼儘量簡單、優美、可擴充套件。在以往開發中，通常是在有需求過來，現在的系統架構不容易實現，從而對原有系統進行重構；或者在開發過程中有剩餘時間了，對現在程式碼進行重構整理。但是在敏捷開發中，重構貫穿於整個開發流程，每一次開發者check in程式碼之前，都要對所寫程式碼進行重構，讓程式碼達到clean code that works。值得注意的是，在重構時，每一次改變要儘可能小，用單元測試來保證重構是否引起衝突，並且不只是對實現程式碼進行重構，如果測試程式碼中有重複，也要對它進行重構。

　　Pair-Programming，結對程式設計。

　　在敏捷開發中，做任何事情都是Pair的，包括分析、寫測試、寫實現程式碼或者重構。Pair做事有很多好處，兩個人在一起探討很容易產生思想的火花，也不容易走上偏路。在我們公司，還有很多事都是Pair來做，比如Pair學習，Pair翻譯，Pair做PPT，關於這個話題，錢錢同學有一篇很有名的文章對它進行介紹，名為Pair Programming (結對程式設計)。

　　Stand up，站立會議。

　　每天早上，專案組的所有成員都會站立進行一次會議，由於是站立的，所以時間不會很長，一般來說是15-20分鐘。會議的內容並不是需求分析、任務分配等，而是每個人都回答三個問題：1. 你昨天做了什麼？2. 你今天要做什麼？ 3. 你遇到了哪些困難？站立會議讓團隊進行交流，彼此相互熟悉工作內容，如果有人曾經遇到過和你類似的問題，那麼在站立會議後，他就會和你進行討論。

　　Frequent Releases，小版本釋出。

　　在敏捷開發中，不會出現這種情況，拿到需求以後就閉門造車，直到最後才將產品交付給客戶，而是儘量多的產品釋出，一般以周、月為單位。這樣，客戶每隔一段時間就會拿到釋出的產品進行試用，而我們可以從客戶那得到更多的反饋來改進產品。正因為釋出頻繁，每一個版本新增的功能簡單，不需要複雜的設計，這樣文件和設計就在很大程度上簡化了。又因為簡單設計，沒有複雜的架構，所以客戶有新的需求或者需求進行變動，也能很快的適應。

　　Minimal Documentation，較少的文件。

　　其實敏捷開發中並不是沒有文件，而是有大量的文件，即測試。這些測試程式碼真實的反應了客戶的需求以及系統API 的用法，如果有新人加入團隊，最快的熟悉專案的方法就是給他看測試程式碼，而比一邊看著文件一邊進行debug要高效。如果用書面文件或者註釋，某天程式碼變化了，需要對這些文件進行更新。一旦忘記更新文件，就會出現程式碼和文件不匹配的情況，這更加會讓人迷惑。而在敏捷中並不會出現，因為只有測試變化了，程式碼才會變化，測試是真實反應程式碼的。這時有人會問：程式碼不寫註釋行嗎？一般來說好的程式碼不是需要大量的註釋嗎？其實簡單可讀的程式碼才是好的程式碼，既然簡單可讀了，別人一看就能夠看懂，這時候根本不需要對程式碼進行任何註釋。若你覺得這段程式碼不加註釋的話別人可能看不懂，就表示設計還不夠簡單，需要對它進行重構。

　　Collaborative Focus，以合作為中心，表現為程式碼共享。

　　在敏捷開發中，程式碼是歸團隊所有而不是哪些模組的程式碼屬於哪些人，每個人都有權利獲得系統任何一部分的程式碼然後修改它，如果有人看到某些程式碼不爽的話，那他能夠對這部分程式碼重構而不需要徵求程式碼作者的同意，很可能也不知道是誰寫的這部分程式碼。這樣每個人都能熟悉系統的程式碼，即使團隊的人員變動，也沒有風險。

　　Customer Engagement ，現場客戶。

　　敏捷開發中，客戶是與開發團隊一起工作的，團隊到客戶現場進行開發或者邀請客戶到團隊公司裡來開發。如果開發過程中有什麼問題或者產品經過一個迭代後，能夠以最快速度得到客戶的反饋。

　　Automated Testing ，自動化測試。

　　為了減小人力或者重複勞動，所有的測試包括單元測試、功能測試或整合測試等都是自動化的，這對QA人員提出了更高的要求。他們要熟悉開發語言、自動化測試工具，能夠編寫自動化測試指令碼或者用工具錄製。我們公司在自動化測試上做了大量的工作，包括Selenium開源專案。

　　Adaptive Planning，可調整計劃。

　　敏捷開發中計劃是可調整的，並不是像以往的開發過程中，需求分析->概要設計->詳細設計->開發 ->測試->交付，每一個階段都是有計劃的進行，一個階段結束便開始下一個階段。而敏捷開發中只有一次一次的迭代，小版本的釋出，根據客戶反饋隨時作出相應的調整和變化。

　　敏捷開發過程與傳統的開發過程有很大不同，在這過程中，團隊是有激情有活力的，能夠適應更大的變化，做出更高質量的軟體。

敏捷開發的特點

　　敏捷方法主要有兩個特點，這也是其區別於其他方法，尤其是重型方法的最主要特徵:

　　（1）敏捷開發方法是“適應性”(Adaptive)而非“預設性” (Predictive)。

　　這裡說的預設性，可以通過一般性工程專案的做法理解，比如土木工程，在這類工程實踐中，有比較穩定的需求，同時建設專案的要求也相對固定，所以此類專案通常非常強調施工前的設計規劃。只要圖紙設計得合理並考慮充分，施工隊伍可以完全遵照圖紙順利建造，並且可以很方便地把圖紙劃分為許多更小的部分交給不同的施工人員分別完成。

　　然而，在軟體開發的專案中，這些穩定的因素卻很難尋求。軟體的設計難處在於軟體需求的不穩定，從而導致軟體過程的不可預測。但是傳統的控制專案模式都是試圖對一個軟體開發專案在很長的時間跨度內做出詳細的計劃，然後依計劃進行開發。所以，這類方法在不可預測的環境下，很難適應變化，甚至是拒絕變化。

　　與之相反的敏捷方法則是歡迎變化，目的就是成為適應變化的過程，甚至能允許改變自身來適應變化。所以稱之為適應性方法。 　　 　　（2）敏捷開發方法是“面向人” (people oriented)而非“面向過程”(process oriented)。

　　Matin Flower認為：“在敏捷開發過程中，人是第一位的，過程是第二位的。所以就個人來說，應該可以從各種不同的過程中找到真正適合自己的過程。”這與軟體工程理論提倡的先過程後人正好相反。 (續致信網上一頁內容)

　　在傳統的軟體開發工作中，專案團隊分配工作的重點是明確角色的定義，以個人的能力去適應角色，而角色的定義就是為了保證過程的實施，即個人以資源的方式被分配給角色，同時，資源是可以替代的，而角色不可以替代。

　　然而，傳統軟體開發的這些方法在敏捷開發方式中被完全顛覆。敏捷開發試圖使軟體開發工作能夠利用人的特點，充分發揮人的創造能力。

　　敏捷開發的目的是建立起一個專案團隊全員參與到軟體開發中，包括設定軟體開發流程的管理人員，只有這樣軟體開發流程才有可接受性。同時敏捷開發要求研發人員獨立自主在技術上進行決策，因為他們是最瞭解什麼技術是需要和不需要的。再者，敏捷開發特別重視專案團隊中的資訊交流，有調查顯示：“專案失敗的原因最終都可追溯到資訊沒有及時準確地傳遞到應該接受它的人。”

敏捷開發的價值觀

　　實際上敏捷開發運動在數年前就開始了，但它正式開始的標誌是2001年2月的“敏捷宣言”（Agile Manifesto），這項宣言是由17位當時稱之為“輕量級方法學家”所編寫簽署的，他們的價值觀是：個人與互動重於開發過程與工具；可用的軟體重於複雜的文件；尋求客戶的合作重於對合同的談判；對變化的響應重於始終遵循固定的計劃。

　　個人與互動重於開發過程與工具的原因：一個由優秀的人員組成但使用普通的工具，要比使用優秀的工具但由普通人組成、紊亂的小組做得更好。多年來人們花了很多時間試圖建立一種過程，以便把人當作機器上的一個可以替代的齒輪，但結果卻並不成功。敏捷過程是承認每個人都有特定的能力（以及缺點）對之加以利用，而不是把所有的人當成一樣來看待。更重要的是，在這樣的理念下，幾個專案做下來，每個人的能力都從中得以提高。這種人的能力的提高，對公司是無價之寶。而不至於把人當成齒輪，隨著時間的推移，人的能力慢慢被消耗掉，最後變成留之無用、棄之可惜的尷尬人物。

　　可用的軟體重於複雜的文件的原因:可用的軟體可以幫助開發人員在每次迭代結束的時候，獲得一個穩定的、逐漸增強的版本。從而允許專案儘早開始，並且更為頻繁的收集對產品和開發過程的反饋。隨著每次迭代完成軟體的增長，以保證開發小組始終是處理最有價值的功能，而且這些功能可以滿足使用者的期待。

　　尋求客戶的合作重於對合同的談判的原因:敏捷開發小組希望與專案有關的所有團體都在朝共同方向努力，合同談判有時會在一開始就使小組和客戶出於爭執中。敏捷開發追求的是要麼大家一起贏，要麼大家一起輸。換句話說，就是希望開發小組和客戶在面對專案的時候，以一種合作的態度共同向目標前進。當然，合同是必需的，但是如何起草條款，往往影響到不同的團體是進行合作式的還是對抗式的努力。

　　對變化的響應重於始終遵循固定的計劃的原因：敏捷開發認為對變化進行響應的價值重於始終遵循固定的計劃。他們最終的焦點是向用戶交付儘可能多的價值。除了最簡單的專案以外，使用者不可能知道他們所需要的所有功能的每個細節。不可避免地在過程中會產生新的想法，也許今天看起來是必需的功能，明天就會覺得不那麼重要了。隨著小組獲得更多的知識和經驗，他們的進展速度會比開始的時候期望值慢或者快。對敏捷開發來說，一個計劃是從某個角度對未來的看法，而具有多個不同的角度看問題是有可能的。

專案的敏捷開發方法

　　敏捷方法很多,包括 Scrum、極限程式設計、功能驅動開發以及統一過程（RUP）等多種法，這些方法本質實際上是一樣的，敏捷開發小組主要的工作方式可以歸納為：作為一個整體工作； 按短迭代週期工作； 每次迭代交付一些成果； 關注業務優先順序； 檢查與調整。下圖是典型的敏捷過程總圖，下面介紹其有關的特點。

　　1、敏捷小組作為一個整體工作

　　專案取得成功的關鍵在於，所有專案參與者都把自己看成朝向一個共同目標前進的團隊的一員。“扔過去不管”的心理不是屬於敏捷開發。設計師和架構師不會把程式設計“扔”給編碼人員；編碼人員也不會把只經過部分測試的程式碼“扔”給測試人員，一個成功的敏捷開發小組應該具有“我們一起參與其中的思想”， “幫助他人完成目標”這個理念是敏捷開發的根本管理文化。當然，儘管強調一個整體，小組中應該有一定的角色分配，各種敏捷開發方法角色的起名方案可能不同，但願則基本上是一樣的。第一個角色是產品所有者，他的主要職責包括：確認小組成員都在追求一個共同的目標前景；確定功能的優先等級，以便總是處理最有價值的功能；作出可以使專案的投入產生良好回報的決定。產品所有者通常是公司的市場部門或者產品管理部門的人員，在開發內部使用的軟體的時候，產品所有者可能是使用者、使用者的上級、分析師，也可能是為專案提供資金的人。

　　2、敏捷小組按短迭代週期工作

在敏捷專案中，總體上並沒有什麼上游階段、下游階段，你可以根據需要定義開發過程在初始階段可以有一個簡短的分析、建模、設計，但只要專案真正開始，每次迭代都會做同樣的工作（分析、設計、編碼、測試。等等）。迭代是受時間框限制的，也就是說即使放棄一些功能，也必須結束迭代。時間框一般很短，大部分是 2～4周，在 Scrum中採用的是 30個日曆天，也就是 4 周。迭代的時間長度一般是固定的，但也有報告說，有的小組在迭代開始的時候選擇合適的時間長度。

　　3、敏捷小組每次迭代交付一些成果

　　比選擇特定迭代長度更重要的，是開發小組在一次迭代中要把一個以上的不太精確的需求宣告，經過分析、設計、編碼、測試，變成可交付的軟體（稱之為功能增量）。當然並不需要把每次迭代的結果交付給使用者，但目標是可以交付，這就意味著每次迭代都會增加一些小功能，但增加的每個功能都要達到釋出質量。每次迭代結束的時候讓產品達到可交付狀態十分重要，但這並不意味著要完成釋出的全部工作，因為迭代的結果並不是真正釋出產品。假定一個小組需要在釋出產品之前對軟硬體進行為期兩個月的“平均無故障時間”（MTBF）測試，他們不可能縮短這兩個月的時間，但這個小組仍然是按照 4 周迭代，除了MTBF測試，其它都達到了釋出狀態。

　　4、敏捷小組關注業務優先順序

　　敏捷開發小組從兩個方面顯示出他們對業務優先順序的關注。首先，他們按照產品所有者制定的順序交付功能，而產品所有者一般會按照組織在專案上的投資回報最大化的方式來確定優先順序，並且把它組織到產品釋出中去。要達到這個目的，需要綜合考慮開發小組的能力，以及所需功能的優先順序來建立釋出計劃。在編寫功能的時候，需要使工能的依賴性最小化。如果開發一個功能必須依賴其它 3 個功能，那產品所有者這就很難確定功能優先順序。功能完全沒有依賴是不太可能的，但把功能依賴性控制在最低程度還是相當可行的。

　　5、敏捷小組檢查與調整

　　任何專案開始的時候所建立的計劃，僅僅是一個當前的猜測。有很多事情可以讓這樣的計劃失效：專案成員的增減，某種技術比預期的更好或更差，使用者改變了想法，競爭者迫使我們做出不同的反應，等等。對此，敏捷小組不是害怕這種變化，而是把這種變化看成使最終軟體更好地反映實際需要的一個機會。每次新迭代開始，敏捷小組都會結合上一次迭代中獲得新知識做出相應調整。如果認為一些因素可能會影響計劃的準確性，也可能更改計劃。比如發現某項工作比預計的更耗費時間，可能就會調整進展速度。也許，使用者看到交付的產品後改變了想法，這就產生反饋，比如他發現他更希望有另一項功能，或者某個功能並不像先前看得那麼重。通過先期釋出增加更多的使用者希望的功能，或者減少某些低價值功能，就可以增加產品的價值。迭代開發是在變與不變中尋求平衡，在迭代開始的時候尋求變，而在迭代開發期間不能改變，以期集中精力完成已經確定的工作。由於一次迭代的時間並不長，所以就使穩定性和易變性得到很好的平衡。在兩次迭代期間改變優先順序甚至功能本身，對於專案投資最大化是有益處的。從這個觀點來看，迭代週期的長度選擇就比較重要了，因為兩次迭代之間是提供變更的機會，週期太長，變更機會就可能失去；週期太短，會發生頻繁變更，而且分析、設計、編碼、測試這些工作都不容易做到位。綜合考慮，對於一個複雜專案，迭代週期選擇4周還是有道理的。

　　MIT Sloan Management Review（麻省理工學院專案管理評論）所刊載的一篇為時兩年對成功軟體專案的研究報告，報告指出了軟體專案獲得成功的共同因素，排在首位的是迭代開發，而不是瀑布過程。其它的因素是：

　　1、至少每天把新程式碼合併到整個系統，並且通過測試，對設計變更做出快速反應。

　　2、開發團隊具備運作多個產品的工作經驗。

　　3、很早就致力於構建和提供內聚的架構。

　　從這個報告中所透露出的資訊告訴我們，認真研究敏捷過程對軟體專案的成功是非常有意義的，它的意義在於：

　　1）給開發小組的自組織提供了機會

　　經典專案管理就好比一個具備中央排程服務的航空管理系統，這個系統是自治的，而且是封閉的，但現實中更龐大的系統，似乎並不屬於中央排程控制系統，但也同樣也是有效的。假如我們開車到某個地方，我們可以任意選擇所需要的路線，我們甚至不需要準確計算停車，只要我們遵守交通法規，駕駛員可以臨時根據路況改變某個轉彎點，在駕駛遊戲規則的框架內，依照自身最大利益做出決策。成千上萬的駕駛者，並不需要中央控制和排程服務，人們僅僅在簡單的交通法規的框架內，就可以完成綜合起來看是更龐大的目標，很多事情從管理的角度只要抓住關鍵點，並不需要多麼複雜的規則，往往會更有效。隨著系統複雜度的提高，中央控制和排程系統面臨崩潰。仔細研究交通系統的特點，我們會發現這樣的系統中獨立的個體在一組適當的規則下執行，並不需要設計每個個體臨時變更的方案，而每個個體只需要知道目標和大致的狀況，他們完全可以利用自己的聰明才智來決定自己的行為。

　　2）縮短了反饋通道

　　敏捷過程有效運作的另一個原因是，它極大的縮短了使用者與開發者、預測目標與實施狀況、投資與回報之間的反饋迴路。在面對不斷變化的市場、業務過程以及不斷髮展的技術狀態的時候，便需要有一種方法在比較短的時間內發展完善。事實上，所有的過程改進都不同程度的使用著戴明迴圈，以研究問題、測試解決方案、評估結果，進而根據已知的事實來進行改進，這就稱之為基於事實的決策模式，我們都知道，這比前端預測的決策方式更加有效。

　　3）易於集思廣益

　　敏捷過程能有效應用的另一個原因在於，它可以就一個問題集思廣益。我們的經驗告訴我們當一個問題發生的時候，總有某些人員知道問題所在，但他的觀點卻遭到忽視。例如太空梭在起飛階段發生爆炸，事後分析出了各種原因，但這種調查也提供給我們一個驚人的事實，就是部分工程師早就意識到這些潛在問題，卻無法說服他人重視這個擔憂。對這些事實的深入思考，促使我們研究我們應該採取何種管理系統，使前線工作人員的經驗、觀點及擔憂得到充分的重視呢？

對敏捷開發的誤解

　　誤解一：敏捷對人的要求很高

　　很多人在嘗試實施敏捷時說：敏捷對人的要求太高了，我們沒有這樣的條件，我們沒有這樣的人，因此我們沒法敏捷。可是，敏捷對人的要求真的那麼高麼？ 軟體歸根到底還是一種創造性活動，開發人員的技術水平和個人能力對軟體的質量還是起著決定性的作用，各種過程與方法只是幫助開發人員、測試人員等角色能夠更好的合作，從而產生更高的生產力。不管用什麼方法，開發人員的水平永遠都是一個主要的因素。

　　從另一個角度來看：過程和方法究竟能幫開發人員多大忙？對於技術水平較低的開發人員，敏捷方法和傳統方法對他的幫助是差不多的，因此看不到顯著的效果，甚至有些時候還有反效果；而隨著開發人員技術水平的提高，敏捷方法能夠解開對人的束縛，鼓勵創新，效果也會越來越顯著。

　　敏捷對人的要求並不高，而且會幫助你培養各種所需的能力，當然前提是你處在真正敏捷的環境中。

　　誤解二：敏捷沒有文件，也不做設計

　　這個誤解從XP開始就沒有停止過，XP鼓勵“在非到必要且意義重大時不寫文件”。這裡面提到的“必要且意義重大”是一個判斷標準，並不是所有的文件都不寫。例如，使用者手冊是不是“必要且意義重大”？這取決於客戶的要求，如果客戶不需要，那就不用寫,如果客戶需要，就一定要寫；再如，架構設計文件要不要寫？複雜要寫，不復雜不用寫。通常架構設計只需要比較簡單的文件，對於有些專案，一幅簡單的UML圖就夠了。因此，寫不寫，怎麼寫，都要根據這個文件到底有多大意義，產出和投入的比例，以及專案的具體情況決定。實際操作時可以讓專案組所有人員表決決定，儘量避免由某一個人（比如lead）來決定。

　　至於設計，XP奉行的是持續設計，並不是不設計。這實際上是將設計工作分攤到了每天的日常工作中，不斷的設計、改善（重構），使得設計一直保持靈活可靠。至於編碼前的預先設計，Kent Beck等人確實實行著不做任何預先設計的開發方式，但是對於我們這些“非大師”級開發人員，必要的預先設計還是需要的，只是不要太多，不要太細，要有將來會徹底顛覆的準備。

　　誤解三：敏捷好，其他方法不好

　　有些人一提到敏捷就大呼好，只要是敏捷的實踐就什麼都好，而提到CMMI等方法就大呼不好，不管是什麼只要沾上邊就哪裡都不好，似乎敏捷和其他方法是完全對立的。牛頓說過，我是站在了巨人的肩膀上。敏捷同樣也吸取了其他方法論的優點，也是站在了巨人的肩膀上，敏捷依然保持了很多歷史悠久的實踐和原則，只是表現方式不同罷了。

　　從另一個方面來看，方法本沒有好環，好與壞取決於是否適合解決你的問題。每一種方法都有他最善於解決的問題和最佳的發揮環境，在需求穩定、軟體複雜度相對不高的時代，瀑布模型也可以工作的很好，而敏捷恰好適用於變化快風險高的專案 － 這恰恰是現在很多專案的共性。

　　因此選擇一個方法或過程，並不是根據它是否敏捷，而應根據它是否適合。而要了解一個東西是否適合，還是要嘗試之後才知道，任何沒有經過實踐檢驗的東西都不可信。

　　誤解四：敏捷就是XP（極限程式設計），就是Scrum

　　XP 和Scrum只是眾多敏捷方法中的兩種，還有很多其他的敏捷方法。龍生九子各個不同，敏捷的這些方法看起來差別也是很大的，可是他們之所以被稱為敏捷方法，就是因為他們背後的理念和原則都是相同的，這個原則就是《敏捷宣言》。學習敏捷不僅僅要學習實踐，還要理解實踐後的原則，不僅要理解怎麼做，還要理解為什麼這麼做，以及什麼時候不要這麼做。

　　即使將XP或Scrum完全的應用的你的專案中，也未見得就能成功，適合別人的東西未必就適合你。敏捷的這些實踐和方法給了我們一個起點，但絕對不是終點，最適合你的方式還要由你自己在實際工作中探索和尋找。

　　誤解五：敏捷很好，因此我要制定標準，所有專案都要遵循著個標準

　　沒有哪兩個專案是一樣的，客戶是不一樣的，人員是不一樣的，需求是不一樣的，甚至沒有什麼可能是一樣的。不一樣的環境和問題，用同樣的方法解決，是不可能解決的好的。方法是為人服務的，應該為專案團隊找到最適合他們的方法，而不是先確定方法，再讓團隊適應這個方法。因此也不存在適合所有專案的統一的方法。任何企圖統一所有專案過程的方法都是不正確的。

　　同時，對於同一個團隊，隨著專案的進行，對需求理解的深入，對技術理解的深入，一開始適合專案的過程和方法也會漸漸的不適合。這時候也需要團隊對過程進行及時的調整，保證專案的質量和效率。敏捷是動態的，而非靜止不變的，因為這個世界本身就是變化的，在變化的世界使用不變的方法，是不現實的。銀彈從來就沒有過，在有限的將來也不會存在。