II. 前言

主題名稱的意義

會對這個議題有興趣的聽眾，我想可能特別是針對「現形」這個動詞有感吧！我原本是這樣想的，但在演講現場卻是善用工具與開發流動較多人有興趣，這個意想之外倒是挺有意思的。（笑）

回歸正題，「善用工具現形你的開發流動」在這個句子下，「開發流動」是受詞，是要去「現形」的對象，但它又是比較抽象的事物，再談現形與工具前，要先有同樣的認知，以對齊接下來的內容。

所以在本主題中會先從「開發流動」(1) 的定義與譬喻講起，再去講述理論上可以怎麼將其「現形」 (2)，最後在談論實務的工作環境中，如何「善用工具」(3)將其實現。

對象、理論、實務，大概就是這樣的順序。

需要特別一提的是，在「善用工具」這一點，指的不會只是單純的使用好工具而已，而是更冀望不要被工具所侷限，不要被工具所用，而是真的去「善用」工具，讓自己想聚焦的開發流動真的現形。

第一部分

第 01 章：為何要現形開發流動？

身在軟體開發這樣的一個產業，接觸的是非常抽象的工作內容。有別於製造業、建築業這些可以看得見實體的產業，從需求到開發過程，最後交付成果，這些歷程幾乎都存在虛擬世界與彼此的互動，不是實體的堆砌。在這樣的過程中，很容易產生資訊落差，更仰賴這溝通。

但是說要溝通，這種幾乎是看不到的過程，是要怎麼溝通呢？就像是空氣在流動，我能感覺到風，卻難以描述；像是水在流動，我能感覺到衝擊，卻很難言喻。如果能將開發過程中的這些「流動」現形，那溝通起來會更加順暢。

但在軟體開發業裡，因為偏好使用數位化工具，資訊雖然容易被儲存，但卻也容易被藏得更深。就像是放到冰箱裡，資訊的確保存期限更長了，但也更容易忘記有這份資訊放在冰箱裡，總要哪天打開冰箱亂翻時，才會突然想起（想想自家冰箱裡有多少食品是自己壓根忘記它存在的）。這樣的通性，卻也造成了開發流動埋得更深、更加隱性的原因。

開發流動這類資訊，應該要更加顯性一點，不只是可以被量化成數據，而更應該成為一目瞭然的圖表或者對應的視覺特徵。更好的是能夠放在顯目的地方，可能是透過數位化工具讓他變得醒目、或者時刻提醒；也可能是在實體的牆上，貼上相關資訊，像是暖爐一樣，不斷將暖一幅射出去，實體的牆上也能將資訊輻射給經過的每個人。這就是現形。

敏捷開發的 Scrum 中有三本柱，我認為也很適合作為敏捷開發的基柱。而透明性則更是其中之最，有了足夠的透明性，才能支撐檢視性與調適性的作用。Scrum 中，協助擴大透明性的方式是訂定了三種產出物（Artifacts），分別是 Product Backlog、Sprint Backlog 與 Increment，透明這這個產品的待辦項目與優先序、Sprint 期間要專注的範疇、以及目前的進度與成果。

然而在軟體開發中，需要被透明出來的資訊不止這些，「現形」本身就是嘗試作為這些資訊的產出物，補足 Scrum 沒有涵蓋、但我們需要的部分，讓我們能夠容易意識與對齊相關資訊，產生有效的溝通，進而做出好的下一步調整與改變。