#18：在壓力中放棄計劃

當項目進 度遇到麻煩，開發(fā)者會放棄原先制定好的計劃（Humphrey 1989）。問題的嚴重性并不在于放棄了計劃，而在于沒有建立一個備用方案，從而陷入編寫-修復的循環(huán)中。在案例分析3-1中，團隊因為按時進行第一次發(fā) 布（這很正常），因而放棄了他恩的計劃。結果是，這一時間點之后的工作都是無計劃的，甚至Jill開始用一部分時間來為她以前的隊員工作，且沒有一個人知道。

#19：在“模糊的前端”中浪費時間

“模糊的前端”指的是在項目開始之間所進行的驗證和預算階段。不少項目會花上幾個月甚至幾年的時間來進行這項工作，然后制定出一個非常緊迫的項目進度。從“模糊的前端”中節(jié)約幾個星期或幾個月的時間要比在經(jīng)過壓縮后的項目進度中節(jié)約時間容易、便宜和有保障得多。

#20：不充足的前期工作

比較緊急的計劃會嘗試著縮減一些不必要的工作，所以諸如需求分析、建構和設計等不能產(chǎn)生代碼的工作成為了縮減的首要目標。有一次我接手了一個非常糟糕的項目，我說我想看一下項目的設計圖，團隊領導卻說他們沒有時間做出設計圖。

這個錯誤還被稱為“直接跳進編碼階段”，其結果是可以料想到的。在案例分析中，條狀設計圖被質量設計工作所代替。在產(chǎn)品可以被發(fā)布之前，設計圖的工作只能被否決，更高的質量工作必須要立刻完成。縮減了前期工作的項目肯定要在后期工作中彌補這些工作，而花費的精力卻是10倍甚至100倍的（Fagan 1976; Boehm and Papaccio 1988）。如果你沒有額外的5個小時去把第一項工作做好，難道你能找到額外的50個小時去做接下來的工作嗎？

#21：不充足的設計

在不充足的前期工作中，不充足的設計是一個特例。緊急的項目會使用來進行項目是設計的時間減少，同時高壓的環(huán)境會讓提出替代方案變得非常困難。項目設計的目的在于權宜而不是質量，所以在項目完成之前你需要一些非常耗時的項目設計周期。

#22：不充足的質量保證

一個緊急的項目會 通過減少設計和編碼的檢查、減少測試計劃并只進行簡單地測試。在案例分析中，設計回顧和編碼回顧都只花了很少的時間以完成項目進度。而結果是，當項目進行 到關鍵的地方，仍有過多的程序錯誤導致推遲5個多月發(fā)布。這種后果是很典型的。在質量保證過程中減少了的工作，會在后期增加3到10天的工作量 （Jones 1994）。這會降低項目開發(fā)的速度。

#23：不充足的管理控制

在案例分析中，有一些管理控制措施會用來對即將發(fā)生的工作失誤進行警告。但是，當項目出現(xiàn)了問題，這些管理控制被放棄了。如果你想讓項目一直保持在軌道上，那你必須知道項目是否在軌道上，即有一個評定的標準。

#24：過早的或過于頻繁的整合

在產(chǎn)品即將發(fā)布之前，應該做一些準備，如提高產(chǎn)品的星等、打印終使用文檔、組織終的幫助系統(tǒng)掛鉤、修飾一下安裝程序、找出不能完成任務的組件等。在緊急的項目中，人們喜歡把項目過早地整合起來。由于在完成之間不能進行組合，于是有人在工作過程中對項目進行許多次的整合，直到成功。這些額外的整合并沒有使項目受益，而只是浪費時間和拖延進度罷了。

#25：忽略了某些任務

如果人們不對已經(jīng)完成的項目作仔細的記錄，而忘記了其中某些不顯眼的任務，那這些任務會越積越多。這些被忽略的工作會累計到整個進度的20%到30%。

#26：計劃以后再抓緊

如果你要完成一個6個月的項目，而用了3個月的時間完成了2個月的工作，你會怎么做？許多開發(fā)人員會說他們計劃以后再抓緊，但是他們從來沒有這樣做過。你在建立項目的時候你會知道得越多，其中包括還需要多少時間去完成它。所以這些信息也需要反映在項目日程中。

另一種錯誤來自于項目的變更。如果你的項目變了，那你需要完成該項目的時間也會發(fā)生變化。在案例分析3-1中，項目的主要需求改變了，而項目開發(fā)團隊卻沒有制定相應的措施來對進度表作出調整。面對日益增多的新要求，而不在項目進度中反映出來，一定會導致不能按期交貨。

#27：糟糕的編碼

有些組織認為快速、隨意的編碼是同樣快速開發(fā)的捷徑。他們爭辯道，如果開發(fā)者被充分地激勵了，他們能克服萬難。這遠遠不是實施，本書的其他章節(jié)會闡述其中原因。“企業(yè)家模式”通常是守舊的“編碼-修復”模式的幌子，而且這種模式幾乎不管用。這也是“錯加錯不等于對”的一個例子。

產(chǎn)品

以下列舉一些在定義產(chǎn)品的時候所容易犯的錯誤。

#28：過高的需求

有些項目從一開始被提出了過高的需求。項目需求的提出往往會超過實際的需求，這無疑會增長項目的進度。用戶對市場和開發(fā)速度的需求要比那些復雜的特性來得高，而且復雜的特性會大大改變項目的開發(fā)進度。

#29：過低的需求

即使你成功避免了過高的需求，平均每個項目都會在其生命周期中發(fā)生25%的改變（Jones 1994）。某一個改變至少會增長25%的開發(fā)進程，這對快速開發(fā)來說是致命的。