微軟項目求生法則 內容簡介
本書是特為每個關注項目開發成敗的人，特別是那些沒有經過正式軟體項目管理訓練的人而寫的一本書。作者利用在研究與工作中獲得的經驗告訴您項目開發過程中的規劃、設計、管理、質量控制、測試與完工所需的策略與觀念，並利用大量技巧建立一套精簡可靠的框架來成功地管理項目。不論是新手還是老練的項目管理者都將從中獲益匪淺。本書將是每個項目人員案頭不可或缺的指導書。本書作者曾著有兩本頗受好評的微軟經典著作，通過他的親身經歷，現身說法，使您獲得"原沐原味"的微軟經驗與法則，助您攀著巨人肩膀步入巨人行列！
相關圖書：《微軟團隊成功秘訣》 、《微軟研發致勝策略》
微軟項目求生法則 本書前言
前 言
現在美國差不多有兩千萬人在開發約三十萬件軟體項目。三分之一到二分之一的基礎上會在完成前超出時間表與預算目標；在預算花費最多的軟體項目中，約半數最後會因為失去控制而取消，有更多項目胎死腹中，被完全擱置，或者這些項目的主持人會宣稱目標達成了，可是這些項目結束時沒有完成新軟體，說明他們碰到了麻煩。本書說明如何避免你的基礎上陷入上述困境中，無論你是名資深主管、執行經理、軟體客戶、使用者代表，還是項目主持人，你都能從本書中獲益。
軟體項目失敗的原因有兩種因素：負責項目的團隊缺乏成功進行項目的知識，或者項目團隊缺乏有效進行項目所需的決心，本書對缺乏決心的問題幫不上什麼忙，不過卻包含許多成功推行一個軟體項目所需的知識。
軟體項目成功的因素不全是技術上的，有時軟體項目生存或失敗被當成完全倚賴軟體開發者成功施展神奇技術咒文與否的神秘存在。當軟體開發人員被問及為何一個組件慢了兩個星期才推出，他們會說："我得在我們的OCX接口上寫個32-bit thunking layer"面對諸如此類的解釋，也難怪缺乏完整專門技術背景的人們會對如何影響一個軟體項目的成敗感到無能為力了。
本書的要旨是闡明軟體項目的成敗並不在如thunkinglayer那樣完全技術層面的考慮上，而是在更凡俗的問題上，軟體項目的成敗取決於項目本身是否被小心規劃、謹慎執行。絕大部分軟體項目都可以以一種幾乎保證成功的決定性方式進行。如果一個項目的資金投入者了解決定項目成敗的主要軲紗，他們就能確定項目成功完成。帶領項目朝著正確方向前進的人可以是名技術主管或個別的軟體開發者，也可以是名上層主管、客戶、投資者、使用者代表，或任何其他關注項目的團體。
誰該看這本書
這本書是為所有關注軟體項目成敗的人所寫的。
上層主管、客戶、投資者、使用者代表
非軟體開發人員常擔負起管理軟體產品開發的責任。這些人中，有些有行銷、管理、金融、法律或其他方面的背景，有些則可能對項目沒有任何直接的正面影響力，不過他們還是對項目順利進行負有連帶責任，至少這些人期望在項目開始出錯時聽到警訊。
如果你處於這類人中，本書提供給你一個簡短易讀的說明，告訴你一件成功的基礎上的概貌。它會更進一步給你許多方法來分辨項目是朝向成功還是失敗的方向進行著。它也告訴你怎樣分辨哪時沒訊息算好事，哪時好訊息其實不好，或是哪時好訊息真正代表好訊息。
項目主管
許多軟體項目主管沒經過任何管理軟體項目的訓練就被推上管理職位。如果你是這樣的人，本書會幫你熟悉需求管理，軟體項目規劃、項目進行、質量保證和變化控制的關鍵技術管理技巧。
技術主持人、專業開發人員與黑客
如果你是名技術方面的專家，你可能會不太了解項目主持人需關切的項目輪廓為何，在這方面，你可以將本書當成加注過的基礎上規劃。通過提供一個成功軟體項目的概覽，本書將幫助你從專業技術人員轉型成高效的基礎上主持人，你可以將本書中描述的規劃方式當成一個可以依照你的特定項目量身修訂的規划起點。
本書適用的項目上類型
本書中所述的規劃方式適用於商用系統，廣泛的軟體銷售、垂直市場系統、科學套用系統及類似的程式，它是為利用如對象導向設計與程式寫作方式等現代化開發方式的桌面型client/server項目所設計的，不過也可以方便地用在以傳統開發方式和大型主機進行的基礎上上。這個規劃方式是為預期在3-18個月以3-25人的團隊規模完成的基礎上所設計的。這樣的基礎上可說是箇中型項目。如果你的基礎上更小些，你可以自行斟酌本書中建議的做法(我在本書從頭到尾都會指出哪些做法是你能斟酌選用的)
本書主要是為那些正在規劃階段的基礎上所寫。如果你才剛開始執行項目，你可以將本書的做法作為項目規劃的基礎，如果項目已經進行到一半了，第二章中的求生測試和每一章末尾的求生檢查會幫你找出項目的成功率。
這本書的規劃本身對應付生命與案例要求苛刻的系統還不夠正式或嚴格，它適用於商業套用與事務軟體的開發上，而且顯著改善了許多目前已經使用的並且以百萬美元為成本單位的基礎上計畫。
給進階技術讀者的說明
本書描述一種有效進行軟體項目管理的方法，這方法不是惟一的，而且對任何一個特定項目都可能不是最好的。有獨特見解的技術主持人通常能夠想出比本書所提到的通用規劃方式更好。更完善、更獨到的開發計畫。不過本書中提到的規劃方式總比臨時救急或是完全毫無頭緒的做法要強多了。尤其當"完全零規劃"是最常見的情形時。
本書中所述的規劃方式用來針對軟體項目中最常面對的那些弱點，大致依據軟體工程協會在SEI能力成熟模型第二級中指出的"關鍵程式"而來，SEI將這些關鍵程式當成讓組織符合時間表、預算、質量與其他目標的關鍵要素。所有組織有約85%的表現都在第二級之下，這份規劃方式會大大改善這些組織的表現。
軟體工程協會將第二級的關鍵過程定義如下：
需求管理
項目執行與監督
結構管理
質量確認
分層管理
本書主要是針對分層管理以外的其他項目。
……
微軟項目求生法則 本書目錄
第一篇 求生心態
第1章 歡迎來到軟體項目求生訓練中心
求生需求
求生權利
求生檢查
第2章 軟體項目求生測驗
求生測驗
求生測驗的評分
求生測驗的說明
第3章 求生概念
"開發程式"的威力
上下游
第4章 求生技能
規劃
軟體規劃的例子
規劃審查
風險管理
項目控制
項目洞悉力
人因工程
使用者參與度
產品簡化主義
焦點放在推出軟體
第5章 看看成功的項目
思考階段
項目流程
規劃階段
匯聚人力
程式代碼增長曲線
主要完成點與推行點
第二篇 求生準備
第6章 命中移動目標
變動管理程式
變動管制益處
一般變動管制問題
交付變動管制
第7章 初步規劃
項目目標前景
主持推動權
項目規模目標
公開規劃與進度
風險管理
細節風險管理規劃
匿名風險反饋通道
人事策略
時間管理
軟體開發規劃
第8章 需求開發
需求開發概覽
需求開發程式細節
第9章 質量保證
質量為何重要
品管規劃
缺陷追蹤
技術檢查
系統測試
Beta版公開測試
品管規劃涵蓋的工作成果
支持活動
第10章 構架
緩緩進入構架階段
良好的構架的特色
如何分辨構架完成與否
軟體構架檔案
第11章 最後準備
項目預估
階段性完成規劃
持續規劃工作
第三篇 逐步邁向成功
第12章 階段的初步規劃
為何要進行階段規劃
階段性規劃概要
階段里程碑
階段規劃與管理風格
第13章 細節設計
重新檢查構架
一個項目需要多少細節設計工作
技術檢查
細節設計檔案
第一個階段的特別考慮
第14章 構建過程
源代碼質量
軟體整合程式
每日整建與冒煙測試
進度追蹤
每周更新項目進度追蹤
控制變動
保持焦點
這就是構建過程中所有要做的事情
第15章 系統測試
測試哲學
測試小組對每日整建的幫助
第16章 軟體開發
嚴肅看待發行工作
何時發行
發行檢查清單
發行認可檔案
第17章 階段完成記錄
總結更動會議
估計修正
對項目規劃的評估表現
項目檔案保存
更新項目記錄
第四篇 完成任務
第18章 項目歷程
匯集項目資料
軟體項目歷程檔案
準備未來項目使用的項目歷程結果
散發軟體項目歷程的複製檔案
第19章 求生小技
NASA的成功檢查清單
其他求生資源
參考書
網路資源
尾聲
微軟項目求生法則 文章節選
你可能很難相信，一般人對軟體產品的要求要比軟體項目嚴格多了。使用軟體的人希望軟體產品可以連續使用好幾個鐘頭，可以連續執行好幾百萬個程式命令而歷我彌新。可是軟體開發者對軟體項目反面不抱太大期望。使用者與客戶也許會抱怨項目慢了一個月、三個月甚至半年才推出，也許抱怨程式不好用或缺乏幾項重要功能。可是如果軟體產品計畫中的主體如期推出，即使不惜血本，大部分消費者還是會認為開發產品的項目成功了。我們看過太多失敗的例子，所以我們認為只有完全像是扶不起的阿斗的項目才算是失敗的。多年來，軟體工業的高層人士對軟體項目的要求總是愛之深。責之切。一個成功的項目應該儘可能滿足成本與時間的需求，以追求高質量的產品為目標，不要瞻前顧後。確定了這點，就現階段的技術還可以控制在百分之十上下的水準。一般的軟體項目主管都可以做得到，即使是項目外的其他人，如高階主管、經理、客戶、投資人和使用者代表一樣可以發揮相同的影響力。
一名Construx software Builders的首席軟體工程師請我去看他們一些失敗的案例。在專家眼裡，失敗的原因通常很明顯。中型軟體項目的失敗(20000-250000行原始碼)其實很容易避免。此外我發現軟體項目不是不能達到最短時程、最低成本。最佳質量或任何其他目標擇一力臻完美。
並非以上所有目標都能同時完成，本書想要告訴大家的是力求在眾多目標之間取得平衡，讓一個低成本而高質量的產品能如期推出。
求生需求
軟體項目求生第一步就是確認生存的基本需要。Abraham maslow觀察出人類的需求依照程度由低到高，以自然階層的形態呈現，最低程度的需求稱作"生理需求"。這是人類生存所必需的最低要求。在我們滿足上層的需求前，必須先滿足圖中的虛線以下部分的軟低程度需求。所以要先滿足對食物、空氣、水的生理需求之後，我們才能夠追求"歸屬感"與愛自尊與自我實現的滿足。
如同許多軟體專家一樣，我發現類似的需求階層也可以套用在軟體項目上，軟體項目有一組斟酌需求必須先被滿足，逐步攀爬到需求金字塔的上層，就可以大幅改善項目的質量與生產力。
項目團隊必須滿足"一定會完成項目"的最低層次需求，接著再來考慮有關時間和預算目標百分之十上下的問題，而且項目小組必須在有限的預算和時間之內，以現有的技術水準，努力推出預定計畫中的最佳軟體。
軟體項目的需求階層與製作項目的個人需求大相逕庭，舉例來說，開發人員會將他們的個人自尊擺在健全的團隊動力之前，但就項目而言，健全的團隊動力要比開發人員個人自尊更重要。
本書針對軟體項目需求中下階層的部分討論，只要當上層需求的方向影響下層需求的滿足時，才會提到上一階層的部分。
求生權利
處境艱難的項目威脅到各相關人士的生存需求，客戶擔心項目到底不能推出，結果會不會太慢或太貴。主管擔心客戶會不會取消項目導致失敗，或者開發人員能不能夠完成，開發人員擔心他(她)會不會丟掉飯碗，或是被迫犧牲數百上時的休閒時間表示他(她)真的全心投入工作了。每一種情形，每個人都退回到項目需求階層的最底層部分----擔憂是否滿足他們個人承諾的安全需求，這樣的反應反而讓他們放棄追求金字截上層可達成最高質量與生產力的東西。
……
