軟體工程第六版第四章 機敏流程的觀點

機敏軟體發展宣言 2001 年 Kent Beck 和其他十六位著名的軟體

開發業者、作家和顧問 (以下稱為「機敏聯盟」簽署「機敏軟體發展宣言」。此宣言說道： 我們正藉由實作以找出更好的發展軟體方法，並協助

其他人一起實行。經由此工作，我們得以評估出其價值： 流程與工具間的個別 (individuals) 與交互 (interactions) 各種型式文件編寫的工作軟體 合約談判時與客戶的協調合作 依循計劃執行時對變更的回應

雖然右邊的項目是有價值的，但我們更著重於對左邊項目的評斷。

機敏宣言與政治行動 一份宣言通常會伴隨著政治性的行動

攻擊舊勢力並倡議革命性的改變 (希望變得更好 )。

在某些形式上，這正好就是所謂的機敏發展。

機敏軟體發展的需要 在現代的經濟中，要預測以電腦為基礎的系統 (例

如網路應用程式 )隨時間演進的情形常常是很困難或不可能的。 市場狀況迅速地改變、使用者需求的演進及新的競爭威

脅無預警的出現。 在許多情形下，當專案開始前我們不在有能力完全地定

義需求。 軟體工程師必須夠機敏的回應流動性的商務環境。

這些事實將導致我們拋棄有價值的軟體工程原則、觀念、方法和工具嗎？ 完全不是！如同所有的工程紀律，軟體工程繼續的演進

調整，以符合機敏要求的挑戰。

規範流程模型的重大缺失 Alistair Cockburn 認為規範流程模型有

重大的缺失： 忽略建構電腦軟體的人。

軟體工程師不是機器人。 軟體工程師展現工作形態的巨大差異

在技術水準、創造力、有規律、一致性和自發性的重大差別。

某些人可以用書面進行良好的溝通，有些則不能。

流程模型中的紀律與容忍 Cockburn主張流程模型可以「用紀律和 (或 )容忍 (tolerance)處理人們共通的弱點」，而大部份的規範流程模型則選擇了紀律。 他說道：「因為動作的一致是人類的弱點，高度紀

律的方法將會很脆弱的」。 假設流程模型可行，他們必須提供一個真實的

機制以激勵所必需要的紀律，或者他們必須以某種方式突顯展現對從事軟體工程從業人員的「包容」。

快速瀏覽 它是什麼？

機敏軟體工程結合哲學和一組發展指導方針。此哲學鼓勵客戶的滿意度及儘早交付漸進的軟體版本；小而有高度動機的專案團隊；非正規的方法；最小化的軟體工程工作產品；和整體發展的單純化。

發展指導方針強調交付 (delivery)超過分析和設計 (雖然這些活動並沒有被忽視 )，和開發者與客戶間主動且不斷地溝通。

誰完成它？ 軟體工程師和其他的專案利益共享者 (經理、客戶與使

用者 )以機敏的團隊一起工作 - 一個自我組織和控制自己命運的團隊。機敏團隊對所有執行的成員間，培育溝通與協調。

快速瀏覽 它為何重要？

現代的商務環境引起以電腦為基礎的系統和軟體產品是快步調的和不斷的改變。

機敏的軟體工程對傳統軟體工程中某些軟體類型與某些專案軟體型態，代表著一項合理且可供選擇的方法。它已經展示出可以快速地交付成功的系統。

步驟為何？ 機敏的發展可能最好稱為「清淡的軟體工程」。 基本的框架活動維持著 -顧客溝通、計劃、模型、建構、

交付和評估。 它們變形成為極小的任務組，以推動專案團隊朝向建構

與交付 (某些人會爭議問題分析所需的花費與解決方案的設計 )。

快速瀏覽 工作產品為何？

客戶和已採用機敏的哲學的軟體工程師都有相同的看法，唯一非常重要的工作產品是在適當的承諾日期交付給顧客可運作的「軟體增量」。

我如何確定我所做的是正確的？ 如果機敏團隊同意流程工作，與團隊生產可以

交付的軟體增量以滿足客戶，你已經做對了。

4.1 何謂機敏性 究竟什麼是軟體工程工作環境中的機敏性？

Ivar Jacobson提出有助益的討論：

機敏已成為今天用以描述現代軟體流程的專業術語。每個人都是機敏的。一個機敏的團隊是能適當地回應改變的精明團隊。軟體發展的改變是非常大的。軟體建構中的改變、團隊成員的改變、因為新技術所造成的改變等，在他們所建構的產品或創建產品的專案中，所有形態的改變都會產生衝擊。對改變所提供的支援應該內建在我們所做關於軟體的每件事物，我們擁抱某些事物，因為它是軟體的核心與靈魂。一個機敏的團隊瞭解到軟體是藉由團隊中個別的工作和這些人的技術所發展出來的，他們協調合作的能力位在專案成功的核心。

機敏性的主要驅動力 在 Jacobson 的觀點中，貫徹改變

(pervasiveness of change) 是機敏性的主要驅動力。

如果軟體工程師要能調適如 Jacobson 所描述的快速改變，則他們必須要加快腳步。

達成機敏性的原則 -1

機敏聯盟 (Agile Alliance) 定義出 12 項原則給想要達成機敏性的人： 我們最高的優先順序是經由早期與連續交付有

價值的軟體以滿足顧客。 歡迎變更的要求，甚至在發展階段的後期發生

改變。機敏流程是為著顧客的競爭利益駕馭改變。

頻繁的交付工作軟體，從幾個星期到幾個月，以較短的期間為佳。

達成機敏性的原則 -2 商務人員與開發者於專案期間每日必須要一起

工作。 以激勵個人的方式建立各種專案。給他們所需

要的環境與支援，並信賴他們執行此一工作。 對研發團隊與內部之間最快速且有效的傳遞資訊方法是面對面的交談。

工作軟體是進展最主要的衡量標準。 機敏流程促進持續的發展。贊助者、開發者和

使用者應該能夠無限期地維持固定的步調。

達成機敏性的原則 -3 持續的注意技術上優良與卓越的設計，以提升

機敏性。 簡單化　　極大化未完成工作數量的藝術　　

是必要的。 最好的架構、需求和設計是從自我組織的團隊

中出現。 定期的時間間隔，團隊要反映出如何可以變得

更為有效，然後適當地調節與調整它的行為。

4.2 何謂機敏的流程 任何機敏軟體流程的特性可用三個關鍵的假設描述大多數的軟體專案： 事先預測出那些軟體的需求會持續不變、那些則會

改變是相當困難的。 在專案進行時預測出客戶改變的優先順序也同樣地非常困

難。 對於許多軟體的類型，設計和建構是彼此交錯的。

兩個活動應該一前一後的施行，設計模型建立後就可以被驗證。

當使用建構 (construction)證明設計之前，預測需要多少設計也是非常困難的。

分析、設計、建構和測試可能都是無法預測 (從計畫的觀點 )。

如何創造一個可以管理無法預測的流程 ?

給定三項假設時，會出現一個重要的問題：我們如何創造一個可以管理無法預測的流程？ 信賴流程的可適應性 (adaptability)( 以迅速地變更專

案和技術條件 )。 機敏流程必須是可適應的。

機敏軟體流程可適應性的問題 不斷地適應而不能有所進展時只能完成少許的工作。

機敏軟體流程必須漸進地適應。 為完成漸進地適應，機敏團隊需要顧客的回饋 (以使適當的適應得以產生 )。 操作的原型或操作系統的某部分，得以有效激發出顧客的

回饋。 漸進發展策略 (incremental development strategy) 應該被制定。 軟體漸進版本 (software increments)( 可執行的原型或操作系統的某部分 )必須在短期內遞交，以便適應能與改變 (無法預測的 )保持步調。這種反覆的步驟讓客戶得以定期地評估軟體的漸進版本，提供所必需的回饋給軟體團隊，並影響流程中用來調整顧客反饋的適應性。

4.2.1 機敏發展的政見 對於作為反對較為傳統軟體流程的機敏軟體發展，在其效益與應用性 (applicability) 方面有著相當多的爭議(有時是很刺耳的 )。 Jim Highsmith(勉強的 )極端的陳述說當他在處理特性機敏

時，可感覺偏向機敏的陣營 (“agilists”) 。 「傳統的方法論者是一群身陷泥淖的人，他們寧可生產完美的文

件，也不願將工作系統做的更為符合商務的需求」。 傳統的軟體工程陣營是：「輕量級，呃，「機敏的」方法論者是

一群美化電腦駭客，當他們試著擴大他們的玩具成為企業級的軟體」。

就像所有的軟體技術的爭論，這種方法論的爭辯冒著退化到如同宗教戰爭的風險。 如果衝突爆發，理性的思考將會消失，信仰將會取代事實指導

著決策的形成。

機敏性的真正問題 沒有人會反對機敏性。真正的問題則是：

最好的達成方法是什麼？ 我們如何建構符合客戶現今所需要的軟體，並且展現此軟體可延伸和擴展以符合客戶長期需要的品質特性，？

對於這些問題都沒有絕對的答案。 其底線是：有很多可以得到藉由考慮兩個學院最好的，但除了方法以外不要有任何的毀謗。

4.2.2 人的因素 機敏軟體發展的倡議者強調在成功的機敏發

展中「人的因素」的重要性時，都感到極大的痛苦。

Cockburn 和 Highsmith 說： 「機敏發展聚焦於個人的才能和能力，針對特

定的人和團隊塑造適當的流程」。 此陳述的關鍵點是針對個人和團隊的需要塑造

流程，而不是其他相關的方法。

有效軟體團隊成員間必須存在的關鍵特質 一個有效軟體團隊的成員間，必須要存在何種關鍵的特質？ 能力 (Competence)

「能力」包含了天生的才能、特定的軟體相關技能、和最重要的是具備團隊所選擇應用流程的全面知識。

技能和流程的知識可以而且必須要教授給服務於機敏團隊的所有成員。

共同焦點 (Common focus) 機敏團隊成員可能執行不同的工作，並於專案中運用不同

的技能，但所有的必須聚焦於一個目標上： 在承諾的時間內交付給顧客工作軟體的漸進版本。

為達成此目標，團隊也必須聚焦在持續不斷的適應 (大或小 )，以讓流程適合團隊的需要。

有效軟體團隊成員間必須存在的關鍵特質 協調合作 (Collaboration)

軟體工程 (不管流程 )是有關評估、分析及運用資訊與軟體團隊溝通；產生有益於協助客戶和其它的人瞭解團隊工作的資訊；和建立 (電腦軟體和相關的資料庫 )提供給客戶商務價值的資訊。為完成這些工作，團隊成員必須與另一個人、客戶及商務經理人彼此協調合作。

決策能力 (Decision-making ability) 任何優秀的軟體團隊 (包括機敏團隊 )必須允許有控制它自己命運的自由度。這意味著團隊被授予自治(autonomy) - 在技術和計畫議題上做決策的權力。

有效軟體團隊成員間必須存在的關鍵特質 模糊解決問題能力 (Fuzzy problem-

solving ability) 軟體經理應要明瞭機敏團隊必須不斷地處理模稜兩可的問題，且必須不斷地與”變更”進行搏鬥。某些情形下，團隊必須接受”今天正在解決的問題，很可能明天就成為不需要在解決的問題”的事實。然而，從任何解決問題的活動中所學習到的這些教訓 (包括那些已解決的錯誤問題 )可能對團隊往後的專案有益。

有效軟體團隊成員間必須存在的關鍵特質 相互信賴與尊重 (Mutual trust and

respect) 機敏團隊必須成為 DeMarco 和 Lister[DEM98]

所稱的「凝聚」 (jelled)團隊 (詳見第 21 章 )。凝聚團隊展現信賴和尊重是有必要的，使得他們「強烈地結合成比部份的總和還更好的整體」[DEM98] 。

有效軟體團隊成員間必須存在的關鍵特質 自我組織 (Self-organization)

在機敏發展的環境中，自我組織隱含著三件事情： 機敏團隊為完成其工作組織他們自己； 團隊組織出能最佳地調適本地環境的流程； 團隊組織出最佳的工作時程，以最佳地達成軟體漸進版本的

交付。 自我組織有許多技術上的益處。但更重要的是它增進協

調合作和提高團隊的士氣。 基本上，團隊所做的就是自我管理。

Ken Schwaber[SCH02]強調這些議題並寫道：「團隊在每次重複的循環中，挑選它相信可完成的工作量，並且對這些工作許下承諾。任何激勵團隊的措施，都不會比接受實現團隊自己所承諾的責任來得有效。」

4.3 機敏流程模型 軟體工程的歷史是許多遭丟棄和一些已廢棄

的、流程描述與方法論、模型製作方法與記號法、工具和技術。 每個都會名聲大噪一陣子以後，然後因為某些

新的或 (謠傳的 )更好的東西而黯然失色。

4.3.1 極限規劃 (Extreme Programming, XP)

雖然結合極限規劃 (XP) 的早期構想和方法發生於 1980年代後期，有影響力的相關工作才由 Beck 於 1999年出版。

接下來由 Jeffries et al 所撰寫的著作才詳述 XP 的技術，

有關 XP 計劃 (XP planning) 的其他工作，則由 Beck 和 Fowler[BEC01b]闡述出方法的細節。

XP 的框架活動 XP 使用物件導向的模式作為它所偏愛的發展典型。 XP含括一組規則和發生在其環境中的四種框架活

動： 計劃 (planning) 設計 (design) 編程碼 (coding) 測試 (testing)

圖 4.1 說明 XP 的流程及註記一些與每個框架活動所相關的關鍵想法與任務。

圖 4.1 極限規劃的流程

關鍵的 XP活動 _計劃 (Planning)

計劃活動是由一組描述發展軟體所需求的性能和功能故事 (stories)(也稱為使用者故事(user stories)) 的產生所開始。 每個故事 (類似於第 7 、 8 章中所描述的使用

案例 )是由客戶寫在索引卡上。

何謂 XP 的「故事」 客戶基於特性和功能的整體商務價值，對故

事指定某個值 (value)(即優先權 )。 XP團隊成員隨後評估每個故事，並對每個故

事指派一個價 (cost) – 以開發所需的週數量測。 如果故事的發展需要超過三週，則要求客戶將故

事再分割成較小的故事，並再次指派其值與價。 客戶和 XP團隊一起工作以決定如何將故事集聚成為新的版本 (下一個軟體漸進版本 )讓XP團隊進行開發。

XP 的排序發展 一旦對某個釋出的版本有了基本的承諾 (包括

對故事的協議、交付日期和其他的專案事項 )，XP團隊會將故事用以下三種之一的方式排序發展： 所有的故事將立即實作 (在數星期之內 )； 具有最高重要性的故事將優先排於時間表內並優先實作；或

風險最高的故事將優先排在時間表內並優先實作。

XP 的專案速率 當第一個專案版本 (也稱為軟體漸進版本 )

交付後， XP團隊會計算專案的速率。 專案速率 (project velocity) 即為第一個釋出

版本中所實作顧客故事的數目。 專案的速率可以用來：

協助預估下個版本的交付日期與時程，和 決定是否對橫跨整個發展專案的故事做出過度

的承諾。 如果有過度的承諾發生，則修正釋出版本的內容或

改變最終交付的日期。

XP 發展工作的進行 當發展工作進行時，客戶可能會增加故事、

變更現有故事的重要性、分割故事或取消它們。 隨後 XP團隊則必須重新考慮剩餘所要交付的版本，並據此修正它的計劃。

關鍵的 XP活動 _設計 (Design) XP 的設計嚴格地遵循著 KIS(keep it simple) 的

原則。 簡單的設計總是比複雜的呈現更受到喜愛。

設計提供被撰寫出故事的實作指導 - 不多也不少。 額外功能性的設計 (因為開發者假設它於稍後會被需要 )

是不被鼓勵的。 XP鼓勵使用 CRC(類別 -責任合作者 ))卡片 (第8 章 )作為思考關於在物件導向環境中軟體的一個有效的機制。 CRC卡片認明識別與辨認出與目現軟體漸進版本有關的物件導向類別。

XP團隊使用類似第八章中 (第 8.7.4 節 )所描述的流程導入設計的作業。

關鍵的 XP活動 _設計 (Design) 作為 XP 流程的一部份， CRC卡片是設計的唯一

工作產品。 因為 XP設計沒有使用虛擬的記號法，並且產生極少的工

作產品。 若有的話，除了 CRC卡片和突波解決方案以外，設計則

可被視為一項短暫的人工製品，當往建構前進時，它可以且必須被不斷地修正。

如果故事設計的某部份遭遇某個困難的設計問題， XP 建議立即創造此一部份設計可操作的原型。 對此設計雛型的實作與評估稱為突波解決方案 (spike

solution) 。 其意圖是在真正執行開始時降低風險，並且檢驗含有設

計問題故事的估計。

重構 (refactoring) XP鼓勵重構 (refactoring) – 是一種建構技術，同時也是一種設計技術。 Fowler 以下列的描述說明重構：

重構是改變軟體系統的流程，此種方法不會改變程式碼的外在行為，而僅改善其內部的架構。這是一種有紀律清除程式碼，以降低引入「臭蟲」 (bug) ( 及修正 /簡化內部設計 )機會的方法。基本上，當你在進行重構時，它已在你設計程式碼後開始改進程式碼的設計。

重構的意圖是藉由建議「以根本地改善設計」的較小設計改變以控制這些修正。

當應用程式的大小成長時，重構所需要的努力也會戲劇性地增長。

XP 的中心觀念是，設計發生在編碼出現之前與出現之後。當系統建構時，重構意謂著設計正不斷地發生。 建構活動本身將提供 XP團隊如何改善設計的導引。

關鍵的 XP活動 _編碼 (Coding)

XP 建議在故事發展後並完成初步的設計工作時，團隊不應該進行編碼。 要發展一系列的單元測試以熟練包含於最近上

市版本中 (軟體漸進版本 )的每個故事 。 當單元測試產生時，開發者最好能夠聚焦在實

作什麼才得以通過單元測試。 不要增加任何外來的事 (儘量簡單， KIS) 。

當編碼完成後，它可立即進行單元測試，藉此提供開發者即時的回應。

何謂搭檔編程 (pair programming)? 搭檔編程 (pair programming)

在編碼活動期間一項重要的概念 (和最常談論有關 XP之一 )。

XP 建議由二人一起於電腦工作站上共同為某個故事產生程式碼。 這提供了一項可即時解決問題的機制 (二個頭腦總比一

個強 )與即時的品質保證。 讓開發者保持專注於解決目前手上的問題。

實際上，每個人所扮演的角色都有稍微的差異，例如，某人可能會思考特定部分設計的編碼細節，而其他人則會確認編碼標準 (XP 所需的一部份 )是被遵循著，且產生的程式碼將「適合」於故事的設計。

成對規劃的整合 當成對的程式設計師完成他們的工作時，他

們所開發的程式碼會與其他人的工作整合。 某些情況下，這種工作每日都由整合團隊執行

的。其他的情況下，成對的程式設計師則負有整合的責任。

這種「不斷地整合」的策略協助避免相容性(compatibility) 與界面 (interfacing) 問題，並提供「煙霧測試」 (smoke testing) 的環境 (第 13 章 )，以協助及早發現錯誤。

關鍵的 XP活動 _測試 (Testing) 單元測試的產生是在編碼之前就開始的，這是 XP

模式的一個關鍵要素。 所產生的單元測試應該要以能夠讓它們成為自動化的框

架 (因此，它們可以很容易並重複地執行 )實作。 這激勵迴歸測試策略 (regression testing strategy)

編碼隨時修正的策略 (第十三章 ) ( 經常的提供給 XP再因素原理 )。

當個別的單元測試組織成為「通用性測試組套」時，系統的整合和驗證測試就可以每日進行。 這提供 XP團隊持續前進的指示，也在事情出差錯時及早

發出警告訊號。 威爾斯說道：「每幾個小時解決一些小問題總比在截止期限前修正極大的問題還要節省時間」。

XP驗收測試 XP驗收測試 (acceptance tests)也稱為

客戶測試 (customer tests) ，它是由客戶所指定並且著重在整體系統中可由客戶看到與可檢視的特性與功能性。 驗收測試源於使用者故事並已成為軟體上市的

一部份。

4.3.2 適應的軟體發展 (Adaptive Software Development, ASD) 適應的軟體發展 (ASD) 由 Jim Highsmith提出成為

建構複雜軟體和系統的一項技術。 ASD 的哲學基礎聚焦在人的協調合作和團隊的自我組織。

Highsmith討論這些時寫道： 自我組織是一種複雜適應系統的特質，類似「啊哈 (ah

a) 」的瞬間創造能力，當一些嘮叨問題浮現時的解決辦法。 自我組織的出現當單獨的，獨立的代理人 (身上的細胞，一

個生態系統的品種，一個開發者在特徵團隊 )合作 [協力 ]產生的突發結果時。

一個突發的結果特質超越任何的個別代理人的能力。例如，個別的腦神經在腦裡原沒有意識，但集體時的意識特質浮現。

我們傾向於看這集體的出現的現象為意外的，或至少難控制的和不可信任的。自我組織的研究證實了錯誤的觀點。

ASD 的「生命週期」 Highsmith 爭論基於協助合作的機敏、適

應的發展方式是「在我們的複雜的有規律和工程交互作時用有如規範資源」。

他定義結合三個階段的 ASD 「生命週期」(圖 4.2) ： 臆測 (speculation) 合作 (collaboration) 學習 (learning) 。

ASD 的「生命週期」 _臆測(Speculation)

在臆測期間專案被啟始，並導入適應性的週期計劃 (adaptive cycle planning) 。

適應性的週期計劃使用專案啟始的資訊－客戶的任務聲明 (mission statement) 、計畫的限制 (即交付日期或使用者描述 )和基本需求－ 以定義一套專案所要求的釋出週期 (軟體漸進版本 ) 。

ASD 的「生命週期」 _合作(Collaboration)

合作 (Collaboration) 有動機的人在一起工作可以將他們的天份與創意產生比絕對值超越數倍。

這種協同合作的方式在所有機敏的方法中循環的主題。但協同合作並不容易。不只是簡單的溝通而已，雖然溝通也是它的一部份。它不只是一些團隊作業而已，雖然凝聚的團隊 (第 21章 )是產生真正協同合作的基礎。

團隊的信任 個別的創新能力在協同合作的思考中扮演重

要的角色。其中最重要的就是信任 (trust) 。 人們一起工作必須在以下方面信任他人：

批評但不仇視； 協助而沒有怨恨； 工作和他人一樣努力或超越他人； 讓技術可隨時取得；和 使用能夠導致有效行動的方法溝通問題或憂慮。

ASD 的「生命週期」 _學習 (Learning)

學習 (Learning) 作為一位 ASD團隊的成員，當開始發展適應性週期某個部份的元件時，其主要強調在朝向完整週期的進程中要儘可能的學習。

Highsmith 認為軟體開發者時常對他們自己的理解 (在技術、流程和專案 )作過度的評價，而學習將可幫助他們改善他們真正瞭解的程度。

ASD 的哲學有顯著的忽視所使用的流程模型。 ASD 的全面強調動態的自我組織團隊、人們之間的協助

合作和個人與團體的學習所產生的軟體專案團隊將有較高的成功機會。

ASD 的「生命週期」 _學習 (Learning)

ASD團隊用以下的三種方式學習： 聚焦團體 (Focus groups)

客戶或使用者對所交付軟體漸進版本的回饋。這直接的提供產品是否充份滿足商務需求的徵兆。

正規的技術檢視 (Formal technical reviews) ASD團隊成員檢視所開發的軟體元件，並在過程

中改進品質與學習。 事後檢討 (Postmortems)

ASD團隊針對他們自己的績效和流程 (以學習與改進它的方式為意圖 )變成內省的。

圖 4.2 適應性的軟體發展

4.3.3 動態系統發展方法 (DSDM) 動態系統發展方法 (DSDM) 是一種機敏的軟體發展

方式，它「透過控制的專案環境中漸進雛型的使用，提供符合緊迫的時間限制的建構和維修系統的框架」。

DSDM 所建議的哲學是借用巴瑞圖原則 (Pareto Principle) 的修正版本。 在此情況下，某個應用程式的 80% 可以在全部 (100%) 應

用程式交付時間的 20%內交付。 DSDM 建議一種反覆的軟體流程。

DSDM 的方式對於每次的反覆都遵循百分之八十的規則。 也就是對於促使前往下一個漸進版本移動的每個增量的要

求就是唯有足夠的工作量。 當更多的商務需求被知曉或被要求與協調變更後，剩下的細節就可於稍後完成。

DSDM生命周期 DSDM生命周期定義三種不同的反覆周期，接

續著二個附加的生命周期活動： 可行性研究 (Feasibility study)

結合所要建立的應用程式，建立基本的商務需求與限制，然後評估應用程式是否為可實行的 DSDM 流程候選者。

商務研究 (Business study) 建立讓應用程式提供商業價值的功能和資訊的需求；並且

定義基本應用程式的架構和區別應用程式的可維護性需求。

DSDM生命周期 功能的模型反覆 (Functional model iteration)

產生一組對客戶展示功能性的漸進版本雛型 (附註：所有的 DSDM 原型傾向於演進成為可交付的應用程式 )。在此反覆周期期間的意圖是當使用者操練雛型時，藉由他們引出回饋，以蒐集額外的需求。

設計和建立反覆 (Design and build iteration) 重訪於功能的模型反覆期間所建造的雛型，以確定每個都已經採用讓它能夠提供終端使用者營運上商務價值的工程方法。某些情況下，功能的模型反覆和設計與建立反覆會併行發生。

DSDM生命周期 實作 (Implementation)－將最新的軟體漸進版本 (一

個「可運作化」的雛型 )置入運作的環境中。這裡應注意： (1) 漸進版本不可能百分之百的完成，或 (2) 在漸進版本安置好後，可能還會要求改變。在上述任一情況中， DSDM 的發展工作將繼續返回到功能模型反覆活動。

DSDM 可和 XP提供組合步驟來定義一穩固的處理模型(DSDM生命周期 )，用螺絲和螺絲帽的步驟來執行(XP) 建立軟體增量所需。除此之外，合作的 ASD 觀念和自我組織團隊可適應一組合的處理模型。

4.3.4 並列爭球 (Scrum)

並列爭球 (名稱源於橄欖球 (rugby)比賽中所發生的活動 )於 1990年代早期由 Jeff Sutherland 和他的團隊所發展的機敏流程模型。 近幾年來，並列爭球方法的進一步發展已由

Schwaber 和 Beedle履行。

並列爭球的原則 並列爭球原則與機敏的宣言是一致的：

小的工作團隊被組織成「最大化的溝通、最小化的花費和最大化的默契與非正式知識的分享」。

流程對於技術和商務的改變必須是可適應的，以「確保產生最佳可能性的產品」。

流程頻繁的產生「可以檢查、調整、測試、證明和擴建」的軟體漸進版本。

並列爭球的原則 發展工作與執行的人可以區分成為「乾淨

(clean) 、低耦合度區隔 (low coupling partitions) 或包裝 (packets) 」。

當產品建構時，持續的執行測試和文件編寫。 並列爭取流程提供「宣布產品“完成”的能力，

無論何時需要 (因為剛剛完成交付競爭、因為企業需要現金、因為使用者 /客戶需要的功能、因為它先前已承諾…。

並列爭球原則的框架活動 並列爭球原則常用於合併以下框架活動：

需求、分析、設計、演進和交付的流程中，指導發展的活動。

在每個框架活動裡，工作任務發生在一個流程模式 (process pattern) 中 (於下段中討論 )產生稱為競逐 (sprint) 。 這工作在一競逐 (競逐的次數必需依產品和其複雜

和大小的每個架構活動而改變 )適應在手邊問題和定義與時常的即時變更在並列爭取團隊。

並列爭球的軟體流程模式與活動 並列爭球強調使用一組「軟體流程模式

(software process patterns) 」，此流程模式已經證明其對有緊迫時間期限、變更需求和臨界商務的專案有效。

並列爭球的發展活動 並列爭球的軟體流程模式每個都定義一組

發展活動： 儲備 (Backlog)

專案需求優先列表或提供給客戶商務價值的性能。 項目可以隨時加入儲備中 (這就導致改變產生 )。 產品經理評估儲備並依據需求更新優先權。

並列爭球的軟體流程模式與活動 衝刺 (Sprints)

組成需要達成定義於儲備所需求的工作單元，此儲備必須符合預先定義的時間箱 (time-box)(典型為30 天 ) 。

在衝刺期間，儲備項目競逐工作單元位址被凍結(也就是在競逐期間不導致變更 )。

衝刺允許團隊成員在短期卻穩定的環境中工作。

並列爭球的軟體流程模式與活動 並列爭取會議 (Scrum meetings)

並列爭取團隊每日所舉行的簡短會議 (典型為 15分鐘 )。

所有的團隊成員不斷地針對三個關鍵的問題發問與答覆： 你自最後一次團隊會議後做了什麼？ 你碰到什麼障礙？ 你計劃到下次團隊會議時能完成什麼？

團隊的領導者，稱為「並列爭取隊長 (scrum master) 」，帶領會議並評估來自每個人的回應。

並列爭取會議協助團隊儘早地找出潛在的問題。同時，這些每日的會議引導「知識社交 (knowledge socialization) 」，並藉此促進自我組織的團隊結構。

並列爭球的軟體流程模式與活動 展示 (Demos)

運送軟體漸進版本給客戶，使得實作的功能性可以對向客戶展示並評估。

展示可能不包含計劃中的所有功能性，但寧可將那些可於時間盒內可建立的功能交付。

並列爭球的流程

4.3.5 水晶 (Crystal) Alistair Cockburn 和 Jim Highsmith創造機敏方

法的結晶家族 (Crystal family of agile methods)以達成軟體發展方式 將 premium 在「可操作性(maneuverability) 」在期間 Cockburn特性化成為「有限資源、發明與溝通的合作遊戲，以最主要的目標 交付有用、可工作的軟體和建立在下一個遊戲的第二目標」。

要達成可操作性， Cockburn 和 Highsmith 定義一套方法學，對全體每個都有核心元件和角色、流程、模式、工作產品和實務對每個都是獨有的。

結晶家族實際上是一套經證明對不同類型的專案是有效的機敏流程。其意圖讓機敏團隊選擇對他們的專案與環境最適合的結晶家屬成員。

4.3.6 性能驅動發展 (Feature Driven Development, FDD)

性能驅動發展 (FDD)緣於 Peter Coad 和他同事的構思，作為物件導向軟體工程的實務流程模型。

Stephen Palmer 和 John Felsing 則擴展與強化 Coad 的工作，描述出適應性的機敏流程，以應用到中型和較大型的軟體專案中。

FDD 環境中的性能 在 FDD 的環境中，性能 (feature) 「是可於二週或更短的時間內實作，達成客戶價值(client-valued) 的功能」。

這種對於特性定義上的強調提供了以下的好處： 因為特性都是可遞送功能性的一些小區塊，使用

者可以更容易地描述它們，瞭解它們如何與彼此保持良好關係，和對不明確、錯誤或疏忽的地方進行更好的檢視。

特性可以組織到階層式商務相關的群組內。

FDD 環境中的性能 因為一個特性是 FDD 可交付的軟體漸進版本，團隊每二週發展出可運作的特性。

因為特性很小，它們設計和編碼的呈現更容易有效地檢查。

專案的計劃、排程和追蹤是由性能階層 (feature hierarchy) 所驅動，而不是任意地採用地軟體工程任務組 (task set) 。

定義性能的樣版 Coad 和他的同事建議使用以下的樣版

(templete) 定義性能：<action> the <result> <by I for I

of I to> a(n) <object>

其中<object>是「一個人、地方或事物 (包括角色、時刻或時間的間隔或類似目錄輸入般(catalog-entry-like) 的描述」。

性能範例 一個電子商務應用程式的性能範例如下：

加入 (Add)產品 (product) 到 (to)購物車 (a shopping cart) 。

顯示 (Display)產品 (product) 的技術規格(technical-specifications) 。

儲存 (Store)運送資料 (shipping-information) 為 (for) 客戶 (a customer) 。

性能集合群組 相關到商務相關領域性能的一個性能集合群組被定義成為：<action><-ing> a(n) <object>

舉例說明：產品銷售 (making a product sale) 是一個性能集合，它將含括上述與其他的性能。

FDD 定義的「流程」 FDD 方式定義五種「協調合作」框架活動 (在 FDD

中稱這些為「流程」 )，如圖 4.4 所示。 FDD比許多其他的機敏方法，更為強調專案管理指

導方針與技術。 當專案的規模更大更複雜時，隨意的 (ad hoc) 專案管理經常是不充足的。這是開發者、他們的經理和客戶想要瞭解計畫狀態的基礎– 那些已經完成和所遇到的問題等。

如果截止日期的壓力非常重，則軟體漸進版本 (特性 )已適當地排程，就是一項重要的決定。

圖 4.4 性能驅動發展

FDD 定義的里程碑 在設計與實作特性時， FDD 定義六項里程碑

(milestons) ： 設計攻略 (design walkthrough) 設計 設計檢查 (design inspection) 編碼 編碼檢查 (code inspection) 促進建構 (promote to build) 」

4.3.7 機敏塑模 (Agile Modeling, AM)

軟體工程師在很多情況下一定要建立大的、有重大的商務系統。這類範圍和複雜度的系統必須塑模，以便 : 所有的成件 (constituencies) 能更為瞭解所需

要完成的事件； 在必須解決問題的人們之間有效地切割問題； 當系統被工程化與建造時，品質能在每個步驟

中評估。

機敏塑模 (AM)

在「官方的機敏塑模網站」中， Scott Ambler[AMB02] 以下述的方式描述機敏塑模 (AM) ： 機敏塑模 (AM) 是以實務為基礎的方法學，對以

軟體為基礎的系統能有效的塑模與文件製作。 簡單的說，機敏塑模是塑模軟體的價值、原則與

實務的集合，它可以用有效和輕鬆的 (light-weight) 態度應用在軟體的發展專案上。機敏模型比傳統模型更為有效，因為他們就是這麼好，但不須要是完美的。

機敏塑模 (AM)

除了價值與機敏宣言是一致的以外， Ambler提出勇氣 (courage) 和人性 (humility) 。 一個機敏團隊必須要有勇氣作出可能造成駁回設

計與再因素 (refactor) 的決定。 它必須要具有人性以瞭解技術人員並沒有所有的答案、商務專家和其他利益共享者應該受到尊重和擁抱 (embraced) 。

機敏塑模的獨特性 雖然機敏塑模建議廣泛的「核心 (core) 」和

「補充 (supplymentary) 」塑模原則，但使得機敏塑模具有獨特性的是以下部份： 有目的的模型 (Model with purpose)

一位使用機敏塑模的開發者在創造模型前，在腦袋裡應該有個特定的目標 (例如與客戶溝通資料並協助更為瞭解軟體的一些觀點 )。

當目標確定後，所使用的記號類型與所需要的詳細程度將會更為清楚。

機敏塑模的獨特性 使用多重模型 (Use multiple models)

有許多不同的模型和記號可以用來描述軟體。 對大多數的專案來說，只要一個小的子集合即可。 機敏塑模建議提供必要的洞察力 (insight) ，每

個模型都應該呈現系統不同的面向，並且只有對有企圖的聽眾能提供價值的模型才會被使用。

機敏塑模的獨特性 輕裝旅行 (Travel light)

當軟體工程工作進行時，只保留那些能提供長期價值的模型，其他剩下的則拋棄掉。

當變更發生時，被保留的每個工作產品都必須要維護。 這表示此種工作會使團隊進行的速度減緩。

Ambler提到「每次你決定保存某個模型時，你會為某種對你的團隊具有訊息有效便利性，以抽象的方式來權衡機敏性 (因此潛在地增強你的團隊和專案利益共享者的溝通 )。

機敏塑模的獨特性 內容比呈現更為重要 (Content is more

important than representation) 塑模應該透露資訊給對它有意圖的聽眾。

一種依照文章所構成的 (syntactically) ，但僅透露一點點有用內容的完美模型，並不比有瑕疵記號但提供其聽眾有價值內容的模型具有價值。

瞭解模型和你所使用來創造的工具 瞭解每個模型和用來創造它的工具的長處與弱點。

局部地適應 (adapt locally) 塑模方式應該適應機敏團隊的需求。