領域驅動設計學習筆記（12）：Event Storming與User Story

Dec. 27 20:05~21:45

▲ezKanban團隊的開發流程

問題

有朋友問Teddy：「Event Storming做完之後，如何轉成user story與團隊溝通？」

在ezKanban開發過程中，團隊的開發流程從2020年暑假開始從Scrum轉成Kanban。團隊不再額外寫In order too [獲得什麼好處]….As a user, I want to [做什麼事] 這種格式的user story，而是直接將Event Storming的Command變成Use Case放到product backlog裡面。

傳統OOAD的Use Case其粒度一般來講比user story要大，一個Use Case可能有多個執行路徑或多個劇情，每一個執行路徑可視為一個user story。所以直接以Use Case來取代user story，有可能會違反敏捷與精實開發的小批量生產原則—開發的功能儘量切小，可獲得較短的交期（lead time）。不但bug會比較少，品質較好，也可以快速收集使用者回饋。

ezKanban團隊在Event Storming的過過程中不是從CRUD的角度來尋找領域事件，而是找出任務導向（task-oriented）的領域事件，並且採用TDD/BDD/SBE的方式實作Use Case。因此從實作面的角度，也是以step by step、piece by piece、scenario by scenario的方式完成使用者需求，並不會因為沒有將Use Case改寫成user story就造成溝通或是開發上的問題。

***

範例說明：Move Lane使用案例

圖1：Move Lane Command

視覺化是實施看板方法的第一條原則，因此ezKanban軟體自然要提供設計工作流程的功能，讓使用者可以新增Stage（垂直的工作階段）與SwimLane（水平的工作階段）。除此之外，使用者在視覺化工作流程的時候經常需要調整工作流程的順序與層級，因此Move Lane（移動工作階段）使用案例也很重要，如圖1所示。

使用者可以直接用滑鼠將最上層的工作階段拖拉到想要的順序，如圖2所示，使用者正在把Reviewed移到Ready to Deploy之後。

圖2：實作完成的Move Lane畫面

***

實作Move Lane使用案例

因為採用TDD方式開發，因此先撰寫第一個Use Case的測試案例—移動最上層的Stage。請參考圖3，這個測試案例代表最常見使用情況的happy path。

圖3：Move Lane的第一個測試案例

一開始這個測試案例根本無法編譯，因為都還沒寫production code。接著就按照TDD的流程，以最簡單的方式撰寫讓測試案例可以通過的production code，再透過重構來改善設計。

因為移動工作階段這個功能比較複雜，光靠Use Case的驗收測試無法涵蓋所有可能的移動情況，因此以specification by example的精神，以單元測試來代表移動工作階段的各種可能狀況，單元測試案例執行結果請參考圖4。

圖4：Workflow身上的moveLane方法的單元測試

針對move lane的各種狀況，ezKanban團隊目前一共寫了9個單元測試，從單元測試的名稱就可以很清楚看到所想要涵蓋的情況，例如以下兩個單元測試代表移動工作階段的邊界條件測案例。

• should have correct order when move substage0 from order0 to order0 in the same parent
• should have correct order when move substage4 from order4 to order4 in the same parent

單元測通過之後，回頭跑Use Case測試案例，順利通過就完成Move Lane使用案例的第一個happy path。

接著撰寫第二個Move Lane使用案例的驗收測試—should succeed when move second root stage containing sublane to first root stage，這個案例比較複雜，代表兩個平行的stage A 和stage B，其中stage B底下還有其他的stages，然後把stage B移到stage A底下。

這兩個驗收測試都通過之後，就可以撰寫rest controller，完成後再寫前端的react程式，把前後端接起來這個Move Lane功能就完成了……第一版。

上述提到兩個驗收測試都是移動Stage，還需要增加移動SwimLane的驗收測試，測試通過後整個Move Lane使用案例才可以算是完成。

目前ezKanban團隊的TDD僅限於use cases與entities這兩層的物件，這兩層以外的開發並沒有採用TDD，而是採用傳統code first方式。

***

通用語言表現在程式碼

領域驅動開發有一個重要的觀念—Ubiquitous Language in Code，能夠做到這個層次，開發團隊本身，以及開發團隊與stakeholders（尤其是domain experts）的溝通也就沒什麼問題。

Teddy整合了DDD、Event Storming、Clean Architecture與TDD/BDD/SBE，首先透過event storming建立ubiquitous language 與domain model，接著透過clean architecture與TDD將ubiquitous language落實在程式碼之中。以上這些都做到之後，如果覺得還是需要撰寫傳統的user story，那也沒關係，就去寫吧。

***

友藏內心獨白：到了離，就不用守了。

領域邏輯與應用邏輯

Dec. 10 13:50~14:49

名詞解釋

在物件導向分析與設計（Object-Oriented Analysis and Design；OOAD）、領域驅動設計（Domain-Driven Design）或是簡潔架構（Clean Architecture）中，經常會看到領域邏輯（Domain Logic）與應用邏輯（Application Logic）這兩個名詞。在Clean Architecture中，前者稱為關鍵業務規則（Critical Business Rule），後者稱為特定應用業務規則（Application-Specific Business Rule）。

一般針對這兩個名詞的解釋：

• 領域邏輯：特定業務領域（business domain）都適用的邏輯。
• 應用邏輯：在某個業務領域中，特定應用程式的邏輯。

一般情況下，除非很大型的系統，否則開發人員遇到的情況很可能只有開發一個業務領域中的一個應用程式。也就是說，不太容易區分這兩者，特別是對初學者而言。

***

例子

最近跟北科大資工系ezKanban團隊討論看板系統的領域模型（domain model）。原本的需求只需支援圖1中的看板系統。

▲圖1：看板系統範例

為了支援圖1的看板系統，ezKanban的domain model如圖2所示。

▲圖2：ezKanban的Domain Model

圖2暗示了一個領域邏輯：一個Stage（圖1中的待辦事項、分析、實作等）有一個預設的MiniStage（圖1中待辦事項底下的想法與Top 5），一個MiniStage有一個預設的SwiLane（用來放置工作卡片的物件）。

***

過了一陣子，Teddy覺得一個看板系統應該有一個預設的Stage用來存放剛剛新增的Work Item（工作卡片），還有另一個預設的Stage用來存放已完成的Work Item。如圖3所示。

▲圖3：新的看板系統需求，一個看板有兩個預設Stage：Backlog與封存（Archive）

如此一來，增加了一個新的邏輯：一個Board物件至少有兩個Stage，如圖4所示。

▲圖4：Board與Stage的關係

圖4中的關係，應該要算是領域邏輯還是應用程式邏輯？

很顯然地這應該是一個應用程式邏輯，因為ezKanban這個應用程式的要求，才讓Board與Stage產生這樣的關係限制。如果是其他人使用相同的domain model來開發看板系統，則不一定會對Board與Stage的關係規範這種限制。

所以要實作圖4的邏輯，應該是放在DDD所說的應用程式層（Application Layer），或是Clean Architecture裡面的使用案例層（Use Case Layer）。

至於圖2中Stage與MiniStage以及SwimLange的關係，屬於domain model的核心邏輯，所以在DDD裡面的Domain Layer（又稱為Model Layer）或是Clean Architecture的Entity Layer實作。

***

友藏內心獨白：分層負責才會乾淨。

感受作用力

Dec. 07 09:21~10:25

▲使用者故事對照（User Story Mapping；USM）活動

不是可不可以的問題

有一個問題每過一陣子Teddy就會被跑Scrum或Kanban的朋友被問一次：「可不可以用軟體加投影機取代實體Scrum Board或是Kanban Board？」

這種問題，問「可不可以」之前，應該先問「Scrum Board或Kanban Board要解決什麼問題？」，然後再問「改用電子化之後，原本要解決的問題依然持續被解決嗎？有沒有產生新的問題？」。

***

低科技，高接觸

敏捷圈有一種說法：「Low Tech, high touch. High tech, low touch」。有好幾位跑Scrum的朋友跟Teddy提過，他們從實體Scrum Board（Task Board）改用軟體加投影機之後，原本Daily Scrum每個人都投入的狀況，變成傳統會議那種大家看著投影機「假裝有在聽」別人說話，但卻少了很多之前的互動，原本Daily Scrum每天「重新計畫」的目的因而大打折扣。

但也有朋友告訴Teddy，他們花重本買了大觸控電視用來取代實體Scrum Board，效果比起投影機要好很多，接近實體Scrum Board。

去感受案發現場的作用力（forces），看看解決方案有沒有平衡這些作用力，你就可以判斷目前的解決方案是否合適。

通常會想用數位工具取代實體Scrum Board或Kanban Board，不外乎：

1. 工作環境沒有牆面可以拿來建置實體Scrum Board或Kanban Board。
2. 不是所有人都在同一工作地點，可以直接觀看實體Scrum Board或Kanban Board。
3. 想要保存Scrum Board或Kanban Board的歷史紀錄。

第1點，工作環境不允許應該是要「突破」的限制而不是反過來被它限制。工作場所沒有電腦怎麼辦？總不能上班的時候把程式寫在紙上，回家再輸入自己的電腦中吧！沒有電腦公司要去買啊（或是凹員工自己帶）。

至於其他兩點，Teddy建議以實體Scrum Board或Kanban Board為主，在讓團隊成員或指派特定人員每日更新電子看板即可。聽起來好像很麻煩，實體與電子各有一份，還要手動維持同步。但實際上，同步的工作一天頂多也就花個10分鐘，是值得的投資。

***

感受作用力

今年11月的【Scrum敏捷方法實作班】 ，不知道是不是因為學員組成比較多元，包含專案經理、產品經理、開發人員、主管，在各項練習活動中都特別投入，效果也很好。

特別是在使用者故事對照（User Story Mapping；USM）活動中，所有人一起同步討論需求。有幾位學員跟Teddy反應，和他們以往的需求討論會議有很大的差別，不只是在形式上USM比較有趣，在實質面獲得的有用資訊量也大勝傳統方式。

但這並不能完全歸功於USM，同樣的練習活動，Teddy也遇過產出空洞使用者地圖的團隊。所以說，好的團隊成員加上用對方法，身處現場便可感受到好的力場。

這不是風水，更不是迷信。認真做事，活在當下，便可察覺到團隊的狀況。

***

友藏內心獨白：工具與方法最後都是要遺忘的東西。

如何用看板管理卡住的工作項目？

May 31 10:30~11:53

狀況分析

使用看板的團隊經常會遇到工作做到一半卡住的問題，卡住的原因不外乎：

• 遇到技術困難不知道該怎麼做下去。
• 遇到相依性問題，需要等待其他資源（工作、人、設備、材料）完成才可以繼續。

依據卡住的時間長短，卡住的狀況又可分為：

• 短期：團隊投入資源想辦法排除卡住的原因，每日站立會議追蹤卡住工作的進度，儘量讓工作可以順利往下游移動。
• 遙遙無期：預期工作會卡住很久，或是在特定時間才有辦法處理該工作。不需要在每日站立會議追蹤卡住工作的進度，一周、兩周甚至一個月更新一次進度即可。

***

用看板管理卡住的工作項目

▼針對短期卡住的工作，在該工作卡片上面貼上一張粉紅色便利貼，提醒團隊該工作項目發生阻礙，需要特別關注排除阻礙讓工作順利流動。

▼每日站立會議時追蹤阻礙項目的狀況，如果尚未排除則在該阻礙項目上用筆點一點，類似progress bar的概念。如果阻礙卡片上的progress bar越長，表示該阻礙停留時間越久。

***

針對被卡住「遙遙無期」的工作項目，短時間團隊並不會也沒辦法去處理它。如果直接把它放在看板上不管，會佔據一個WIP，這樣也不好。

▼一種常見的作法是在看板上建立一個獨立的Ice Box（冰箱）工作階段，把卡住遙遙無期的工作項目移入Ice Box。如此一來原本的工作階段便空出一個WIP，而團隊只需要定期檢視Ice Box裡面的工作卡片有沒有「臭酸」或「超出保存期限」即可。

當Ice Box中的工作項目其卡住的原因排除之後，只要原本的工作階段未達WIP上限，便可移回原本的工作階段繼續施工。

***

如果怕整個看板只有一個Ice Box不容易分類不同工作階段卡住的工作項目，可以參考《Agile Project Management with Kanban》書中的做法，直接在工作階段增加一個追蹤（Track）欄位。

▼如下圖所示，追蹤欄位和Ice Box類似，（通常）沒有WIP限制，放在其中的工作項目數量不會佔據實作工作階段（WIP Limit  = 5）的WIP。

***

結論

看板透過小批量生產與消除變異性讓工作流動得更順暢，縮短產品交期。卡住的工作代表產生阻礙，也就是工作流程產生變異，需要特別關注，才不會發生「人進不來，貨出不去，公司發不了財」的問題。

***

友藏內心獨白：貨暢其流。

設定看板的WIP

May 29 11:52~13:41

前言

很多剛開始跑看板的鄉民都有一個疑問：「要如何設定每個工作階段的WIP？」今天介紹《Agile Project Management with Kanban》書中提到的方法。

***

準備工作

要決定如何設定WIP，以下資料需要先準備好：

• 視覺化工作流程，例如分析、開發、測試。
• 知道每個工作項目（work item）完成的平均時間，例如分析工作一周完成六個，開發工作一周完成兩個，測試工作一周完成三個。
• 每個工作階段有多少人負責，特別是瓶頸工作階段的人數（詳見下面說明）。

***

開始計算

有了以上資訊，就可以計算初始看板的WIP。參考下表，計算步驟如下：

	分析	實作	測試
平均每人完成工作速度	6/week	2/week	3/week
工作階段人數		3
產能		6/week
WIP		3 * 1.5 = 5

• 找出瓶頸，也就是速度最慢的工作階段，在這個例子中實作速度最慢。
• 算出瓶頸的產能：平均每人完成工作速度 * 工作階段人數，2 * 3 = 6，代表實作階段每周可完成6個工作項目。
• 將實作的WIP訂為：工作階段人數 * 1.5 （四捨五入），實作階段的開發人員有3人，3 * 1.5 = 5。乘上1.5的目的是讓每個人手邊有1.5件工作可以做，以免WIP太小任何一件工作卡住就必須等待。但也不會因為WIP太高導致context switch的浪費。這個技巧在《Kanban in Action》書中也有介紹。
• 其他工作階段配合瓶頸速度：由於屬於瓶頸的實作階段每周只可完成6件工作，因此分析只需要1人即可搭配實作階段的消耗工作速度。同理，而測試階段只需要兩人。

	分析	實作	測試
平均每人完成工作速度	6/week	2/week	3/week
工作階段人數	1	3	2
產能	6/week	6/week	6/week
WIP		3 * 1.5 = 5

• 計算其他工作階段WIP：分析工作階段WIP = 1 * 1.5 = 2。測試階段WIP = 2 * 1.5 = 3。

	分析	實作	測試
平均每人完成工作速度	6/week	2/week	3/week
工作階段人數	1	3	2
產能	6/week	6/week	6/week
WIP	2	3 * 1.5 = 5	3

***

人太多怎麼辦

剛剛的例子是由瓶頸階段的人數與平均每人完成工作的速度，回推其他工作階段需要多少人。但很多情況是團隊人數已經確定，例如分析、實作、測試各2人，請參考下表：

	分析	實作	測試
平均每人完成工作速度	6/week	2/week	3/week
工作階段人數	2	2	2
產能	12/week	4/week	6/week
WIP	3	3	3

在這種情況下，因為一周完成12件分析工作但卻只能消化4件，因此分析階段的工作會累積在實作之前。而測試會沒有工作可做，導致人員閒置。

但是，幸好有WIP限制，分析工作不可能無限增加。如下圖所示，假設分析與實作階段已達WIP上限，此時分析人員便不可再從待辦事項中拉取工作來分析，只能停下來看看如何幫助工作流動得更順暢。

同理，測試階段可能沒有多餘的工作可以做，一樣需要思考如何幫助工作流動得更順暢。最直接的方式就是所謂的swarming，分析與測試階段的人到實作階段幫忙，提高實作階段，也就是瓶頸階段，的產能。

如果能夠從每個工作階段的產出可以互相匹配的角度來安排人力與設定WIP，會讓工作流動比較順暢。

當然，實務上平均每人完成工作速度的變異性可能很高，受到品質、施工人員的技能與身心靈狀態、工作項目大小、需求不確定性等因素影響，導致需要控制的因素很多，因而需要時時檢討人力、WIP的設置是否恰當，以及透過流程改善來讓工作流動更加順暢，降低交期（lead time）。

***

友藏內心獨白：小批量生產與消除變異性。

Product Owner的怨念

Jan. 29 10:22~11:48

▲排除阻礙可以改善開發進度

價值驅動

在Scrum框架中，Product Owner的主要責任是負責產品的投資報酬率（ROI），換句話說要釐清對使用者有價值並且能為公司帶來收入的需求，並依據需求的價值安排施工順序。

但是，「使用者價值」是很抽象的概念。幸運的話，等產品上市之後，從銷售量與使用者回饋得以驗證。不幸的話，產品釋出乏人問津，怎麼死的都不知道。

***

PO心中的痛

既然價值不好控制也不易評估，許多Product Owner便將眼光放在「進度控管」上面，畢竟產品的釋出進度也是Product Owner需要負責的部分。Teddy認識的Product Owner，10個裡面有11個或多或少都覺得開發團隊進度太慢。Product Owner經常公開或私下抱怨：

為什麼這個sprint只拿那麼少量的user story？

每個sprint承諾的user story為什麼總是做不完？

承諾的user story做不完為什麼沒有「自願加班」把它做完？

***

為什麼快不了？

「預估進度與實際進度不符」是軟體開發經常面對的問題。根據字面上的意思，「預估」原本就包含「猜測」與「誤差」的涵義，而「實際進度」總是要等做出來之後才曉得。所以「預估進度與實際進度不符」實屬正常現象，請安心服用。

但是，身為Product Owner還是要為產品的整體進度跟老闆或客戶交代，因此無法容忍實際進度跟「Product Owner腦袋中的進度」相差太大。如同Teddy常說的，Scrum只是一面照妖鏡。Scrum跑的好，可以反映出個人、團隊與組織的現況。如果Product Owner覺得團隊進度太慢，應該與團隊一起探討關於進度認知落差的原因，例如：

不熟悉Scrum：剛開始接觸Scrum的團隊，前半年可能都還在熟悉Scrum與敏捷開發的思維與團隊合作模式，因此開發進度會比較慢。

團隊的真實進度就是如此：以前隱瞞現實狀況才讓進度看起來符合預期，例如：犧牲品質、功能沒有做完但卻宣稱已完成，反正有問題等QA測試再來除錯就好了。現在跑Scrum，透明性增加，只是反應出團隊的真實狀況而已。

需求的不確定性高：需求的不確定性高，或是Product Owner與開發團隊缺少問題領域的專業知識，導致邊開發邊釐清需求，以及增加重工（rework）的時間。

技術的不確定性高：開發過程採用太多新技術，因此團隊成員需要花很多時間去學習與熟悉這些技術。加上新技術通常不太穩定，學習資源也比較少，因此增加團隊的學習曲線。例如，採用新的JavaScript框架、新的程式語言、新的軟體架構、新開發環境或建構工具。

多工與中斷太多：除了開發工作，團隊經常被中斷處理其他產品或專案的維護或救火工作。這可能代表以前開發的品質太差，現在回過頭來「討債」。或是每個人負責的工作太多，多工切換導致浪費，雖然每個人看起來很忙，但真正花在工作上的時間反而很有限。

外部相依性高：開發的產品有很多外部相依性，例如需要與協力廠商配合，或是開發軟體相依於公司其他部門的韌體與硬體。無法有效管理外部相依性，因而影響到產品開發的進度。

開發環境與設備太爛：有些公司業務團隊就在開發團隊的隔壁，業務與客戶講話自然音量比較大，干擾了開發團隊的思緒。另外，開發設備太爛也會嚴重影響開發進度，例如開發電腦太慢、記憶體太小、沒有雙螢幕、鍵盤太難打、持續整合伺服器跑太慢、測試設備不足等，都會影響開發進度。

開發人員不適任：進度太慢當然也可能是開發人員本身的問題，可能能力不符合團隊的期望，而且一直無法有效提升自己的能力。或是有些團隊成員立志當米蟲，能撈就撈、能混就混。也有些人比較適合傳統瀑布式專案，一個口令一個動作，不習慣Scrum團隊的自組織模式，因此表現不佳。遇到這種情況，就不需要客氣，該換人時就需要換人。

***

對症下藥

沒有Product Owner會嫌自己團隊開發太快，只會覺得可以再快一點嗎。但Scrum的目的原本就不是快，而是讓公司可以在快速變動的環境之下保持成功。Scrum跑的好，首先可以反應出團隊現況的生產力。不管有多慢，很抱歉你的團隊就是這樣，除非你有能力可以換一個你覺得更棒的團隊，否則請先接受這個事實。

接下來才能夠靜下心思考，如何讓你手邊這個由派大星、海綿寶寶、天線寶寶與珊迪所組成的團隊，可以在兼顧需求交付的前提下，透過迭代與增量的方式，逐次提升團隊所能交付的價值。

這並不一定代表團隊馬上就具備越開發越快的能力，也有可能是Product Owner更能判斷客戶所需要的價值，因此開發越少的功能就能夠具備足夠的產品競爭力。也有可能是改善價值鏈的瓶頸，使得工作流動更順暢，減少交期（lead time）。當然團隊成員的投入程度、溝通與解決問題能力的提升，也是提升交付速度與價值的重要因素。

***

友藏內心獨白：敏捷就是最大化未完成工作的藝術。

你的看板有流動嗎？

December 06 13:12~14:30

五位小朋友在操場上體育課，有人踢毽子、有人放風箏、有人扯鈴、有人踢足球，大家各玩各的。有時候踢足球的小朋友不小心把球踢到玩扯鈴的小朋友哪邊，玩扯鈴的小朋友基於「團隊合作精神」，會很好心的放下手邊的扯鈴，幫忙把球踢回去。大家 忙得 玩得不亦樂乎，遠遠看起來狀似一個運作良好的自組織團隊。

有一天這五位小朋友的體育老師學了看板方法，心血來潮將這五位小朋友上體育課的狀況用看板將其視覺化，如上圖所示。各位鄉民有沒有發現上面這個看板什麼地方怪怪的？

***

這的確是一個看板，它是一個視覺化的板子（visual board），每個工作流程也有WIP限制，但是它卻沒有真實反映工作流程，它是一個沒有流動的看板。每一位或每一組小朋友只關注自己所玩的遊戲，他們可以藉由看板知道其他小朋友目前玩遊戲的狀態，但他們並沒有一起合作完成一件工作。

看到這裡鄉民們有沒有一種似曾相似的感覺，雖然工作上幾個人被歸類成同一個團隊，但實際上很多工作都是每一個人獨力完成，並沒有團隊合作，也沒有工作流動的現象發生。在這種情況下，光是把每個人的專長，或是每個人所做的工作類別變成看板的工作階段（workflow stage），是沒辦法看出工作流動的狀態，頂多作為追蹤每個人手邊有多少工作的工具。

***

解決的方法有兩種。首先，培養團隊成員具備多能工（multi-skills），大家具備踢毽子、放風箏、扯鈴、踢足球的能力。其次，重新思考工作流程，如下圖所示（省略WIP限制）：

在「玩遊戲」這個階段，同學還是可以各玩各的，如果想知道每個人在玩什麼遊戲，只要寫在工作卡片（work item card）上面即可，如下圖所示：

***

看板視覺化工作流程，如果你的看板沒有展現出流動的效果，也許這是一種重新思考如何表達現有工作流程的訊號。

***

友藏內心獨白：「通」才不會「痛」。

做雞還是做豬？

October 27 11:56~12:33

敏捷開發領域有一個老故事，有一天雞和豬走在路上…

雞：我們一起來開一間餐廳怎麼樣？

豬：嗯，也許可以喔。餐廳要叫什麼名字？

雞：就叫做「火腿與雞蛋」。

豬：嗯…我看還是算了。

雞：為什麽？

豬：因為我要貢獻出我的肉（committed），而你只需要下蛋參與其中（involved）。

***

雞只要出雞蛋，而豬卻要拿出自己的肉做成火腿，兩者對於這間餐廳的承諾完全不同。在Scrum團隊中，Product Owner，Team，Scrum Master都屬於豬，而其他人則是雞。用傳統專案管理的說法，雞就是stakeholder：「與專案相關，但不需要動手做事的人」。

在一個口令，一個動作（command and control）的管理制度下，許多公司把員工當作「雞」來使用，希望這些雞不要有太多意見，只要按照進度每天乖乖下蛋即可。久而久之，員工也習慣當雞，對於公司或主管的命令，鮮少去質疑或提問。對公司而言，這些基層員工雖然職位不高，但因為他們是「真正做事的雞」，對於工作現場所遭遇的問題有著第一手的經驗與觀察。少了他們的回饋，對公司而言也排除了修正計畫的機會。

做雞做久了之後，員工也習慣了這種設定，就算公司決定改用敏捷方法來開發產品，讓員工自組織、自我管理，但這並不會讓員工一夕之間「雞豬變色」，馬上由雞變成豬。

有敏捷開發經驗的鄉民們，可以看看自己的敏捷團隊成員，運作起來像是對產品、目標有承諾的豬，還是僅是覺得自己只是被參與其中，「不生雞蛋亂拉雞屎」的雞？

***

友藏內心獨白：好好當人不行嗎。

為什麼看板方法適合控制與能力文化？

June 20 15:19~17:05

▲敏捷轉型之後的華麗轉身，到底是一種驚艷還是驚嚇？

▼昨天Teddy在Facebook上貼了一段話：

▼Nick問到為什麼看板適合Control & Competence文化？

今天來討論這個問題。

***

Schneider文化模型

Michael Sahota在他的《An Agile Adoption and Transformation Survival Guide》書中引用了另一位作者William E. Schneider的著作《The Reengineering Alternative: A Plan for Making Your Current Culture Work》所提出的文化模型，X軸依據公司導向（company oriented）或人員導向（people oriented），Y軸依據現實導向（reality oriented）或可能性導向（possibility oriented）而將文化分成四大類：

• 控制文化：獲得並保持控制性。
• 能力文化：做到最好。
• 合作文化：一起合作。
• 培育文化：在特定目的下學習與成長。

***

文化模型的應用

Michael Sahota進一步將敏捷方法、看板方法、軟體工藝（Software Craftsmanship）對應到基於Schneider文化模型，得到以下結論：

• 敏捷文化：合作為主，培育為輔的一種文化。
• 看板文化：控制為主，能力為輔的一種文化。
• 軟體工藝文化：能力為主，合作為輔的一種文化。

作者對應的方式也很簡單，將敏捷宣言裡面的12條原則，看板方法的六大原則，以及軟體工藝宣言的內容，依據「作者自己的判斷」對應到Schneider文化模型裡面，看看這些原則落在哪一個象限中，最多的那個象限定義了這些方法屬於哪一個文化。

▼下圖是Michael Sahota對應看板方法的結果，他認為視覺化工作流程、讓政策很明顯、管理流、尊重現有流程、角色、責任、抬頭等都屬於控制文化，占了看板方法核心原則的大部分。看板方法的其餘核心原則，包含限制WIP、持續改善、使用科學方法等則被歸類為能力文化。因此Michael Sahota將看板方法歸類為控制為主、能力為輔的文化。

***

不要誤解

由於文化上的差異太大，因此Michael Sahota在書中表示他曾經認為看板方法是敏捷方法的一種，但經過分析之後他便不再如此認為。但這並不是說看板方法就不能與敏捷方法一起運用，有一種觀點是將看板方法視為特洛伊木馬（Trojan Horse）或入門毒藥（Gateway Drug）。在一個注重控制文化的企業、組織、或團隊中，使用看板方法作為入門工具比較容易被接受，可以透過看板方法慢慢引導組織朝向合作與培育文化邁進，這就是所謂的敏捷轉型。

所以Michael Sahota說 Kanban + Agile = Agile。（乞丐中的霸主還是乞丐的概念嗎XD）。

並不是所有人都同意Michael Sahota的觀點，《An Agile Adoption and Transformation Survival Guide》附錄列出了其他人對這本書的看法，有興趣的鄉民可以細看這些不同的觀點，畢竟古語有云：「盡信書不如無書」。

▼下圖就是依據附錄中Alexie Zheglov對於看板文化對應的看法所畫出來的圖，鄉民們可以比較看看和Michael Sahota對應出來的圖很不一樣。在Alexie Zheglov的對應圖中看板方法橫跨了合作文化、控制文化、能力文化，而Michael Sahota的對應圖中看板方法則是以控制文化為主，能力文化為輔的一種方法。

***

結論

從文化的角度出發，針對看板方法有兩個啟發：

• 看板經常被認為適合處理「中斷型（插件）」的工作，而且導入門檻很低（可能因為大部分公司都屬於控制型的文化）。但「工作是否有插件」並非看板與Scrum的主要差異點，看板對於插件的處理方式並不會比Scrum好多少。從Michael Sahota的分析可以看出來，敏捷方法與看板方法的主要差異在於文化上的不同（mindset不一樣） 。
• 有些人採用看板之後並沒有發揮預期的成效，很可能是因為他一直停留在控制文化這個象限，一味地迎合現況而沒有逐漸轉型與改善。

如果你只是因為工作容易中斷或（看起來）導入簡單而使用看板方法，小心跟吃「安慰劑」的效果一樣，除了自嗨以外實際藥效不大。

***

友藏內心獨白：可以嘗試對應自己公司的文化屬於哪一種。

C.C. Agile 56心得

April 28 15:55~16:49

 

昨天是C. C. Agile 第56次聚會，邀請服務於NEXCOM公司的Cobalt Chang分享Software Driven Hardware Development這個題目，談談敏捷開發如何應用於嵌入式系統開發中。

第一次認識Cobalt是在去年（2016）某一次C. C. Agile聚會，當時採用open space（開放空間）的形式討論敏捷開發的問題。Cobalt與他的主管和同事一起參加，Teddy剛好參與他們的討論小組，當下聽到了他們所遭遇到的許多問題，也聽到與會者給他們許多不錯的建議。

本以為活動結束就結束了，沒想到之後每個月Cobalt他們都來參加C. C. Agile聚會，在一次聊天當中Cobalt提到他們落實了幾項當初在open space活動中所聽到的建議之後，解決了不少團隊的問題。當下Teddy覺得很意外，因為說實話大部分的人參加活動聽到建議都只是「聽聽而已」，回去公司之後並不會採取什麼改善行動。沒想到Cobalt他們不但行動，而且還有不錯的改善成效，所以Erica和Teddy便邀請他們來C. C. Agile分享。更難得的是，Cobalt他們的產品是屬於軟硬整合的產業，在與硬體相關的產業落實敏捷開發相較於純軟體產業更加困難。

***

在Cobalt昨晚的分享中，Teddy聽到幾個很有幫助的做法：

• 以縮短交期（lead time）為做事原則：Cobalt他們採用許多Scrum實務做法與看板方法（Kanban Method）的精神，因為產品包含硬體設計，所以很難用iteration-based的開發方式在iteration開始的時候計畫這個iteration要完成的功能。因此他們採用看板方法的作法，針對專案的每一個工作項目，首先排列優先順序，在施工的時候運用各種方式儘量縮短每一個工作的lead time。因為觀念轉換，傳統上在硬體部門、韌體部門、軟體部門之間丟來丟去沒人管的工作，就由傳統工作流下游的軟體團隊一肩扛起，往上游追朔找與其他部門的人一起合作完成工作。
• 說對方聽得懂的語言：Cobalt在演講中舉了一個例子，他們有一個案子因為硬體的限制需要把網路速度控制在100M，但原本的硬體設計並不支援。如果軟體團隊跑去跟硬體設計師說：「請把硬體改成網路速度控制在100M」那麼硬體的人會不知道你在說什麼，無從改起。但如果你跟他說：「把某個接線跳到另一個接線」那麼硬體的人就知道該如何做，也會很樂意幫忙。
• 說明「為什麼」並請求協助：軟體團隊若只是一味地「指使」其他團隊的人改這個、做那個，對方可能會覺的「我為什麼要聽你的？」如果可以先跟對方說明遇到什麼問題，所以要做一些調整或改變，則比較容易得到對方的配合。
• PM很弱不一定是壞事：不管軟體或硬體專案，許多團隊都遇到「PM（專案經理）」有點弱（擺爛？！）的冏境，團隊成員除了碎念以外，還能怎麼辦？Cobalt提到其實團隊成員大可直接去面對客戶，既然PM不管事那就自己管，到頭來反而順利完成專案（自組織團隊的概念）。
• 把繁瑣的固定知識記錄在Wiki上：軟硬體整合的專案有很多關於設定的細節，如果設定錯誤便會造成系統無法運作。這些知識一定要在解決問題的當下趕緊記錄下來，以減少「重複學習」的浪費（精實開發的作法）。

***

Cobalt在整場演講中並沒有對於Scrum或看板方法作任何說明，而是用四個專案作為例子，告訴我們如何落實敏捷與精實開發精神。許多敏捷開發的初學者經常會糾結於「XXX算不算Scrum？」而忘了原本採用敏捷開發的原意—如何在競爭的環境中保持成功。Cobalt的演講以解決問題為出發點，選用任何可以幫助他們縮短lead time並保持持續改善精神的方法，是一場非常棒的分享。

***

友藏內心獨白：從人鬼殊途到通靈少女。

【工商服務】看板方法：科技企業漸進變革成功之道（平日班）

March 21 07:50~08:13

 

你的專案遭遇到很多問題：一個團隊同時需要處理多個專案、時程延遲、團隊士氣低落、人員流動率高、加班情況嚴重、技術停滯不前、老闆或業務單位不斷地塞新需求。針對以上問題，Scrum敏捷開發法提供了不錯的解法，但是正所謂施政要「因地制宜」，治病要「對症下藥」，有時候Scrum這帖藥方可能不適合你的公司或團隊，因為：

• 公司採用瀑布式（waterfall）開發流程，短時間不太可能改成Scrum這種敏捷方法。
• 你是專門搶案子的資訊服務業者，你的團隊手上同時負責很多專案，而Scrum建議一個人最好同時間只處理一個專案，和你的現況衝突。
• 你的團隊主要在開發新產品，但三不五時會有舊產品的維護需求跑出來，而且這些臨時性的需求都很急，必須要立即處理，因此打亂了Scrum的開發步驟。
• 你的工作內容與「消防隊員」類似，專門處理突發事件，例如使用者回報的bug修正、客訴案件、公司IT維護與營運專案，不容易在固定的時間點（每個sprint開始的時候）朝開會議安排工作，而需要採用事件驅動的方式，即時的處理需求。
• 你的團隊成員比較無法一下子接受過於激烈的組織與工作模式調整，依據Scrum的建議立即組成跨職能團隊（cross-functional team）。
• 雖然可以從Scrum的工作看板（task board）得知每項工作狀態，但標準的工作看板只有「位施工」、「施工中」、「已完成」這三個狀態。你想要可視化更詳盡的工作流程，並從其中觀察出工作瓶頸以求改善之道。
• 你是老闆、高階主管或專案經理，其實你不關心什麼敏捷不敏捷、精實不精實的，你只想要有一種比較好的方法來管理專案，方便你「切票（切割工作）」和「派票（分派工作）」，以及知道團隊的進度、工作效率和生產力。
• 你已經採用Scrum，執行成效還不錯，但在開發流程與品質的持續改善方面遇到瓶頸。

 

如果你的專案具有以上任何一種「症狀」，都值得了解另外一種新的敏捷/精實開發方法：看板方法（Kanban Method）。看板以「可視化現有工作流程」為起點，先不要求團隊做出巨大的改變，以減少採用新方法的抗拒。接著，依據團隊的現有人力，設定每一個工作階段的同時施工項目上限，以協助團隊成員聚焦於「把工作完成」，而非不斷地製造「賣不出去的半成品」。 透過視覺化工具，看板方法可協助團隊找出工作瓶頸，並藉由五步驟聚焦法協助排除瓶頸，達到改善團隊工作效率，提升工作品質的目的。

看板可以應用在以下狀況：

• 幫助新創公司要管理開發流程以便快速找到市場定位
• 協助開發團隊有效管理手上同時進行的多個專案
• 增進Scrum團隊的敏捷性與觀察問題的能力
• 協助擴展大型敏捷開發團隊（例如Scaled Agile Framework, SAFe）
• 管理IT維護與營運專案的事件驅動型工作
• 以漸進且比較無痛的方式實施敏捷開發方法
• 透過視覺化管理工作流程以便觀察與突破工作瓶頸

 

▲課程實況照片。

***

報名網址在此：【看板方法與精實開發實作班】，上課日期2017年4月25、26日（二、三）。

***

友藏內心獨白：流程改善從此開始。

工作項目小於WIP限制代表什麼意思？

Jan. 15 23:15~13:43

 

1月12日禮拜四是Teddy在北科兼任的「敏捷與精實軟體開發」課程期末考的日子，其中有一個考題是：

在看板系統中，某流程階段工作卡片（work item）數量小於該流程階段的WIP上限（例如「開發」工作階段的WIP=5，但目前該工作階段只有3個work item）。就你所知，請寫出這種情況所代表的所有可能意義？

學生的答案不外乎：

• 目前工作階段還有餘力可以做更多的事（也就是說發出一個可以往上游拉取工作的信號）。
• WIP設太大。
• 此工作階段的work item被丟掉或暫時放入冰箱（ice box）。
• 上游沒有已經完成的work item可以拉取。
• 下游拿走了此工作階段buffer（已經做完）的工作，但此工作階段施工中的work item卡住（尚未完成）或太難，所以沒有人力可以往上游拉取工作。
• 下游的工作卡住所以這個工作階段的人跑去下游幫忙，導致這個工作階段的work item小於WIP。
• 忘記更新kanban board…Orz。
• 保留實力應付緊急工作，所以拉取的work item小於WIP（迷之音：用加急通道不就好了）。
• 開發人員處於閒置狀態。
  

跑過看板方法（Kanban Method）的鄉民們可以思考一下，還有沒有其他的可能性呢？

***

友藏內心獨白：這一題只有一個學生獲得滿分。

做了才有感覺

Nov. 25 10:40~11:34

 

昨天上午在北科上「敏捷與精實軟體開發」，一上課擔任「專案經理」角色的同學先報告上週專案進度，包含專案看板、用Cucumber寫成的自動化驗收測試、跑在Jenkinks上的整合報表。看完之後Teddy問了幾個問題：

1. 看板的邊界在哪裡？lead time怎麼計算？
2. 知道看板邊界之後，誰是你們的上游、誰是下游？你們和上、下游的關係如何？如何透過增進上、下游關係來改善你們的敏捷度？
3. 為什麼看板第一個工作階段「Backlog」沒有設定WIP？
4. 如何、何時決定把工作項目拉進Backlog？
5. 用Given-When-Then（GWT）格式寫成的自動化驗收測試Ｗhen的部分有兩條句子，用 and連接起來，為什麼要這麼寫？會不會有什麼問題？
6. 「定義測試DoD」這個工作項目已經完成了，當初該工作項目在看板流動的時候是經過分析、實作、才流到測試階段，還是直接從Backlog拉到測試階段？

針對這些問題和學生討論過後，他們也問了幾個問題，其中有一個比較有趣的問題：

學生：一個工作項目從「Backlog」拉到「分析階段」，分析完成之後發現太大，可以切成兩個工作項目嗎？例如「開發票」這個功能，經過分析階段之後發現可以分成「二聯發票」和「三聯發票」。

Teddy：為什麼要切？

學生：因為不切會做不完？

Teddy：何謂「做不完」？看板有要求你要在多久完成一個工作項目嗎？

學生：「做不完」的意思是要花比較長的時間才能完成。

Teddy：這個狀況在看板中會如何展現？

學生：就…會有比較長的lead time（交期）？

Teddy：對啊，所以發現lead time太長就是一種改善的訊號（看板六大原則第三條：Managing Flow）。你們應該是Scrum跑太習慣，所以地一個反應會想把工作項目切小一點，希望在「一個開發週期中完成」，忘了看板是「流（flow）」的概念。

Teddy：但是，這個問題也有另一個角度可以探討。請問你們Backlog工作階段的「DoR」（Definition of Read）是什麼？

學生：我們沒有訂。

Teddy：這會不會是問題的根源？因為工作項目沒有跟「上游的人」討論清楚就直接拉到Backlog，所以才會在分析之後想要把工作切小。為了縮短lead time，在看板中如果可以在工作進入Backlog之前就先切成大小相近且偏小的工作項目也許可以改善這個問題。

Teddy：最後退一萬步想，你可不可以在分析之後把一個工作項目切成兩個？你想這麼做也不會有警察來開你罰單。

***

友藏內心獨白：是不是比微積分簡單很多。

2016年11月【看板方法與精實開發實作班】

August 29 16:55~17:21

 

你有以下問題嗎需要解決嗎？

• 一個團隊同時開發多個專案，工作分配與時程管理一團亂，該怎麼辦？
• 最近DevOps很熱門想導入但卻不知如何著手落實？
• Scrum跑了一陣子但團隊的持續改善能力並沒有顯著提升？
• 不知如何將敏捷開發應用在大型專案上？
• 如何管理IT維護與營運專案的事件驅動型工作？
• 行政人員、HR也可以導入敏捷嗎？

歡迎報名參加「看板方法與精實開發實作班」。

▲課程實況照片。

***

報名網址在此：【看板方法與精實開發實作班】，上課日期2016年10月2、3日（日、一）。

***

友藏內心獨白：本年度最後一次公開班。

建立高效軟體團隊的五個因素

July 13 13:30~17:18

 

今天介紹一篇刊登在最新一期 IEEE Software 的文章：「Team Performance in Software Development」(軟體開發團隊績效)。文章提到五個影響軟體開發團隊的因素，分別是：

• Team Coordination（團隊協作）
• Goal Orientation（目標導向）
• Team Cohesion（團隊凝聚力）
• Shared Mental Models（共享心智模型）
• Team Learning（團隊學習）

***

Team Coordination

軟體開發包含很多不確定性，開發人員經常面對模糊、定義不清且時常異動的需求。在這種情況下需要依靠團隊成員之間的良好協作來處理問題。「協作」這個字經常聽到，到底是什麼意思？根據文中的定義，協作就是「管理活動之間的相依性」，例如：共用資源（昂貴的測試設備誰要先用）、工作分派、不同工作包之間的關係。

良好的協作需要團隊成員頻繁地互動（interaction）與回饋（feedback），以及在團隊成員之間對於相依性的事物需要達成共識，才不會出現雞同鴨講的現象：

成員甲：你這個工作怎麼做了三天都還沒完成？

成員乙：我根本還沒開始做啊。不是要等你先做好X我才可以開工？

成員甲：這兩件事情沒有一定誰要先作、誰要後做啊！

***

對應到敏捷開發，團隊協作的機制非常多。像是Scrum裡面的各種會議以及短開發週期，XP的pair programming也是一種協作開發方法。看板方法則是透過限制在製品（WIP）數量，以視覺化的方式達到人員協作的目的。

***

Goal Orientation

目標導向也是大家耳熟能詳的 口號 方法。沒有目標，或是目標不明確，會導致大家瞎忙，但卻沒有實質產出，當然會嚴重損害團隊績效。講是這樣講，但讓團隊成員擁有一個清楚且願意共同努力的目標，有時候並不是那麼容易。相信不少人有類似的經驗，老闆為了「激勵士氣」，訂定一個非常有企圖心的目標讓團隊去完成。最後除了達到激怒團隊的效果以外，並沒有實質提升績效。

文中提到團隊領導要引導成員朝向目標邁進，必須要了解軟體開發流程中種種的動態變化，時時關注與評估團隊成員的行為。

對應到敏捷開發，在Scrum中每個sprint都有一個sprint goal，由Product Owner與團隊成員共同決定。團隊成員依據story優先順序施工，這也算是一種落實目標導向的方法。Release plan（產品釋出計畫）可視為更大的目標，以避免只關注sprint goal產生見樹不見林的問題。另外，最小可行性產品（Minimum Viable Product；MVP）也是一種目標導向的做法，只是在MVP的觀念中，這個目標是有待驗證的假設，希望藉由快速上市獲得用戶回饋來修正目標。

***

Team Cohesion

團隊凝聚力就是一群人黏在一起，團結一致以追求目標的傾向。看過電影《魔戒》的人都知道，魔戒遠征隊剛開始凝聚力不高，以至於出發沒多久就只剩下佛羅多和山姆兩個人。凝聚力越高，代表團隊對於完成使用有著較高的承諾（commitment）。

XP的Collective code ownership（又稱為shared code）是一種提升團隊凝聚力的方法。Scrum的自省會議（retrospective meeting）藉由團隊成員持續提出改善建議，（做得好的話）也是一種有效提升凝聚力的手段。

***

Shared Mental Models

共享心智模型聽起來不太像平常會說的話，翻成白話文就是團隊成員對於工作、工作之間的關係、如何協作與互動等概念，有著相同的認知。例如，Scrum、XP或是Kanban這些方法便可視為一種心智模型（如何做事，以及對於某些名詞有共同的定義、理解）。說的再簡單一點，就是團隊成員認同某種做事的方法，這種認同就是共享心智模型。擴大一點來講，可以解釋成「文化」。句有相同文化背景的人，對於如何生活、如何溝通、如何做事以及一些約定俗成的事物，都有著共同理解。

共享心智模型可以增進團隊效能道理也很簡單，試想一個想要導入Scrum的團隊，只有一個人去上過課，其他人都還活在waterfall的世界中，這樣的團隊怎麼可能有效率。所以，要讓敏捷開發產生作用，必須建立起團隊的敏捷思維（agile mindset）或是敏捷文化（agile culture）。

***

Team Learning

最後一點，團隊學習，算是大絕招。不管團隊具備什麼能力，這些能力都可能會「過時」。怎麼辦？有什麼能力可以解決能力過時的問題？想來想去就是「學習力」。只能具備學習力，所以不足的能力都可以獲得，這也就是「學習性組織」的概念。

敏捷開發就是一種持續學習、持續改善的方法，各種會議、回饋機制，都是一次團隊學習的機會。

***

分類人人都會，各有巧妙不同。光是知道這五種高效團隊的特性其實沒什麼用處。鄉民們可以試者將自己熟悉的開發方法，或是目前團隊實際的做法，套到這五個因素中。自己分析看看，這些因素目前自己團隊的實踐方式是什麼？有沒有可以改進之處？具體而言可以採用何種方式來落實？

**

友藏內心獨白：寫好久。

【工商服務】敏捷大師百寶箱：瓶頸遊戲師資班

June 30 15:45~17:01

 

敏捷開發這幾年在台灣漸漸普及，不少人已經上過敏捷開發相關課程，例如Scrum與Kanban（看板方法），並且在公司內實際運用。在敏捷轉型的過程中，勢必遭遇到各種不同的阻礙，像是如何提升團隊自組織的程度、改善流程與軟體品質、敏捷團隊如何打考績、敏捷開發如何拓展到大型團隊、持續改善的具體做法、如何有效管理需求、改善團隊溝通等。如何逐一克服這些問題，具備「打怪」的能力，成為許多敏捷團隊需要克服的課題。

為了協助鄉民們解決這些雜七雜八的問題，泰迪軟體從去年底開始規劃一系列一天內的短期課程，稱為「敏捷大師百寶箱」。7月28日將推出第一次課程—「敏捷大師百寶箱：瓶頸遊戲師資班」，作為「打怪起手式」。

***

運用五步驟聚焦法持續改善流程

持續改善是敏捷開發中一個很重要的精神，Scrum團隊每個sprint都會舉辦的自省會議（retrospective meeting）就是用來落實持續改善的活動。但是，跑過幾次自省會議，你會不會有以下的疑問：「難道透過團隊成員寫出一堆便利貼並投票，就可以達到改善目的？」「有沒有什麼系統化的方式可以可以協助團隊觀察並落實改善的環節呢？」。

「五步驟聚焦法」就是一個簡單且有效的方法，可以協助團隊透過找出工作流程的瓶頸為起點，藉由最大化瓶頸效率、配合瓶頸、打破瓶頸，將局部改善擴大全面價值流的改善。

「瓶頸遊戲」將可讓學員透過模擬工作流程學習如何運用「五步驟聚焦法」持續改善系統，同時在過程中體驗敏捷與精實開發精神。

你也可以當遊戲主持人

這幾年Erica和Teddy有好幾次經驗參加各種不同的敏捷遊戲工作坊，深刻體驗到遊戲主持人的功力大大影響了這個遊戲所帶來的學習效果。好的主持人可以讓學員透過遊戲連結到背後的理論基礎，並有助於日後落實在工作上的實際應用。次一等的主持人會讓學員感受到遊戲的熱鬧，但然後呢？然後他就死了 然後玩完就沒了。

「敏捷大師百寶箱：瓶頸遊戲師資班」不只讓學員玩遊戲，課程還包含「完整的遊戲準備手冊」以及「設計技巧與原理解說」，讓你在上完課之後，可以直接把遊戲帶回公司，與團隊一起透過遊戲學習五步驟聚焦法，改善工作瓶頸。

***

上課日期2016年7月28日（四）13:30~18:30，共五小時。

***

友藏內心獨白：不只是玩，還可以帶著別人玩。

2016年7月【看板方法與精實開發實作班】

June 14 17:35~18:40

 

最近一個多月去某知名外商上了四天的課，昨天是最後一次上課，上的是「單元測試與持續整合」。因為有學弟在該公司上班，前三次中午都和學弟在公司的員工餐廳吃飯。昨天中午有一位主管突然找Teddy一起吃飯，他正嘗試在自己的團隊中導入Scrum，遭遇到一些困難，找Teddy交換一些意見。

課程結束之後學弟留下來問Teddy幾個有關導入看板方法（Kanban Method）的問題。學弟想要在自己的團隊中導入看板方法，他對於「拉動模式（pull model）」以及如何設定看板流程有些做法想跟Teddy討論。

該公司規模比較大，員工的素質也很高。不同團隊之間沒有統一規定的開發流程，可以由團隊主管自行決定，大原則只要能符合公司對於產品時程的要求即可。

***

Scrum和看板方法（Kanban Method）是目前兩個比較流行的敏捷/精實開發方法，有些團隊非常喜歡Scrum，也有人覺得看板方法的漸進式改善模式比較符合他們企業的文化。引入新的方法，無論是哪種方法，都是一種行為模式改變的過程。導入的成敗，很大部分取決於團隊行為模式改變的程度，以及改變之後的合適度（fitness）。在學習新方法的過渡期間，因為新方法尚未熟練、舊方法尚未割捨，所以遇到問題很容易回到舊習慣中找答案，最後導致四不像，無疾而終又打回原形。

縮短導入新方法的磨合期，提高成功率，最快且有效的方法就是找熟習的專家輔導，其次則是參加培訓課程。以看板方法為例，正確的觀念可以避免以下常見錯誤：

• 實體看板（visual board）成為主管塞工作給團隊成員以及稽催工作進度的視覺化工具。
• 看板沒有設定在製品上限，導致工作不斷地由主管塞給員工，形成累積半成品的浪費。
• 沒有持續改善，忽略以下所有改善的契機。
  • 縮短交期（lead time，完成一件工作所花的時間）
  • 透過累積流量圖觀察工作流動是否順利
  • 發現瓶頸、最大化瓶頸使用率、配合瓶頸、突破瓶頸
  • 從全面（系統性）的角度重新思考現有工作流程的合理性與效率
  • 透過消除浪費達到流程改善
  • 提高延遲承諾（defer commitment）與快速交付（deliver fast）的能力

***

學習看板方法，光是透過讀書，很快就會忘記且不太容易體會箇中精妙之處。泰迪軟體的【看板方法與精實開發實作班】透過看板桌遊，讓學員在遊戲中快樂體驗看板方法，加深看板方法理論與實務之間的聯繫。搭配講師Teddy與Erica理論與實務兼備的精彩解說，讓你想學不會也難。

▲看板桌遊

***

看板方法可應用在以下狀況：

• 讓你的Waterfall流程變得更順暢
• 幫助新創公司要管理開發流程以便快速找到市場定位
• 協助開發團隊有效管理手上同時進行的多個專案
• 增進Scrum團隊的敏捷性與觀察問題的能力
• 協助擴展大型敏捷開發團隊（例如Scaled Agile Framework, SAFe）
• 管理IT維護與營運專案的事件驅動型工作
• 以漸進且比較無痛的方式實施敏捷開發方法
• 透過視覺化管理工作流程以便觀察與突破工作瓶頸

▲課程實況照片。

***

報名網址在此：【看板方法與精實開發實作班】，上課日期2016年7月15、16日（五、六）。

***

友藏內心獨白：上了再回去試。

遊戲易玩，講解難尋

June 01 10:30~11:37

▲重構樂高遊戲（Refactoring Lego Game）

 

敏捷社群有一種「透過遊戲學習新知」的方法，例如「Scrum樂高遊戲」、「看板桌遊」、「多工遊戲」、「樂高TDD遊戲」、「自組織遊戲」等。有一次Teddy和Erica去參觀某車廠的零件倉庫，看到現場的「豐田生產系統」學習中心，有很多種學習遊戲教具。也許敏捷社群的做法，就是仿造「豐田生產系統」的訓練方式。

▲看板桌遊

 

▲看板大雞排遊戲

 

▲多個團隊一起合作的「Scrum樂高遊戲」（Scrum Lego Game）

 

▲棉花糖挑戰遊戲

***

大部分遊戲本身都不難，只要親身玩過一次大概就可以回公司帶著同事一起玩，有些遊戲簡單到就算沒玩過，只要上網查一下遊戲規則也可以很快樂地找一群人玩起來。但「玩遊戲」本身並不是重點，重點在於透過遊戲連結到敏捷與精實開發中所要表達的觀念與精神，這種連結可以加深玩家的記憶，而整個學習過程又不會枯燥乏味。所以「遊戲主持人」或「講解者」的功力就非常重要，必須要引導或帶領玩遊戲的人將遊戲內容反應至所要傳達到學習重點。否則，遊戲本身除了新鮮、有趣以外，對於「學習」的幫助可能很有限。

***

昨天在日本禪學大師「鈴木大拙」的書中看到一句話：「練習劍道的大堂稱為『道場』，道場原本是指宗教修練的場所，其梵語原意是『悟的場所』。」做軟體的人借用劍道的「道場」，創立「程式道場（Coding Dojo）」活動，雖然不像「玩遊戲」那麼輕鬆，但也是一種透過親身操作達到學習目的的方法。

道場是「悟的場所」，不要因為形式而遺忘了原意。

***

友藏內心獨白：讓人感覺強大好像很容易。