敏捷開發(Agile development)

敏捷開發(Agile development)

敏捷開發是一種以人爲核心、迭代、按部就班的開發方法。在敏捷開發中，軟件項目的構建被切分紅多個子項目，各個子項目的成果都通過測試，具有集成和可運行的特徵。換言之，就是把一個大項目分爲多個相互聯繫，但也可獨立運行的小項目，並分別完成，在此過程當中軟件一直處於可以使用狀態。

 

敏捷開發的路線圖：

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）等多種法，這些方法本質其實是同樣的，敏捷開發小組主要的工做方式能夠概括爲：做爲一個總體工做； 按短迭代週期工做； 每次迭代交付一些成果； 關注業務優先級； 檢查與調整。下圖是典型的敏捷過程總圖，下面介紹其有關的特色。

　　

　　一、敏捷小組做爲一個總體工做

　　項目取得成功的關鍵在於，全部項目參與者都把本身當作朝向一個共同目標前進的團隊的一員。「扔過去無論」的心理不是屬於敏捷開發。設計師和架構師不會把程序設計「扔」給編碼人員；編碼人員也不會把只通過部分測試的代碼「扔」給測試人員，一個成功的敏捷開發小組應該具備「咱們一塊兒參與其中的思想」， 「幫助他人完成目標」這個理念是敏捷開發的根本管理文化。固然，儘管強調一個總體，小組中應該有必定的角色分配，各類敏捷開發方法角色的起名方案可能不一樣，希望則基本上是同樣的。第一個角色是產品全部者，他的主要職責包括：確認小組成員都在追求一個共同的目標前景；肯定功能的優先等級，以便老是處理最有價值的功能；做出能夠使項目的投入產生良好回報的決定。產品全部者一般是公司的市場部門或者產品管理部門的人員，在開發內部使用的軟件的時候，產品全部者多是用戶、用戶的上級、分析師，也多是爲項目提供資金的人。

　　二、敏捷小組按短迭代週期工做

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

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

　　比選擇特定迭代長度更重要的，是開發小組在一次迭代中要把一個以上的不太精確的需求聲明，通過分析、設計、編碼、測試，變成可交付的軟件（稱之爲功能增量）。固然並不須要把每次迭代的結果交付給用戶，但目標是能夠交付，這就意味着每次迭代都會增長一些小功能，但增長的每一個功能都要達到發佈質量。每次迭代結束的時候讓產品達到可交付狀態十分重要，但這並不意味着要完成發佈的所有工做，由於迭代的結果並非真正發佈產品。假定一個小組須要在發佈產品以前對軟硬件進行爲期兩個月的「平均無端障時間」（MTBF）測試，他們不可能縮短這兩個月的時間，但這個小組仍然是按照 4 周迭代，除了MTBF測試，其它都達到了發佈狀態。

　　四、敏捷小組關注業務優先級

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

　　五、敏捷小組檢查與調整

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

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

　　一、至少天天把新代碼合併到整個系統，而且經過測試，對設計變動作出快速反應。

　　二、開發團隊具有運做多個產品的工做經驗。

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

　　從這個報告中所透露出的信息告訴咱們，認真研究敏捷過程對軟件項目的成功是很是有意義的，它的意義在於：

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

　　經典項目管理就比如一個具有中央調度服務的航空管理系統，這個系統是自治的，並且是封閉的，但現實中更龐大的系統，彷佛並不屬於中央調度控制系統，但也一樣也是有效的。假如咱們開車到某個地方，咱們能夠任意選擇所須要的路線，咱們甚至不須要準確計算停車，只要咱們遵照交通法規，駕駛員能夠臨時根據路況改變某個轉彎點，在駕駛遊戲規則的框架內，依照自身最大利益作出決策。成千上萬的駕駛者，並不須要中央控制和調度服務，人們僅僅在簡單的交通法規的框架內，就能夠完成綜合起來看是更龐大的目標，不少事情從管理的角度只要抓住關鍵點，並不須要多麼複雜的規則，每每會更有效。隨着系統複雜度的提升，中央控制和調度系統面臨崩潰。仔細研究交通系統的特色，咱們會發現這樣的系統中獨立的個體在一組適當的規則下運行，並不須要設計每一個個體臨時變動的方案，而每一個個體只須要知道目標和大體的情況，他們徹底能夠利用本身的聰明才智來決定本身的行爲。

　　2）縮短了反饋通道

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

　　3）易於集思廣益

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

對敏捷開發的誤解

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

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

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

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

　　誤解二：敏捷沒有文檔，也不作設計

　　這個誤解從XP開始就沒有中止過，XP鼓勵「在非到必要且意義重大時不寫文檔」。這裏面提到的「必要且意義重大」是一個判斷標準，並非全部的文檔都不寫。例如，用戶手冊是否是「必要且意義重大」？這取決於客戶的要求，若是客戶不須要，那就不用寫,若是客戶須要，就必定要寫；再如，架構設計文檔要不要寫？複雜要寫，不復雜不用寫。一般架構設計只須要比較簡單的文檔，對於有些項目，一幅簡單的UML圖就夠了。所以，寫不寫，怎麼寫，都要根據這個文檔到底有多大意義，產出和投入的比例，以及項目的具體狀況決定。實際操做時可讓項目組全部人員表決決定，儘可能避免由某一我的（好比lead）來決定。

　　至於設計，XP奉行的是持續設計，並非不設計。這其實是將設計工做分攤到了天天的平常工做中，不斷的設計、改善（重構），使得設計一直保持靈活可靠。至於編碼前的預先設計，Kent Beck等人確實實行着不作任何預先設計的開發方式，可是對於咱們這些「非大師」級開發人員，必要的預先設計仍是須要的，只是不要太多，不要太細，要有未來會完全顛覆的準備。

　　誤解三：敏捷好，其餘方法很差

　　有些人一提到敏捷就大呼好，只要是敏捷的實踐就什麼都好，而提到CMMI等方法就大呼很差，無論是什麼只要沾上邊就哪裏都很差，彷佛敏捷和其餘方法是徹底對立的。牛頓說過，我是站在了巨人的肩膀上。敏捷一樣也吸收了其餘方法論的優勢，也是站在了巨人的肩膀上，敏捷依然保持了不少歷史悠久的實踐和原則，只是表現方式不一樣罷了。

　　從另外一個方面來看，方法本沒有好環，好與壞取決因而否適合解決你的問題。每一種方法都有他最善於解決的問題和最佳的發揮環境，在需求穩定、軟件複雜度相對不高的時代，瀑布模型也能夠工做的很好，而敏捷剛好適用於變化快風險高的項目 － 這偏偏是如今不少項目的共性。

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

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

　　XP 和Scrum只是衆多敏捷方法中的兩種，還有不少其餘的敏捷方法。龍生九子各個不一樣，敏捷的這些方法看起來差異也是很大的，但是他們之因此被稱爲敏捷方法，就是由於他們背後的理念和原則都是相同的，這個原則就是《敏捷宣言》。學習敏捷不只僅要學習實踐，還要理解實踐後的原則，不只要理解怎麼作，還要理解爲何這麼作，以及何時不要這麼作。

　　即便將XP或Scrum徹底的應用的你的項目中，也未見得就能成功，適合別人的東西未必就適合你。敏捷的這些實踐和方法給了咱們一個起點，但絕對不是終點，最適合你的方式還要由你本身在實際工做中探索和尋找。

　　誤解五：敏捷很好，所以我要制定標準，全部項目都要遵循着個標準

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

　　同時，對於同一個團隊，隨着項目的進行，對需求理解的深刻，對技術理解的深刻，一開始適合項目的過程和方法也會漸漸的不適合。這時候也須要團隊對過程進行及時的調整，保證項目的質量和效率。敏捷是動態的，而非靜止不變的，由於這個世界自己就是變化的，在變化的世界使用不變的方法，是不現實的。銀彈歷來就沒有過，在有限的未來也不會存在。

本條目相關文檔參考文檔地址：http://doc.mbalib.com/search？q=%E6%95%8F%E6%8D%B7%E5%BC%80%E5%8F%91

本文爲轉載至  http://wiki.mbalib.com/wiki/%E6%95%8F%E6%8D%B7%E5%BC%80%E5%8F%91，如需轉載請註明出處。