前序
這本軟件工程管理指南針對我們軟件從業(yè)人員常見的場景，進(jìn)行了科學(xué)地分析，詳細(xì)地講解了在軟件管理過程中遇到問題的原因是什么，我們該如何解決，讀之后有種豁然開朗，仿佛撥開工作上軟件管理的重重迷霧的感覺。本節(jié)主要介紹下作者是怎么看待項目管理中進(jìn)度安排的，是否越多人參與項目，項目就能越快完成交付呢？
第1章
? ? ? ? 在講進(jìn)度安排前，先介紹下背景。本章用焦油坑舉例，輔之以數(shù)據(jù)，講述了現(xiàn)在的軟件系統(tǒng)，正如一只只猛獸，掉進(jìn)了一個焦油坑里，無法掙脫，越陷越深，直至被焦油吞沒。（這個場景也很像沼澤地，陷進(jìn)去很難出來。）在著名的la brea焦油坑，發(fā)現(xiàn)了恐龍，猛犸象，獅子等巨獸化石，難以想象這樣的龐然大物在焦油坑里掙扎是怎樣的一種震撼場面。聯(lián)想到我們的軟件開發(fā)，人們投入了大量的金錢和時間研發(fā)出一個個系統(tǒng)，然而這些系統(tǒng)大都達(dá)不到目標(biāo)、進(jìn)度、預(yù)算被丟進(jìn)了焦油坑里。你有沒有在公司里遇到這種情況呢，辛辛苦苦開發(fā)出來的系統(tǒng)，或夭折或開發(fā)出來后越來越少人使用，甚至被淘汰了。那我們要怎么解決這個終極難題呢？接下來的章節(jié)將系統(tǒng)地去講解。
第2章
? ? ? ? 回歸正題，俗話說，工欲善其事，必先利其器。我們要幫助正在焦油坑里的軟件系統(tǒng)爬出來或者是提前避免掉進(jìn)這個坑，那我們需要去找方法。這里可以用逆推，把前者失敗的因素歸納總結(jié)起來，就是我們的規(guī)避方法。也就是前車之覆，后車可鑒。
總結(jié)前人的經(jīng)驗，掉進(jìn)坑的原因主要有以下：
1.程序員的樂觀主義。缺少對技術(shù)估算的方法，對編程時間錯誤評估，例如其中的技術(shù)難點，bug排查沒有一個客觀估算，導(dǎo)致評估出來的時間是樂觀的。
2.簡單地使用工作量單位“人月”（比如2個月5個人完成一個系統(tǒng)）去預(yù)估進(jìn)度和排期。用人月作為衡量一項工作的規(guī)模是一個危險和帶有欺騙性的神話。暗示著我們?nèi)撕驮率强梢曰ハ嗵鎿Q的。但人數(shù)和時間的替換僅適用于像割小麥，收棉花這種工作上。
但在編程上是不可能的。
第一種，具有次序性，任務(wù)完全不能分解。
第二種，任務(wù)可以分解，但需要溝通和交流，調(diào)整人手后情況會比第一種好一些。
第三種，任務(wù)錯綜復(fù)雜，彼此都需要互相交流的情況。工作量將激增，假設(shè)每個任務(wù)都需要和其他任務(wù)協(xié)作完成，工作量按照n(n-1)/2遞增。這個公式應(yīng)該是推演總結(jié)出來的。比如一對一交流，3個人的工作量是2個人的3倍，4個人就是2個人的6倍。于是就會到變成以下：
從而增加人手，反而延長了時間進(jìn)度。
3.系統(tǒng)測試，提倡允許充分的系統(tǒng)測試時間。
4.但可能又會延伸出另一個問題，怎么樣才算充分，一年也是充分嗎？這時就暴露另外一個問題，空泛的估算。我們經(jīng)常是像廚師一樣，計劃進(jìn)度收顧客的緊迫程度影響，要求急，工期短。不急，工期長。這種不合理的進(jìn)度安排問題，在軟件領(lǐng)域比其他工程領(lǐng)域普遍得多。這樣很難生產(chǎn)出可靠的估計。
兩種解決方案：（1）開發(fā)并推行生產(chǎn)率圖表，缺陷率圖表、估算規(guī)則。實際上現(xiàn)在很多公司都是采用估算規(guī)則，例如現(xiàn)在某類需求，告知需求方，一個需求至少n小時才能完成，一般是下需求后的第二天提供。又或者是制定每類需求的工時，以此用作后續(xù)同類需求的評估規(guī)則：
（2）在第（1）出來之前，項目經(jīng)理根據(jù)經(jīng)驗和直覺去把控，會比讓編程人員自己根據(jù)需求方期望而評估出來的時間要可靠。
5.進(jìn)度把控問題，重復(fù)產(chǎn)生的進(jìn)度災(zāi)難
當(dāng)項目軟件落后于進(jìn)度時，通常做法是增派人手，有所幫助，但可能無法解決問題。
一個預(yù)估需要12個人月的任務(wù)，安排3名人員4個月內(nèi)完成。每個月月尾設(shè)置可測量里程碑ABCD。
假設(shè)項目進(jìn)度落后了，2個月后A沒有完成。項目經(jīng)理有哪些方案可以選擇？
（1）假定項目一定要按時完成進(jìn)度，不然出大問題。假設(shè)僅僅是第一部分估計不得當(dāng)，那剩9個人月工作量，剩下2個月，要按時完成的話，需要4.5個人手，也就是在原來基礎(chǔ)上增加2人。
（2）假定項目一定要按時完成進(jìn)度，不然出大問題。整體都估計不得當(dāng)，還剩18個人月，需要2個月，9個人才能按時完成，比原來3人多了6人。
（3）重新安排進(jìn)度
（4）削減任務(wù)
前兩種情況，堅持把不經(jīng)調(diào)整的任務(wù)在4個月內(nèi)完成是災(zāi)難性的。第一種，假設(shè)增加1個人手需要培訓(xùn)1個月，新增2個人，那么3個人月需要投入到項目以外的工作中，此外，任務(wù)劃分成5部分。還剩7個人月工作量，此時只有5個人月，還是會延期。
如果加4人呢，就沒問題了吧？培訓(xùn)需要5個人月，還剩7個人月，那剛好7人。
但如果考慮任務(wù)劃分和系統(tǒng)測試的工作量，隊伍將達(dá)到7人以上，任務(wù)劃分、溝通問題等等會更加棘手，造成項目最終還是一團(tuán)槽的進(jìn)度不可控場面。這里簡單跟作者一樣，冒昧地簡化一下Brooks法則：
向進(jìn)度落后的項目中增加人手，只會使進(jìn)度更加落后。
我們以前可能一直以為，人多好辦事。能向上級申請或能調(diào)動越多的人力資源就越好保證項目進(jìn)度。當(dāng)我們看完這一章節(jié)，我們終于見到了褪去了神話色彩的人月真實情況是怎樣的。項目的時間依賴于順序上的限制，人員的最大數(shù)量依賴于獨立子任務(wù)的數(shù)量。安排人員較少，花費的時間較長（風(fēng)險是產(chǎn)品可能會過時）。相反，分派較多的人手，計劃較短的時間，無法得到可行的進(jìn)度安排。
總之，在軟件管理中，缺乏合理的進(jìn)度安排是造成項目滯后的最主要原因，是比其他所有因素加起來的影響還要大。所以在進(jìn)度出現(xiàn)問題的時候，不能一味地增加人手，應(yīng)視上述情況而定，必要時或最糟糕時，砍掉部分非核心部分功能，也是一種把控項目的方法。
