相較於傳統的開發流程或形式，敏捷更重視溝通這件事，敏捷軟體開發宣言說得更重視「個人與互動」大致上就是在強調溝通和合作 [^1]。

不知道大家有沒有這種經驗：某件工作交由某人負責後，某人總是回報有在做、一切順利、還可以，卻在死線前幾天突然說「做不到」。遇到這種事不管是團隊、管理者、公司、客戶都會非常崩潰。而且這種經驗通常不會只有一次，那既然此類事情會層出不窮，那有沒有辦法可以避免呢？我想這就是要靠溝通以及合作了。

但講溝通與合作誰都會講，重點就是不知道該怎麼做。那麼，有一個可以嘗試的方向就是「讓阻礙可以被看見」。什麼是阻礙呢？就是舉凡你在完成這個項目會遇到的任何會導致進度延宕的問題都算阻礙，從技術問題不知道要怎麼解、或是正在忙其他項目、或是被誰抓去做其他事、甚至這幾天有私事，無法專心處理⋯⋯等，都可以算是阻礙。暸解什麼是阻礙後，再來就是要研究怎麼讓它被看見、被知曉。

在前幾段描述的情境，通常是會希望那個某人早點講，這樣團隊就有辦法進行補救。那到底是為什麼導致某人不去提早說明呢？是怕被認為自己能力不足嗎？還是覺得時間還很長，不一定要現在做，晚點做也來得及呢？還是其實很一直努力，但是卻在後面被其他事干擾導致突然延宕呢？原因有很多種，每次遇到這類事情時都應該要去詢問到底是遇到什麼阻礙，而不是單純的咎責。正如我在〈嘗試營造團隊的氛圍〉所言，在結果上應該只看團隊有沒有事情完成，是團隊要起負責，而不只是某個人的問題。某個人會遇到的問題，別人可能也會遇到，去找尋原因並選擇改善才是比較好的處理方式。

透過這種處理方式，嘗試建立一個安全的氛圍，讓所有成員遇到阻礙都敢勇於講出是讓阻礙被看見一個很重要的前提。接下來可能就是比較細節的方法論，雖然不一定適用於所有團隊，但我仍嘗試舉例幾個讓大家參考看看。

最常見的做法是讓團隊每天開一個簡短的日會，並讓日會成為「最晚」阻礙回報時機。也就是製造一個交流空間，讓大家彼此交換資訊，暸解「誰誰誰遇到什麼阻礙，可能需要幫助，那有誰主動能給予幫助呢？」之類的。但要注意的是，這邊提到了一個「最晚」，也就是想另外強調，只要遇到阻礙都應該盡量提早提出，而不一定要等到日會，可能是在團隊通訊平台（Slack, IRC 等等）、專案管理或議題追蹤工具（Jura, Asana, Github Issues等），就可以先留言表示有遇到這類問題，若是到日會前都沒人給予回應或幫助，可以在日會時再講一次。當我們在各平台留言、或是在日會去訴說時，都是讓阻礙被看見的行為。

另外也可盡量將工作項目切成相近時間成本的大小或是子項目，若是這個項目有人開始接手後，超過幾天未完成時就開始用個記號去表示，然後逐日增加。像是在看板（KanBan）中，可以在便利貼上貼上紅色圓點貼紙，只要超過預定要完成的日期時，就每天貼一張；或是若是用資訊工具，則可以在標題加上一種表符，例如 ⚠️、?、?、?，一旦超過預定就每天加一個表符。當便利貼充滿越多貼紙、或是資訊工具的標題越來越多表符時，大家就會暸解哪些項目可能遇到阻礙，需要協助了。

在運行看板的話，也會建議將阻礙用特定顏色的便利貼寫下來，並貼在相關項目的便利貼旁邊。若是有人願意處理這個阻礙就貼上個人記號，表示有人在協助排除了。這樣也是一個有助於讓大家聊解阻礙排除狀況的方式，其他流程或工具也可以採用類似方式，將阻礙明白記下來去追蹤。

上面幾種方式希望能帶給大家一些啟發。只要讓阻礙被看見，就能製造出討論、溝通的機會，讓問題提早被發現、進而順利解決。

1: 敏捷軟體開發宣言