讓團隊中的資訊流動

在前文〈軟體開發的軟實力──溝通〉一文中，我會強調了溝通在軟體開發過程中的重要性。

有些程式開發者，即使他對程式語言和技術不那麼全面深入了解、撰寫程式也不那麼的快，但是因為他能夠適當的讓別人知道他遭遇到的問題、請求別人的協助，也懂得確認自己所接收的資訊是否正確、避免因為資訊傳達錯誤而衍生出種種的問題。所以這樣子的開發者，反而能夠在團隊中扮演稱職的角色，讓開發的工作進展順利。

相反的，有些技術高強的開發者，如果被賦予一個需要大量溝通的工作，但他本身卻不擅長溝通時，就有可能沒有辦法圓滿的把工作完成。由此可見溝通對軟體開發的重要性。

需要流通的資訊類型
事實上，溝通這件事除了倚賴團隊中每個成員自己的能力及自覺之外，其實為團隊設計良好的機制及流程，也可以誘發團隊成員間的溝通，做為一個導引和輔助的力量。

即使不同類型的開發專案，在資訊的權限控管上會有不同的考量。不過我覺得對於資訊控管上沒有特殊需求的團隊而言，「盡可能的讓資訊在團隊中流通」是很重要的一件事。

這包括了和開發有關的種種資訊，和專案工作排程有關的，像是現在總共有那些工作、每個人分別負責什麼工作、下一個開發的里程碑時限訂在何時、這個里程碑抵達時需要完成那些工作等等。

而和程式有關的則像是系統的架構為何、總共有那些主要的類別、每個類別的作用、它們是如何和其他類別進行互動……等等。

也有一些和團隊成員有關的，像是某成員可能在幾天後要請假，或是某人最近身體或心理狀態不好，可能沒有辦法全力投入在開發之類的。

各種和專案本身、和需求規格、和設計、和程式碼、和每個成員有關的資訊，都應該盡可能的在團隊中流通，因為讓團隊中的成員知道愈多的資訊，他們便更有機會做出更好的決策、得到更好的工作結果。

從極限編程看資訊流通的意義
就像之前我在〈程式碼共同擁有，有助能力提升〉一文中提到的，在極限編程（XP）裡主張「集體程式碼共有（Collective Code Ownership）」的概念。在這個概念下，專案中的每個人都有權力及能力，基於增加功能、修正錯誤，以及重構的原因，更動系統中的每一行程式碼。

而當我們談到了「能力」，不禁會問到，要怎麼才能夠讓每個人都有能力來更動系統中的每一行程式碼？除了本身技能之外，也得讓和每一行程式碼對應相關的資訊（像是領域知識或是演算法，甚至是設計細節或特殊考量），都讓每個成員知曉，才能夠讓他真正具備更動程式碼的能力。

極限編程裡怎麼達到這件事呢？

它是透過搭檔編程及系統隱喻等準則，來達到程式碼的共有。透過持續更換搭檔編程的對象，讓不同的成員間得以都有合作的機會，每個人都有機會碰觸到每一段程式碼。

而在搭檔編程的過程中，透過這種特有的合作模式，領域知識、演算方法、設計思維，都可以在成員間流動、傳遞。我們可以說， 極限編程透過開發方法及流程本身的設計，促進了這些資訊在團隊中流動。只要這些資訊能夠在團隊中流動，這些資訊就容易被更多的人所持有。

使溝通順利進行，讓團隊成員之間更樂於相互了解
這正是本文的主旨，我們是可以透過機制的建立，來促進各種形式的溝通在開發過程中發生，而不必只是倚賴團隊成員自己的能力及自覺。甚至，我們有機會利用這些機制，強化成員溝通的能力與意願。

以溝通所得到的效益，很容易可以構成一個正向循環。當團隊成員發現這麼做可以得到好處，他們就更願意溝通。一開始是機制的導入，隨著大家在這過程中所感受到的好處，就會漸漸形成文化。

就像我知道的一些團隊，他們用IRC網路聊天室來做為團隊中資訊交換的中心。他們建立IRC的專用頻道，每個成員習慣這個頻道上，將自己正在做些什麼、打算做些什麼、有什麼想法，對於別人想法的評論或建議、等等的資訊都丟上去。

雖然不見得每個人隨時都看著頻道的內容，甚至不是每個人都一直待在座位上，但是，因為他們都會掛在該頻道上，所以只需要檢視頻道內的資訊，就可以知道其他人所丟出來的各種資訊──即使這些資訊是在自己的非工作時間被丟出來的。

我相信，這一開始或許只是一兩個成員所建立的機制，但是每個人融入這個機制後，享受到好處，也進而形成一個文化。這樣的文化很好，也有一個機制來輔助，可以隨時、隨地都在溝通。因為有更多的資訊在團隊中流動，所以其他成員就能接收到愈多的資訊，而這些資訊便可以輔助他們做決策，使得決策的品質更好。

在過去，我們可能很習慣利用定期或不定期會議的方式來做溝通，像是定期的進度會議來審閱每個人的進度、是否遭遇到什麼困難、以及討論各種問題的解決方案。但是這樣子的資訊流通及溝通方式，受限於會議的參加者必須要在同一個時間出現，甚至不利用遠距通訊機制的話，還得在同一個地點一起出現，都讓資訊流動的速率不夠即時，也讓溝通的頻率顯得有點過低。

其實，這些在開發中的活動，都可以設計一些其他的機制來輔助的。像是，你可以利用規範成員撰寫版本控制系統上的commit log的方式，來讓成員間彼此了解彼此的工作進展。

怎麼說呢？一般而言，commit log的的主要目的，是要記錄你所commit到版本控制系統上的原始碼，究竟是為了達到什麼樣的目的，大致上做了那些事情。這樣子的記錄，有助於當我們要追溯版本控制系統中原始碼的每一次變動，找出究竟發生了什麼事情。

例如，我們在現行的原始碼版本中，發現了一個重要的程式臭蟲，為了找出這個臭蟲究竟影響到那些版本，我們就得找出這個臭蟲究竟是何時被埋到系統中的。

每一次變動的commit log，當然可以提供不錯的提示及幫助。這有助於我們判斷版本間的變化究竟是基於什麼原因、發生了什麼事情、以及可能會產生什麼效應。

不過，除了上述的目的之外，其實，commit log還有一個很好的好處，就是每個人都可以透過查看其他成員的commit log，來了解其他成員做了些什麼事情；遇到感興趣的部份，還可以把和該commit log有關的原始碼部份，都擷取出來閱讀。

這是一種有趣的方式，我知道有人會利用有空的時間去查看團隊中其他成員的commit log，看到有興趣的部份，就會拿出來好好的研究一番。無論對方是不是高手，都可以查看、研究其他成員的程式撰寫方式，看他解決特定問題的手法，看他的思維方式是否值得效法，或者是存在破綻。

以上述的描述做為一個例子，commit log除了原先就具備在版本控制系統上的好處之外，一方面，可以讓團隊成員間知道彼此的工作進展，二方面也提供一個彼此效法或相互審閱潛在問題的途徑。如果，能夠在團隊中建立這樣的機制，讓大家開始也這麼做，漸漸形成一個文化，那麼，必然可以強化團隊中資訊流通的速度及品質。

我相信，還有很多可以強化資訊在團隊中流通的方式，也衷心的建議大家不妨花點時間思考，還可以透過什麼樣機制的建立，來達到這個目標。最後也還是再度強調，資訊在團隊中的流動，是再怎麼樣也不嫌多的。