第 23 章：現形開發流動，然後呢？

今天來到了本系列的最一天，用了 29 天的篇幅探討了如何善用工具現形開發流動，無論是流動順暢度、開發流程、需求生命週期，都在這一個月內，陸續分享了現形方式，提高了開發流動的透明性。

現形了這些開發流動，然後呢？

於是三者構成了一個循環關係，透過現形需求生命週期，了解到了目前需求的邊界與其來龍去脈，能用更全面的視角去看待開發流動；並以聚焦的邊界去透過現形流動順暢度，以數據為基礎，識別開發流動的現況與趨勢；最後以此資訊，提出改善方案，透過現形開發流程去執行與改變在需求的生命週期上，成為一個循環。如此逐步地讓開發流動越拉越順暢，達到團隊想要的境界。

有別與以往，可能會在 Sprint Retrospective 中單純透過事件、想法去討論下一步的改善行動。現在有了數據的支持，團隊可以更客觀地去詮釋目前的狀況，發現單靠回憶難以發現到的特爭。以數據發現症狀（不預期的流速），以此去挖掘病因何在（不合適的開發流動），數據會驅動改變。

但是有一點是需要特別注意，且在前面一再強調的是，數據與其衍生出來的指標、圖表，都只是用某個視角切入去看待現在開發流動，並沒有任何一個方式可以直接看到全貌。

最忌諱的是直接透過某項指標去判決團隊的狀態，並要求一定要達到某個數值。這通常就會導致局部最佳化的發展，單看某指標是達到了，等整體的系統卻劣化了。比如說過度強調 Velocity 每週要有 8 點，那團隊可能迫於壓力之下，就會改變估算的方式，可能是膨脹每個 PBI 的工作量故事點。

數據應該帶來的是協助判讀整體狀況，綜合多項指標、圖表，以及團隊在這段期間發生的事件、互動，去探討整體的脈絡，再去假設問題，提出改善行動去實驗，監測預期要改善的指標的趨勢走向，這才是比較健康的狀態。

第 24 章：總結

至此，本主題想要分享的概念與實踐經驗算是有一個初步的樣貌。在這裡進行總結，期望讀者能更深入了解筆者預期要傳達的原則。

工具的使用方式，應該聚焦在要透明的資訊是什麼

本系列有滿大的篇幅在講工具的使用方式，尤其是在流動順暢度的篇章中。在使用數位化管理工具時，不用被工具本來提供的功能與方式侷限住，重點是當下聚焦要透明的資訊是什麼。想要有 PBI 狀態的區隔？那就自己建立分隔線來區分吧！想要能夠提醒 PBI Age Time 的功能？那就透過自動化去建立吧！

但是想要的功能在當前的工具真的難以實踐，嘿，一個工具不夠用，你有試過用兩個工具嗎？跳脫被工具 All in One 的綁架，工具是工具、資訊是資訊，工具只是協助團隊管理資訊的工具，而不是唯一使用資訊的管道。嘗試將資訊背後的數據抽出來，用適合的工具去實現自己想要的呈現方式，才是應該要有的思維。就如同本系列將數據從 Jira 抽出來，用 Google Sheet 去做後續的計算與繪製一樣。

這個概念也是本系列文章的起點，當初 HWDC 投稿的主旨：「誰說工具只能這樣用？重點是你想要透明的資訊流是什麼！」

數位化與實體化工具之爭？

本系列礙於篇幅，只有在第 03 章現形的方式有提到，在這個面向傳達的可能不夠深刻，在這裡多分享一點。

自從看了《Kanban in Action》後，筆者就對於資訊應該盡量用實體的方式去呈現，將其擴散出去這件事非常看重，而在 T 社的工作的環境的確也很適合這麼去做，也崇尚這樣做。

但隨著疫情時代開啟了在家工作的模式，數位化工具因為異地協作興起，漸漸的團隊成員都開始習慣使用數位化工具去協作，甚至疫情結束，回到辦公室上班之後，也就維持了這個習慣。當身為 Scrum Master 建議團隊要善用實體牆視覺化相關資訊時，開始會受到原本沒有的阻力：「這樣要紀錄兩個地方」、「實體的話沒辦法留下紀錄」、「用打字的比較快」，甚至當初在釐清 PBI 的需求，習慣面對面搭配白板書寫的討論方式，也變成一群人看著投影幕與電腦螢幕去進行。

經過了好一段時間的輔導，團隊開始嘗試拾回原本實體化的實踐，才又開始感受原本已經遺忘的好處，並且持續實踐。其中也包括了團隊遇到了變化非常快速的開發情境，透過數位化工具的操作，其實相對並不直覺、更新上很是麻煩，資訊也難以擴散，成為了回歸實體化的推力。

最後，在實體化與數位化兩者之間的工具使用、互動方式中，逐漸取得了平衡，筆者也是在這個過程中，發現兩者並沒有衝突，反而能夠各司其職。

數位化工具的好處在於自動化與易於儲存資訊，並且有隨時隨地都能讀取的特性，那就讓它成為開發流動中的資料中心，將詳細的資訊都往裡面丟，並透過其他工具自動化計算指標與產生圖表；實體化工具的強項在於互動性直覺、資訊擴散力度大，那就讓它成為平時團隊需要即時互動的方式，比如說討論、Task Board、Item Level Kanban，並善用其特型作為索引與即時記錄的方式。

不再只是「要將資訊紀錄兩個地方」，而是兩個地方各有其意義。紀錄資訊的介面是可以混編的，用實體化降低紀錄門檻，用數位化提升儲存效期與可以再利用的程度。

對筆者來說，不再有所謂的數位化與實體工具之爭，而只有數位化與實體化工具協作之美。

產出物與透明性

本系列的標題，用「現形」（Visualize）作為動詞去貫穿者個主題，這是有其意義的。

在 Scrum Guide 裡，指出 Scrum 有三本柱，分別是透明性、檢視性與調適性，三者是相依關係，有足夠的透明性，才能有越接近全貌的檢視性，才能能產出合適調適性的行動方案去改善，解決問題時，也提升了透明性與檢視性。

而 Scrum 中是如何提升透明性的？就是利用 Product Backlog、Sprint Backlog、Increment 這三個產出物（Artifacts）。這三者分別提升了產品要開發項目的範疇與排序的透明性、當前週期要專注的範疇與進行狀態的透明性、目前開發進度與對於是否符合使用者需求的透明性。

但是在整個產品開發過程中，需要提升透明性的不只有這些面向，在開發的實務經驗中，仍然受到許多資訊未透明後產生的溝通問題所苦。

儘管 Scrum 只定義了核心的三個產出物，不代表不能再有更多產出物協助提升透明性。既然團隊有更多透明性的需求，那就聚焦在要透明的資訊，將其一一透過各種產出物去「現形」吧！

但在產品開發中，又可以現形些什麼？於是本系列就以開發流動的視角去切入，探索開發流動能現形什麼？並以流動順暢度、開發流程、需求生命週期去展開這個話題，期望能帶給讀者不同的想法與收穫。

透過數據判讀，而是不是用做直接判決

提升了透明性，下一步就是該如何利用？在上一章提及應該是透過數據判讀，而是不是用做直接判決。而如何判讀這些數據，仍然是本系列文章來不及加以著墨的，這部分更適合用真實情境做案例研究，透過產出的圖表，搭配系統思考去詮釋。期望未來有機會搜集更多案例，去識別化後再與各位讀者分享囉！