Jserv's blog

鼯鼠與軟體專案開發

「鼯鼠」跟「軟體專案開發」之間有什麼關聯呢？在解釋匪夷所思的標題之前，先來探討鼯鼠。

圖片來源： http://wcm.gdf.gov.cn/dzw/upimages/19.gif
圖片來源： http://www.e-earthgeo.com/summary_pic/166/166050.jpg
稍早曾閱讀過李美嬅所撰寫的 [教師抨教改：下一代不如鼯鼠 ] 一文，該老師擔憂，在教育改革的多元化，與課程廣度的變化衝擊下，青年學子是否會連「五技而窮」的鼯鼠還不如呢？沒有受過高等教育的我，沒資格評論教育改革，但我對於「五技而窮」的出處感到很好奇，查閱了一些資料。 《荀子‧勸學》述及：

「螣蛇無足而飛，梧鼠五技而窮。」

相關的注釋：

• [教育部成語典：梧鼠技窮]
• [清風閣：梧鼠技窮]
• 楊倞˙注：梧鼠當為鼫鼠。
• 宋朝黃庭堅詩：「五技鼯鼠笑鳩拙」。
• 《爾雅》：鼯鼠，形似松鼠，尾長，腹旁有飛膜，目前肢之腕起，至後肢跗部而達尾根，能在樹上飛躍。
• 《說文》將鼫鼠稱為「五技之鼠」，並說它的「五技」是：「能飛不能過屋，能緣不能窮木，能游不能渡谷，能穴不能掩身，能走不能先人。」
• 螣蛇是一種龍，沒有腳，但能騰雲駕霧，飛游空際。

所以，後世比喻什麼都懂一點、卻又什麼都不甚高明，就稱作「梧鼠之技」或「梧鼠五技」。鼯鼠有五種技能，但都不專精：能飛卻不能上屋，能緣卻不能窮木，能遊卻不能渡谷，能穴卻不能掩身，能走卻不能先人，荀子用語即警惕學子要用心專一，即可事無不成。

然而經典之所以為經典，在於其永遠無法完美實現。作一個學問研究者，不可能只對一個領域或一個項目感興趣，難免會涉及非主要專長項目，換個角度來想，只專注單一技術的者，有可能讓自我的視野受侷限，並且該圈子將會越來越窄，相反的，我們很多時候都需要扮演「鼯鼠」的角色。

Fredrick P. Brooks Jr. 的經典著作《人月神話》中最重要的概念就是「概念整體性」(conceptual integrity)，用以貫穿全書，大意就是說寧可少添加雜七雜八的功能 (anomalous features)，也應該保證，整個系統體現的是完整的一套設計理念。這幾個字看起來理說當然，但等專案進來時，就不是這麼一回事，畢竟「出錢的是大爺」，我們必須竭盡所能的滿足客戶的需求 (well，你也知道，這句是官話)。就算是我這種不入流的工讀生，也會被指派成為一個計畫的專案經理，或者計畫執行人，既然領老闆給的薪資，就要謹記於心：「不賺錢的企業是罪惡的」。但是在軟體的「蘊釀」過程中，各級決策者都很容易產生強調「功能」而逐漸忽略「概念整體性」(諷刺的是，我們的確可以看到書架上擺放著《人月神話》一書)。

為了時程安排 (說難聽一點就是：怕客戶抽單)，我們 (既然作為一個「聚合體」，似乎就難脫離關係) 會在專案初期先做出 "Demo" 版本，以一個沒有妥善規劃的 codebase 出發，趕在 deadline (對每個趕過專案的開發者來說，"dead"-line 一詞實在太妙了) 前做出包含大量「功能」、但就整體而言，卻是不知所云的系統。好，現在客戶決定要下單了 (按：[Jouston] 透露說跟日本客戶打交道，要會灌酒，意識不清的情況下，規格標準才不會那麼嚴苛)，有資金下來，身為專案經理或者是軟體架構師，就需要開始好好規劃「真正」的系統設計。《人月神話》提到的「第二版效應 (the second system effect)」，簡單來說，在設計第一版系統時，往往出於較弱的自信心以及量力而行的考慮，儘量剪裁要實現的功能數量，但是當第一版系統成功發布，也就是剛剛提到的 "Demo" 版本，開始第二版的設計時，隨著自信心的增強，大量以前被壓制的提議都會重現，設計師在塞入新的功能時也會不再那麼保守，很多情況下，這導致一個臃腫而缺乏「概念整體性」的第二版系統，更可能釀成由於一兩個附加功能的實現難度，而導致整個系統開發推遲、甚至難產的事例。

所以，Brooks 認為首先要區分產品人員和開發人員：architect 和 implementor。為確保「概念整體性」，做出決定的必須是少數，甚至一個人。另，在開發過程中可以考慮「外科手術式」的開發團隊，明確來說，就是由唯一的「手術師」以及多個助手、測試人員、專案聯絡員 / 工具 / 管理員、秘書等組成的隊伍。Brooks 在其他的章節裡說過，提高軟體項目的質量的最好辦法之一，就是找到合適的人，也就是說，「偉大」的設計師和普通設計師之間的差別，比採用任何先進開發工具 / 方法論 / 管理模式前後的差別都要大。我想，這些經典相當明確的指出軟體開發的問題，而且歷久彌新，但我的疑惑是，如果有一天我們被拔擢成為前述的「手術師」，該以何種態度勝任呢？

這時候，我們可能要扮演「鼯鼠」的角色。每個人都有其長處，而且我們可以假設團隊中的每個人都有某項凌駕於其他成員的能力，一個軟體架構師或者專案管理者，面對小組成員的工作切割、專案時程規劃、技術議題，以及潛在的 blackbox (通常是需要自 3rd-parties 取得的技術或專利項目，之中有很多非技術議題)，就某些角度來說，架構師樣樣不精樣樣通，雖然無法登上個別項目的巔峰，但卻可更易使身段柔軟，更貼近專案成員。就算該架構師在某個技術領域耕耘多久，有多漫長的從業經驗，但需要考慮一個很重要的原則：「尊重做事的人」。為了顧及大局，一個架構師很難事必躬親，畢竟還可能要面對來自客戶的衝擊，更要協調箇中的衝突，每個人被安排任務後，必定有其價值，也會有其範疇，經過適度切割與交叉性的驗證與合作，才能逐漸在渾沌中逐漸勾勒專案的樣貌，但問題總是發生在成員間的交戶作用中，架構師必須以「鼯鼠」的姿態，事先將某個技術項目分派給成員，並且要在執行過程中，用不甚專精的技能基礎，來檢閱與分析執行效能與進展。

對我來說，自由自在般的生活，逐漸開拓自己的格局，才是我想要的，無論我今天負責的工作規模是如何成長、職稱與工作內容是怎樣被提升，讓我保有一點自身的缺陷，姑且作隻樣樣不精樣樣通的鼯鼠吧 :)
由 jserv 發表於 October 8, 2005 03:24 PM