石頭閒語

中央大學資工系在6月15日舉辦了一場「台灣敏捷方法實務研討會」，由陳振炎教授主講。我將聽到的內容與自己的感想做了一番整理。

敏捷方法的特色與重點，絕對是「人際溝通」。 Ivar Jacobson 說「敏捷是一門社會科學。它關注的是如何讓大家像一個團隊般工作、如何激勵成員、如何相互合作等等」(CSDN《程序員》2007年4月刊)。

群育訓練與人際溝通

陳教授指出台灣的教育過度重視智育訓練，而忽視群育訓練，導致人們習慣單打獨鬥，而不善於溝通與團隊合作。故而他在會中特別提出重視「群育訓練」的想法。若能加強群育訓練，至少會改善兩方面的工作。

1. 改善重構工作。重構工作要求程序員閱讀並修改程式碼，而且不僅限於自己撰寫的程式碼，也包括其他人寫的程式碼。當我們重構其他人的程式碼時，必須認真地閱讀與思考其他人的程式碼內容，也可能與原設計者溝通，以求理解其設計思維，之後才動手修改。一般初學者常犯的毛病是粗暴地按自己的想法修改，而不了解原始設計思維。透過群育訓練，以提高程序員閱讀與修改彼此程式碼的意願，才能普遍地進行重構工作。
2. 程序員較願意遵循或者有默契地形成一種 Coding style ，並樂意使用各種現有的程式庫。在此補充我個人對 coding style 的想法， RUP 或 CMMI 之中也有 Coding style 的規範內容，但它們要求 coding style 必須是「顯式知識」，作為 Coding Standard 規範。但我以為在敏捷方法之中， coding style 的內容主要是來自慣例。應該避免冗長的 Coding Standard 文件。

就溝通的方式，陳教授依對「人際溝通關係的衝擊刪減程度」(這說法很怪，我以為該說「人際溝通關係的感覺豐富度」) 作了一番區分。指出面對面的溝通方式優於文件上的溝通。在 XP 中就強調每個小組都應該每天進行10到15分鐘的站立會議，針對昨天的問題及今天的待辦事項進行短時間而有效的討論。

儘管面對面的溝通方式優於文件上的溝通方式，我倒不認為我們可以完全不使用文字的溝通。畢竟面對面的溝通方式僅限於小規模的軟體公司。跨國性的軟體公司，或者是開放源碼的專案團隊，一般都有面對面溝通途徑的限制。有些開放源碼專案的團隊成員，甚至從未謀面，口語語言也不通的。在敏捷方法中，更重視溝通管道的多元化。在軟體開發環境中，訊息更是無所不在，甚至使每一種軟體工具都能做為訊息溝通管道。像版本控制工具、 xUnit 工具等，其實都不是傳統上的訊息溝通工具，但它們確實發揮了訊息溝通的功能(運用訊息溝通網絡及軟體工程方法建立開放源碼專案之個人淺見)。

Pair Programming

由於敏捷方法重視溝通，所以它最為突出的特色就是「結對編程 (Pair programming)」。 Pair programming 可說是 XP/敏捷方法 獨有的特色。

在會中有人問 pair programming 應如何配對，可否老鳥與菜鳥搭一組。我記得陳教授是說要避免資深和資淺的搭配，以免資深程序員總是對菜鳥進行「教學」。但我認為要加個但書，我們要避免太極端與太平均的配對。把最資深的與最資淺的配在一起固然不好，但把兩個能力相近的程序員配在一起也是不當。兩個能力相近的程序員可能會一起陷入死胡同而不自知。最好是配對時選擇一定的能力差距，如此我們可以透過類似「學徒制」的方式，由資深引導資淺，將軟體設計中的經驗潛移默化至資淺的程序員身上。若要在專案小組中導入 Agile Method ，必須要有資深 programmer 引導才能成事(軟體工程三大陣營)。不過台灣軟體界的問題是 台灣資訊軟體業缺乏資深programmer。

台灣軟體業導入 Pair programming 的障礙還有管理者思維的僵化。我個人會非常不客氣地說：台灣軟體業中真正具有管理思維的管理者並不多。他們只看到表面上是兩個人做1個工作，完全沒有任何實證就認為這是不合人事成本。雖然現在我還沒有看到夠多的實證研究結果，但從已知的成果案例來看，2個人結對合作先後成2個工作的績效，將比2個人分別且同時進行2個工作的績效要高。

由於 Pair programming 的績效是如此地出人意料，即使是不強調 pair programming 的 RUP 工法，也擷取其中概念，提出了「智能代理者 (Intelligent Agents)」的輔助工具 WayPointer (軟體工程的 GPS)。至於為每個程序員買一套智能代理者是否比兩人結對的成本支出划算，那就是管理者的判斷了。

我個人還要補充一個經驗：「一個人寫程式，其實很苦悶；兩個人一起寫，就頗有樂趣了」。不論是從工作績效、員工的工作認同與滿意度等管理指標上來看， Pair programming 都是有效率的生產方法。