搞笑談軟工

2017年6月22日星期四

當Pattern遇到Scrum（6）：Definition of Done

June 20 13:28~14:57

Definition of Done Pattern

今天談Definition of Done，簡稱DoD。該模式的原文在此，有興趣想詳讀的鄉民可以參考。今天看Context、Problem、Force、Solution這四個元素。

Context：有幾位團隊成員展示「已完成」的Product Backlog Item給Product Owner看。Product Owner詢問Development Team何時可以使用這個功能，團隊成員表示該功能還需要額外的測試與系統遷移工作，而這些工作又相依於另外一件工作，所以現在還不能上線。經過進一步討論，另一位團隊成員表示由於這個功能是系統的核心功能，因此上線之前還需要經過審核。「那到底何時才可以完成呢？」Product Owner感到很困擾，團隊成員剛剛展示了這個功能，但還有更多的工作需要完成這個功能才算做完。

Problem：如何確保Scrum團隊對於開發團隊所交付完成的工作有相同的認知？

Forces：

在Sprint Review的時候Product Owner需要知道實際的開發進度才可根據此回饋做出相對應的決策。
團隊在Sprint結束時應該交付Potentially Shippable Product Increment（潛在可交付產品增量），如果它的品質低於利害關係人的要求，該次增量就無法釋出，需要額外的時間來讓產品變得更穩定。
不佳的品質與不預期的延遲最終可能會怪罪於團隊而造成團隊的緊張與壓力。為了真正成為一個團隊，團隊成員必須共同努力在品質上保持一致。
對於完成的認知不是只有針對外部看得到的東西，任何對於利害關係人與開發團隊有價值的東西都應該包含在內。例如，依循編程規範的所撰寫的程式碼讓開發人員在日後的開發活動中更加順利。
團隊成員很容易有意無意地隱藏他們跳過編程規範或品質要求的事實，因此產生了技術債。產品的外部品質可以在Sprint Review討論，即使你很信任團隊會努力把產品做到做好，也需要一個機制來規範產品內部品質。

Solution：所有Scrum團隊完成的工作都必須遵循開發團隊與Product Owner所同意的標準，此標準稱為Definition of Done（DoD）。「做完」表示開發團隊確認依據DoD的標準沒有任何已知未完成的工作，如果工作沒有符合DoD的要求，依據定義該工作就是沒有做完，而該工作所對應的Product Backlog Item也不能交付。

***

討論

Scrum並沒有規範團隊要採用何種敏捷實務做法，例如要不要做pair programming、BDD/TDD、CI等，只是從「黑箱」的角度要求每一個sprint結束要產生Potentially Shippable Product Increment（潛在可交付產品增量）。怎麼產生？不知道。每個sprint要能夠產生潛在可交付產品增量是一個很大的挑戰，在Scrum的框架之下透過調整DoD來增進產品品質因而達到在sprint結束有能力產出潛在可交付產品增量是最直接的做法。

DoD並不是要求團隊做出「完美無瑕」的產品，因為為了達到完美無瑕可能需要付出不合理的過高成本。因此DoD需要開發團隊與Product Owner一起定義，在追求量與追求品質之間獲得平衡。

DoD可以隨著團隊對於Scrum的理解度、敏捷力與技術能力增加而逐次加強。實務上有時候Product Owner可能會要求累積一點技術債以縮短開發時間（例如趕著參加展覽），但要記得如果產品要持續開發，短時間欠下的技術債越早還越好，以免最後被技術債所造成的利息壓到喘不過氣來，導致軟體變成硬體就敏捷不起來了啊。

***

友藏內心獨白：累積技術債除了經濟上的利息還有團隊心理上的利息。

2017年6月21日星期三

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

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不一樣）。
有些人採用看板之後並沒有發揮預期的成效，很可能是因為他一直停留在控制文化這個象限，一味地迎合現況而沒有逐漸轉型與改善。

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

***

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

2017年6月20日星期二

當Pattern遇到Scrum（5）：Sprint Retrospective

June 20 10:43~12:00

Sprint Retrospective Pattern

今天談Sprint Retrospective，簡稱Retrospective。該模式的原文在此，有興趣想詳讀的鄉民可以參考。今天看Context、Problem、Force、Solution這四個元素。

Context：Sprint即將結束，你已經準備好繼續打拼下一個sprint。無論這個sprint進行的如何，你總是希望下一個sprint能夠越做越好。

Problem：如何持續改善開發流程？

Forces：

Daily Scrum提供了一個持續改善的機會，但由於每天周期太短不易發現改善之處也不易評估改善成效，加上Daily Scrum的主要目的在於讓團隊重新計畫以便達成Sprint Goal，所以不適合用來討論持續改善的議題。
Sprint Review用來評估產品，且可能有stakeholders參加，同樣不適合用來討論持續改善的議題。
Sprint一個接著一個，團隊傾向急著進入下一個sprint開發新的功能而忘了思索現有的工作模式可否有改善之處，因而導致相同錯誤一再發生。
團隊在最近一個sprint做了許多改善，他們認為現狀已經很好沒什麼可進一步改善，更多對於改善的討論只是浪費時間而已，他們的時間要拿來做「真正的開發工作」。
當團隊成員自我評量的時候他們可能會覺得不好意思、受威脅、不稱職，這可能導致防衛行為—否認自己的責任並且把問題歸咎於其他人。

Solution：在每個Sprint結尾舉辦一個活動讓Scrum Team可以評估它在Sprint中的工作狀況。

***

討論

Retrospective（自省會議）講起來簡單做起來不容易，畢竟持續改善本身就是一種「找自己麻煩」的做法，要讓團隊自我感覺良好很容易，要讓團隊自我感覺不良好卻很傷腦筋。因此不少人選擇「閉上眼睛就以為看不見」，或是抱持著「改善是Scrum Master的責任，你來告訴我怎麼做，我覺得合理就配合，覺得不爽就不鳥你」的心態。

落實持續改善最基礎的做法是讓Scrum團隊有一個大家共同願意遵守的Definition of Done（DoD），一開始DoD不要訂得太嚴謹，最好跟團隊現況一樣或稍微增加一點要求即可。隨著每個sprint的進行，依據團隊的狀況再逐次慢慢加強DoD。

另一種方式是在〈高效率Scrum團隊的九個模式〉介紹過的Scrumming the Scrum模式：「找出上一個sprint中最重要的一個阻礙（impediment），把它寫成user story加上驗收條件放入下一個sprint的sprint backlog，確保在下一個sprint結束前把這個阻礙移除。」

也有許多團隊喜歡每次retrospective採用一種新的開會方式，例如心情曲線與各種形式的ORID等。這些做法原意是讓團隊可以透過不同的角度來「自己看到問題」，但套用這些方法很容易走火入魔，變成為了方法而方法，流於形式而忘了原本目的是要持續改善。一開始團隊成員對於新的retrospective方法覺得很有趣，但是如果持續改善沒有發生，只有改善的方法持續改變，不久之後團隊成員也會覺得無聊而把retrospective視為浪費時間的活動。

很多時候持續改善無法發揮作用，並不是團隊不知道那些地方需要改善，而是團隊乃至於整個公司缺乏信任，因此團隊成員自然產生防衛心態。任何的改善建議都好像是衝著自己而來，不管是在檯面上還是檯面下，當然要抵死反對到底啊。

***

友藏內心獨白：實質重於形式。