第三部分：如何現形開發流程

現形流動順暢度的篇幅大致就先到此為止，之後有時間筆者再來多補充一些資訊。在剩下的七天裡，咱先把整個開發流動剩下的元素聊完吧！

在過去大概 20 天左右，著重在聊流動順暢度的概念與如何現形，讓團隊可以有一些方式可以檢視與探討現況，透過持續追蹤，建立起之後可以驗證各項實踐的實驗與調正的成效如何。在展開實踐經驗之前，筆者來為讀者複習在本系列頭起天對於開發流程的詮釋，再聊聊現形開發流程的部分，又可以分哪幾個面向，最後聊聊筆者過去有什麼實踐經驗是可以分享的。

**開發流程（Development Process )**是開發流動的其中一個面向，就像是公路上的號誌、標線、車流控管相關規則與措施一般，協助駕駛去理解流動的方式。也就是我們開發期間——從接到需求到交付期間的程序、方式、互動等等，可以說是需求流動的方式與策略。

通常這一塊也會是我們平常會專注改善的地方。但是過去常遇到的困境可能在於，我們很努力改善這裡，但卻沒有方式可以度量有沒有變得更好，更多是仰賴開發上的體驗與感受，最後會導致 Sprint Retrospective 開始流於形式，難以聚焦在應該改善的方向上。但透過前面的篇幅的論述，已經建立起流動順暢度的度量指標，去檢驗我們訂出來的改善方真否有用，那就可以驅散了原本的迷霧。

至於如何改善開發流程，其實讀者比起筆者肯定也更有自己的經驗、甘苦與專業，這部分筆者其實也只是協助拋磚引玉與歸納出方向而已，這邊就對此多聊聊吧。

在現形開發流程的部分，大致可以分成三個面向：

• 讓狀態更加顯著
• 讓方針更好追蹤
• 讓知識更能擴散

第 16 章：讓狀態更加顯著

所謂的狀態，不外乎就是 PBI 或是團隊與開發過程的各項資訊，增加這些資訊的透明性，能夠讓團隊更以實際的行動去協助改善流動順暢度。這邊用幾個例子去闡述：

• Age Time
• 被插單的通知
• Sprint 的儀式感
• 團隊投入開發的時間比例

Age Time

所謂的 Age Time 就是從說要做，到現在為止所經過的時間。如果已經交付，就會變成 Lead Time，在還沒交付前，就是 Age Time。

所以如果團隊希望降低的 Lead Time 指標，那如何讓呈現現在 PBI 進行狀況的 Age Time 或停在某階段的天數就是需要在開發過程中去關注的。

比如說在 PBI 的卡片上，寫上是哪一天開始去做，是有助於團隊在掃視卡片時，有機會去意識到已經多久了，是不是符合預期？有沒有在開發流程要做調整的。在實體的環境中，就是在貼有 PBI 的牆面上，直接在卡片上或是另外貼一張小便利貼寫下日期。在數位工具裡，則是在卡片顯示中，嘗試將該欄位顯示出來。

但在開發過程稍微長的情況下，對於 Age Time 是否過長的敏感度相對難抓，更直覺的方式就是將這個資訊再拆分，去意識到該 PBI 在某階段停留多少，那就更容易用經驗去判斷。在實體的環境中，通常會善用圓點貼紙，每經過一天就貼一張，不同階段可能就可以貼不同顏色；這個實踐也適用於被外部相依或障礙卡住時，另外貼一張便利貼在 PBI 上寫上原因後，在原因的便利貼上貼貼紙。

而在數位工具裡，就不像實體這麼方便，通常能夠利用的顯著篇幅就是標題，但是要團隊每個標題都要手動更新貼上貼紙，又相對麻煩。

遇到這種情況，以 Jira 為例就可以嘗試寫個 Automation Rules 去排程執行，每天為 PBI 按照條件新增不同的 Emoji。比如說要顯示 Age Time 就用蘑菇 🍄 的照片，意味這放太久。而如果要針對階段，則可以加入對 Status 的判定，加入不同形式的 Emoji，像是仿效圓點貼紙的🔴 🟠 🟡 🟢 🔵 🟤。可以參考下圖的腳本去調整：

若是以 Azure Board 為例，則可以使用 Board Setting 中的 Style 功能，去設定符合某些條件的情況下，為卡片途上不同的底色。

插入的通知

在開發流程中，其實最需要的就是將突然變化的相關資訊給即時揭露出來。以最常遇到的情況可能就是有另一張不在本週預期範疇內的 PBI，因為市場變化或者發現錯誤的情況下，優先順序突然拉高，不得不臨時插單到現有範疇內。

以 Scrum Team 來說，這些資訊最晚擴散給整個團隊知道的時機點是 Daily Scrum，但能不能有更即時的方式擴散這個資訊又不太打擾需要立即專注這個資訊的成員呢？多數時候都會善用團隊協作的訊息溝通工具，諸如 Slack、Teams 等等。但若一件事總仰賴團隊成員有意識去做，一來是總會有缺漏，而來也是在消耗專注力，這件事若是能自動化就更好了。

以 Jira 為例，在插單時通常會將某張 PBI 拖進 Sprint 的範疇裡，那這裡就是 Automation Rules 可以發揮的時候了。下圖就是當 PBI 的 Sprint 屬性欄位的值改變時會觸發的 rule，藉由檢查改變後的值是不是等同於現在當前的 sprint，就可以判別出是不是插單了。接下來就有很多做法可以突顯這件事，比如說透過 Webhook 發送訊息到 Slack 的頻道裡，抑或是透過在標題上加注、新增 Label 讓這個資訊在 Board 上更加明顯。

開始與結束的儀式感

另外一個跟 Sprint 有關的實踐是，在 Sprint 開始或結束時觸發 Automation Rules，去做一些有趣的事情。比如說發送通知到 Slack，並且擴上一些資訓，簡單點的就是當前 Sprint 的 Sprint Goal 為和，如下圖的示範。複雜一點就是搭配 branch 去揭露這個 Spritn 要做哪些 Item，或是結束時有哪些 Item 是做完的、哪些還沒。

想要知道時間投入比例？

另外一個狀態其實是團隊與 PO 可能都想了解的，就是團隊目前對時間的利用比例有多少時間是能用在開發上的。多數開發團隊遇到的困境就是在開發以外，仍有很多會議或活動佔用了團隊的時間。但若總只是口頭抱怨：「會議太多」、「這個 Sprint 開發不完都是給我們開發的時間太少了！」，其實對於事情的聚焦並沒有幫助。畢竟在沒有數據或攤開事實的情況下，團隊以外的人是無法理解或證實團隊說的話以及影響的程度。

最好就是在 Sprint 結束時，團隊的成員能夠整理出這個 Sprint 時間的在各項活動的比例會更好。比較初始的方式當然就是仰賴團隊自己算，但做這個計算事實上可能也要花上不少時間，那豈不又是一種消耗？如果能用更簡單的方式去得到這類數據該有多好。

這時候就可以用紀錄開發順暢度指標所需數據的思路，紀錄數據的這件事，是能夠與什麼行為掛勾，產生一石二鳥的局面？在時間管理上很明顯的就是仰賴行事曆。

所以在筆者過去服務的團隊，就有同事製作了一個網頁程式的 Side Project，能夠與 Google Calendar 做連結，將所有行事曆事件都顯示出來，讓團隊去點選這週與開發無關，卻實際有佔用時間的事件有哪些，這樣只需要點擊幾下就可以算出結果，比較人工要在自己計算更加簡單。

筆者則基於這個 Side Project 再進一步客製化，可以顯示事件的顏色、將資料匯出到 Google Sheets 之中、建立專注時間段的概念等等。如下圖

有了數據就可以畫出個時間比例占用的圖表，如下圖。簡單一點就分成開發與非開發時間，得知比例。進階一點就是根據情境用不同顏色顯示出不同的活動類型，這樣團隊與主管就可以討論、協調時間運用的比例。像是減少不必要的會議，降低外部的干擾等等。

更近一步甚至可以在 Calendar 的事件名稱與使用方式進行協議，讓這些現存半自動的紀錄與計算方式，透過事件的特徵自動分類，將所有紀錄與計算都完全自動化！用最低的成本拿到對團隊重要的資訊。