第一部分有效開發

第二章快速軟件開發的策略

快速開發的總體策略

*避免典型錯誤

*打好開發基礎

*管理風險 避免災難

*采用面向進度的開發方式

開發速度的四維

*人員，過程，產品，技術

*人員

1.項目成員的選擇

*有才能的人 更少和更好的人

*工作匹配 使任務和人員的技能和動機相匹配

*職業的晉升 幫助人員自我實現

*團隊平衡 強調人員之間的互補和協調

*排除不稱職的人員盡快！

2.項目組結構

3.人員激勵

*過程

1.避免重復工作

2.質量保證

質量保證有兩個目的：

A.基礎的質量保證

B.在各個階段用最少的時間代價，查出錯誤

我覺得還有以下目的：

C.對真實進度進行審核。因為有時程序員的進度是有水分的，需要通過測試將水分排出，獲得真實進度情況。

3.開發基礎

4.風險管理

5.資源目標

6.生命期計劃

由于生命期計劃是基本的項目管理，因此它是非常有用的。例如，你有一個高風險的項目，基于風險的生命期模型就非常適合，如果面對一個需求含糊的項目，則增量生命期模型更有益。生命期模型可以使你更容易確定并組織軟件項目要進行的多種活動，從而更高效的工作。

7.面向客戶的開發

現代軟件的開發方式與典型的主機時代的開發方式相比，一個最為徹底的改變是更側重于關注客戶的需求和愿望。開發人員已經意識到：開發符合產品規格的軟件只是完成了一半的工作，另一半是幫助客戶配置出產品能夠實現的功能，而實現這些功能所花的時間遠遠多于紙面上確定的產品規格所需的時間。將自己站在客戶的角度考慮問題，是避免返工最好的方法，因為最終是客戶來決定你花了12個月開發出來的東西，是不是合適。

*產品

1.產品規模

產品規模是對開發進度影響最大的因素，大項目耗費的時間多，小項目耗費的時間少，是最簡單的原理，所以大幅度提高進度最直接的方式就是縮小產品規模，俗稱砍需求。或者可以分階段開發來臨時縮小規模。

2.產品特性

對性能，內存，穩定性，可靠性要求很高的產品需要更長的時間周期。選擇你的戰略目標，如果進度排在首位，就不要同時設置太多其他因素去限制開發人員的手腳。

*技術

工具，控件，技術積累都是爭取快速開發的關鍵。

開發速度的進化過程

基于承諾的快速開發

基于承諾的開發策略也是一只快速開發的方式，這種策略要求員工對項目總體進行承諾，并授予其自主權，然后看著他們每周工作60或80小時，直到最后他們完了(累垮)或者項目完了(完成)。

基于承諾的開發策略一般是通過磨練，汗水，決心來實現的。

對于公司來說，利用開發人員的承諾與責任心，用一個月的薪水壓榨兩個月的工作也是是很劃算的。

然后其帶來的弊端與風險太大：

1.無法保證項目是否完成

即使基于承諾，但也不是每個承諾都能兌現。導致完成不了的因素很多，且不可控，與承諾沒有太大關系。

2.將導致長期激勵問題

一旦員工全身心投入到承諾中，并最后面臨失敗，他們將變得沮喪，怨恨，士氣低落。

3.不可重復

4.人力資源的浪費

參與項目的人員忘記了家庭，朋友，愛好，甚至他們的健康，去促使項目成功，這種獻身不是必須的，通過周密，理性，知識化的管理和計劃，可以用少許努力獲得同樣的結果。

第三章典型錯誤

錯誤對于開發進度的影響

任何最佳實踐的使用，都只是項目成功的必要條件，而非充分條件。即使你做了一些正確的事情，只要做錯一件事，就會使你前功盡棄，而滑向失敗的深淵。

常見的典型錯誤

*人員

1挫傷積極性

2人員素質低

在很多案例中，人員的選擇都著眼于盡快招到人，而不是在項目中能工作得最好的人。這種方法能讓項目盡早的啟動，但不一定能盡早的完成。

3對有問題的員工失控

4英雄主義

5項目后期加入人員

6辦公室擁擠嘈雜

7開發人員與客戶之間的摩擦

這種沖突往往來自缺乏有效溝通，缺乏溝通還會導致對需求的準確理解，對界面的設計不合理等。雙方的摩擦和沖突會轉移客戶和開發人員雙方的注意力。

8不現實的預期

有人認為樹立現實的預期，是項目成功的前5個因素之一。(Standish Group)。這個錯誤容易發生在一線技術人員，或者一線管理人員身上。

9缺乏有效的項目支撐

快速開發有很多方面需要得到高層的支持，包括實際的計劃，變更控制等。

10缺乏各種角色的齊心協力

11缺乏客戶介入

沒有用戶的早期介入，充滿了需求誤解的風險。

12政治高于物質

13對現實充滿想象

*過程

14過于樂觀的計劃

過于樂觀的計劃給團隊施加額外的壓力，為了滿足樂觀的計劃，可能砍掉很多必要的工作，對開發人員的自信和生產率造成了長期和巨大的傷害。

15缺乏足夠的風險管理

有時我們沒有足夠的風險意識，有時我們意識到了風險卻沒有制定對應的措施。

16承包人導致失敗/客戶方導致失敗

17缺乏計劃

18在壓力下放棄計劃

項目組制定了計劃，但當項目遇到困難時就放棄計劃。那么失敗的原因不是在于放棄計劃本身，而是不能制定替代計劃，就一頭栽進編碼和麻煩中去。

19在模糊的項目前期浪費時間

模糊的前期一般是指項目開始之前的時間，通常是花在審批和預算上。通常在這個時期為后面節約出更多時間，是廉價的。

20前期活動不合要求

由于需求分析，概要設計，詳細設計等工作，并不生成代碼，對于急于砍掉不必要的活動的項目，他們很容易成為目標。

21設計低劣

22缺少質量保證措施

23缺少管理控制

項目過程中很少設置控制點，缺乏必要的計劃拖延警告。想要保證項目可控，你必須隨時準確說出項目所處的位置。

24太早或過于頻繁的集成

這點可能無法完全認同，現在也有持續集成的觀點。

25相遇估算時遺漏必要的任務

26追趕計劃

27魯莽編碼

*產品

28需求的鍍金

29功能蔓延

30開發人員的鍍金

31又推又拉的交易

經理在批準進度順眼的同時，又加入了新的功能。

32研究導向的開發

*技術

33銀彈綜合癥

過于相信沒有采用過的技術，當項目鎖定這個技術，并期望以此來解決進度問題時，不可避免的遭遇挫折。

34過高的估計了新技術新方法帶來的節省量

35項目中間切換工具

36缺乏有效的源代碼控制手段

37沒有總結出自己最差的實踐

項目不停的做，卻沒有總結出自己的錯誤列表，那么你自己無法從以往的項目中學習，也無法與其他人其他團隊交流。

第四章軟件開發的基本原則

管理原則

簡單的來說，管理原則由以下幾個部分組成：判定產品規模，根據規模分配資源，制定資源計劃，監控引導項目。

*項目估算和進度安排

1判定項目規模大小

2估算完成項目的代價

3基于估算制定計劃

*計劃編制

糟糕的計劃比其他麻煩更經常地激起問題。與計劃編制相關的問題舉例如下：

*計劃編制失敗

*沒簽訂好合同

*無效的變更控制

*不切實際的最終期限

*跟蹤

制定了一個項目計劃，就要監控他是否在按計劃進行，包括對進度，費用，質量等目標的檢查。典型的管理控制包括：任務列表，進度報告會，里程碑檢查，預算報告及走查管理。典型的技術控制包括：技術方案確認(UML，流程圖確認)，質量檢查。

跟蹤是一個基本的項目管理行為。如果你不跟蹤項目，則無法管理項目。

度量

保持長期可持續運作的關鍵，是能夠搜集基準數據來分析質量和生產率。

技術原則

*需求管理

需求管理就是收集需求，把需求記錄成文檔，電子郵件，編寫界面串聯腳本(原型)等形式，然后根據這些來跟蹤設計和編碼，并隨時管理修改需求以適應隨后項目的過程。

程序員對需求管理的抱怨太常見。

以下是一些需求管理的基礎：

*需求分析方法。包括結構分析，數據結構分析和面向對象分析。

*系統建模實踐。如類圖，數據流圖，實體關系圖，數據字典和狀態圖等。

*溝通實踐。

*需求管理和生命期模型的關系。如漸進交付，階段交付，螺旋型，瀑布型，編碼修正型等。

需求管理在兩個方面對加快開發速度發揮著重要作用。第一，正規的需求管理中，需求收集往往比較從容。第二，正確把需求擺在首位，往往比被動這樣花費少得多的時間。

*設計

*構建

*軟件配置管理

質量保證原則

*易錯模塊

20%的模塊中，集中了80%的錯誤。

*測試

單元測試10%到50%的漏洞。

系統測試20%到60%的漏洞。

剩下的40%要么通過技巧發現，要么最終被用戶發現。

*技術回顧

1走查

走查不止包括代碼部分，更加側重于需求，設計。對于我們的項目，建議每個負責人審核每個模塊的數據流圖或流程圖。

2代碼閱讀

3檢查

檢查的內容跟走查差不多，但是比走查正式得多。你可以使用它對需求分析，界面原型，設計，編碼等差錯。

檢查過程如下：

檢查會議之前，

“仲裁人”發布產品要被檢查的消息。

“審閱人”在會議之前列出檢查列表。

檢查會議開始，

“作者”解釋要被檢查的內容。

“審閱人”鑒別錯誤。

“記錄員”記錄錯誤。

檢查會議結束，

“仲裁人”寫一份檢查報告，說明每個漏洞和如果處理。

4技術回顧

按照指導來做

第五章風險管理

風險管理要素

風險管理工作就是在風險成為影響軟件項目成功的威脅前，識別，著手處理并消除風險的源頭。你可以在幾個層次中管理風險：

1危機管理：救火模式，在風險已經造成麻煩后才著手處理。

2失敗處理，察覺到了風險并迅速反應，但只是在風險發生之后。

3風險緩解，事先制定好風險發生后的措施，但不做任何預防措施。

4著力預防，將風險識別和風險防范作為項目的一部分加以規劃和執行。

5消滅根源，識別和消除可能產生的風險根源。

本章的目的是描述如果定位4和5層面上的軟件進度風險。

總體來講，風險管理由風險評估和風險控制組成。

*風險評估

風險評估由風險識別，風險分析，風險優先級組成。

*風險識別，就是提出潛在的可能破壞項目的風險列表。

*風險分析，評估每一個風險的可能性和影響，判定風險的級別。

*風險優先級，按風險影響大小排出一個風險優先級列表，這個風險列表將作為風險控制的基礎。

*風險控制

風險控制由風險管理計劃，風險化解和風險監控構成。

*風險管理計劃：制定一個應對每個重要風險的應對方案，同時確保每一個單獨的風險管理計劃之間，以及與整體風險管理計劃之間一致。

*風險化解：每個重要風險所對應的計劃的執行。

*風險監控：就是對解決風險的過程進行監控，監控還包括識別新的風險并反饋到正在進行的風險管理中。

風險識別

*最常見的進度計劃風險：

1功能蔓延

2需求鍍金，開發人員鍍金

3質量不定

4計劃過于樂觀

5設計欠佳

6銀彈綜合癥

7研發導向的開發

8人員薄弱

9簽約商失敗

10研發人員與客戶之間的摩擦

*進度計劃風險的完整列表：

1計劃編制風險

1計劃，資源和產品定義全憑客戶或上級口頭指令，并且不完全一致。對于我們的項目，這點可以理解為產品經理太軟弱，在開發過程中聽憑客戶定義產品范圍。

2計劃是優化過的，是“理想狀態”。這點對于開發人員和經驗比較少的項目經理，幾乎是通病。他們對于計劃過于樂觀。

3計劃忽略了必要的步驟。計劃時間容易被想象成實現任務，而非設計+檢查+實現+測試。

4計劃基于特定的成員。而實際上那些成員無法進入項目。

5在限定時間內無法建成一定規模的產品。俗稱無法完成的任務。

6產品規模比預估要大。或者是過程中，產品規模變得比預估要大。

7工作量大于估算。

8進度已經拖延。在計劃編制時，如果當前進度已經落后，非常容易過于樂觀的預估今后的速度。

9進度的延誤造成生產率下降。

10目標日期提前，但是沒有相應地調整產品范圍或可用資源。

11一個任務的延遲，導致相關任務的連鎖反應。

12涉足不熟悉的產品領域，花費在設計和實現的時間比預估要多。

2組織和管理

1項目缺乏一個有凝聚力的領導人。對于我們公司來說，這個風險天然存在。因為產品經理，項目負責人，商務，都無法單獨全權對項目負責。期望以后項目部在開發階段能全權對項目負責。

2由于前期乏力，項目被長時間擱置。

3解雇和削減開支，導致小組能力下降。

4僅由管理層或市場人員進行技術決策，導致計劃進度延長。

5低效的項目組織結構，導致生產率降低。前期公司測試自成一個部門，這點我認為非常不利于項目快速開發。現在產品部門也正在造成同樣的問題。

6管理層的決策時間/周期比預估要長。

7預算削減打亂項目計劃。

8管理層做出了打擊項目積極性的決定。

9非技術的第三方工作比預估要長。

10計劃性太差，無法適應期望的開發速度。這點對于現在一部非常普遍，項目計劃太差，監控太差，里程碑幾乎沒有，相應的進度預警幾乎沒有。

11項目計劃由于進度壓力而放棄。非常普遍。

12管理層強調英雄主義。

3開發環境

1設施沒有及時到位。

2設施擁擠，雜亂和破損。雜亂的辦公環境，說這個不知道算不算矯情。

3開發工具沒有及時到位。

4開發工具不如期望的那樣有效。如：需要時間熟悉新工具，新環境等。

5開發工具不是基于技術需求，不能提供計劃所要求的性能。

6新工具的學習時間比預期時間要長。

4最終用戶

1用戶堅持新需求。

2用戶對交付的產品不滿意，要求重新設計和重做。這點很大程度上，是由需求細節溝通不充分導致，其次就是用戶介入時間太晚，最后就是產品質量太差。

3用戶不買進項目相關產品，導致項目功能殘缺。比如短信接口，服務器等。

4最終用戶的意見未被采納，造成產品不得不重做。

5客戶

1客戶堅持新需求。

2客戶對規劃，原型和規格的審核/決策周期比預估要長。

3客戶沒有或者不能參與規劃，原型，和規格審核，導致需求不穩定或耗時的變更。比這更可怕的是客戶對原型審核過于草率。

4客戶答復的時間比預期要長。比如回答或者澄清需求相關問題。

5客戶堅持要做技術決策而導致進度延遲。

6客戶對開發進度管理過細，導致進展很慢。

7客戶提供的組件無法與開發的產品匹配，導致額外的設計和集成。

8客戶提供的組件質量較差，導致額外的設計工作，以及額外的客戶關系維護工作。雅漾就是這個情況，碰到這種情況，一定要通過郵件確認客戶問題，以免最后被客戶反咬。

9客戶不接受交付的軟件，盡快已經滿足了所有的規格。這種情況，一般客戶會用我方一些小錯誤作為不接受交付的理由。

10客戶期望的開發速度是開發人員無法達到的。

6承包商/客戶方

1承包商/客戶方沒有按承諾交付組件。

2承包商/客戶方提交的組件質量太差。

3承包商/客戶方沒有買進項目開發必要的工具。

7需求

1需求已經成為項目基準，但變化還在繼續。

2需求定義欠佳，而進一步定義卻會擴張項目范圍。出現這種情況，一般就是產品經理的原型不細致。所以在審核原型的時候，一定要細致。

3添加額外的需求。做好需求管理，不管新需求是小是大。

4產品定義含混的部分比預期的要大。

8產品

1錯誤發生率比較高的模塊，需要比預期更多的時間測試，設計和實現。

2矯正質量低下的產品，需要比預期更多的時間測試，修復。

3使用不熟悉的新技術。

4由于產品功能錯誤，導致需要重新設計和實現。

5開發額外不需要的功能(需求鍍金)。

9外部環境

1產品依賴政府規章。

2產品依賴正在草擬的標準。

10人員

1招聘人員所花的時間比預期要長。

2作為先決條件的任務無法完成。

3開發人員與管理層關系欠佳。

4成員沒有全身心的投入產品。

5缺乏激勵機制，士氣低下。

6缺乏必要的規范，增加了工作失誤與重復工作。

7項目結束前，人員流失。

8項目后期加入新員工。

9項目組成員無法有效的一起工作。

10項目組成員之間沖突。

11有問題的成員，沒有盡早的調理開發組，導致其他成員不滿。

12最佳人員沒有進入項目組。

13人員不足。

14任務分配不合理。

15人員工作的進展比預期要慢。

16管理人員怠工，導致計劃和進度失控。參考何飛創業期，何飛和我的怠工狀態，是項目計劃和進度失控。

17開發人員怠工，不仔細，導致工作遺漏，質量低下。

11設計和實現

1設計過于簡單，導致需要重新設計和實現。

2設計過于復雜，導致一些不必要的工作。

3設計質量底下，導致重復設計和實現。

4使用不熟悉的方法。

5產品采用太底層的語言或技術。

6一些必要的功能，無法使用現有的代碼和實現。開發人員必須要用新的庫或自行開發。盡快完善代碼庫。

7代碼和庫質量低下。

8分別開發的模塊，無法有效集成。參考后臺和移動端集成，參考移動端之間的一致性。

12過程

1大量紙面工作，拖慢了進度。

2過程跟蹤不準確。

3前期工作不真實。

4質量跟蹤不準確。

5太不正規。缺乏對軟件開發策略和標準的遵循。我們應該在這個地方。

6過于正規。教條的遵循軟件開發策略和標準。

7向管理層撰寫進程報告，占用開發人員大量時間。

8風險管理粗心，導致沒有發現重大項目風險。

9項目風險管理花費的時間，比預期時間長。

風險分析

在確定了項目存在哪些風險之后，下一步就是分析每個風險可能造成的影響。以下是一些風險分析方法。

*風險影響量

風險影響量是一種非常有用的風險分析方法，它常被寫成RE，Risk Exposure。風險的一個定義就是“不希望的損失”。風險暴露量就等于“不希望的損失”的概率乘以造成損失之后的損失程度。舉例來說就是：你認為實際進度比計劃要延長4周的概率是25%，那么風險影響量就是25% x 4周= 1周。

你可以建立一個由風險，發生概率，損失大小，影響量組成的風險評估表。

風險影響量的缺點是：主觀意見對風險結果影響比較大，因為你必須給出概率和損失大小的數值，所以不能指望它有多精確。

下面將描述怎樣預估損失大小和風險概率。

*預估損失大小

損失大小通常比風險概率更容易預估。例如：如果你的項目可能在2月1號通過，最遲應該是在3月1號，那么你的風險損失就是一個月。

如果有時損失大小不容易直接估算出來，還可以將損失拆分成更小的部分，分別評估。

*預估風險概率

風險概率的預估有很強的主觀性。以下是一些提供主觀預估精確度的方法：

1由最熟悉項目的人評估。應該是目前最適合我們的。

2 Delphi法或少數服從多數的方法。每個人獨立的對風險概率預估。然后一輪輪討論，直到達成共識。

3打賭法。比如：設備如果及時到位，你贏得125塊，如果沒有到位，你輸我100塊，逐步調整賭注，直到雙方都滿意。那么設備無法及時到位的風險就是100/125 = 44%。

4使用形容詞標準。如非常可能，很可能，可能，或許，不太可能，不可能，根本不可能等，讓成員選擇風險對應的形容詞，然后把形容詞轉化為量化的評估。

*整個項目的延期和緩沖

對風險影響量的評估，最終需要反映到整個項目預期上來。所以在進度計劃制定過程中，應該加上風險影響量的時間。

之前何飛的做法，是在進度計劃上，直接加10%到30%的時間，以應對風險，這種做法比較粗糙，建議使用風險影響量。

風險優先級

一旦建立了風險列表，下一步就是確定每個風險的優先級。

首先，按照風險影響量從大到小排序，就形成了一個粗略的優先級列表。如果能成功的處理影響量較大的主要風險，就有希望超出預期計劃完成項目了。一般情況下，你最好花時間控制影響量大的主要風險。

然后，根據實際情況，將影響量沒有在前面，但是概率或損失很大的風險提高優先級。

風險控制

確定了風險優先級列表，就可以準備對它進行控制了。本節描述風險控制的三個方面：風險管理計劃，風險化解，和風險監控。

*風險管理計劃

編制風險管理計劃的重點是制定一個計劃，以處理高優先級的風險。

風險管理計劃可以理解為一段一段的風險管理描述，例如每個風險由誰引起，表現形式是什么，可能什么時候發生，在哪發生，為什么發生以及是怎樣發生的，并描述風險監控，關閉已經化解的風險，確定緊急風險等。

*風險化解

1避免風險

不要做冒險活動。

2將風險從系統的一部分轉移到另一部分

有時系統中一個部分的風險，在另一個部分則不是風險。比如說服客戶自己設計業務模塊，而不是自己設計。

3購買關于風險的信息

4消除產生風險的根源

5接受風險

6發布風險

讓上級領導或客戶提前知道風險以及可能后果，如果發生了，他們也就沒有這么驚訝了。

7控制風險

定制風險無法化解時的處理方案。比如：分配額外的資源來測試令人擔心的模塊等。

8記住風險

以下是一些風險，已經對應的控制方法：

*風險監控

當我們定制了風險防范計劃之后，雖然風險還是存在的，并且風險在項目過程中，會增大，或減小，所以需要對風險進行監控。

1前十個風險列表

最有效的風險監控工具之一就是每周前十個風險列表。列表包括：風險當前級別，以前級別，上表次數，風險名字，風險化解進展。每周對風險列表進行更新。下面是個示意表：

對于快速開發項目，項目經理和項目經理的上司每周都應該審核前十個風險列表。它最有意義的地方是促使你定期查看風險情況。

2中間檢查

在每個小里程碑后進行一次風險檢查是非常有益的。

3風險官員

為了防止項目經理和開發人員忽視計劃中的風險，有些企業任命了全職的風險官員，專門警告項目風險。

第二部分快速開發

第六章快速開發中的核心問題

一個標準是否可以適應所有情況

你需要怎樣的開發方法

*進度計劃有嚴格限制的產品

對于確實需要全力以赴提高開發速度，而不注重成本，可預測性的產品來說，它與典型產品有著不同的時間價值曲線：

*表面上的快速開發

某些項目中，客戶，用戶，上級或者產品提出“快速開發”的需求，有時還希望低費用，低風險。他們其實也不知道這樣的要求是否過分，或者是否真的過分。

在你得到消息要在限定的時間內“快速開發”時，應該充分挖掘你所面對的真實需求。各種表面上號稱需要“快速開發”的項目，實際上是還有其他需求。

1防止失控狀態

如果一個軟件組織有失控，拖延工期，或者超出預算的歷史，如果一個客戶有被其簽約商拖延工期，超出預算的歷史，都會造成客戶要求“快速開發”。但是在這種情況下，客戶真正的需求是能在規定的進度和預算下完成。

在這種情況下，你真正需要的是較好的風險管理，預算管理和進度控制來保證項目順利進行。

2可預測性

在很多情況下，客戶需要將軟件產品與市場，發布會，公司計劃等其他項目協調在一起。這時你需要較好的風險管理。

3最低費用

對于軟件開發項目，客戶希望費用最低的情況并不罕見。在這種情況下，他們口里說著快速開發，其實是需要降低費用。

但是在實際上，最短的開發周期跟最低的費用并不是同義詞。

4渴望加班

在一些情況下，客戶或者上級利用他們對進度的關系，來掩飾他們希望開發者提供免費加班。

這種情況是很容易區分的，在這種情況下，客戶強烈關系進度，但是無法提供與之對應的費用或資源。如果客戶對項目進度的關心讓你感到壓力，那么它的重要性足以讓客戶增加對項目的支持。

*你真正需要的是全力以赴的開發

現實中的項目，客戶希望你在低費用，短時間里，提供質量最好的產品。往往你只能三選二。在短時間里，提供低質量的產品往往是最錯誤的做法。因為如果你準時發布了低質量的產品，客戶不認為你準時發布了產品，而是你發布了低質量的產品。對應到我們項目組，也就是一直存在的細節問題。認為項目很急，所以在細節問題的處理上太粗心。

按時完成的可能性

我們感覺開發速度緩慢，一部分原因是有些工作確實緩慢，另一部分原因是沒有達到預期的速度，所以顯得緩慢。對于第二種情況，我們的對策是維護兩套進度，一套用來真實的控制項目，另外一套給上海和客戶，用來降低客戶預期。

軟件項目包含太多可變因素，通常不能100%精確地設定開發進度。

上面的圖表達了幾個假定：

l完成一個項目，都有一個最快完成速度的極限值。

l完成一個項目，沒有一個最慢完成速度的極限值。

l完成幾率曲線的前一段和后一段形狀不同。

很多項目最初瞄準了不可能開發的區域，最終落在了緩慢開發的區域。

建議安排好項目進度，使按時完成的可能性達到50%是比較合理的做法。

感知與現實

即使按時完成任務，要知道開發速度慢的感覺與事實上的速度慢一樣能影響你的項目成果。即使我們一直不停的在做，也沒有理由期望客戶緘默的等待幾個月，直到項目結束。應該意識到讓客戶定期知道項目的進度情況是我們工作的一部分。

不切實際的用戶期望

如果項目進度制定在一個不可能的區域內，但在有效區域完成，人們還是認為這是一個失敗的項目。盡管它是在給定資源條件下，以有效的進度完成。

有時候，客服開發速度慢的感覺，需要確保合理的用戶期望，并提供穩定的項目進展報告。

克服慢速開發的感覺

兩種方法克服慢速開發的問題：

l將事實上的慢速開發重新定位。

將實際進度縮短，將進度移動到有效開發區域。

l將感覺上的慢速開發重新定位。

拜托癡心妄想，延長計劃進度時間，縮小計劃于實際的差距。

時間都去哪里了

*典型的觀點

許多項目開始于需求定義之前，如果這一階段沒有經過良好的定義和管理，可能會延續很長一段時間。

*軟性問題

1返工

對具有缺陷的需求，設計，代碼進行返工，普遍需要花費整體開發費用的40%。在早期對缺陷進行修正是最廉價的。因而避免返工是一個縮短項目執行時間的有利機會。

2功能蔓延

典型的項目經驗告訴我們，25%的需求會發生變化，有些時候更多。對本質的需求變化不加以限制是開發效率的首要錯誤。所以避免功能蔓延，需求鍍金對項目進度是很有好處的。

3需求定義

一般情況下，需求定義要花費項目全部時間的10%到30%。而且由于需求收集是一種無所限制的工作，也就可能會花費大量不必要的時間。在需求定義階段適當的督促，對項目進度很有幫助。在需求定義期間，包括聯合應用開發，漸進原型，階段交付和不同的風險管理方法，將在其他章節中介紹。

4模糊的項目前期

開發速度的權衡

最初的資源股價和進度往往不能被接受，這不是因為項目經理或程序設計者的工作有差錯，而是由于用戶通常希望得到的比他們提供的資源要多。如果工作不能與可行的進度和資源想適應，那么他們要么就得到的更少，要么就是導致時間和資源增加。

*進度，費用和產品的平衡

*質量的權衡

對軟件產品的質量要求分為兩種：

第一種是要求軟件有較低的缺陷率。由于低缺陷率與短的開發周期分身就是匹配的，在這種情況下沒有更好的辦法為了進度來權衡質量。

第二種是要求產品包括高質量產品應有的特性，可用性，健壯性，有效性等。對之中質量要求的關注會延長開發時間，因此也就使我們需要相對于進度去平衡這種質量要求。

*個人效率的權衡

在嘗試達到個人最大生產力和最求進度最快之間存在沖突。達到每個人最大生產力的最簡單辦法就是保持小規模團隊，而最求進度最快最簡單的方法就是擴大團隊人數。因此意味著快速開發并不總是生產力最高的。

典型的進度改進模式

如上圖，典型開發過程中，計劃雖然好看，但是很少有機會完成。從典型開發到有效開發要完成的最大部分工作是從癡心妄想轉變到有意義的項目計劃。如下圖：

如上圖，有效開發的項目中，進度的分布范圍是較狹窄的。有兩個原因：一是人們學會了怎樣實際地設置目標，二是人們學會了如何較快的開發軟件。

向快速開發前進

后續章節中將描述實現快速開發的方法：

l生命期計劃

l估算

l進度計劃

l面向客戶開發

l激勵

l團隊合作

l團隊結構

l生產力工具

l項目矯正

以上的部分內容我們在前面曾經講過，之所以我們在下面還要討論，是因為以上內容是獲得最快開發速度的關鍵方法。

第七章生命期計劃

任何軟件開發都要經歷一個“生命期”，包括從1.0版本在某個人腦中閃現到6.74b版本在最后一個用戶的機器上最后一次使用之間的所有活動。

生命期模型的主要功能是為開發活動確定一種次序，一種標準。

人們最熟悉的模型是瀑布生命期模型，但是它的弱點也同樣著名。作為一個項目骨架，你選擇的生命期模型對項目的成功和任何其他計劃一樣重要，并幫助你一步一步接近目標。如果你選擇了合適的生命期模型，就可以提高開發速度，提高質量，加強項目跟蹤控制，減少成本，降低風險或改善用戶關系。選擇了錯誤的生命期模型，也必定會導致工作拖沓，勞動重復，無謂的浪費和挫折。

純瀑布模型

1說明

盡管存在許多問題，純瀑布模型是其他模型的基礎，是一個比較有效的生命期模型。

在瀑布模型中，項目始終按照一定順序的步驟從初始概念進展到系統測試。項目確保在每個階段結束時進行檢查，判定是否可以開始下一個階段的工作。

文檔驅動。意味著主要工作成果是通過文檔傳遞。在瀑布模型中，各階段不連續也不交疊。

降低計劃管理費用。因為你可以預先完成所有計劃，文檔產生并提供了貫穿生命期過程的充分說明。

2適合情境

當你有一個穩定的產品定義和很容易被理解的技術解決方案時，瀑布模型特別合適。在這種情況下，瀑布模型可以幫助你及早發現問題，提供穩定的需求。

對于那些容易理解但很復雜的項目，采用瀑布模型很合適。

3缺點

缺乏靈活性。必須在項目開始階段就說明全部需求。

編碼修正模型

1說明

編碼修正模型是一種不太有用的模型，但是比較常見。如果你沒有明確的選擇其他生命期模型，也許你就不自覺的在用編碼修正模型。編碼修改也被稱為魯莽編碼。

當你使用編碼修正模型的時候，你是從一個大致想法開始，可能有一個正式規范，可能沒有，然后你結合設計，編碼，調式和測試方法，完成開發。如下圖：

2適合情境/優點

編碼修正模型有兩個優點：第一，不需要什么成本。你不需要在編碼工作之外付出成本，比如項目規劃，文檔編制，質量保證等。第二，只需要極少的專業知識。任何有編碼技能的人都能使用它。

對于一些非常小的，用完就丟的軟件，原型，驗證程序等，這種模型還是很合適的。

3缺點

對于其他項目來說，這種模型是非常危險的。因為它不提供項目進展，質量評估，風險識別等。

螺旋模型！

1說明

螺旋模型是一種以風險為導向的生命期模型。它把項目分解成一個個小項目，每個小項目都標識一個或多個主要風險，直到所有主要風險都被確認。“風險”的概念在這里有所外延，它可以是需求或者是框架沒有被理解清楚，潛在的性能問題，根本的技術問題，等等。

它的基本思路是，從一個小范圍的關鍵中心開始尋找風險，制定風險計劃，并交付給下一步驟。如此迭代，每次迭代都把項目擴展到更大的規模。每次迭代都包括一下六個步驟：

（1）確定目標，方案和約束條件。

（2）識別并解決風向。

（3）評價備選方案。

（4）開發本次迭代可供交付的內容，并檢查它們的正確性。

（5）規劃下一個迭代過程。

（6）交付給下一步驟，開始新的迭代過程。

2適合情境/優點

可以采用不同的方法把螺旋模型和其他生命期模型結合在一起使用。比如使用螺旋模型將項目分解，將風險降低到可以接受的水平后，再采用瀑布模型或其他模型來執行項目。

通常都是在螺旋模型中，把其他生命期模型引入作為迭代過程。

螺旋模型最重要的優勢就是，隨著成本的增加，風險程度隨之降低。時間和資金花得越多，風險越小。

螺旋模型至少提供和瀑布模型一樣多的管理控制。在每個迭代結束前都設置了檢查點。

螺旋模型能使你對任何無法逾越的風險都提前預知。

3缺點

螺旋模型唯一的缺陷就是比較復雜。需要責任心，專注和管理方面的知識。通過目標和里程碑，來決定項目是否已經準備好進行下一輪迭代。

如果項目的目標明確，風險適度，你就沒有必要采用螺旋模型。

生魚片模型

1說明

純瀑布模型最大的弱點不是這些活動本身，而是模型把活動看作是不連續的，有順序的階段來處理。因此，可以針對這個弱點，來調正模型，進化成各種修改后的瀑布模型，生魚片模型就是其中一個。

傳統瀑布模型允許在階段之間，存在最低限度的重疊。而生魚片模型建議的是一種大幅度的重疊。

2適合情境/優點

對比純瀑布模型，生魚片可以充分減少文檔需求。

如果你在一個小的，定義得很好的項目，那么這種模型可以用到最有效的模型。

3缺點

因為階段是重疊的，所以將會導致里程碑非常不明確，很難精確進行過程跟蹤。

具有子項目的瀑布模型

1.說明

純瀑布模型的另一個問題是，必須在上階段全部完成后，才進入下一個階段。但在實際工作中，系統某些部分可能比較簡單，有些地方比較復雜，而由于復雜的問題，導致簡單的部分也無法開始。因此，我們可以把系統分成幾個相對獨立的子項目，每個子項目都按自己的節奏進行，這就形成了一個具有子項目的瀑布模型。

2.適合情境/優點

這種模型比較適合于系統包含多個相對獨立的項目。

3.缺點

具有子項目的瀑布模型，主要的風險在于子項目之間的相關性無法預料。為了解決這個風險，你可以等到架構設計完成，排查相關性之后，再拆分子項目。

降低風險的瀑布模型

1.說明

純瀑布模型的另一個問題是，必須在開始架構設計之前，就完整的定義需求。這在實際工作中非常困難。所以我們可以在瀑布模型中引入螺旋模型，以便確定和降低風險。

2.適合情境/優點

降低風險的瀑布模型比較適合開發一個高風險內核的項目。不止在需求階段，在項目任何階段都能引入螺旋模型以降低風險。

3.缺點

降低風險的瀑布模型跟螺旋模型一樣，就是比較復雜。

漸進原型！

1.說明

漸進原型通常是從最顯著的方面開始，向客戶展示完成的部分，然后根據反饋信息繼續開發項目，一直重復這一過程，直到用戶認為原型已經足夠好，然后結束工作，交付作為最終產品的原型。

2.適合情境/優點

在需求變化很快的時候，用戶很難提出明確需求的時候，開發人員對于最佳架構沒有把握的時候，漸進原型都特別有用。

3.缺點

漸進原型主要的缺點是，你不可能在開始的時候知道產品總時間需要多久。

另一個缺點就是，漸進原型很容易退化成編碼修正模型。所以要注意，真正的漸進原型，包含真正的需求分析，設計和可維護的代碼。漸進原型每次重復時的實際進展是比較小的。

階段交付！

1.說明

階段交付可以持續地在確定的階段向用戶展示軟件。和漸進原型不同，在前期你就明確的知道整體分為多少階段，每個階段完成哪些內容。

2.適合情境/優點

階段交付模型，在整個周期內，持續不斷的產出階段性成果，把有用的功能交付到客戶手中。

階段交付能夠提供有形的階段進度產出。這樣的進度產出能夠使項目進度壓力更加可控。

3.缺點

階段交付的主要缺點是，如果管理層面和技術層面缺乏仔細的規劃，工作就無法進行。

使用階段交付模型需要注意的問題是：

在管理層面上，你需要確信所規劃的階段對用戶非常有意義，而且在工作安排上保證員工能及時在階段最后期限完成。

在技術層面上，你需要確信考慮了不同產品組成部分的技術依賴性。通常會犯的一個錯誤就是把一個在第二階段就需要用到的組件，放在了第四個階段才開發。

面向進度的設計

1.說明

面向進度的設計模型，類似于階段交付，相同點是都在連續的階段規劃產品。差異是面向進度設計模型，在開始的時候不必知道究竟能達到什么樣的預定目標。你可能規劃了五個階段，由于一些限制，僅僅完成了前三個階段。

2.適合情境/優點

面向進度的設計模型，能確保你在一個確定的日期發布產品。

該模型的關鍵在于按優先級區分系統特性，規劃開發階段。比如windows系統中包括了一些小程序，比如計算器，寫字板，畫筆等，可以為這些小程序采用面向進度的設計模型，來保證他們不影響windows的開發和發布。

是否使用本模型，取決于你對自己的工作規劃是否有信心。如果你非常有信息，那么面向進度的設計是個低效的模型，如果你不是那么自信，這個模型就很有用了。

3.缺點

面向進度的設計模型，最大的缺點是如果你不明白所有階段，就會浪費時間去指定，架構和設計你不需要的特性。

漸進交付！

1.說明

漸進交付是一種跨越了漸進原型和階段交付兩種模型的生命期。漸進交付跟漸進原型比較類似，區別是取決于你計劃滿足用戶需求的程度。如果你計劃滿足用戶的絕大部分需求，漸進交付就跟漸進原型差不多。如果你計劃滿足少量的需求，漸進交付就跟階段交付差不多。

漸進交付于漸進原型最大的差別不在方法上，而是工作重點上。漸進原型中，你強調系統看得見的樣子，然后回來補系統漏洞；在漸進交付中，你在乎的是系統的核心。

增量開發方法

增量開發方法包括螺旋型模型，漸進原型，階段交付，漸進交付。

面向開發工具的設計

商品軟件

當你興沖沖的準備做一個新系統時，一個常常被忽略的選擇就是可以直接購買商品軟件。

為項目選址最快的生命期模型！