我看「人月神話」一書

這本書我在今年七月左右看完。遲遲沒有上部落格發表心得的原因,除了忙與懶外,也覺得網路上已經有很多人發表了專業意見,應該沒有我這個後生小輩置喙的餘地。不過最近寫書評寫上癮了,抱著獨樂樂不如眾樂樂的心態,還是在此發表我的看法。

先說我對它的評價:五顆星中可以得到四顆星。扣一顆星的原因,是這本書乃 1975 年出版,書中內容在當年雖為振聾發嘳之作,但在現今看來,會有理所當然或早已過時之感。如果我在三十年前看到這本書,一定會給它五顆星滿分。

全書的重點大概分為下列這幾點:

   1. 在落後的專案增加人力,並非挽救時程之靈丹妙藥。
   2. 架構規劃應由少數精英為之,軟體實作才需多人並行。
   3. 垂直分工比水平分工有用。
   4. 軟體開發的瓶頸在於由「抽象概念」 --> 「實作架構」這段轉換流程。
   5. 專案成功四要素:(1) 高品質人力 (2) 正確的組織 (3) 良好的管理 (4) 優秀的環境。

在落後的專案增加人力

這個主題也是本書的重點,更是書名「人月神話」的由來。主要內容乃敘述專案管理者的一個迷思:「如果專案落後,那麼就多加一點人趕回來。」之所以無法用增加人力來趕上時程,乃因軟體開發為高度知識密集的工作。整個團隊成員會隨著專案時間的推移,慢慢共同擁有一種推動工作所需的知識。在一起工作的時間越長,這個共識就會越大。越晚進來團隊的成員,就得花越多時間汲取這個共識,趕上大家。 而原先在團隊中的某些成員,會因幫助這位新進人員,而拖慢原先的工作速度。

此外,越多人也代表需要溝通的管道越多。一個有 n 個人的團隊,每個人都需要跟其他 n-1 個人溝通。也就是所需的溝通管道有 n(n-1) 個這麼多。因此,在落後的專案中增加人力,有蠻大的可能會失敗的。

我個人倒是對此抱持一點點不同看法。雖說在知識密集的專案中加人得不到好處,但這不代表在軟體專案中,勞力密集的部份加人,是完全得不到好處的。相反地,若軟體架構都已經定好,剩下的只是找人把程式碼填上去,這部份如果增加人手,應該是可以加速整個專案進行的速度。但如果填程式碼時,仍需大量與其他人溝通,或者要填入程式碼,需要先汲取大量背景知識,那您可能就得考慮一下了。

架構規劃應由少數精英為之

作者見過一個大系統專案下來後,專案經理粗暴地切為數個模組,每個模組各交給一個團隊,去執行「設計、實作、測試」等動作,然後整合不起來的慘痛教訓。因此作者強調,「設計」或「架構規劃」這件事,必須僅由少數精英為之,免得發生最後整合不起來的狀況。作者用「先專制、後民主」來形容架構設計初期應由少數精英專制為之。等到架構固定後,怎麼去把它實作出來,則下放由程式師自由決定。這段話,我相當同意,也與我日常感受的實務經驗是相符的。

垂直分工 vs. 水平分工

執行過軟體專案管理的人應該都有這個經驗:一個專案如果要分工的話,究竟是應該依照「模組一」、「模組二」...這樣分給不同團隊,然後在每個團隊都配置程式師、測試人員呢?還是依照「專案組」、「實作組」、「測試組」...然後在專案需要實作時,整個交給實作組。需要測試時,整個交給測試組呢?前者作者命名為「水平分工」,後者則命名為「垂直分工」。

作者建議採取「垂直分工」會優於「水平分工」。如果採取「水平分工」,會破壞軟體專案的整體性,有可能導致各模組最後整合不起來的窘境。而每個小團隊內應採取「外科手術團隊」的模式。所謂外科手術團隊,就是只有一兩個人是主刀者,其他都扮演支援主刀者的角色。

以「實作組」為例。專案交到此組後,只會由一兩個人真正去實作。其他人都扮演支援實作者,讓他們速度加快的角色。如果不採取此一方式,而讓實作組內每個人都是程式設計師的話,軟體專案一來,又會落入如何切割此一專案,好讓它「平行」地被處理。然而我們都知道,軟體最好是不要切割,才容易在最後整合、並保有其完整性。

軟體開發瓶頸

整個軟體開發過程中,您知道哪一段最耗費時間嗎?先給您一點提示,絕對不是實作。之所以大家會花費大量時間在實作,那是因為我們都太早開始寫程式了。如果能將架構分析到稍微細一點,程式設計只是花時間寫就有成果的苦工而已。

答案是由「抽象概念」-->「實作架構」這段最花時間。套句軟體工程的行話,就是「Requirement」 --> 「Design」這段最花時間。舉例來說,一個 ATM 機器設計出它有「存款」、「提款」...等功能。但要設計到存款的軟體架構出來,是最花時間的。一旦架構清楚了,實作程式碼只是「花時間就有」的苦工。

專案成功四要素

首先是高品質的人力。根據研究,一位好的工程師與一般的工程師,生產力最高可達十倍以上。但每位專案經理也知道,要找能力好、配合度(我比較喜歡稱它為「溝通能力」)高的人,是非常不容易的一件事。我個人比較偏好選擇善於溝通的人。通常善於溝通的人也大多容易接受變化,吸收新知能力也不錯。所以,我會很留心那種履歷看起來不怎麼樣,但每個工作都隱藏了求職者在溝通領域上豐碩成果的人。

其次是正確的組織。一個正確的組織,可以降低溝通的複雜度。沒有一種組織可以適用於所有的專案,所以在這裡作者也沒有告訴我們一種可以照抄的「黃金組織」。您必須審慎評估每次任務著重的是什麼,來決定您的組織應該長得如何。

再來是良好的管理。所謂的管理,幾乎都跟人有關。這裡作者蠻推崇另一本書「Peopleware」。該書詳細提到軟體工程師在意的、不在意的事情有哪些。如果您不是工程師出身,建議您一定要去看看。您會驚訝的發覺,工程師在意的其實都是小事,而且還蠻容易達成的。您可能也會發覺,平常自覺做一些「有利於工程師」的事,為什麼他們都不領情。

最後是優秀的環境。很多人以為,工程師要的環境,是像 Google 總部那樣,要有喝不完的飲料、吃不完的餅乾、撞球檯...等。事實上,那些設備都是讓工程師覺得「我被重視,我不是一顆螺絲釘」而已。而讓工程師受到重視的方式很多,不一定要花大錢。只要把握「尊重」原則即可。像在大家加班時,經理人去買罐飲料請大家喝,都是讓工程師感到尊重的方法。此外,軟體工程師還需要「安靜」的環境。這裡的「安靜」,不是維持一根針掉在地上都聽得到的環境。正確一點來說,應該是「不被打擾」的環境。比如說,可以把電話鈴聲切斷,讓他們好好想程式碼或軟體架構的環境。或者是沒有愚蠢至極的「XXX 請接二線」那種廣播的環境。其實,只要你能提供工程師一個「不受打擾」的環境,剩下的部份,他們會把玩偶啦、書籍啦搬來辦公室,讓自己舒舒服服的,這點不用您操心。

本書內容概述

我覺得本書的精華在:

  • 第二章「人月神話」:敘述「在落後的專案投入人力,未必能扭轉乾坤」。
  • 第三章「外科手術團隊」:描述小團隊應只有一兩人執行「主刀者」的角色,其他人執行支援任務,可以達到最大綜效。
  • 第四章「專制、民主與系統設計」:講述了系統架構設計應由少數精英為之,以稍微專制的方式維持其一致性。之後實作時,只要程式師能達到目標,實作內容應由程式師自由地決定。
  • 第五章「第二系統效應」:談到在第一個版本成功後,要避免把第一個版本未實作的功能,一股腦塞入第二版本,導致系統規格崩潰的效應。
  • 第十六章「沒有銀彈:軟體工程的本質性與附屬性工作」:這篇是 1986 年,作者大膽預測,在未來十年內,不會有任何一種工具,可以把生產力提高十倍以上。因為軟體工程的瓶頸,就是在把「系統需求」的抽象概念,轉換成「系統設計」的實作架構。而這部份需要高度的智慧,機器是無法代勞的。
  • 第十七章「再論『沒有銀彈』」:前一篇刊出後,造成極大風波。作者在前一篇發表十年後,將他收集到的意見,重新詮釋他所謂「沒有銀彈」的真正意涵。並回頭檢視十年前他發表那一篇「沒有銀彈」,是否為正確的預測(當然是囉)。

至於其它章節,可能有些過時,或者當年說的事情,已經在今日奉為圭臬。所以參考價值不高。不過,能吸收到上面六個章節的概念,我也覺得已經值回票價了。

結論

本書雖然內容有部份已經過時,但仍有不少概念,歷經三十年,仍為業界真理。回頭看來,不得不佩服作者當年的遠見。建議所有專案經理人,都應該閱讀本書。本書前後章節雖偶有關聯,但關聯性不強。您可參照我上面提出的六個精華章節,順序閱讀完畢即可。期待同為喜好本書的讀者交流意見。

2 意見:

    太深奧了,我大概很難消化。

    哈哈,焦糖大說得是。下次我寫得平易近人一點。謝謝你來我的部落格逛逛喔~

MistyLook made by Web hosting Bluebook. Port to Blogger Template by Blogcrowds