
62
|
第三章
一起溝通與工作
打從軟體團隊開始建構軟體,他們就一直在與「多少文件才夠」這個問題奮戰。就像許
多團隊多年來一直在尋找「萬靈丹」方法論以解決流程、程式設計和交付的問題一樣,
他們同樣一直在尋找「萬靈丹」文件系統或範本,希望可以很神奇地記錄他們今天在建
構軟體時需要知道的每件事,然後在未來維護這份文件的內容。
傳統上認為軟體文件應該像這樣:我們需要一套文件管理系統,好讓每個人都可以放入
他們擁有的資訊,並與其他人的資訊緊密連結。如果可以追蹤的話,我們便可以建立
所有資訊之間的完整關聯性,賦予我們近乎完美的可視性,讓我們知道自己將要建構什
麼、將要如何測試,以及如何佈署和維護。其想法是,開發人員可以追蹤設計上的每個
元素是否與需求一致,而測試人員則可以追蹤每個測試案例是否與設計、需求和範圍一
致。每當團隊需要變更時,比方說某個部分的設計,他們可以實際看出哪些程式、需
求、範圍和測試案例將會受到影響,因此不必浪費太多的時間在做分析。軟體工程師稱
之為「
影響分析
」(
Impact Analysis
),他們通常試著維護大量的追溯矩陣,以便相互對
應範圍、需求、設計和測試中的所有元素。接著專案經理可以使用這份對應的矩陣來追
蹤程式、Bug 報告、設計元素和需求的源頭。
讓我們回到團隊長久以來所面臨的那個問題:他們應該建立多少文件呢?答案是,對敏
捷團隊而言,文件只要足夠建構專案就可以了。完全視團隊而定,他們溝通越順暢,問
題就越容易解決。想像一下軟體團隊建構過的所有其他文件:透過複印會議記錄來捕捉
每場會議中的所有決策;建立描述所有資料來源的所有面向的交叉參照文件;複雜矩陣 ...