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

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

2. 機敏軟體發展宣言 • 2001年Kent Beck和其他十六位著名的軟體開發業者、作家和顧問(以下稱為「機敏聯盟」簽署「機敏軟體發展宣言」。此宣言說道： • 我們正藉由實作以找出更好的發展軟體方法，並協助其他人一起實行。經由此工作，我們得以評估出其價值： • 流程與工具間的個別(individuals)與交互(interactions) • 各種型式文件編寫的工作軟體 • 合約談判時與客戶的協調合作 • 依循計劃執行時對變更的回應 • 雖然右邊的項目是有價值的，但我們更著重於對左邊項目的評斷。

3. 機敏宣言與政治行動 • 一份宣言通常會伴隨著政治性的行動 • 攻擊舊勢力並倡議革命性的改變(希望變得更好)。 • 在某些形式上，這正好就是所謂的機敏發展。

4. 機敏軟體發展的需要 • 在現代的經濟中，要預測以電腦為基礎的系統(例如網路應用程式)隨時間演進的情形常常是很困難或不可能的。 • 市場狀況迅速地改變、使用者需求的演進及新的競爭威脅無預警的出現。 • 在許多情形下，當專案開始前我們不在有能力完全地定義需求。 • 軟體工程師必須夠機敏的回應流動性的商務環境。 • 這些事實將導致我們拋棄有價值的軟體工程原則、觀念、方法和工具嗎？ • 完全不是！如同所有的工程紀律，軟體工程繼續的演進調整，以符合機敏要求的挑戰。

5. 規範流程模型的重大缺失 • Alistair Cockburn認為規範流程模型有重大的缺失： • 忽略建構電腦軟體的人。 • 軟體工程師不是機器人。 • 軟體工程師展現工作形態的巨大差異 • 在技術水準、創造力、有規律、一致性和自發性的重大差別。 • 某些人可以用書面進行良好的溝通，有些則不能。

6. 流程模型中的紀律與容忍 • Cockburn主張流程模型可以「用紀律和(或)容忍(tolerance)處理人們共通的弱點」，而大部份的規範流程模型則選擇了紀律。 • 他說道：「因為動作的一致是人類的弱點，高度紀律的方法將會很脆弱的」。 • 假設流程模型可行，他們必須提供一個真實的機制以激勵所必需要的紀律，或者他們必須以某種方式突顯展現對從事軟體工程從業人員的「包容」。

7. 快速瀏覽 • 它是什麼？ • 機敏軟體工程結合哲學和一組發展指導方針。此哲學鼓勵客戶的滿意度及儘早交付漸進的軟體版本；小而有高度動機的專案團隊；非正規的方法；最小化的軟體工程工作產品；和整體發展的單純化。 • 發展指導方針強調交付(delivery)超過分析和設計(雖然這些活動並沒有被忽視)，和開發者與客戶間主動且不斷地溝通。 • 誰完成它？ • 軟體工程師和其他的專案利益共享者(經理、客戶與使用者)以機敏的團隊一起工作 - 一個自我組織和控制自己命運的團隊。機敏團隊對所有執行的成員間，培育溝通與協調。

8. 快速瀏覽 • 它為何重要？ • 現代的商務環境引起以電腦為基礎的系統和軟體產品是快步調的和不斷的改變。 • 機敏的軟體工程對傳統軟體工程中某些軟體類型與某些專案軟體型態，代表著一項合理且可供選擇的方法。它已經展示出可以快速地交付成功的系統。 • 步驟為何？ • 機敏的發展可能最好稱為「清淡的軟體工程」。 • 基本的框架活動維持著-顧客溝通、計劃、模型、建構、交付和評估。 • 它們變形成為極小的任務組，以推動專案團隊朝向建構與交付(某些人會爭議問題分析所需的花費與解決方案的設計)。

9. 快速瀏覽 • 工作產品為何？ • 客戶和已採用機敏的哲學的軟體工程師都有相同的看法，唯一非常重要的工作產品是在適當的承諾日期交付給顧客可運作的「軟體增量」。 • 我如何確定我所做的是正確的？ • 如果機敏團隊同意流程工作，與團隊生產可以交付的軟體增量以滿足客戶，你已經做對了。

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

11. 機敏性的主要驅動力 • 在Jacobson的觀點中，貫徹改變(pervasiveness of change)是機敏性的主要驅動力。 • 如果軟體工程師要能調適如Jacobson所描述的快速改變，則他們必須要加快腳步。

12. 達成機敏性的原則-1 • 機敏聯盟(Agile Alliance)定義出12項原則給想要達成機敏性的人： • 我們最高的優先順序是經由早期與連續交付有價值的軟體以滿足顧客。 • 歡迎變更的要求，甚至在發展階段的後期發生改變。機敏流程是為著顧客的競爭利益駕馭改變。 • 頻繁的交付工作軟體，從幾個星期到幾個月，以較短的期間為佳。

13. 達成機敏性的原則-2 • 商務人員與開發者於專案期間每日必須要一起工作。 • 以激勵個人的方式建立各種專案。給他們所需要的環境與支援，並信賴他們執行此一工作。 • 對研發團隊與內部之間最快速且有效的傳遞資訊方法是面對面的交談。 • 工作軟體是進展最主要的衡量標準。 • 機敏流程促進持續的發展。贊助者、開發者和使用者應該能夠無限期地維持固定的步調。

14. 達成機敏性的原則-3 • 持續的注意技術上優良與卓越的設計，以提升機敏性。 • 簡單化　　極大化未完成工作數量的藝術　　是必要的。 • 最好的架構、需求和設計是從自我組織的團隊中出現。 • 定期的時間間隔，團隊要反映出如何可以變得更為有效，然後適當地調節與調整它的行為。

15. 4.2 何謂機敏的流程 • 任何機敏軟體流程的特性可用三個關鍵的假設描述大多數的軟體專案： • 事先預測出那些軟體的需求會持續不變、那些則會改變是相當困難的。 • 在專案進行時預測出客戶改變的優先順序也同樣地非常困難。 • 對於許多軟體的類型，設計和建構是彼此交錯的。 • 兩個活動應該一前一後的施行，設計模型建立後就可以被驗證。 • 當使用建構(construction)證明設計之前，預測需要多少設計也是非常困難的。 • 分析、設計、建構和測試可能都是無法預測(從計畫的觀點)。

16. 如何創造一個可以管理無法預測的流程? • 給定三項假設時，會出現一個重要的問題：我們如何創造一個可以管理無法預測的流程？ • 信賴流程的可適應性(adaptability)(以迅速地變更專案和技術條件)。 • 機敏流程必須是可適應的。

17. 機敏軟體流程可適應性的問題 • 不斷地適應而不能有所進展時只能完成少許的工作。 • 機敏軟體流程必須漸進地適應。 • 為完成漸進地適應，機敏團隊需要顧客的回饋(以使適當的適應得以產生)。 • 操作的原型或操作系統的某部分，得以有效激發出顧客的回饋。 • 漸進發展策略(incremental development strategy)應該被制定。 • 軟體漸進版本(software increments)(可執行的原型或操作系統的某部分)必須在短期內遞交，以便適應能與改變(無法預測的)保持步調。這種反覆的步驟讓客戶得以定期地評估軟體的漸進版本，提供所必需的回饋給軟體團隊，並影響流程中用來調整顧客反饋的適應性。

18. 4.2.1 機敏發展的政見 • 對於作為反對較為傳統軟體流程的機敏軟體發展，在其效益與應用性(applicability)方面有著相當多的爭議(有時是很刺耳的)。 • Jim Highsmith(勉強的)極端的陳述說當他在處理特性機敏時，可感覺偏向機敏的陣營(“agilists”)。 • 「傳統的方法論者是一群身陷泥淖的人，他們寧可生產完美的文件，也不願將工作系統做的更為符合商務的需求」。 • 傳統的軟體工程陣營是：「輕量級，呃，「機敏的」方法論者是一群美化電腦駭客，當他們試著擴大他們的玩具成為企業級的軟體」。 • 就像所有的軟體技術的爭論，這種方法論的爭辯冒著退化到如同宗教戰爭的風險。 • 如果衝突爆發，理性的思考將會消失，信仰將會取代事實指導著決策的形成。

19. 機敏性的真正問題 • 沒有人會反對機敏性。真正的問題則是： • 最好的達成方法是什麼？ • 我們如何建構符合客戶現今所需要的軟體，並且展現此軟體可延伸和擴展以符合客戶長期需要的品質特性，？ • 對於這些問題都沒有絕對的答案。 • 其底線是：有很多可以得到藉由考慮兩個學院最好的，但除了方法以外不要有任何的毀謗。

20. 4.2.2 人的因素 • 機敏軟體發展的倡議者強調在成功的機敏發展中「人的因素」的重要性時，都感到極大的痛苦。 • Cockburn和Highsmith說： • 「機敏發展聚焦於個人的才能和能力，針對特定的人和團隊塑造適當的流程」。 • 此陳述的關鍵點是針對個人和團隊的需要塑造流程，而不是其他相關的方法。

21. 有效軟體團隊成員間必須存在的關鍵特質 • 一個有效軟體團隊的成員間，必須要存在何種關鍵的特質？ • 能力(Competence) • 「能力」包含了天生的才能、特定的軟體相關技能、和最重要的是具備團隊所選擇應用流程的全面知識。 • 技能和流程的知識可以而且必須要教授給服務於機敏團隊的所有成員。 • 共同焦點(Common focus) • 機敏團隊成員可能執行不同的工作，並於專案中運用不同的技能，但所有的必須聚焦於一個目標上： • 在承諾的時間內交付給顧客工作軟體的漸進版本。 • 為達成此目標，團隊也必須聚焦在持續不斷的適應(大或小)，以讓流程適合團隊的需要。

22. 有效軟體團隊成員間必須存在的關鍵特質 • 協調合作(Collaboration) • 軟體工程(不管流程)是有關評估、分析及運用資訊與軟體團隊溝通；產生有益於協助客戶和其它的人瞭解團隊工作的資訊；和建立(電腦軟體和相關的資料庫)提供給客戶商務價值的資訊。為完成這些工作，團隊成員必須與另一個人、客戶及商務經理人彼此協調合作。 • 決策能力(Decision-making ability) • 任何優秀的軟體團隊(包括機敏團隊)必須允許有控制它自己命運的自由度。這意味著團隊被授予自治(autonomy) - 在技術和計畫議題上做決策的權力。

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

24. 有效軟體團隊成員間必須存在的關鍵特質 • 相互信賴與尊重(Mutual trust and respect) • 機敏團隊必須成為DeMarco和Lister[DEM98]所稱的「凝聚」(jelled)團隊 (詳見第21章)。凝聚團隊展現信賴和尊重是有必要的，使得他們「強烈地結合成比部份的總和還更好的整體」[DEM98]。

25. 有效軟體團隊成員間必須存在的關鍵特質 • 自我組織(Self-organization) • 在機敏發展的環境中，自我組織隱含著三件事情： • 機敏團隊為完成其工作組織他們自己； • 團隊組織出能最佳地調適本地環境的流程； • 團隊組織出最佳的工作時程，以最佳地達成軟體漸進版本的交付。 • 自我組織有許多技術上的益處。但更重要的是它增進協調合作和提高團隊的士氣。 • 基本上，團隊所做的就是自我管理。 • Ken Schwaber[SCH02]強調這些議題並寫道：「團隊在每次重複的循環中，挑選它相信可完成的工作量，並且對這些工作許下承諾。任何激勵團隊的措施，都不會比接受實現團隊自己所承諾的責任來得有效。」

26. 4.3 機敏流程模型 • 軟體工程的歷史是許多遭丟棄和一些已廢棄的、流程描述與方法論、模型製作方法與記號法、工具和技術。 • 每個都會名聲大噪一陣子以後，然後因為某些新的或(謠傳的)更好的東西而黯然失色。

27. 4.3.1 極限規劃(Extreme Programming, XP) • 雖然結合極限規劃(XP)的早期構想和方法發生於1980年代後期，有影響力的相關工作才由Beck 於1999年出版。 • 接下來由Jeffries et al所撰寫的著作才詳述XP的技術， • 有關XP計劃(XP planning)的其他工作，則由Beck和Fowler[BEC01b]闡述出方法的細節。

28. XP的框架活動 • XP使用物件導向的模式作為它所偏愛的發展典型。 • XP含括一組規則和發生在其環境中的四種框架活動： • 計劃(planning) • 設計(design) • 編程碼(coding) • 測試(testing) • 圖4.1說明XP的流程及註記一些與每個框架活動所相關的關鍵想法與任務。

29. 圖4.1 極限規劃的流程

30. 關鍵的XP活動_計劃(Planning) • 計劃活動是由一組描述發展軟體所需求的性能和功能故事(stories)(也稱為使用者故事(user stories))的產生所開始。 • 每個故事(類似於第7、8章中所描述的使用案例)是由客戶寫在索引卡上。

31. 何謂XP的「故事」 • 客戶基於特性和功能的整體商務價值，對故事指定某個值(value)(即優先權)。 • XP團隊成員隨後評估每個故事，並對每個故事指派一個價(cost) – 以開發所需的週數量測。 • 如果故事的發展需要超過三週，則要求客戶將故事再分割成較小的故事，並再次指派其值與價。 • 客戶和XP團隊一起工作以決定如何將故事集聚成為新的版本(下一個軟體漸進版本)讓XP團隊進行開發。

32. XP的排序發展 • 一旦對某個釋出的版本有了基本的承諾(包括對故事的協議、交付日期和其他的專案事項)，XP團隊會將故事用以下三種之一的方式排序發展： • 所有的故事將立即實作(在數星期之內)； • 具有最高重要性的故事將優先排於時間表內並優先實作；或 • 風險最高的故事將優先排在時間表內並優先實作。

33. XP的專案速率 • 當第一個專案版本(也稱為軟體漸進版本)交付後，XP團隊會計算專案的速率。 • 專案速率(project velocity) 即為第一個釋出版本中所實作顧客故事的數目。 • 專案的速率可以用來： • 協助預估下個版本的交付日期與時程，和 • 決定是否對橫跨整個發展專案的故事做出過度的承諾。 • 如果有過度的承諾發生，則修正釋出版本的內容或改變最終交付的日期。

34. XP發展工作的進行 • 當發展工作進行時，客戶可能會增加故事、變更現有故事的重要性、分割故事或取消它們。 • 隨後XP團隊則必須重新考慮剩餘所要交付的版本，並據此修正它的計劃。

35. 關鍵的XP活動_設計(Design) • XP的設計嚴格地遵循著KIS(keep it simple)的原則。 • 簡單的設計總是比複雜的呈現更受到喜愛。 • 設計提供被撰寫出故事的實作指導 - 不多也不少。 • 額外功能性的設計(因為開發者假設它於稍後會被需要)是不被鼓勵的。 • XP鼓勵使用CRC(類別-責任合作者))卡片(第8章)作為思考關於在物件導向環境中軟體的一個有效的機制。 • CRC卡片認明識別與辨認出與目現軟體漸進版本有關的物件導向類別。 • XP團隊使用類似第八章中(第8.7.4節)所描述的流程導入設計的作業。

36. 關鍵的XP活動_設計(Design) • 作為XP流程的一部份，CRC卡片是設計的唯一工作產品。 • 因為XP設計沒有使用虛擬的記號法，並且產生極少的工作產品。 • 若有的話，除了CRC卡片和突波解決方案以外，設計則可被視為一項短暫的人工製品，當往建構前進時，它可以且必須被不斷地修正。 • 如果故事設計的某部份遭遇某個困難的設計問題，XP建議立即創造此一部份設計可操作的原型。 • 對此設計雛型的實作與評估稱為突波解決方案(spike solution)。 • 其意圖是在真正執行開始時降低風險，並且檢驗含有設計問題故事的估計。

37. 重構(refactoring) • XP鼓勵重構(refactoring) – 是一種建構技術，同時也是一種設計技術。 • Fowler以下列的描述說明重構： • 重構是改變軟體系統的流程，此種方法不會改變程式碼的外在行為，而僅改善其內部的架構。這是一種有紀律清除程式碼，以降低引入「臭蟲」(bug) (及修正/簡化內部設計)機會的方法。基本上，當你在進行重構時，它已在你設計程式碼後開始改進程式碼的設計。 • 重構的意圖是藉由建議「以根本地改善設計」的較小設計改變以控制這些修正。 • 當應用程式的大小成長時，重構所需要的努力也會戲劇性地增長。 • XP的中心觀念是，設計發生在編碼出現之前與出現之後。當系統建構時，重構意謂著設計正不斷地發生。 • 建構活動本身將提供XP團隊如何改善設計的導引。

38. 關鍵的XP活動_編碼(Coding) • XP建議在故事發展後並完成初步的設計工作時，團隊不應該進行編碼。 • 要發展一系列的單元測試以熟練包含於最近上市版本中(軟體漸進版本)的每個故事 。 • 當單元測試產生時，開發者最好能夠聚焦在實作什麼才得以通過單元測試。 • 不要增加任何外來的事(儘量簡單，KIS)。 • 當編碼完成後，它可立即進行單元測試，藉此提供開發者即時的回應。

39. 何謂搭檔編程(pair programming)? • 搭檔編程(pair programming) • 在編碼活動期間一項重要的概念(和最常談論有關XP之一)。 • XP建議由二人一起於電腦工作站上共同為某個故事產生程式碼。 • 這提供了一項可即時解決問題的機制(二個頭腦總比一個強)與即時的品質保證。 • 讓開發者保持專注於解決目前手上的問題。 • 實際上，每個人所扮演的角色都有稍微的差異，例如，某人可能會思考特定部分設計的編碼細節，而其他人則會確認編碼標準(XP所需的一部份)是被遵循著，且產生的程式碼將「適合」於故事的設計。

40. 成對規劃的整合 • 當成對的程式設計師完成他們的工作時，他們所開發的程式碼會與其他人的工作整合。 • 某些情況下，這種工作每日都由整合團隊執行的。其他的情況下，成對的程式設計師則負有整合的責任。 • 這種「不斷地整合」的策略協助避免相容性(compatibility)與界面(interfacing)問題，並提供「煙霧測試」(smoke testing) 的環境(第13章)，以協助及早發現錯誤。

41. 關鍵的XP活動_測試(Testing) • 單元測試的產生是在編碼之前就開始的，這是XP模式的一個關鍵要素。 • 所產生的單元測試應該要以能夠讓它們成為自動化的框架(因此，它們可以很容易並重複地執行)實作。 • 這激勵迴歸測試策略(regression testing strategy)編碼隨時修正的策略(第十三章) (經常的提供給XP再因素原理)。 • 當個別的單元測試組織成為「通用性測試組套」時，系統的整合和驗證測試就可以每日進行。 • 這提供XP團隊持續前進的指示，也在事情出差錯時及早發出警告訊號。 • 威爾斯說道：「每幾個小時解決一些小問題總比在截止期限前修正極大的問題還要節省時間」。

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

43. 4.3.2 適應的軟體發展(Adaptive Software Development, ASD) • 適應的軟體發展(ASD)由Jim Highsmith提出成為建構複雜軟體和系統的一項技術。 • ASD的哲學基礎聚焦在人的協調合作和團隊的自我組織。 • Highsmith討論這些時寫道： • 自我組織是一種複雜適應系統的特質，類似「啊哈(aha)」的瞬間創造能力，當一些嘮叨問題浮現時的解決辦法。 • 自我組織的出現當單獨的，獨立的代理人(身上的細胞，一個生態系統的品種，一個開發者在特徵團隊)合作[協力]產生的突發結果時。 • 一個突發的結果特質超越任何的個別代理人的能力。例如，個別的腦神經在腦裡原沒有意識，但集體時的意識特質浮現。 • 我們傾向於看這集體的出現的現象為意外的，或至少難控制的和不可信任的。自我組織的研究證實了錯誤的觀點。

44. ASD的「生命週期」 • Highsmith爭論基於協助合作的機敏、適應的發展方式是「在我們的複雜的有規律和工程交互作時用有如規範資源」。 • 他定義結合三個階段的ASD「生命週期」(圖4.2)： • 臆測(speculation) • 合作(collaboration) • 學習(learning)。

45. ASD的「生命週期」_臆測(Speculation) • 在臆測期間專案被啟始，並導入適應性的週期計劃(adaptive cycle planning)。 • 適應性的週期計劃使用專案啟始的資訊－客戶的任務聲明(mission statement)、計畫的限制(即交付日期或使用者描述)和基本需求－ 以定義一套專案所要求的釋出週期(軟體漸進版本) 。

46. ASD的「生命週期」_合作(Collaboration) • 合作(Collaboration) • 有動機的人在一起工作可以將他們的天份與創意產生比絕對值超越數倍。 • 這種協同合作的方式在所有機敏的方法中循環的主題。但協同合作並不容易。不只是簡單的溝通而已，雖然溝通也是它的一部份。它不只是一些團隊作業而已，雖然凝聚的團隊(第21章)是產生真正協同合作的基礎。

47. 團隊的信任 • 個別的創新能力在協同合作的思考中扮演重要的角色。其中最重要的就是信任(trust)。 • 人們一起工作必須在以下方面信任他人： • 批評但不仇視； • 協助而沒有怨恨； • 工作和他人一樣努力或超越他人； • 讓技術可隨時取得；和 • 使用能夠導致有效行動的方法溝通問題或憂慮。

48. ASD的「生命週期」_學習(Learning) • 學習(Learning) • 作為一位ASD團隊的成員，當開始發展適應性週期某個部份的元件時，其主要強調在朝向完整週期的進程中要儘可能的學習。 • Highsmith認為軟體開發者時常對他們自己的理解(在技術、流程和專案)作過度的評價，而學習將可幫助他們改善他們真正瞭解的程度。 • ASD的哲學有顯著的忽視所使用的流程模型。 • ASD的全面強調動態的自我組織團隊、人們之間的協助合作和個人與團體的學習所產生的軟體專案團隊將有較高的成功機會。

49. ASD的「生命週期」_學習(Learning) • ASD團隊用以下的三種方式學習： • 聚焦團體(Focus groups) • 客戶或使用者對所交付軟體漸進版本的回饋。這直接的提供產品是否充份滿足商務需求的徵兆。 • 正規的技術檢視(Formal technical reviews) • ASD團隊成員檢視所開發的軟體元件，並在過程中改進品質與學習。 • 事後檢討(Postmortems) • ASD團隊針對他們自己的績效和流程(以學習與改進它的方式為意圖)變成內省的。

50. 圖4.2 適應性的軟體發展