敏捷開發

敏捷建模（AM）定義了一系列的核心原則和輔助原則，它們為軟件開發項目中的建模實踐奠定了基石。其中一些原則是從XP中借鑑而來，在Extreme Programming Explained中有它們的詳細描述。而XP中的一些原則又是源於眾所周知的軟件工程學。複用的思想隨處可見！基本上，本文中對這些原則的闡述主要側重於它們是如何影響着建模工作；這樣，對於這些借鑑於XP的原則，我們可以從另一個角度來看待。

◆主張簡單

當從事開發工作時，主張最簡單的解決方案就是最好的解決方案。不要過分構建（overbuild）軟件。用AM的説法就是，如果現在並不需要這項額外功能，那就不要在模型中增加。要有這樣的勇氣：不必要對這個系統進行過分的建模（over-model），只要基於現有的需求進行建模，日後需求有變更時，再來重構這個系統。儘可能的保持模型的簡單。

◆擁抱變化

需求時刻在變，人們對於需求的理解也時刻在變。項目進行中，Project stakeholder可能變化，會有新人加入，也會有舊人離開。Project stakeholder的觀點也可能變化，努力的目標和成功標準也有可能發生變化。這就意味着隨着項目的進行，項目環境也在不停的變化，因此開發方法必須要能夠反映這種現實。

◆第二個目標是可持續性

即便團隊已經把一個能夠運轉的系統交付給用户，項目也還可能是失敗的－－實現項目投資者的需求，其中就包括系統應該要有足夠的魯棒性（robust ），能夠適應日後的擴展。就像Alistair Cockburn常説的，進行軟件開發的競賽時，第二個目標就是準備下一場比賽。可持續性可能指的是系統的下一個主要發佈版，或是正在構建的系統的運轉和支持。要做到這一點，不僅僅要構建高質量的軟件，還要創建足夠的文檔和支持材料，保證下一場比賽能有效的進行。要考慮很多的因素，包括現有的團隊是不是還能夠參加下一場的比賽，下一場比賽的環境，下一場比賽對組織的重要程度。簡單的説，在開發的時候，要能想象到未來。

◆遞增的變化

和建模相關的一個重要概念是不用在一開始就準備好一切。實際上，就算想這麼做也不太可能。而且，不用在模型中包容所有的細節，只要足夠的細節就夠了。沒有必要試圖在一開始就建立一個囊括一切的模型，只要開發一個小的模型，或是概要模型，打下一個基礎，然後慢慢的改進模型，或是在不再需要的時候丟棄這個模型。這就是遞增的思想。

◆令投資最大化

項目投資者為了開發出滿足自己需要的軟件，需要投入時間、金錢、設備等各種資源。投資者應該可以選取最好的方式投資，也可以要求團隊不浪費資源。並且，他們還有最後的發言權，決定要投入多少的資源。

◆有目的的建模

對於自己的產出，例如模型、源代碼、文檔，很多開發人員不是擔心它們是否夠詳細，就是擔心它們是否太過詳細，或擔心它們是否足夠正確。不應該毫無意義的建模，應該先問問，為什麼要建立這個產出，為誰建立它。和建模有關，也許應該更多的瞭解軟件的某個方面，也許為了保證項目的順利進行，需要和高級經理交流方法，也許需要創建描述系統的文檔，使其他人能夠操作、維護、改進系統。如果連為什麼建模，為誰建模都不清楚，又何必繼續煩惱下去呢？首先，要確定建模的目的以及模型的受眾，在此基礎上，再保證模型足夠正確和足夠詳細。一旦一個模型實現了目標，就可以結束工作，把精力轉移到其它的工作上去，例如編寫代碼以檢驗模型的運作。該項原則也可適用於改變現有模型：如果要做一些改變，也許是一個熟知的模式，應該有做出變化的正確理由（可能是為了支持一項新的需求，或是為了重構以保證簡潔）。關於該項原則的一個重要暗示是應該要了解受眾，即便受眾是自己也一樣。

◆多種模型

開發軟件需要使用多種模型，因為每種模型只能描述軟件的單個方面，“要開發現今的商業應用，我們該需要什麼樣的模型？”考慮到現今的軟件的複雜性，你的建模工具箱應該要包容大量有用的技術（關於產出的清單，可以參閲AM的建模工件）。有一點很重要，你沒有必要為一個系統開發所有的模型，而應該針對系統的具體情況，挑選一部分的模型。不同的系統使用不同部分的模型。比如，和家裏的修理工作一樣，每種工作不是要求你用遍工具箱裏的每一個工具，而是一次使用某一件工具。又比如，你可能會比較喜歡某些工具，同樣，你可會偏愛某一種模型。有多少的建模工件可供使用呢，如果你想要了解這方面的更多細節，我在Be Realistic About the UML中列出了UML的相關部分，如果你希望做進一步的瞭解，可以參閲白皮書The Object Primer -- An Introduction to Techniques for Agile Modeling。

◆高質量的工作

沒有人喜歡爛糟糟的工作。做這項工作的人不喜歡，是因為沒有成就感；日後負責重構這項工作（因為某些原因）的人不喜歡，是因為它難以理解，難以更新；最終用户不喜歡，是因為它太脆弱，容易出錯，也不符合他們的期望。

◆快速反饋

從開始採取行動，到獲得行動的反饋，二者之間的時間至關緊要。和其他人一起開發模型，你的想法可以立刻獲得反饋，特別是你的工作採用了共享建模技術的時候，例如白板、CRC卡片或即時貼之類的基本建模材料。和你的客户緊密工作，去了解他們的需求，去分析這些需求，或是去開發滿足他們需求的用户界面，這樣，你就提供了快速反饋的機會。

◆軟件是你的主要目標

軟件開發的主要目標是以有效的方式，製造出滿足投資者需要的軟件，而不是製造無關的文檔，無關的用於管理的工件，甚至無關的模型。任何一項活動（activity ），如果不符合這項原則，不能有助於目標實現的，都應該受到審核，甚至取消。

◆輕裝前進

你建立一個工件，然後決定要保留它，隨着時間的流逝，這些工件都需要維護。如果你決定保留7個模型，不論何時，一旦有變化發生（新需求的提出，原需求的更新，團隊接受了一種新方法，採納了一項新技術...），你就需要考慮變化對這7個模型產生的影響並採取相應的措施。而如果你想要保留的僅是3個模型，很明顯，你實現同樣的改變要花費的功夫就少多了，你的靈活性就增強了，因為你是在輕裝前進。類似的，你的模型越複雜，越詳細，發生的改變極可能就越難實現（每個模型都更“沉重”了些，因此維護的負擔也就大了）。每次你要決定保留一個模型時，你就要權衡模型載有的信息對團隊有多大的好處（所以才需要加強團隊之間，團隊和項目投資者之間的溝通）。千萬不要小看權衡的嚴重性。一個人要想過沙漠，他一定會攜帶地圖，帽子，質地優良的鞋子，水壺。如果他帶了幾百加侖的水，能夠想象的到的所有求生工具，一大堆有關沙漠的書籍，他還能過得去沙漠嗎？同樣的道理，一個開發團隊決定要開發並維護一份詳細的需求文檔，一組詳細的分析模型，再加上一組詳細的架構模型，以及一組詳細的設計模型，那他們很快就會發現，他們大部分的時間不是花在寫源代碼上，而是花在了更新文檔上。

最重要的是通過儘早和不斷交付有價值的軟件滿足客户需要。

我們歡迎需求的變化，即使在開發後期。敏捷過程能夠駕馭變化，保持客户的競爭優勢。

經常交付可以工作的軟件，從幾星期到幾個月，時間尺度越短越好。

業務人員和開發者應該在整個項目過程中始終朝夕在一起工作。

圍繞鬥志高昂的人進行軟件開發，給開發者提供適宜的環境，滿足他們的需要，並相信他們能夠完成任務。

在開發小組中最有效率也最有效果的信息傳達方式是面對面的交談。

可以工作的軟件是進度的主要度量標準。

敏捷過程提倡可持續開發。出資人、開發人員和用户應該總是維持不變的節奏。

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

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

最好的架構、需求和設計都源自自我組織的團隊。

每隔一定時間，團隊都要總結如何更有效率，然後相應地調整自己的行為。 ^[2] 

要達到敏捷的成功—交付支撐業務的最佳軟件—軟件專家也可以引用這些規則。

專注於工作，交付正確的軟件，而不是被他人的憤怒情緒所影響。

構建完美軟件開發流程，並沒有統一的模式。但是在這個領域，敏捷技術，加上持續的應用和改進，都能夠達到敏捷的成功。 ^[3] 

TFS，即團隊基礎服務器（Team Foundation Server），是微軟應用程序進行生命週期管理的服務器，用於幫助團隊在Visual Studio的協作開發。最近，它進行了升級，包括工作項目執行改進、富文本編輯器的改進，以及富文本編輯器中改善的超鏈接體驗。 TFS中的Kanban面板也做了改善，提升了可以錄入和跟蹤的項目數量。該服務器現在有一個“利益相關者”許可，來規範服務器的訪問權限。

Atlassian推出的Jira是一個很流行的工具，主要用於跟蹤產品開發、幫助團隊整理問題、安排事務，以及記錄團隊行為。它內置的Jira Agile插件使開發人員更容易部署關鍵敏捷策略，這包括用户故事開發、衝刺模塊構建，以及可視化的團隊活動。

Axosoft以前被稱為Axosoft OnTime Scrum，這一軟件套件有四個功能模塊：Scrum、Bug追蹤器、幫助台和Wiki。它是基於HTML5構建的，幫助開發團隊管理待辦事項列表、發佈和衝刺，帶有燃盡圖功能，有一個管理儀表板用於跟蹤編碼和修改BUG的時間。

使用 LeanKit的團隊可以看到工作負載的分佈並導出歷史數據。最近 LeanKit 進行了一次升級，包含單點登錄功能和附加報告功能，從而提供更細粒度的數據詳細信息。

Planbox 敏捷管理工具通過燃盡圖跟蹤進程，集成客户反饋，它的目標人羣很廣泛。最近它對應用的前端和後端都做了升級，添加了更強大的報告功能和新儀表盤，來提升項目速度。它所具有的時間跟蹤特性和工具允許用户得到所有他們在Planbox產生的數據。 ^[4] 

敏捷建模（AM）在AM原則的基礎上定義了一組核心實踐（practice）和補充實踐，其中的某些實踐已經是極限編程（XP）中採用了的，並在 Extreme Programming Explained一書中有詳細的論述，和AM的原則一樣，我們在描述這組實踐時，將會注重於建模的過程，這樣你可以從另外一個角度來觀察這些已或XP採用的素材。

◆Stakeholder的積極參與 我們對XP的現場客户（On-Site Customer）的概念做了一個擴充：開發人員需要和用户保持現場的接觸；現場的用户要有足夠的權限和能力，提供建構中的系統相關的信息；及時、中肯的做出和需求相關的決策；並決定它們的優先級。AM把XP的“現場客户”實踐擴展為“使project stakeholder積極參與項目”，這個project stakeholder的概念包括了直接用户、他們的經理、高級經理、操作人員、支持人員。這種參與包括：高級經理及時的資源安排決策，高級經理的對項目的公開和私下的支持，需求開發階段操作人員和支持人員的積極參與，以及他們在各自領域的相關模型。

◆正確使用artifact 每個artifact都有它們各自的適用之處。例如，一個UML的活動圖（activity diagram）適合用於描述一個業務流程，反之，你數據庫的靜態結構，最好能夠使用物理數據（physical data）或數據模型（persistence model）來表示。在很多時候，一張圖表比源代碼更能發揮作用，一圖勝千言，同樣，一個模型也比1K的源代碼有用的多，前提是使用得當（這裏借用了 Karl Wieger的Software Requirements中的詞彙）。因為你在研究設計方案時，你可和同伴們和在白板上畫一些圖表來討論，也可以自己坐下來開發一些代碼樣例，而前一種方法要有效的多。這意味着什麼？你需要了解每一種artifact的長處和短處，當你有眾多的模型可供選擇的時候，要做到這一點可沒有那麼容易。

◆集體所有制 只要有需要，所有人都可以使用、修改項目中的任何模型、任何artifact。

◆測試性思維 當你在建立模型的時候，你就要不斷的問自己，“我該如何測試它？”如果你沒辦法測試正在開發的軟件，你根本就不應該開發它。在現代的各種軟件過程中，測試和質保（quality assurance）活動都貫穿於整個項目生命週期，一些過程更是提出了“在編寫軟件之前先編寫測試”的概念（這是XP的一項實踐：“測試優先”）。

◆並行創建模型 由於每種模型都有其長處和短處，沒有一個模型能夠完全滿足建模的需要。例如你在收集需求時，你需要開發一些基本用例或用户素材，一個基本用户界面原型，和一些業務規則。再結合實踐切換到另外的Artifact，，敏捷建模者會發現在任何時候，同時進行多個模型的開發工作，要比單純集中於一個模型要有效率的多。

◆創建簡單的內容 你應該儘可能的使你的模型（需求、分析、架構、設計）保持簡單，但前提是能夠滿足你的project stakeholder的需要。這就意味着，除非有充分的理由，你不應該隨便在模型上畫蛇添足－－如果你手頭上沒有系統認證的功能，你就不應該給你的模型增加這麼一個功能。要有這樣的勇氣，一旦被要求添加這項功能，自己就能夠馬上做到。這和XP的實踐“簡單設計”的思想是一樣的。

◆簡單地建模 當你考慮所有你能夠使用的圖表（UML圖、用户界面圖、數據模型等）時，你很快會發現，大部分時候你只需要這些圖表符號的一部分。一個簡單的模型能夠展示你想要了解的主要功能，例如，一個類圖，只要能夠顯示類的主要責任和類之間的關係就已經足夠了。不錯，編碼的標準告訴你需要在模型中加入框架代碼，比如所有的get和set操作，這沒有錯，但是這能提供多少價值呢？恐怕很少。

◆公開展示模型 你應當公開的展示你的模型，模型的載體被稱為“建模之牆”（modeling wall）或“奇蹟之牆（wall of wonder）”。這種做法可以在你的團隊之間、你和你的project stakeholder之間營造出開放誠實的溝通氛圍，因為當前所有的模型對他們都是舉手可得的，你沒有向他們隱藏什麼。你把你的模型貼到建模之牆上，所有的開發人員和project stakeholder都可以看建模之牆上的模型，建模之牆可能是客觀存在的，也許是一塊為你的架構圖指定的白板，或是物理數據模型的一份打印輸出，建模之牆也可能是虛擬的，例如一個存放掃描好的圖片的internet網頁。如果你想要多瞭解一些相關的資料，你可以看看Ellen Gottesdiener的Specifying Requirements With a Wall of Wonder。

◆切換到另外的Artifact 當你在開發一個artifact（例如用例、CRC卡片、順序圖、甚至源碼），你會發現你卡殼了，這時候你應當考慮暫時切換到另一個artifact。每一個artifact都有自己的長處和短處，每一個artifact都適合某一類型的工作。無論何時你發現你在某個artifact上卡殼了，沒辦法再繼續了，這就表示你應該切換到另一個artifact上去。舉個例子，如果你正在製作基本用例，但是在描述業務規則時遇到了困難，你就該試着把你的注意力轉移到別的artifact上去，可能是基本用户界面原型、CRC模型，可能是業務規則、系統用例、或變化案例。切換到另一個artifact上去之後，你可能就立刻不再卡殼了，因為你能夠在另一個artifact上繼續工作。而且，通過改變你的視角，你往往會發現原先使你卡殼的原因。

◆小增量建模 採用增量開發的方式，你可以把大的工作量分成能夠發佈的小塊，每次的增量控制在幾個星期或一兩個月的時間內，促使你更快的把軟件交付給你的用户，增加了你的敏捷性。

◆和他人一起建模 當你有目的建模時你會發現，你建模可能是為了瞭解某事，可能是為了同他人交流你的想法，或是為了在你的項目中建立起共同的願景。這是一個團體活動，一個需要大家有效的共同工作才能完成的活動。你發現你的開發團隊必須共同協作，才能建立一組核心模型，這對你的項目是至關重要的。例如，為了建立系統的映像和架構，你需要和同組成員一起建立所有人都贊同的解決方案，同時還要儘可能的保持它的簡單性。大多數時候，最好的方法是和另一些人討論這個問題。

◆用代碼驗證 模型是一種抽象，一種能夠正確反映你正在構建的系統的某個方面的抽象。但它是否能運行呢？要知道結果，你就應該用代碼來驗證你的模型。你已經用一些HTML頁面建立了接受付款地址信息的草圖了嗎？編碼實現它，給你的用户展示最終的用户界面，並獲取反饋。你已經做好了表示一個複雜業務規則邏輯的UML順序圖了嗎？寫出測試代碼，業務代碼，運行測試以保證你做的是對的。永遠也別忘了用迭代的方法開發軟件（這是大多數項目的標準做法），也別忘了建模只是眾多任務中的一個。做一會兒建模、做一會兒編碼、做一會兒測試（在其它的活動之中進行）。

◆使用最簡單的工具 大多數的模型都可以畫在白板上，紙上，甚至紙巾的背面。如果你想要保存這些圖標，你可以用數碼相機把它們拍下來，或只是簡單的把他們轉錄到紙上。這樣做是因為大多數的圖表都是可以扔掉的，它們只有在你畫出模型並思考一個問題的時候才有價值，一旦這個問題被解決了它們就不再有意義了。這樣，白板和標籤往往成為你建模工具的最佳選擇：使用畫圖工具來創建圖表，給你重要的project stakeholder看。只有建模工具能夠給我們的編程工作提供價值（例如代碼自動生成）時才使用建模工具。你可以這樣想：如果你正在創建簡單的模型，這些模型都是可以拋棄的。你建模的目的就是為了理解，一旦你理解了問題，模型就沒有存在的必要了，因此模型都是可以丟棄的，這樣，你根本就不必要使用一個複雜的建模工具。

◆使用建模標準 這項實踐是從XP的編碼標準改名而來，基本的概念是在一個軟件項目中開發人員應該同意並遵守一套共同的建模標準。遵守共同的編碼慣例能夠產生價值：遵守你選擇的編碼指南能夠寫出乾淨的代碼，易於理解，這要比不這麼做產生出來的代碼好得多。同樣，遵守共同的建模標準也有類似的價值。可供選擇的建模標準有很多，包括對象管理組織（OMG）制定的統一建模語言ML，它給通用的面向對象模型定義了符號和語義。UML開了一個好頭，但並不充分－就像你在Be Realistic About The UML中看到的，UML並沒有囊括所有可能的的建模artifact。而且，在關於建立清楚可看的圖表方面，它沒有提供任何建模風格指南。那麼，風格指南和標準之間的差別在何處呢。對源代碼來説，一項標準可能是規定屬性名必須以attributeName的格式，而風格指南可能是説在一個單元中的一段控制結構（一個if語句，一段循環）的代碼縮進。對模型來説，一項標準可能是使用一個長方形對類建模，一項風格指南可能是圖中子類需要放在父類的下方。

◆逐漸應用模式 高效的建模者會學習通用的架構模式、設計模式和分析模式，並適當的把它們應用在模型之中。然而，就像Martin Fowler在Is Design Dead中指出的那樣，開發人員應當輕鬆的使用模式，逐漸的應用模式。這反映了簡單的價值觀。換言之，如果你猜測一個模式可能適用，你應當以這樣的方式建模：先實現目前你需要的最小的範圍，但你要為日後的重構留下伏筆。這樣，你就以一種可能的最簡單的方式實現了一個羽翼豐滿的模式了。就是説，不要超出你的模型。舉一個例子，在你的設計中，你發現有個地方適合使用GoF的Strategy模式，但這時候你只有兩個算法要實現。最簡單的方法莫過於把算法封裝為單獨的類，並建立操作，能夠選擇相應的算法，以及為算法傳遞相關的輸入。這是Strategy模式的部分實現，但你埋下了伏筆，日後如有更多的算法要實現，你就可以重構你的設計。並沒有必要因為Strategy模式需要，就建立所有的框架。這種方法使你能夠輕鬆的使用模式。

◆丟棄臨時模型 你創建的大部分的模型都是臨時使用的模型－－設計草圖，低精度原型，索引卡片，可能架構/設計方案等等－－在它們完成了它們的目的之後就再不能提供更多的價值了。模型很快就變得無法和代碼同步，這是正常的。你需要做出決定：如果“同步更新模型”的做法能夠給你的項目增添價值的話，那就同步更新模型；或者，如果更新它們的投入將抵消它們能夠提供的所有價值（即負收益），那就丟棄它們。

◆合同模型要正式 在你的系統需要的信息資源為外部組織所控制的時候，例如數據庫，舊有系統和信息服務，你就需要合同模型。一個合同模型需要雙方都能同意，根據時間，根據需要相互改變。合同模型的例子有API的細節文檔，存儲形式描述，XML DTD或是描述共享數據庫的物理數據模型。作為法律合同，合同模型通常都需要你投入重要資源來開發和維護，以確保它的正確、詳細。你的目標是儘量使你係統的合同模型最少，這和XP的原則traveling light是一致的。注意你幾乎總是需要電子工具來建立合同模型，因為這個模型是隨時需要維護的。

◆為交流建模 建模的次要原因是為了和團隊之外的人交流或建立合同模型。因為有些模型是給團隊之外的客户的，你需要投入時間，使用諸如文字處理器，畫圖工具包，甚至是那些“被廣告吹得天花亂墜”的CASE工具來美化模型。

◆為理解建模 建模的最重要的應用就是探索問題空間，以識別和分析系統的需求，或是比較和對照可能的設計選擇方法，以識別可能滿足需求的、最簡單的解決方案。根據這項實踐，你通常需要針對軟件的某個方面建立小的、簡單的圖表，例如類的生命週期圖，或屏幕順序，這些圖表通常在你完成目的（理解）之後就被丟棄。

◆重用現有的資源 這是敏捷建模者能夠利用的信息財富。例如，也許一些分析和設計模式適合應用到系統上去，也許你能夠從現有的模型中獲利，例如企業需求模型，業務過程模型，物理數據模型，甚至是描述你用户團體中的系統如何部署的模型。但是，儘管你常常搜索一些比較正確的模型，可事實是，在大多數組織中，這些模型要麼就不存在，要麼就已經過期了。

◆非到萬不得已不更新 你應當在你確實需要時才更新模型，就是説，當不更新模型造成的代價超出了更新模型所付出的代價的時候。使用這種方法，你會發現你更新模型的數量比以前少多了，因為事實就是，並不是那麼完美的模型才能提供價值的。我家鄉的街道圖已經使用了5年了，5年我自己街道並沒有改變位置，這張地圖對我來説還是有用的。不錯，我可以買一張新地圖，地圖是每年出一次的，但為什麼要這麼麻煩呢？缺少一些街道並沒有讓我痛苦到不得不投資買一份新地圖。簡單的説，當地圖還管用的時候，每年花錢買新地圖是沒有任何意義的。為了保持模型、文檔和源代碼之間的同步，已經浪費了太多太多的時間和金錢了，而同步是不太可能做到的。時間和金錢投資到新的軟件上不是更好嗎？

確實不錯的主意

以下的實踐雖然沒有包括在AM中，但是可以做為AM的一份補充：

◆重構 這是一項編碼實踐。重構，就是通過小的變化，使你的代碼支持新的功能，或使你的設計儘可能的簡單。從AM的觀點來看，這項實踐可以保證你在編碼時，你的設計乾淨、清楚。重構是XP的一個重要部分。

◆測試優先設計 這是一項開發實踐。在你開始編寫你的業務代碼之前，你要先考慮、編寫你的測試案例。從AM的觀點來看，這項實踐強制要求你在寫代碼之前先通盤考慮你的設計，所以你不再需要細節設 計建模了。測試優先設計是XP的一個重要部分。

AM是一種態度，而不是一個説明性的過程。AM是敏捷建模者們堅持的價值觀、敏捷建模者們相信的原則、敏捷建模者們應用的實踐組成的集合。AM描述了一種建模的風格。當它應用於敏捷的環境中時，能夠提高開發的質量和速度，同時能夠避免過度簡化和不切實際的期望。AM可不是開發的“食譜”，如果你尋覓的是一些細節的指導，如建立UML順序圖或是畫出用户界面流圖，你可以看看在建模Artifacts中列出的許多建模書籍，我特別推薦我的書The Object Primer 2/e（儘管這有失公允）。

AM是對已有方法的補充，而不是一個完整的方法論。AM的主要焦點是在建模上，其次是文檔。也就是説，AM技術在你的團隊採用敏捷方法（例如eXtreme Programming，Dynamic Systems Development Method （DSDM），Crystal Clear）的基礎上能夠提高建模的效果。AM同樣也可以用於那些傳統過程（例如Unified Process），儘管這種過程較低的敏捷性會使得AM不會那麼成功。

AM是一種有效的共同工作的方法，能夠滿足Project Stakeholder的需要。敏捷開發者們和Project Stakeholder進行團隊協作，他們輪流在系統開發中扮演着直接、主動的角色。在“敏捷”的字典中沒有“我”這個單詞。

AM是有效的，而且也已開始有效。當你學習到更多的AM知識時，有件事對你來説可能不好接受，AM近乎無情的注重有效性。AM告訴你：要使你的 Project Stakeholder的投資最大化；當有清晰的目的以及需要了解受眾的需要時要建立模型或文檔；運用合適的工件來記錄手頭的情形；不論何時都儘可能創建簡單的模型。

AM不是靈丹妙藥。敏捷建模是改進眾多專家軟件開發成果的有效技術，充其量也就是這樣了。它並不是什麼了不得的靈丹妙藥，能夠解決你開發中的所有問題。如果你努力的工作；如果你專注其上；如果打心眼兒裏接受它的價值觀、它的原則、它的實踐；你就可以改進你做為一個開發人員的效果。

AM是面向一般的開發人員的，但並不是要排斥有能力的人。AM的價值觀、原則和實踐都簡單易懂，其中的很多內容，可能你都已經採用或期待多年了。應用AM技術並不是要你去練水上飄，但你需要有一些基本的軟件開發技能。AM最難的就是它逼着你去學習更廣泛的建模技術，這是個長期的、持續性的活動。學習建模在一開始可能很難，但你可以試着一次學習一樣技術來完成你的學習。

AM並不是要反對文檔。文檔的創建和維護都會增大項目涉眾的投資。敏捷文檔儘可能的簡單，儘可能的小，目的只集中在和開發的系統有直接關係的事情上，充分了解受眾的需要。

AM也不是要反對CASE工具。敏捷建模者使用那些能夠幫助開發人員提高效果，提升價值的工具。而且，他們還盡力使用那些能夠勝任工作的最簡單的工具。

要想了解AM，你需要了解模型和敏捷模型之間的區別。模型是一個抽象的概念，它描述了問題的一個或多個方面，或是處理這個問題可能的解決方案。傳統意義上，模型被認為是圖表加上相應的文檔。然而那些不夠直觀的artifact，也可以被視為模型，例如CRC卡片集，單條或多條業務規則的文字描述，或是業務流程的一段結構化英文描述。一個敏捷模型就是一個剛剛足夠好的模型。但是你怎麼知道什麼時候模型才是剛剛足夠好呢？當敏捷模型顯現出如下的特性時，它就是剛剛足夠好的：

敏捷模型實現了它們的目的。有時你為溝通而建模，或許你需要把你工作的範圍告訴高級經理；有時你為理解而建模，或許你需要確定一個設計策略，實現一組Java類。一個敏捷模型是否足夠好，要看它是不是滿足了創建它時的初衷。

敏捷模型是可理解的。敏捷模型要能為其預期聽眾所理解。使用用户能夠理解的業務語言來描述需求模型，反之，技術架構模型則需要使用開發人員熟悉的技術術語。你所使用的建模符號會影響易懂性－－如果你的用户不瞭解UML用例圖中的符號的含義，那用例圖對用户就沒有任何價值。這樣的話，要麼使用另一種方法，要麼教授用户學習建模技術。風格問題同樣也會影響易懂性，例如避免交叉線。雜亂的圖表比清晰的圖表難懂。模型的細節程度（見下文），也會影響易懂性，因為相較一個不那麼詳細的模型來説，一個過於詳細的模型要難於理解。簡單（見下文）同樣是影響易懂性的一個因素。

敏捷模型是足夠正確的。模型通常都不需要100%正確，只要足夠正確就行了。舉個例子，如果一張街道地圖漏畫了一條街道，或是它標示某條街道是通行的，但你發現它已經關閉維修了，那你會不會扔掉你的地圖開始在城裏飆車犯罪呢？不太可能。你會考慮更新你的地圖，你可能會拿出筆來自己做修改或是去當地的商店買一張最新版的地圖（你原來的那張過期了）。也許你還是會接受那張雖不完美但仍可使用的地圖，因為它對你來説已經足夠好了。你還是可以用這張地圖四處轉轉，因為它還是個正確的模型，標記出了大部分街道的位置。你在發現這張地圖不正確的時候，你沒有立刻扔掉它，原因是你根本不在乎它是否完美。類似的，當你在需求模型、數據模型中發現錯誤的時候，你也會選擇更新或是接受－－雖不完美但已經足夠好了。有些項目成員能夠容忍這種不正確而有些則不能：這取決於項目的特性，每個團隊成員的特性，組織的特性。充分正確性既和模型的聽眾有關，也和你要處理的問題有關。

敏捷模型是足夠一致的。一個敏捷模型並不需要和自己（或其它有用的artifact）保持完全的一致。如果一個用例在它的一個步驟中顯式的調用了另一個用例，那麼相應的用例圖需要用UML的 ＜＞ 版型來標記這兩個用例之間的關係。然而，你看了看圖表，發現它們並沒有這樣做，天哪！用例和圖之間不一致！危險！太危險了！紅色警報！快逃命呀！等一下，你的用例模型是有不一致的地方，但也沒到世界末日啊。是的，理想情況下，你的所有artifact最好是能夠完全一致，但這通常是不可能的。當我開發一個簡單的商用系統時，我通常都可以容忍部分的不一致。但有時我是不能容忍這種不一致的。最有力的佐證就是1999年 NASA發射火星太空探測器時採用了精密的測量系統。要樹立一個觀點，敏捷模型只要足夠一致就行了，你通常不需要使用那麼完美的模型。

關於正確性和一致性，很明顯要考慮權衡問題。如果你要維護一個artifact（我們稱之為“保管”），隨着時間的流逝，你需要投入資源來更新它。否則它很快會就會過期，對你就沒用了。例如，我可以容忍一張地圖標錯了一兩條街道，但是我絕對無法容忍一張地圖中四分之三的街道都標錯了。這就需要權衡了，進行足夠的努力，保證artifact足夠正確。過多不必要的努力反而會減緩項目的進度，而投入不足就沒有辦法保證artifact的有效性。

敏捷模型有足夠的細節。一張路線圖並不需要標記出每條街道上的每棟房子。那會有太多的細節，使得地圖難以使用。然而，在修路的時候，我想施工人員一定會有這條街道的詳細地圖，包括每幢建築、下水道、電線盒等足夠的細節，這樣的地圖才是有用的。但是這張地圖並不用標記出每個院子和通向它們的路線。因為這樣又太繁瑣了。足夠的細節和聽眾有關，也和他們使用模型的目的有關－－司機需要的是顯示道路的地圖，施工人員需要的是顯示土木工程細節的地圖。

考慮一個架構模型，可能一組畫在白板上的圖表就足夠了－－項目的進行中再對它們更新，也許你需要用CASE 工具來生成一些圖表，也許這些圖表還需要有詳細的文檔，這依賴於環境。不同的項目有不同的需要。在每一個例子中，實際上你都是在開發、維護一個有足夠的細節的架構模型，只是這個“足夠的細節”的概念和環境有關。

敏捷模型能提供正面價值。對項目中的任一artifact，一個基本的要求是它們能夠提供正面價值。一個架構模型給你的項目帶來的價值是不是能夠超過開發它、維護它（可選）的總成本？一個架構模型能夠堅定你們團隊為之努力的願景，所以它當然是有價值的。但是，如果它的成本超過了這個價值，那就是説，它無法提供正面價值。投入100,000美元去開發一個詳細的、重量級的文檔化架構模型，而它的效用，只需一些畫在白板上的圖表就能夠達到，這些圖只需要花你 5,000美元，看看，這是多麼輕率的做法。

敏捷模型要儘可能的簡單。只要能夠達到目的，你應當努力讓你的模型儘可能保持簡單。模型的詳細程度會影響簡單性，而所使用的符號範圍也會影響簡單性。例如，UML的類圖就包括了無數的符號，包括對象約束語言 (Object Constraint Language OCL) ，但大多數的圖使用符號的一部分就能夠完成。所以你常常不需要使用所有的符號，你可以限制自己使用符號的一個子集，當然，這個子集是足夠讓你完成工作的。

因此呢，一個敏捷模型的定義就是一個實現它的目的，沒有畫蛇添足的模型；為你的預期聽眾所理解的模型；簡單的模型；足夠正確、足夠一致、足夠詳細的模型；創建和維護它的投資能夠給項目提供正面價值的模型。

一個普遍的哲學問題是源代碼是不是一個模型，更重要的，它是不是一個敏捷模型。如果你是在我們這篇文章之外問我這個問題，我會回答説，是，源代碼是一個模型，雖然是一個高度細節化的模型，因為它是軟件的一個抽象。同時我還認為，優秀的代碼是一個敏捷模型。但在這裏，我還需要把兩者區分開來，源代碼和敏捷模型還是有區別的——敏捷模型幫助你得到源代碼。

Alistair Cockburn指出：很多的方法學都定義了軟件開發項目中開發人員所擔任的角色，同時還定義各個角色執行的任務，儘管入席，這些方法並沒有定義這些角色最適合的人選。一個人要想成功的擔任某個角色，他應當很好的適應它－－雖然這並不需要人們掌握所有的技能，但人們必須要慢慢的熟悉這些技術。我的經驗告訴我，要成為一個成功的敏捷建模者，下面的列出的個性是必要的：

第一點，也是最重要的一點，敏捷建模者總是積極的尋求協作，因為他們意識到他們不是萬事通，他們需要不同的觀點，這樣才能做到最好。軟件開發可不是游泳，單幹是非常危險的。在敏捷的字典中沒有“我”這個詞。

敏捷建模者都有良好的溝通技巧－－他們能夠表達出他們想法，能夠傾聽，能夠主動獲取反饋，並且能夠把需要的寫出來。

敏捷建模者應當腳踏實地 他們的精力都集中在滿足用户的需求上，他們不會在模型上畫蛇添足，即便那雙足是多麼的好看。他們滿足於提供可能的方案中最簡單的一種，當然，前提是要能夠完成工作。

敏捷建模者樂衷於研究問題，解決問題。

敏捷建模者看問題從不會至於表面，而是會打破沙鍋問到底。他們從不會就想當然的認為一個產品或一項技術和它們的廣告上説的那樣，他們會自己試一試。

敏捷建模者都非常的謙遜，他們從不認為自己是個萬事通，所以他們會在建立好模型之後，用代碼來小心的證明模型的正確。

敏捷建模者應當願意嘗試新的方法，例如一項新的（或是已有的）建模技術。一般而言，他們也會接受敏捷建模開發技術，必要時，為了驗證想法，他們願意同傳統的思想做鬥爭，例如在一個項目中減少文檔數量。

要堅持不懈的遵循敏捷建模的實踐。對你來説，你可能會在不經意間説，“加上這個功能吧！無傷大雅。”或是，“我比project stakeholder更瞭解。”在AM的道路上要想不偏離方向，是需要一定的紀律性的。

走出一般性的設計誤區，邁向成功之途

無論你遵從的是重量級的方法，比如Enterprise Unified Process (EUP)，還是輕量級的開發過程，如Extreme Programming (XP)，建模在軟件開發中都是不可或缺的。但不幸的是，其中充斥着各種謬誤與迷思。這來自於各個方面：有理論家錯誤的研究、數十年來信息技術領域內的文化沉積、軟件工具開發商天花亂墜般的市場宣傳以及象Object Management Group (OMG) 和IEEE這類組織的標準。下面，我們要揭示建模中的誤區，指出其相應的事實真相。

建模就等於是寫文檔

這很可能是其中最具破壞力的一條，因為開發人員可以此為藉口而完全放棄建模。許多優秀的軟件開發人員會説他們不想把時間浪費在這些“無用的“文檔上。他們沉溺於編碼之中，製造着一些脆弱而劣質的系統。

事實分析：“模型”與“文檔”這二者在概念上是風馬牛不相及的——你可以擁有一個不是文檔的模型和不是模型的文檔。一幅設計圖就是一個模型，而不論這幅圖是被畫在餐巾紙的背面，或寫在一塊白板上，或在Class Responsibility Collaboration(CRC)卡片中，還是根據記錄在報紙和便籤紙上的流程圖而生成的一個粗略的用户界面原型。雖然這些都不能説是文檔，但他們卻都是有價值的模型。

建模很象是作計劃：作計劃的價值在於計劃編制的過程中，而非計劃本身；價值體現在建模的活動中，而非模型本身。實際上，模型不是你係統中的一部分正式的文檔，而且在完成它們的使命後可以被丟掉。你會發現值得保留的只有很少的模型，而且它一定非常完美。

從開始階段你可以考慮到所有的一切

這種説法流行於二十世紀七十年代到八十年代早期，現今的許多經理都是在那個時候學習的軟件開發。對這一點的迷信會導致在前期投入可觀的時間去對所有的一切建模，以期把所有一切都弄正確，試圖在編碼開始前就“凍結”所有的需求（見誤區四），以致於患上“分析期麻痹症”——要等到模型非常完美之後才敢向前進。基於這個觀點，項目組開發了大量的文檔，而不是他們真正想要得到的——開發滿足需要的軟件。

事實分析：怎麼才能走出這個誤區呢？首先，你必須認識到你不能考慮到所有的細枝末節。第二，認識到編碼員可能會對建模者的工作不以為然（這是可能的，事實上建模者所作的工作在實際價值中只佔很少的部分），他們或許會説模型沒有反應出真實的情況。第三，認識到不管你最初所作的規格説明書有多好，但註定代碼會很快地與之失去同步，即便是你自己建模自己編碼。一個基本的道理就是代碼永遠只會和代碼保持一致。第四，認識到迭代法（小規模地建模，編一些代碼，做一些測試，可能還會做一個小的工作版本）是軟件開發的準則。它是現代重量級的軟件開發過程（如EUP），以及輕量級（如XP）的基本原理。

建模意味着需要一個重量級的軟件開發過程

走入這個誤區（經常與誤區一有聯繫）的項目組常常是連建模都徹底地放棄了，因為這樣的軟件開發過程對他們來説太複雜太沉重了。這不亞於一場天災。

事實分析：你可以用一種敏捷的方式取而代之。關於用簡單的工具進行簡單地建模的詳細內容，可參看Agile Modeling（AM）。而且，當使命完成之後，你可以丟棄你的模型。同樣，你也可以採用很基本的方式進行建模（比如，從辦公桌起來，來到白板前就開始構略草圖）。只要你願意，你就可以輕鬆地建模。

必須“凍結”需求

這個要求常常來自高級經理，他們確切地想知道他們從這個項目組能得到什麼東西。這樣的好處就是在開發週期的早期確定下需求，就可以確切地知道所要的是一個什麼樣的東西；缺點就是他們可能沒有得到實際上所需要的。

事實分析：變化總會發生的。由於優先級的變化和逐漸對系統有了更進一步的理解，都會引起需求的變化。與凍結需求相反，估計項目成功的風險，儘量去接受變化而且相應地採取行動，就象XP所建議的一樣。

設計是不可更改的

如同誤區四，要求每一個開發人員必須嚴格遵從“設計“，導致開發人員為了符合“設計“而作了錯誤的事情或以錯誤的方式作正確的事情。或者是簡單地忽略了設計，否定了所有設計可能帶來的好處。凍結了設計，就不能從在項目進程中所學到知識進一步獲益。另外一個很大的趨勢就是開發出大量的文檔而不是實際的軟件，使用面向文檔的CASE工具而不是能給項目帶來實際價值的面向應用的工具。

事實分析：事實上，設計會經常根據開發人員和數據庫管理員的反饋進行修改，因為他們是最接近實際應用的人，通常他們對技術環境的理解要好於建模者。我們必須的面對這樣一個事實：人無完人，他們所作的工作也不可能盡善盡美。難道您真的想將一個並不完善的設計固定下來而不再去修改其中的錯誤嗎？另外，如果需求並沒有被凍結，其實就意味着不能凍結設計，因為任何需求的修改勢必影響設計。對之，正確的態度是：只要代碼還在改動，設計就沒完。

必須使用CASE工具

建模常常被認為是一項複雜的工作，因此需要大量地使用CASE工具輔助進行。

事實分析：是的，建模可以是很複雜的。但完全可以建立一個有效而簡單的模型表述其中關鍵的信息，而不是將一些無關緊要的細節包括進來。

建模是在浪費時間

許多新手都這樣認為，這主要是因為他們所接受的教育僅僅侷限於如何編寫代碼，對於完整的開發流程鮮有接觸。而且他們的經驗也僅限於如何實現代碼，就如初級程序員。他們放棄了提高效率和學習技能的機會，這些技能能夠使他們很容易地適應不同的項目或組織。他們應該為此感到羞愧。

事實分析：在大多數情況下，在開始編碼之前畫一個草圖、開發一個粗率的原型或者製作一些索引卡片都能提高生產效率。高效的開發者在編碼之前都要進行建模工作。另外，建模是一種很好的在項目組成員與項目負責人之間溝通的途徑。在這個過程中探討問題，從而對所要的是一個什麼樣的東西可以得到更好的理解，涉及到該項目中的每個成員也可得到對該項目有一個充分的瞭解。

數據模型（Data Model）就是一切

許多組織基於數據模型就蹣跚啓動新的開發工作，也許正如所在的組織：IT部門對於數據有非常嚴格的規定，控制着開發項目；或者以前的數據庫是一團糟，別無選擇。

事實分析：數據模型是一個重要的但不是最重要的建模，它最好是建立在另外的模型之上。（參見“Extreme Modeling”，Thinking Objectively，Nov.2000）。這即使在象數據倉庫這類面向數據的項目中也如此。如果沒有很好的理解用户是如何使用該數據倉庫的（在數據模型中沒有表示出來），這些項目經常是以可悲的失敗而告終。可以使用的模型有很多——使用案例（use cases），業務規則（business rules），activity diagrams，類圖（class diagrams），component diagrams，用户界面流程圖（user interface flow diagrams）和CRC，等等。數據模型僅僅是其中的一種。每種模型都有其長處和短處，應該正確地使用。

所有的開發人員都知道如何建模

面臨這樣一個嚴重的問題：許多不是開發人員的人，不知道軟件是如何建成的。其結果是，他們不能夠區分開熟練的開發者和一般的程序員（當然也分不清高級程序員和一般程序員），他們想當然地認為所有的開發人員都具備從頭到尾開發整個系統的技能。

事實分析：這肯定是不正確的。建模的技能，是隻有當一個開發者通過學習它，並經過長期的實踐才能夠掌握。一些非常聰明的程序員常常相信自己無所不能，畢竟他們終究只是程序員。正因為這樣的狂妄自大，他們承當的一些任務是他們根本就沒有相應的技能去完成的。軟件開發是如此的複雜，單單一個人是很難具備所有的技能去成功地進行開發，甚至也不可能去配置有一定複雜程度的系統。開發者應該有自知之明，明白他們自己的弱點，學無止境。通過互相取長補短，建模者可從程序員身上學到一項技術的具體細節，程序員也可從建模者那裏學到有價值的設計和體系結構的技術。我個人認為所有的人，包括我自己，都是新手。

個體和交互 勝過 過程和工具

可以工作的軟件 勝過 面面俱到的文檔

客户合作 勝過 合同談判

響應變化 勝過 遵循計劃

雖然右項也有價值，但是我們認為左項具有更大的價值。

我們最優先要做的是通過儘早的、持續的交付有價值的軟件來使客户滿意。

即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來為客户創造競爭優勢。

經常性地交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。

在整個項目開發期間，業務人員和開發人員必須天天都在一起工作。

圍繞被激勵起來的個體來構建項目。給他們提供所需的環境和支持，並且信任他們能夠完成工作。

在團隊內部，最具有效果並富有效率的傳遞信息的方法，就是面對面的交談。

工作的軟件是首要的進度度量標準。

敏捷過程提倡可持續的開發速度。責任人、開發者和用户應該能夠保持一個長期的、恆定的開發速度。

n 不斷地關注優秀的技能和好的設計會增強敏捷能力。

簡單是最根本的。

n 最好的構架、需求和設計出自己組織的團隊。

n 每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行為進行調整。

當軟件開發隨需求的變化而變化時，軟件設計會出現壞味道，當軟件中出現下面任何一種氣味時，表明軟件正在腐化。

n 僵化性：很難對系統進行改動，因為每個改動都會迫使許多對系統其他部分的其它改動。

n 脆弱性：對系統的改動會導致系統中和改動的地方在概念上無關的許多地方出現問題。

n 牢固性：很難解開系統的糾結，使之成為一些可在其他系統中重用的組件。

n 粘滯性：做正確的事情比做錯誤的事情要困難。

不必要的複雜性：設計中包含有不具任何直接好處的基礎結構。

n 不必要的重複性：設計中包含有重複的結構，而該重複的結構本可以使用單一的抽象進行統一。

晦澀性：很難閲讀、理解。沒有很好地表現出意圖。

敏捷團隊依靠變化來獲取活力。團隊幾乎不進行預先設計，因此，不需要一個成熟的初始設計。他們更願意保持設計儘可能的乾淨、簡單，並使用許多單元測試和驗收測試作為支援。這保持了設計的靈活性、易於理解性。團隊利用這種靈活性，持續地改進設計，以便於每次迭代結束生成的系統都具有最適合於那次迭代中需求的設計。

為了改變上面軟件設計中的腐化味，敏捷開發採取了以下面向對象的設計原則來加以避免，這些原則如下：

單一職責原則（SRP）

就一個類而言，應該僅有一個引起它變化的原因。

開放-封閉原則（OCP）

軟件實體應該是可以擴展的，但是不可修改。

n Liskov替換原則（LSP）

子類型必須能夠替換掉它們的基類型。

n 依賴倒置原則（DIP）

抽象不應該依賴於細節。細節應該依賴於抽象。

n 接口隔離原則（ISP）

不應該強迫客户依賴於它們不用的方法。接口屬於客户，不屬於它所在的類層次結構。

n 重用發佈等價原則（REP）

重用的粒度就是發佈的粒度。

共同封閉原則（CCP）

包中的所有類對於同一類性質的變化應該是共同封閉的。一個變化若對一個包產生影響，則將對該包中的所有類產生影響，而對於其他的包不造成任何影響。

共同重用原則(CRP)

一個包中的所有類應該是共同重用的。如果重用了包中的一個類，那麼就要重用包中的所有類。

環依賴原則（ADP）

在包的依賴關係圖中不允許存在環。

穩定依賴原則（SDP）

朝着穩定的方向進行依賴。

穩定抽象原則（SAP）

包的抽象程度應該和其穩定程度一致。

上述中的包的概念是：包可以用作包容一組類的容器，通過把類組織成包，我們可以在更高層次的抽象上來理解設計，我們也可以通過包來管理軟件的開發和發佈。目的就是根據一些原則對應用程序中的類進行劃分，然後把那些劃分後的類分配到包中。

敏捷設計是一個過程，不是一個事件。它是一個持續的應用原則、模式以及實踐來改進軟件的結構和可讀性的過程。它致力於保持系統設計在任何時間都儘可能得簡單、乾淨和富有表現力。

最大的分歧在於開發人員和測試人員之間。作為敏捷團隊的成員，測試人員被期望能編寫一點代碼，同時開發人員可以做一些測試。各自的強項還是很重要：新的角色要求每個成員成為大家所謂的“通才”。測試人員大多數時間作測試，開發人員大都編寫代碼，但所有人都分享他們的工作，而且有能力承擔他們面前的任務。

團隊決定作為一個團隊需要做什麼，如何最好地分配工作。第一步是讓團隊成員説説他們自己的技能集、優點和缺點。但卻不希望他們根據以前角色（如，軟件測試員或開發員）來定義自己。所以找到一箇中立點，她列出了小型離線會議，和每週工作之外的小時集體活動所需的事項。這樣，該團隊去當地的農場採摘藍莓。他們一起上瑜珈課。他們集體在廚房裏烤燕麥棒，做果沙。 ^[5] 

團隊找到了讓自此感到舒服的新水平。整個項目的工作流程順利進行，只做一個待辦的事情，而不是四個。 ^[5] 

分佈式敏捷開發方法並不能在所有組織中都工作良好。擁有一個已經建立完成的分佈式敏捷開發工作文化，對於分佈式團隊是很重要的。有些公司一直堅持“面對面”的工作文化，這給分佈式地開展敏捷站立會議增加了難度。

但是如果分佈式的文化一直存在於團隊中，那麼開展敏捷站立會議和其它會議就會很容易。其中的一個選擇是使分散的團隊成員按照同一計劃表工作，即使他們所處的時區不一致。如果所有團隊成員同意，且時差不超過幾個小時的話，這才是有效的。 ^[6] 

1. 快速迭代

相對那種半年一次的大版本發佈來説，小版本的需求、開發和測試更加簡單快速。一些公司，一年發佈僅2~3個版本，發佈流程緩慢，它們仍採用瀑布開發模式，更嚴重的是對敏捷開發模式存在誤解。

需求討論以研討組的形式展開最有效率。研討組，需要包括測試人員和開發者，這樣可以更加輕鬆定義可測試的需求，將需求分組並確定優先級。 同時，該種方式也可以充分利用團隊成員間的互補特性。如此確定的需求往往比開需求討論大會的形式效率更高，大家更活躍，參與感更強。

開始就要用“用户故事”（User Story）的方法來編寫需求文檔。這種方法，可以讓我們將注意力放在需求上，而不是解決方法和實施技術上。過早的提及技術實施方案，會降低對需求的注意力。

任何項目中，溝通都是一個常見的問題。好的溝通，是敏捷開發的先決條件。在圈子裏面混得越久，越會強調良好高效的溝通的重要性。

團隊要確保日常的交流，面對面溝通比郵件強得多。

5. 做好產品原型

建議使用草圖和模型來闡明用户界面。並不是所有人都可以理解一份複雜的文檔，但人人都會看圖。

及早地考慮測試在敏捷開發中很重要。傳統的軟件開發，測試用例很晚才開始寫，這導致過晚發現需求中存在的問題，使得改進成本過高。較早地開始編寫測試用例，當需求完成時，可以接受的測試用例也基本一塊完成了。 ^[7]