【還少一本書】Clean Agile

Feb. 26 15:00~16:54

Clean Agile

《Clean Agile: Back to Basics》是Robert C. Martin（Uncle Bob）最新著作，這本書算是他老人家對於敏捷開發的歷史回顧，以及他對於敏捷開發應該長成什麼樣子的個人意見。

***

第1章

第1章Introduction to Agile談到談到敏捷的歷史，從1880年代的Scientific Management（科學管理）演變到Waterfall，再到1980年代末期～1990年代早期的敏捷改革時期，Uncle Bob提到當時多個輕量級軟體開發方法的興起，到2001年17位輕量級流程愛好者在美國猶他州雪鳥滑雪聖地的聚會，誕生了敏捷方法與敏捷宣言。

第1章最後提到Ron Jeffries所畫的The Circle of Life這張圖，它表達了XP的12個實務做法，《Clean Agile: Back to Basics》這本書的核心基本上是圍繞著The Circle of Life，由外而內分成三章解釋這張圖。

讀完《Clean Agile: Back to Basics》之後，Teddy覺得Uncle Bob所謂的Clean Agile底子裡其實就是XP，這很可能是因為Uncle Bob一開始接觸的敏捷方法就是XP，而且他是個TDD堅定信仰者的關係。

▲The Circle of Life，節錄自《Clean Agile: Back to Basics》

***

第2章

第2章The Reason for Agile，對Uncle Bob來說，理由很簡單：「讓自己以及軟體開發這個行業變得更專業」。如果你夠專業，你就有勇氣可以拒絕長官不合理的要求，你敢說No。你軟體會變軟，你會持續改善與學習，且無懼改變。你的軟體品質會很好，QA應該找不到任何bug。客戶與開發人員各遵其職，相互合作。基本上算是一種軟體開發的大同世界XD。

***

第3~5章

接下來的三章分別介紹The Circle of Life的三個圈圈：

• 第3章Business Practices：介紹Planning Game、Small Releases、Acceptance Tests、Whole Team這幾個實務做法。本章一開始簡短的介紹Story和Story Point，以及軟體估算的幾種方法。然後提到Velocity、小規模釋出、驗收測試以及敏捷團隊的組成。接觸過XP或Scrum的朋友讀起來應該沒什麼困難。
• 第4章Team Practices：這一章提到Metaphor、Continuous Integration、Collective Ownership、Sustainable Pace，除了Metaphor以外其餘三個實務做法都很容易理解。Metaphor在XP剛提出的時候其實很抽象，不好解釋。但後來有了Domain-Driven  Design（領域驅動設計；DDD）之後，Metaphor就有了一個完美的解釋方式，就是DDD裡面的Ubiquitous Language（通用語言）。
• 第5章Technical Practices：這一章提到Simple Design、Pairing、Test Driven Development、Refactoring，算是軟體開發人員比較熟悉的內容。

***

第6章

第6章Becoming Agile，這一章原本是最吸引Teddy的章節。如何變得敏捷？Uncle Bob又回頭偷Kent Beck的四個XP價值觀：

• Courage
• Communication
• Feedback
• Simplicity

這章還有三點Teddy覺得很有趣的部份

• Transformation：敏捷轉型是這幾年很熱門的話題，作者認為˙（大型）組織的敏捷轉型很多都是失敗收場，因為「中間管理層」所存在的目的與敏捷精神相違背，因此他建議「產生新的組織來實施敏捷而非將現有組織轉型」。
• Coaching：近幾年敏捷圈很流行的Coaching（敏捷教練），Uncle Bob的看法異於常人，他覺得敏捷團隊不需要，或是只有偶爾需要聘請教練。
• Agile in the Large：Uncle Bob認為敏捷就是為了解決中小型軟體開發團隊所誕生出來的方法，所以根本沒有所謂「大規模敏捷」的問題。因為大規模團隊合作的問題在5000年前已經被解決了。

***

第7章

第７章Craftsmanship，本章不是由Uncle Bob執筆，而是「外包」給寫了《The Software Craftsman: Professionalism, Pragmatism, Pride》的作者Sandro Mancuso，寫得出乎Teddy意料之外的好。

Software Craftsmanship Manifesto（軟體工藝宣言）在2009年提出，Teddy之前一直覺得既然已經有敏捷宣言了，為什麼要畫蛇添足？是要另立山頭佔領地盤嗎？

廣義來看它可視為一種對於敏捷宣言的補充說明，身為一位軟體工程師，Software Craftsmanship Manifesto 的內容原本就是自己一直以來所重視與實踐的方向，落實敏捷不就是這樣嗎？！

還真的不是，敏捷經過這麼多年的演化，即使只將敏捷限定在軟體開發組織中，很多時候還是偏向A Name Without Quality，變成一種口號與行銷工具。所以這章重回敏捷軟體開發的初心，軟體工藝，也算是呼應了Uncle Bob在第二章所提到的專業。

***

結論

這本書提到很多敏捷這個詞被提出前後的歷史故事，以及重新詮釋XP的12的實務做法與4個價值。雖然書中對於Clean Agile的看法可能與現今主流趨勢相差甚遠，但這應該是作者有意為之的結果。從正面來看，可以讚賞作者不忘初心，方得始終。從負面來可，可以批評他食古不化，沒有與時俱進。

看完《Clean Agile: Back to Basics》，Teddy立馬買了《The Software Craftsman: Professionalism, Pragmatism, Pride》，且興起把當年沒看懂的XP系列書籍拿出來再看一次的衝動。

▲年輕時購買的XP系列叢書，現在回頭讀應該比較看得懂吧XD。

***

友藏內心獨白：是初心不是粗心。

領域事件幫你切割使用案例

Feb. 20 13:45~14:36

售後服務

今天上午有一位剛上過【領域驅動設計與簡潔架構入門實作班】的學員B問Teddy一個關於如何切割使用案例（Use Case）的問題。為了不洩漏學員B的工作內容，以下的文章中Teddy將學員B的應用領域轉成開發看板系統，將他提出的問題改寫，再跟鄉民們介紹。

***

問題敘述

使用者想要列印看板系統中的卡片（Card），使用者可以選擇列印全部的卡片，或是只列印挑選過的若干卡片。開發團隊想到兩種可能的實作方式：

• 方法一：實作一個PrintCardsUseCase使用案例，它接受兩個參數—boardId和filters。如果filters是空的，就列印該看板的全部的卡片；如果filters有資料，則先依據filters條件過濾不需要的卡片，再列印符合條件的卡片
• 方法二：方法一需要在使用案例中加上一個if判斷，感覺不太好。因此衍生另一種想法，把使用案例拆成兩個—PrintAllCardsUseCase和PrintCardsByFilterUseCase，前者只需要boardId這個參數，後者則需要boardId與filters這兩個參數。

寶傑，你怎麼看？！

***

用領域事件思考

學員B遇到的問題很常見，Teddy年輕的時候學習物件導向分析與設計（OOAD）也遇過同樣的問題。學了領域驅動設計和Event Storming之後，這個問題的解決方式就變得很簡單。回到事件風暴（Event Storming）來思考：

• 先寫出領域事件（Domain Event）

• 幫每個領域事件加上Command

• 幫Command寫上Input

分析到這裡就很清楚了（先不用管Aggregate與Policy），使用者的確需要兩個使用案例，但不是原本方法二的PrintAllCardsUseCase和PrintCardsByFilterUseCase這種切割方式，而是：

• FilterCardUseCase
• PrintCardUseCase

使用Event Storming，依據時間軸來思考領域事件，再寫出相對應的Command，系統的行為就會慢慢浮現出來。

***

友藏內心獨白：距離上市集資也就跨進一大步了。

領域專家X

Feb. 11 17:33~19:11

▲立志成為喵星人的領域專家

前言

無論是行為驅動開發（Behavior-Driven Development；BDD）、實例化規格（Specification By Example；SBE）或是領域驅動設計（Domain-Driven Design；DDD），共同存在一個非常重要的假設：「正確的需求可以藉由領域專家與開發團隊密切的迭代溝通所產生」。

在這個假設之下，領域專家彷彿「神一般的存在」，他的腦袋中似乎對所有問題都有答案，對於團隊的提問，他不會說：「都可以，由團隊決定」。

可能是領域專家知道的太多，他無法將所有事情主動告訴開發團隊，需要藉由團隊成員與他的互動，將完整的需求慢慢誘導出來。

這其實並不是什麼新觀念，傳統的軟體開發方法也都持相同看法，只不過BDD/SBE與DDD，特別是BDD/SBE這一系列的方法，特別強調此觀點。

***

落實BDD/SBE的困難

讀過BDD/SBE書籍的鄉民一定會發現，許多書本都會以一個例子來示範如何學習這些方法，例如停車費計算、搭乘巴士或捷運的車資計算、包裹運費計算。相對於一般的商業軟體，這些例子除了功能較少以外（系統較小），還有一個共同特色，就是有著非常明確的商業邏輯。

因為有著非常明確的商業邏輯，領域專家的角色就可以被簡化，也容易透過領域專家與開發人員之間的對話來釐清「規格」，進一步採取「舉例子」的方式來描述這些規格。作為學習目的，這樣的設計非常合理，並無不妥。

落實BDD/SBE的困難之一在於一個完整的系統除了「具備明確商業邏輯」的部分以外，也有許多功能的商業邏輯不是哪麼明確。又或者是這些邏輯不屬於核心商業邏輯（core business logic）， 而是應用程式邏輯　（application logic）。換句話說，領域專家也許對於核心商業邏輯比較清楚，但不一定對於應用程式邏輯有特別的意見。這時候通常需要由開發團隊來主導，再與領域專家確認。這個部分的系統實作，在BDD/SBE的書籍討論的比較少，因為這原本就不是這系列方法所著重的焦點。

舉個例子，以看板系統（Kanban System）為例，它本身有一些相對明確的核心商業邏輯，例如看板核心三原則：

• 視覺化
• 限制WIP（work in progress/process）
• 管理流

根據這三個原則可以舉出好幾的實例，這些都是領域專家比較熟悉的核心商業邏輯：

• 工作流視覺化實例，包含垂直工作流、水平工作流（swim lane）。
• 卡片（Card）視覺化：包含標準卡片、固定交期卡片、加急卡片、Bug修正卡片、技術工作卡片。
• 工作流加上WIP限制之後，卡片數量符合與違反WIP限制的例子。
• 阻礙（Blocker）的表達方式。
• Lead Time、Cycle Time的定義與量測方法。

真正實作看板系統的時候，有一些不屬於核心商業邏輯的應用程式邏輯會跑出來，例如：

• 一個使用者可以擁有多少個看板？
• 不同的使用者是否可以共用看板？
• 使用者要如何設計自己的看板？從頭開始設計，還是可以套用現成的模板（Template）？
• 一個看板只能表達一種工作流程，還是可以同時表達多個工作流程，以便於讓多個團隊共用看板？
• 已完成的卡片（當累積很多之後）要如何「收納」才不會阻礙使用者使用看板？
• 如何表達看板的開始與結束，以便於計算lead time？

以上總總問題，雖然也屬於開發看板系統需要釐清的邏輯，但並不屬於核心商業邏輯，因為不同的看板系統，可以有不同的決定。例如，路人甲所開發的Simple Kanban系統決定一個看板只能有一個工作流程，而路人乙所開發的myKanban系統則是支援一個看板可以有多個工作流程。

***

落實BDD/SBE的困難

相較於BDD/SBE，DDD因為要探討領域模型（domain model）、通用語言（ubiquitous language）、bounded context、context map以及aggregate、entity、value object、repository、service、factory等DDD設計模式，因此需要一個相對比較完整的系統開發作為例子，例如《Implementing Domain-Driven Design》就以開發敏捷專案管理系統當作例子。

落實DDD的困難之一在於如何找到一個「合適且完整的系統當作例子？」例子的問題領域很重要，因為學習者通常是軟體工程師，如果問題領域過於專業，例如健保系統、保險理賠系統、進銷存系統，軟體工程師很難在學習過程中弄清楚這些系統的核心商業邏輯與應用程式邏輯。如果例子太小，又失去套用DDD的意義。

為了解決缺少領域專家的問題，《Implementing Domain-Driven Design》作者選用了敏捷專案管理系統作為例子。一方面這個系統的大小適中，而問題領域又是開發人員比較容易理解的敏捷方法，因此開發人員可以自己腦補，同時扮演領域專家的角色。

***

真實世界的困難

剛剛從學習的角度來討論在學習BDD/SBE與DDD的時候，缺少真正領域專家所造成的問題。在真實世界中，這個問題是否就消失了？

雖然開發團隊應該會有專案經理、系統分析師、產品經理或Product Owner等角色來協助釐清系統需求，但實際上這些人很可能都不是真正的領域專家。就算團隊有領域專家的協助，但如前面所提到的，領域專家可以協助釐清核心商業邏輯，但對於應用程式邏輯的幫助相對較小。

此外，敏捷開發採用迭代與增量的方式，在開發過程需要持續與領域專家討論於釐清問題，但並不是所有領域專家都願意這樣子跟開發團隊配合。有些領域專家甚至認為：「這是開發團隊的工作，我為什麼要花自己的時間幫他們做事？」

所以，開發團隊不能無腦地一味將釐清商業邏輯的責任推給領域專家，而領域專家也應該多聽聽開發團隊的意見，不要把團隊提出的問題當成對自己專業知識的質疑，這是一種釐清問題的溝通過程。

***

友藏內心獨白：沒有的東西要去哪裡生？！