第 21 章：現形協作的關係

前面有提過讓團隊看得更遠的交付視野，可以更了解 PBI 之間的價值差異與排序考量，像是下圖中間；再來是將探索的考量現形，用更高的角度去看待整體需求生命週期的流動，了解為什麼篩選出這些 PBI 去做交付，像是下圖的左邊。最後就再來聊聊用更廣的角度去看待需求生命週期，像是下圖的右側，這時不只是在意自己負責範圍的順暢度，更要開始思考跨服務合作間的關係與整體順暢度。

端到端的廣度

在看向更廣的整體時，可以先釐清一下自身可以負責的範圍在什麼程度。若以視覺化看板來形容，如果是單一職能團隊，可能只有 To、Doing、Done；但若是用稍微更廣的角度，就會看到 Backlog、Design、Dev、Test、Deployment、Done，這些都是需求從概念到實作完成時都會流經之處，若是跨職能團隊，看到的通常就直接會是這樣的廣度。

所以最基本的廣度就是產品需求能夠 End to End 交付會流向的主要階段，這邊不是指人的交接，而是指需求被完成的階段，所以就算是跨職能團隊內部每個人都有覆蓋彼此的技能，還是可以用 Backlog、Design、Dev、Test、Deployment、Done 這樣的階段去命名欄位，而不會因為 PBI 只需經過一個跨職能團隊，就只有 To、Doing、Done 的階段。

筆者會稱呼這樣 End to End 的視覺化看板為 Item Level 的看板，主要是相較於 Scrum Board 或 Task Board 這類以 task 分類的看板去區隔。

但是，就算團隊是跨職能，或是單位本身有包含足夠的單一職能團隊，因此能夠 End to End 的去開發與交付，仍會發現一個問題是，有時候相依的元素不是只有技能，而包含其他的服務，可能是商業上的，比如說平台、第三方業務、金流等；也可能是特殊技能上的，難以涵蓋進跨職能的，比如說 DBA、Infrastructure、第三方資源等。這時候如果仍只能看中自己能夠負責的項目，能夠提升的順暢度或許很容易就抵達極限。

相依的廣度

Agility of an organization is not about having many agile teams.
Organizational agility is about having agile interactions between teams
— Klaus Leopold

這句話是 Flight Level Academy 創辦人 Klaus Leopold 說的一段話，大意就是組織的敏捷性不在於有很多敏捷的團隊，而是在這些團隊之間仍有敏捷的互動，這句話讓筆者深有感觸。

在討論過去單一職能的組成架構時，回聊到跨越職能單位時容易形成穀倉效應，合作不易。所以後來敏捷開發提出了應該組成跨職能團隊，降低跨職能單位合作造成的等待與浪費。跨職能團隊的實踐的確減緩部分的困擾，讓開發端到端的實踐可以以更有效率的交付。然而，跨職能團隊的設計並沒有完全的解決這個問題，仍然會遇到兩個困境：

• 跨職能團隊不一定能夠完全包含所有職能，仍需仰賴單一職能團隊的服務
• 要進行大型專案的開發，仍仰賴多個跨職能團隊開發多個服務，服務之間仍有跨單位的協作

所以實務上，跨職能團隊仍是鼓勵的實踐，但實踐的方向應該著重在會需要交流頻繁的職能之間，比如說前、後端、維運等，而不是追求每種產品會用到的職能都應該涵括在內。

既然跨團隊、跨單位的協作依然會發生，那就一樣溝通與合作方式不順暢的問題。就像是筆者遇過組織內部都是以跨職能的方式去組成的案例，但是服務與服務、產品與產品之間的交流仍然會有可以更好的地方。

也就是在完成一個需求，可能因為跨職能團隊，多數是可以有跨職能團隊完成的，但仍有一部分的需求是會在各個服務間流動，最終才有辦法完成，這些流動也是屬於其生命週期的一部分，若能將其現形與追蹤，就可以讓整體流動的順暢度提高。現形這份的流動，也可以發現某服務已經夠順暢，卻仍然導致整體交付週期過長的可能原因。

這邊提供幾種現形的方式，基本上算是沿用前面提供過的手法。

透過繪製關係線去體現上下層深度結構

這時可以先透過畫圖釐清各階段可能會相依的服務與原因，找尋自己的開發週期中上下層關係為何，使團隊視野更具立體的視角。

追蹤外部相依的數量與時間

當某個 PBI 是需要經過外部協助或是處理時，代表該 PBI 為被 blocked 的狀態，可以在這時候紀錄是需要哪個外部服務的協助，從哪時候開始等待，又是從何時解除 blocked。統計久了就可以得出團隊相依的這個服務通常交付時間是多久。這時就會有兩種對策方向：

1. 以後遇到會需要這個服務的 PBI 時，就預留過去被 blocked 的時間長度
2. 找對方談談，提供數據，提出自己的期望，詢問有什麼可以雙方共同改善這件事的方式

在實踐上，若團隊有實施 通常會在團隊的視覺化看板中呈現 blocked 的狀態，比如說可以用另一種顏色的便利貼，貼在被 blocked 的 PBI / task 上，然後寫上外部服務名稱，並記錄 blocked 的起始與結束時間，並且定期填進去試算裡去繪製圖表。

Product Roadmap 與同時協作

有時候上下層關係只是因為彼此之間的優先順序不同，所以產生了等待，並不是兩個服務之間永遠要等待的上下層結構。這時候可以思考如何將其轉換成平行的關係去應對，也就是盡量讓兩個服務同時一起做這件事。

為了對齊優先順序與開發時程，有一個兼具高度與廣度視野的資訊就要被揭露出來，了解多個服務之間彼此的 Product Roadmap 大致為何，近期的 Release Plan 又大概會怎麼安排，能不能將相依的 PBI 安排在同一個時期去一起進行，那就會變成平行結構了。

當能同步一起開發時，就能夠減少不必要的等待時間，而更能及時去調整與討論。這邊也引用我在 LeSS in Action 課程學到的一個滿受用的概念：

Asynchronous problems are problem, synchronous problems are not problem.
不同步的問題才是問題，同步發生的問題不是問題

第 22 章：現形需求生命週期的遠、高、廣

在這三天筆者透過需求生命週期的三個面向去闡述概念與可以現形的方式，期望這部分能夠讓讀者在思考提升流動順暢度時，有更系統性的視角去看待這些關係，並且逐一去改善。