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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

作者簡介


熱門新聞

Advertisement