1、敏捷開發方法流行于那些發現傳統瀑布法無法適應這個由改新而驅動的世界的要求的 在一個企業向敏捷方式的改變既帶來機會也帶來風險，本書將探究敏捷方法為開發機 構及其力帶來的機會和回報，也將探究其潛在的風險問題。投資組合管理感的閱讀。摘要：敏捷項目管理在一個企業向敏捷方式的改變既帶來機會也帶來風險，本書將探究敏捷方法為開發機構及其力帶來的機會和回報，也將探究其潛在的風險問題。 ：敏捷開發敏捷項目管理如果你學過經濟，就肯定了解制定戰術計劃和制定計劃之間的區別。在 20 世紀 80 年代，行動的戰術窗口只是 35 年的計劃，而計劃則超過 5 年，最多可達 10 年。在 20 世紀 90 年代，也就是信息時

2、代起飛之后，的速率及其附加作用極大地減少了計劃窗口的大小，而開發周期也減少了。到現在，我不認為還有以 20 世紀 80 年代的周期作計劃的 機構存在，尤其是在這一部分。實際上，我聽到經理們講這么一個笑話：“戰術是 今天所要做的，是為明天做計劃?！比缤S多笑話一樣，笑話之中有真理。的速率影響著來開發系統的方式，尤其是那些較大的系統。項目的時間表越 長，項目范圍成為的一部分的幾率就越高。從過去許多經驗中得知，一個花費了兩 年時間進行的項目的結果不一定會和對它的期待一致。傳統項目的計劃精確度非常粗糙，因為即使是最長的性項目也會有一個戰術上的組件：即將進行的迭代。而正是這個組件 會和風險均有不少。本書

3、將探究敏捷方法為開發機構及其力帶來的機會，也將探究潛在 我編寫本書的之一是想把職業生涯內在項目團隊內外所觀察到的信息與大家分 在長期以傳統方式管理的項目過程中，許多項目狀態（尤其是在項目早期階段）過 于樂觀。首先，要讓業務分析師或工程師知道他們的進度于時間表是一件極為量，如何知道現在的工作正按部就班呢？而后在項目進行時，如果項目由于有新的發現 其次，長久以來，受到這樣的教導：項目經理是。他管理團隊，指派任 務并且承擔整體項目成功的責任。所有這些壓力以及所有這些期望都指向同一個人，這個人也負責項目的溝通交流工作。有了這樣的場景，怎么可能期望項目溝通交流是中立的？而延期，但執行分析的人早已離開，他

4、們已經轉移到新的項目上了。的事情。在分析之前或在分析過程中，想知道總共有多少分析量是不可能的。如果不知道總享。這些觀察的結果有許多都能追溯到同一個根本原因：在機構內，我所目睹到的各個方面都缺乏信任。的風險問題。將使得執行官、項目經理以及項目團隊得以掌好項目的舵，帶領項目駛向并不精確的愿景。想轉變為敏捷方法并不是一件容易的事情。改變帶來機會，也總需承擔風險，敏捷開發的機這是造成這種問題的原因之一。為了解決這個問題，許多機構采用或試用敏捷開發方法這是一種基于迭代-增量開發的方法，它將項目的范圍分解為更小的、可管理的塊。從管理的角度看，這是一種理想方法，前言本節為前言部分。敏捷項目管理 前言本書適合

5、項目經理、投資組合經理、業務分析師、PMO 成員以及執行經理等對采納敏捷實踐和企業。既然敏捷開發過程帶來更好的結果，那么也能將這個方法應用于整個 IT 投資組合中。敏捷項目管理譯高級執行官如果要求每周多給出一份詳細的狀態，那么這不就已經是一種不信任的底層形式了嗎？在職業生涯里，我不斷看到這些機能失調和不信任的癥狀。敏捷投資組合管理并不排除交流方式，但它確保溝通進行在執行中的項目所產生的現有敏捷指標的基礎。敏捷投資組合管理在項目團隊和執行官之間建立了一個清晰定義的接口，而其建立在敏捷實踐的基礎上。這些實踐建立在信任之上，并且會對任何朝向組織上的敏捷所作的轉變帶來正面的影響。我將本書稱為敏捷項目管

6、理，因為這正是機構中活動項目的投資組合，這些項目代表了企業的未來，無論是戰術上的還是上的，也無論讀者對這些術語的定義是什么?！懊艚荨边@個術語所強調的不僅是投資組合中的項目是敏捷項目，也強調投資組合是構建在敏捷實踐之上，而且是動態管理的。本書展示了現代敏捷企業的透明性，它清晰地定義了交流通道，所以，本書既面向項目經理也面向執行官。本書分為以下三個部分：第一部分：敏捷與管理。這個介紹性的部分是為想要了解敏捷開發在過去的幾年中變得如此流行的原因的管理用的最重要的敏捷實踐。準備的。它講解了在敏捷開發和敏捷項目管理中常第二部分：定義、計劃并衡量投資組合。第二部分是本書最大的一部分。它講解了與敏捷投資組合

7、管理有關的實踐。本部分所包括的實踐有編寫指標，建立項目選擇過程，評估資源以及計算投資回報。這些章介紹現代投資組合管理的實踐。第三部分：機構和環境。本書的最后一部分為如何把最流行的敏捷開發過敏捷投資組合管理編排在一起提供一些實際操作建議。它介紹了以 Scrum 方式管理項目適應投資組合管理過程的方式。另外，本部分也講解了在敏捷機構中項目管理本書讀者對象（PMO）的新角色。本書主要面向項目經理、投資組合經理、業務分析師、PMO 成員以及執行經理等對采納敏捷實踐和投資組合管理感的人。我希望本書能夠為讀者確切地給出容易消化本的介紹內容，而且有足夠的材料在整個企業中開展敏捷方法。雖然技術讀者不是本書的主

8、要對象，但本書可以幫助他們理會機構內不同層次的的，而且更好地理解項目的外部如何影響他們在企業中的工作。除了能夠為讀者中的專業帶來效益外，我希望本書也能夠幫助正在攻讀工商管理學位的學生理解在業內敏捷開發的重要性和影響。是明天的項目經理。尋找內容如果本書有新的補充材料或者更新材料出現，貼在Press OnlineDeveloper Tools Web 站點上。讀者可找到的材料包括本書內容、文章、勘誤表、樣章等的更新。這個站點很快就可以通過 HYPERLINK http:/learning/books/online/developer http:/learning/books/online/deve

9、loper 來對本書的支持，而且會定期更新。盡力確保本書以及本書的配套內容準確無誤。Knowledge Base 文章中。修正或者變更，它們將出現在Press 在以下 Web 站點提供對本書以及本書配套內容的支持： HYPERLINK http:/learning/support/books/ http:/learning/support/books/問題和評論與本書或者配套內容有關的任何評論、問題或想法，或者無法通過問題，請通過電子郵件將它們發送到：msi或者通過郵寄信件到：上述站點解決的One Way請注意， 不通過上述地址提供產品支持。之寶。他們是：Denise Cook、Marie K

10、alliney 和 Roman Pichler。Roger lanc 擔任本書 要完成一個這樣的項目，僅僅知道其方式是不夠的。家人和朋友給了我所需的信心 和支持 母親 Ute 和父親 Frieder 姐姐 Iris，以及 Rainer L 歸、Markus L 歸、Torben摘要：敏捷項目管理在一個企業向敏捷方式的改變既帶來機會也帶來風險，本書將探究敏捷方法為開發機構及其力帶來的機會和回報，也將探究其潛在的風險問題。 ：敏捷開發敏捷項目管理第 1 章.21.1.1 的變更31.1.6 變更控制.71.4 供給11第 2 章敏捷開發142.1 定義142.1.1 敏捷是什么141.5 小結13

11、1.2 上市時間81.3 革新10需求癱瘓4二義性5需求太多5需求太少61.1 管理的期望2目錄 譯者序前言致謝作者簡介第一部分敏捷與管理本節為目錄部分。L 歸、Reinhold 和 Sieglinde Oppenl 妌 der、Noreen 和 Charles Bramman、Rita O 誈 ray、 Christopher Bramman、Gregory Bramman、Lauren 和 Richard French。還要特別感謝 Gerhard Mauz、Markus Knierim 和 Marcus Zimmermann，這些朋友們讓我一直關注于生命中最重要的東西。敏捷項目管理 目錄

12、編輯，在我認為已經完成的情況下仍舊不停工作，為本書進行了多次重審，直到成書。Steve Sagman 和 Lynn Finnel 編輯并協調了本項目，他們源源不斷的好主意給本書帶來了許多改進。如果沒有他們的評論和熱情，本書就不可能成形。感謝他們！致謝感謝以下各位，他們在本項目的不同階段為我提供的反饋和深度評述實乃無價 Redmond, WA 98052-6399PressAttn: Agile Portfolio Management Editor..5敏捷過程14敏捷敏捷.17.19敏捷項目力網絡192.2 敏捷開發的關鍵實踐.22.2.

13、32.2.4迭代-增量開發20測試驅動開發22持續集成24面對面交流252.3 敏捷項目中所需觀察的事情...6結對編程25例會26與需求有關的故事27團隊.27頻繁發布28自我組織的團隊282.4 小結29第 3 章項目管理303.1 傳統項目管理30..43.1.5工作分解結構31圖32關鍵路徑分析34項目35對的小結36敏捷項目管理36角色與職責393.3.1 角色393.3.2 責任413.4 小結46第二部分定義、計劃并衡量投資組合第 4 章基礎484.1 事實484.2 機構504.2.14.

14、職能型的機構50項目型的機構51矩陣型的機構5復合結構54項目管理.54術語和定義5.24.5.3項目55程序56投資組合574.6 涉眾584.7 目標5..44.7.5太多項目59項目很少能終止60沒有足夠的資源可用60缺乏指標61沒有愿景614.8 小結62第 5 章指標635.1 指標6..2進展64質量74團隊士氣80.82狀態.82解釋845.3 小結86第 6 章投資回報8目標87增量88財務模型9.2

15、.4回收期91凈現值94收益率96成本效益分析976.4 項目提供的效益9.26.4.3正在減少的效益98效益最后期限99正在增加的效益9風險100技術103小結104第 7 章項目投資組合管理1057.1 對項目投資組合進行平衡10..4避免一次從事過多項目106在投資組合中平衡有風險的和值得做的項目108使用有愿景的項目來平衡投資組合114避免限制愿景并阻礙開發的小項目1157.2 初始化一個項目1..47.2.5實現收集的過程117展示業務案例118業務案例的評

16、估120收集并管理提議120項目競爭：讓最好的項目勝出.123選擇項目125繼續/不繼續125項目的暫停127加速項目1287.4 小結130第 8 章資源投資組合管理1318.1 資源投資組合的平衡13..4缺乏愿景132項目太多但資源不夠134項目需要不同技能136缺乏來自資源的反饋138角色和資源池140技能傳授141敏捷培訓1418.3.2 輔導148.7全球化分布開發143企業網絡145.146小結147第 9 章資產投資組合管理1489.1 對資產投資組合進行平衡14.29.1.3它首先是一項資產，然后是個路

17、障149“基業長青”是否是正面屬性.152所的總成本1549.2 小結155第 10 章投資組合在行動156投資組合儀表板156一個示例場景157.210.2.3第一次迭代158第二次迭代159第三次迭代16010.3 小結162第三部分機構和環境第 11 章使用 Scrum 進行投資組合管理164Scrum 概述164投資組合待辦事宜167.211.2.3項目投資組合待辦事宜168資源投資組合待辦事宜169資產投資組合待辦事宜16911.3 角色169.211.3.3投資組合所有者170投資組合隊長170投資組合經理17011.4

18、活動171投資組合沖刺計劃會議171投資組合 Scrum 會議17111.6 Scrum.173第 12 章項目管理.17512.1 敏捷項目管理的.17512.1.3 里程碑監視與過程.179摘要：敏捷項目管理在一個企業向敏捷方式的改變既帶來機會也帶來風險，本書將探究敏捷方法為開發機構及其力帶來的機會和回報，也將探究其潛在的風險問題。 ：敏捷開發敏捷項目管理的要求的企業。在一個企業向敏捷方法的變更既帶來機會也帶來風險，本書將探究敏 捷方法為開發機構及其力帶來的機會，也將探究潛在的風險問題。本書分為以下三個部分：敏捷與管理；定義、計劃并衡量投資組合；機構和環境。 閱讀本書可以了解敏捷開發和敏捷

19、項目管理中常用的敏捷實踐以及如何使用現代投資組 合管理實踐管理敏捷項目。本書也針對如何把最流行的敏捷開發過敏捷投資組合管理編 踐和投資組合管理感的閱讀。參加本書翻譯的有：、管學崗、敏、張德福、陳紅霞、年、 金國良、。排在一起提供了一些實際操作建議。本書適合項目經理、投資組合經理、業務分析師、PMO 成員以及執行經理等對采納敏捷實譯者序敏捷開發方法流行于那些發現傳統瀑布開發方法無法適應這個由變更、革新驅動的世界本節為譯者序。項目管理的最優方法179定義敏捷 PMO 的角色和職責180PMO 和投資組合管理181為敏捷工作選擇正確的工具181開銷和效益182在敏捷環境中應用模型、標準和規則1831

20、2.2 最大限度利用 PMO18312.2.1 輔導18312.2.2 員工配備18412.2.3 培訓184手冊和發布說明184發布團隊18412.2.6 指標18512.2.7 狀態18512.2.8 投資組合18512.3 小結185附錄附加資源186敏捷項目管理 譯者序敏捷項目團隊是賦予力量且是自我組織的175敏捷過程是以經驗為依據的17711.7 小結17411.4.3 投資組合沖刺回顧會議17111.5 指標172摘要：敏捷項目管理在一個企業向敏捷方式的改變既帶來機會也帶來風險，本書將探究敏捷方法為開發機構及其力帶來的機會和回報，也將探究其潛在的風險問題。 ：敏捷開發敏捷項目管理行

21、官和項目經理的書架上。Peter Rivera， AOL Programming 執行創新和程序、高級 副這本書給出了目前對敏捷方法的強烈中被忽略的一個領域。許多機構在采用諸如Scrum 和XP 這樣的敏捷方法時會一些問題，其解決方案存在于有效的投資組合管理中， 而 Jochen 成功地將這個展現在面前。Sanjiv Augustine，Lithespeed、AgileProject Management的作者、敏捷項目力網絡的合伙創辦者這本書絕對值得一讀。Jochen 簡化了一個非常復雜的概念，并且給了一本既言簡意 賅又為敏捷投資組合管理提供非常實用方法的書。Robert Eagan，紐約某

22、主要金融機構的全球項目管理本書開墾了敏捷標準的地，它在程序和投資組合級別上為敏捷機構中的組織工作提 擇、和投資組合管理過程成為實現敏捷開發機構本應支持的完全有競爭力的效益的。本書將為機構提供一些特定的選項，供機構考慮敏捷投資組合計劃和管理實踐的節奏和 質量，以便與現代敏捷開發機構的速度相匹配。Evan Cbell，Rally Software Development專業服務副在這本獨一無二而且開標立范的書中，Jochen Krebs 為 IT 社區帶來了創建并管理敏捷投資組合所急需的、實際的和全面的路線圖。Doug DeCarlo，Doug DeCarlo、eXtreme Project Ma

23、nagement: Using Leadership, Principles & Tools tiver Value終于看到了一本為 IT者和業務涉眾編寫的實用的敏捷項目管理之書。Jochen 對它都極為適合。它也是一本 CIO、PMO和產品所有者必讀的書。Tiran Dagan，GE/NBCUniversal計劃與分析部門/契約在一個全球化、超級競爭的市場中，比以往任何時候都更需要找到持續識別、排序 并執行項目的方法，這些方法能夠像例行公事般地快速部署引人注目的產品與服務，并 帶來企業的革新和更好的收益。已經出現的敏捷開發實踐順應了增長中的需要，而機構 決策和管理方法則繼續植根于那些舊的教科

24、書般的管理實踐緊抓大設計在先的提供與 驅動的世界中，這個框架的構建是為了機構的和實踐方式，以便獲取最大的機構敏 捷性并創造最大價值。我將把 Jochen 的書給我所有的 CXO 客戶閱讀，因為他們希望能夠對如何最好和有效地管理并利用對生存和系統性革新都如此關鍵的敏捷工程實踐有更好的理本書贊譽本書講述企業在投資組合管理應用敏捷方法丟失的環節。Mike Cohn，Agile Estimating and Planning的作者大型機構中存在的各種相互依賴關系會讓想要朝向敏捷方法前進的團隊感到困惑，而Jochen Krebs 著的就是一本為他們解惑的書。本書應該位于那些有前瞻想法的各個層次的執由于時

25、間緊迫，加之譯者水平有限，錯誤在所難免，懇請廣大讀者批評指正。敏捷項目管理 本書贊譽解。Brad Murphy，ValtechCEO執行模型。本書成功地描繪了一個廣泛的、實用的以及具有良好構想的框架。在一個由變更敏捷實踐的全面介紹涵蓋了投資組合管理中的三個關鍵向量：項目、資產和資源的財政、過等方面。這是一本我會擺在案頭的參考書籍，對于任何要進行敏捷戰役的機構而言 he face of Volatility的作者供了特定的技術。隨著大型 IT 機構對敏捷方法的廣泛采用，許多機構發現自己過時的項目選本節為本書贊譽。摘要：敏捷項目管理第 1 章，本章從企業和管理的角度揭示使用傳統開發方法（也稱為瀑布

26、法）的企業要面對的共同。本節為大家介紹管理的期望。 ：敏捷開發敏捷項目管理本書的第一部分是為想要對與敏捷開發有關的效益和有了解的管理而 本部分的 3 章將為在第二部分更深入探究敏捷投資組合管理設立一個舞臺。這一部分的 3 章將從管理的角度來介紹敏捷方法：第 2 章介紹用于敏捷項目的敏捷價值、關鍵實踐和。第 3 章展現敏捷項目管理的角色和職責以及與其涉眾之間的關系，還介紹了傳統項 目管理實踐的。在這個新千年開始的時候，出現了明顯的市場全球化的趨勢，尤其在（IT）領 發的。探究在這個不穩定、不可知和不可的世界中，按傳統方式管理的 IT 項目所要面對的一些。本章從企業和管理的角度揭示使用傳統開發方法

27、（也稱為瀑布法） 的企業要面對的共同。每個以傳統方式管理的項目引起的都會給開發機構帶來風險。這些風險中有一 些是如此難以抵擋，以致現代機構無法它們的存在，甚至無法那些用于降低這些風 險的。多。而結果是，這個系統的受眾可能還是不“喜歡”它。項目是成功的嗎？可能是“是”。系統是否做了用戶想要的事情？極有可能不是。過于的變更、系統的不穩定性以及需求 典型癥狀。盡管開發對細節相當關注，但項目卻無法取得成功，其原因在于要捕獲整個 1.1.1 摘要：敏捷項目管理第 1 章的變更，本章從企業和管理的角度揭示使用傳統開發方法（也稱為瀑布法）的企業要面對的共同。本節為大家介紹的變更。 ：敏捷開發敏捷項目管理1.

28、1.1的變更以傳統方式管理項目的特征是：各個階段由里程碑隔開，階段與階段之間通常需要有一個完成信號。這個完成信號標志著項目團隊通過了里程碑，可以繼續進入下一階段的工作。涉眾群的所有期望是不可能的。這種理想世界不存在。的二義性持續地導致項目與原來的計劃背道而馳，而這些現象正是一個項目無法符合期望的1.1 管理的期望我有很好的理由使用“期望”這個詞而不使用“需求”。需求是一組業務規則和組織政策，它們與涉眾所表達的需要組合在一起。期望包括需求，但它們不那么實際可見，也根本無法表達出來。然而，在項目的最終，對成功的衡量標準是期望，而不是需求。比如，一位業務分析師在將系統的詳細需求整理成檔時，他所給予的

29、最大關注程度也許不會超出需求太域。即使是長久以來認為與這個趨勢無關的本地 IT 企業家，也越來越多地感受到來自國際上的壓力，認為必須拼價值和價格。而涉眾（stakeholder）們不僅僅期待用更少的金錢獲得更高的質量，而且期待開發機構能夠在更短的周期內更快地發布產品。對這個腳步飛快的環境進行管理的需求、對適時將產品發布到市場的需求，以及對價格保持敏感的需求都是敏捷開第 1 章第 1 章使用真實世界的示例、趨勢和業務世界事實來說明敏捷開發最近得到如此多的關注的原因。準備的。這里包括對敏捷是什么以及敏捷開發為什么尤其能在動態市場中很好工作的介紹。第一部分 敏捷與管理第 1 章1.1 管理的期望與有

30、法律約束的合同相似，一旦完成信號得到確認，就很難再轉回項目前面的狀態了。雖然這些合同的簽署在許多情況下合乎情理，它們讓可以對特定的條件達成一致，但是在將其應用于開發環境的時候，這個模型卻受到了?？纯催@是為什么。圖 1-1 概要地描繪了傳統開發方法，諸如需求、分析和設計、編碼、測試以及部署這樣的公共工程活動分成了各自獨立的階段。（點擊查看大圖）圖 1-1的需求變更實施從一個階段到另一個階段的轉移要通過完成信號、批準并提交給下一個專業團隊這幾個過程。一旦進入下一階段，前一階段的工作就完成了，而這正是問題所在。在傳統的過程中，每個項目只在過程中流過一次，最后以系統的部署作為結束。請想象一個需要兩年時

31、間完成的項目，它按如圖 1-1 那樣的階段進行。當進入編碼階段時，我們的需求已經是 10 個月前的了。16 個月之后，系統終于進入測試階段。而正是在測試階段中，人們發現之前沒有發現的需求。如果在測試的時候這些需求還沒有被發現，然后就對系統進行了部署，那才叫糟糕透頂。在部署之后，涉眾將判斷他們早先需求的實現情況。這個時候就會發現問題了，因為最初的涉眾將在的這個階段回來。然而，到了現在想再做變更就了。這有兩個原因：一個是經濟原因，到目前為止這個項目已經花費了所分配的資源中的大部分；另外一個是結構和設計上的原因，它們在構建的時候根本就沒有考慮這些需求。以傳統方式管理的項目好處雖然有許多，但它們有這個

32、共同的變更極難得到消化。當然，程度與引入變更的嚴重程度有關。我甚至見過因為一個需求的變更而造成整個項目完全失敗的情況。這就是我經常在部署階段之后增加一個叫做“批評階段”的新階段的真實原因。請記傳統模型是在 20 世紀 60 年發的，在那個時候IT 王國的是大型計算機。在那個時代所使用的技術并不歡迎變更的到來。那時候編程是過程化的、自上而下的。如果需要變更，就需要重新編譯并重新組裝整個程序或系統。為了安全起見，每一次編譯的成品都需要新的完全測試。這個模型為其特定的技術服務，人們作做好。般地嘗試地把工雖然開發機構已經采納了新的、面向組件的技術，但是底層的開發過程仍舊經常使用相同的傳統方法。正是這個

33、過程反映了整個開發機構的文化。變更一種久負盛名的文化要比使用一種新的編程語言需要的能量。相比之下，現代開發通常使用面象的技術。這些面象的系統是由更小的高度聚合、松散耦合的分塊和元素組裝起來的。這使開發團隊能夠以更小的步驟和單元進行開發、測試并集成。由于新的可用技術的存在，現在處于一個可以關注現發過程及其管理方法的位置上。結果就是，敏捷開發和敏捷項目管理方法更早、更頻繁地把變更帶入，而且這些方法以小的、循序漸進的步驟來構建。摘要：敏捷項目管理第 1 章，本章從企業和管理的角度揭示使用傳統開發方法（也稱為瀑布法）的企業要面對的共同。本節為大家介紹需求癱瘓。 ：敏捷開發敏捷項目管理相比于那些可以實現

34、的的需求變更（雖然很費勁），有些需求由于過于動態或存在 求癱瘓歸根結底只有一個原因：想讓需求“確定下來”。摘要：敏捷項目管理第 1 章，本章從企業和管理的角度揭示使用傳統開發方法（也稱為瀑布法）的企業要面對的共同。本節為大家介紹二義性。 ：敏捷開發敏捷項目管理個人制作一張餅無異于買。當談及諸如比薩餅這樣的日常事務時，似乎不需要任何 解釋。Gause 和 Weinberg 使用一個簡單的句子說明了這個例子：“有了只小羊羔?！边@ 在管理需求期望時也有相同。對于手邊的，每個人的圖像都不同。就如 當你說“明天的天氣將很不錯！”會讓人們有不同的圖像那樣，對于“系統生成一張發 票”這樣的句子也一樣。有些人

35、會想到一張紙，其他的則認為會以電子的方式。結 果就是，完成的系統也以按文檔的規范工作，但卻不是按用戶心中所想的那樣工作。如 果用戶是實際的顧客（比如，購物者），消除二義性就必須是最高優先級的工作。二義 敏捷開發將保持用戶的參與，經常要求涉眾按他們的圖像對成果進行確認。于是， 敏捷開發消除了二義性及其價格上的巨大數字。摘要：敏捷項目管理第 1 章，本章從企業和管理的角度揭示使用傳統開發方法（也稱為瀑布法）的企業要面對的共同。本節為大家介紹需求太多。 ：敏捷開發敏捷項目管理1.1.4需求太多1.1.4 需求太多1.1.3二義性向團隊中的三個成員詢問他們最喜歡的比薩餅是哪種，他們談到的餅可能完全不同

36、。其 中一人可能喜歡薄的、脆的，而不是厚的；另一個人可能喜歡半圓型的，而不是一塊一塊的；而第三個成員可能選擇帶紅色調味汁的比薩餅，而不是白比薩餅。不把需求說清楚就為這三1.1.3 二義性在這種類型的環境中工作尤其讓人感到灰心，因為所有參與方都清楚地知道工作沒有進展。團隊處于這種狀態的時間越長，就越需要更好的激勵才能讓他們回到正軌。基本上，需1.1.2需求癱瘓1.1.2 需求癱瘓性代價高昂。比如，Barry Boehm 就有這樣的評估：如果在需求階段所修正的二義性的成本比率為 1，那么在測試階段發現二義性所造成的修正成本將是這個值的 1540 倍；如果在部署階段之后應用程序或系統開始運行時發現二

37、義性，則成本將高達 401000 倍。請記得，這些統計與傳統方式管理項目有關。里的“有了”有可能以許多不同的方式錯誤地進行解釋。她可能懷了只羊羔，擁有一只羊羔或者實際上吃了一只羊羔都是可能的解釋。而根本無法解決。在需求總是變化，大家疲于對大的技術規格達成一致的情況下，項目 團隊將根本無法找到需求階段的出口在哪兒。讓受困于這種事件圈子中的人感到灰心的是，除了文檔以外項目團隊無法達成任何明確的進展。在涉眾和業務分析師們嘗試解決歧義問題并完成一個足夠穩定的需求范圍以便完成這一階段的過程中，珍貴的時間和資源白白浪費了。這種現象在動態行業中尤其常見，這些行業的變更速率非常高；另外在革新項目中也很常見，這

38、種項目的需求起伏無常。比如傳媒業和業以及金融業就屬于這種動態業務領域。對于這樣的情況，需求可謂。持。當我與其他涉眾這些需求時，發現陳述這些需求的涉眾實際上使用的是過時的 公司政策。你能想象如果這樣的需求當成需要并且加以實現會是個什么樣子嗎？在這個案例中發現了這樣，但我確認在不知情的情況下在其他地方實現 摘要：敏捷項目管理第 1 章，本章從企業和管理的角度揭示使用傳統開發方法（也稱為瀑布法）的企業要面對的共同。本節為大家介紹需求太少。 ：敏捷開發敏捷項目管理到目前為止所有與需求管理有關都有一個積極的方面：有需求可以開始。要么有太多需求，需要應付二義性，需要集成并解決的變更，要么需要應付需求癱瘓。

39、 接下來要的場景可能是傳統項目面對的最糟糕的情況：需求太少。具有諷刺意味的 是，需求太少是敏捷開發非常對付。需求的缺乏對傳統項目有巨大的影響。首先，最初的項目范圍涉眾真正的需要。其次，評估出來的范圍會導致的變更控制攪動（change-control churn），因為涉眾最 終會表達出他們的需要。變更控制攪動看成是在低質量需求基礎上的大量變更。這也 包含“真正的”需求，了真實的潛能。我可以想象得出有多少業務潛能隱藏在那些位于 作為結果，項目團隊按照一級的功能列表工作，這就為其他需求問題開了方 便尤其是二義性和的變更。需求太少是動態市場中的傳統項目典型的情形。在動 態行業中，涉眾的時間通常過于有

40、限，所以會必須是簡短的，而且業務分析師無法給出 足夠的時間來探究需求的細節即使是那些在項目啟動時最重要的需求。“待命”列表的項目中。如果需求太少，那么要想獲得早期或初始的評估，或者對計劃進行迭代，都將會是個挑 戰。然而，事實是，需求終究會出現。在項目要結束的時候需求才出現，這會是傳統項目面 對的最糟糕的情況。這種情況經常發生在雖然剛剛交付了第一個或主要的版本，而項目團隊 卻得繼續為新版本工作時。最可能的情況是，團隊所做的、所修補的是一開始沒想到的事情。包括對先前批準的變更所作的變更。最后但并不是不重要的一點：范圍受限于在項目的第一 部分所表達的需求。所以，許多新發現的需求都是為實際項目之后的所

41、謂改進項目而收集的。這些改進項目對于一個機構而言非常重要，經常是沒有它們就無利可圖。換言之，改進項目1.1.5需求太少過這種類型的需求。教訓就是：要商定需求，進行投票，讓涉眾與你一起工作并保持讓他們參與。涉眾們需求很多，但他們實際需要的是什么？當對所謂的需求規格按優先級排序時，我們將發現，許多需求可有可無，或者完全超出范圍之外。如果給這些功能進行評估，就會發現這個情況特別真實。要記住，需求必須是涉眾們的公同需要。而有些需求可能只來自一位涉眾，這樣的需求必須和其他涉眾進行協商，得到他們的接受和確認。對功能的開發要耗費時間和金錢。不僅如此，有些功能根本不值得開發它們只會占用更重要功能的寶貴時間。許

42、多傳統項目會完成對需求的優先級排序和過濾這一步驟。遺憾的是，這一步驟只執行一次。一旦某些需求被認為超過項目的范圍，以后要想把它們加入到范圍內將會相當費勁。你在本書中自始至終都將看到開放范圍的需求管理在敏捷項目管理中的強大之處。你也將看到，真正的需要總能在最終系統中找到自己的位置。1.1.5 需求太少許多 IT 項目團隊非常嚴肅地對待需求規范。我在職業開始的時候也是這樣的。然而，當我與業務用戶實際操演之后，我發現需求經常只是個人的愿望列表。這些愿望列表經常是以個人的工作慣例為基礎的個人需求。我與一些涉眾交談，了解他們為什么對某些需求那么堅敏捷項目不追求建立一個完美的需求集合，但你將看到這個模型在

43、開發生命周期的初期動態地吸納新發現的重要需求的方法。作為結果，敏捷項目的計劃將在項目的早期就能夠包含新識別的重要需求。1.1.6 變更控制摘要：敏捷項目管理第 1 章，本章從企業和管理的角度揭示使用傳統開發方法（也稱為瀑布法）的企業要面對的共同。本節為大家介紹變更控制。 ：敏捷開發敏捷項目管理為了解決以傳統方式管理項目帶來的需求管理問題，機構建立起所謂的變更控制（Change Control Boards，CCB）。如這個名字所表明的那樣，這是由一些將變更的發生控制在項目范圍內的人組成的。所謂變更可以是對現有需求的變更，也可以是在項目早期或后期出現的新需求。這個通常由幾個項目團隊成員組成（比如

44、，項目經理、架構師、業務分析師等），它按不同案例決定每個變更請求。CCB變更請求，提出行動計劃并變更控制需要大量投資。變更控制不僅需要組織召開會議，也需要抽出可 任務）并集中注意力完成會議。后一項任務需要對決策重新并澄清在范圍上的改變。會議。對于承認變更控制的必要性的機構而言，這是其朝向采用更現代的工程過程所邁 出的第一步。這表明機構正在開始接受改變。不過，要決定變更控制是應該每周開一 次還是每兩周開一次會就能適應動態的要求，對開發和業務分析師來說都很難。在后續章節中敏捷項目如何將變更控制機制直接集成到開發過程中，使之成為一種日常 1.2 上市時間8摘要：敏捷項目管理第 1 章，本章從企業和管

45、理的角度揭示使用傳統開發方法（也 稱為瀑布法）的企業要面對的共同。本節為大家介紹上市時間。 ：敏捷開發敏捷項目管理的主辦方期望項目的回報能超過成本。換言之，應該把項目當成常規投資來。比如，IT 系統應該讓信息傳遞得更快，而且必須非常自動實現緩慢工的業務過程。對于任 項目就啟動了。在理想世界中，項目得以執行，系統得以交付，收到了來自解決方案的 對于本書其他部分所的內容而言這些風險都是最基本的。所以，讓來探究其中的一 糕的是，它可能起反作用。舉個例子來說，考慮一個與新的交易系統有關的性能問題。 他們的業務。圍繞這個場景更大是：“如果知道系統要慢 50%，那么這個項目還會1.2上市時間啟動一個項目是

46、對未來的投資。項目需要時間，也消耗資源，而且在大多數情況下項目進行投票表決。不會有人來做？”是可能不會。每秒執行的事務更少就意味著利潤更少，顧客可能投向其他具有更好基礎設施的券商來進行些風險。技術問題對解決方案所造成的瓶頸會比最初所期待的更嚴重。在業務案例中，期待的應用程序性能可能要比估算的低 50%。在市場上部署這樣的解決方案將讓邊際利潤縮水，而更糟效益。實際上卻沒這么簡單，因為每個項目都有風險。有一些風險十分基本并且顯而易見，何機構而言這是 IT 項目有巨大的投資潛力的原因之一。在識別了機會、確定投資數量之后，活動的方法。最可能的是，最初的決策將導致在項目團隊內召開更詳細的會議，并且可能會

47、有出現突然的觀的時間來準備會議（澄清變更請求、執行風險評估、獲得當前范圍的一致理解并執行管理1.1.6變更控制該公司的股價也許會飛漲。華爾街的家們買入的是未來，因為驅動價值的是這家公 開發與此沒太多區別，即使較大機構中的項目可能不存在與上述例子中相同明 顯的競爭，但通常也不會預先對公眾發布。而 IT 項目所作在于業務通常先于 IT。這是自然的，但這卻是一個。因為可以看到，在，業務小組會與 IT 部門進行競爭。讓想象一下這種場景。一家機構通過讓銷售代表直接與客戶一起工作的方式提供特 項目在于，IT 項目一直都在追隨業務的愿景而很少領先于業務。需要服務。比如，競爭對手也有相似的想法并且在項目開始之

48、后就發布了一個相似的系 統。于是項目團隊就不能忽略這樣一個事實：這個項目在可能按照正確路線進行，但卻 摘要：敏捷項目管理第 1 章，本章從企業和管理的角度揭示使用傳統開發方法（也稱為瀑布法）的企業要面對的共同。本節為大家介紹革新。 ：敏捷開發敏捷項目管理2006 年，租賃公司 Netfix 在 NPR 宣布，只要有人能將他們的系統改進至少 10%就給予 100 萬的獎金。一年以后，到了 2007 年 11 月，仍舊沒有人贏取這項現金從許多角度來看，將這樣的方法公之與眾都是一家公司革新其業務的新的、獨特的 首先，這家公司承認公眾在為 Netfix 的顧客這項工作上可以做得更好。Netfix也承認

49、它自己無法解決這個問題，這是一個巨大的心理。想想有些公司在涉及知識。下面通過與按傳統方式執行的項目作比較來看其如此創新的原因所在。大獎。1.3革新于市場時間表。1.3 革新隨著 IT 項目的時間流逝，業務也在演化。最終所交付的完成的系統可能再也無法為業務定服務與產品。然后，有位業務分析師發現顧客 80%的訂單是周期性的并且是相同的。于是就啟動了一個 IT 項目，旨在將這個訂購過程自動化并對其加速。實現現有業務過程的自動化是項目的典型場景。做好了決定并分配了之后，就要為開發計時了。這些類型的 司的潛力?，F在，證明自己并把許諾的產品推向市場就是這家公司的責任了。隨著項目一天天延期，就可能被其他機構

50、先拔頭籌。賽跑從此開始了。大多數公司都有競爭，他們不是在其市場中孤軍奮戰。啟動一個項目就會引入新的成本中心。只有交付的項目才會對公司的價值有所增加，并且將公司帶到一個獨特的或更好的位置上，也許能夠賺 的錢。不過，公司能收獲效益的時間有限，因為競爭對手很快就會趕上（見圖 1-2）。（點擊查看大圖）圖 1-2 上市時間和時間有限的效益假設有一家公司宣布了一種可以治療特定的藥物。由于其市場價值的，問題時的保護態度吧。這個例子所涉及要比僅僅從顧客那里收集反饋和想法多得多。 都得到了邀請，都能有所貢獻，但有一個很大的不同：贏家將獲得很的獎金。Netfix 使 再次，公司已經在對這個功能定了量因而實現 1

51、0%改進所增加的收入以及增加一個元素的決心以及所關注的顧務領域。有了這個，革新就轉向公開。作為回報，這個為 Netfix 帶來鋪天蓋地的宣傳和爭論，我相信這與整個比賽本身一革新需要創新，以及持續不斷地對現有業務過程進行重新思考。能在現代業務過程 行自動化的同時，也培養了新一代的對 IT 系統有高度期待的專業。Netfix 的示例表明，人們所探討的正在從以技術為的開發轉向以業務為的解決方案。作伙伴和擁有其他業務的。公司通常使用市場和公共關系段將公眾注意力引導到特定產品或服務上。這兩個都要依靠效應。這包括啟動能為其顧客提供 “已經知道你的下一個好！”的市場戰役包括電視、和。雖然 IT 項目只是整個

52、中的一小塊，但卻是不可或缺的一塊，項目中的所有其他部分都依賴于 首先成功的 IT 項目。IT 是整個戰役的發。對于許多在機構執行的項目也是如此。能夠吸引注意力的是與革新有關的。由于革新的存在，第要么為公司的愿景投資要么公司的產品或服務。沒有了與其所 提供的產品有關的革新和有趣的，機構將失去其競爭優勢，最終只會成為市場中的平庸 計劃革新非常，但為革新作計劃則要簡單一些。機構必須創建一個接納并鼓勵創新 的環境。對于項目與投資組合管理，需要為每個人“計劃”一個來引入變更與革 除了能為新產品和服務生成輝煌的想法之外，技術本身經常是業務的激發。比如， 考慮一下使用 GPS 設備作為一種郵遞的機制，使用掃

53、描器來電子測量儀表。我 1.4 摘要：敏捷項目管理第 1 章供給，本章從企業和管理的角度揭示使用傳統開發方法（也稱為瀑布法）的企業要面對的共同。本節為大家介紹供給。 ：敏捷開發敏捷項目管理機構內的流的組織也以能夠按傳統方式管理項目為目標。當未來的 IT在財務年度的末尾進行計劃與協商時，可以對將來項目的投資組合進行估算與評估。其結果將是一個非常靜態并且不靈活的財務模型，無法適應新的額外的項目。這種過程在財務年度中途1.4供給所在本地能源公司最近開始挨家挨戶抄表。我確信許多人之前就在夢想能夠有無需入戶即可 抄表的方法，而激光、條碼和紅外線技術的發明打開了在業務環境中更廣地使用技術的大門。新。就如

54、Alay 曾經的那樣，“未來最好的方法就是發明未來?！边@個必須包括啟動并執行能夠帶來變更和革新的項目的過程。傳統的描述性的過程模型，其事件流是死板、強制的，不如那些能適應經驗的方法易于接納改變。敏捷方法就是適應性的、接納革新的方法。玩家。利益的新產品或新發布版的整個。假設 Netfix 可以為其新系統啟動一次名為 大多數機構依靠從外部世界所獲得的關注來生存。這種關注包括最終消費者，也包括合中應用的新技術可能仍舊在嬰兒期。20 世紀，IT 在將企業內手工的、乏味的信息交換工作進樣有創意。甚至，從該公司開放的愿景和創新所吸引的人們中，公司可能獲得新的業務機會。的客戶滿意度足夠支付這一大筆獎金。最后

55、但并非不重要的一點，這個示例也為競爭對手展示了 Netfix 致力于改進其系統中的用了全球工程師網絡的力量來解決問題，而不是把自己限制在少數幾個合作伙伴中。這一比賽是要求提供解決某特定問題的聰明的方案。其次，Netfix 采用了與開源開發類似的方法，而不是將解決方案外包給承包商。每個人非常難以變更，因為最初的數已經定了下來。而后這些將用于所選的項目。毋庸置疑，新的革新的項目必須推遲，因為有限。管理層通常要求有和估算的硬數據，而不是按比例增加或減少去年的。要滿足這種要求就變成和傳統需求相似的情況。機構不能確切知道新項目需要什么、什么時候需要、需要多少和資源。項目的定義很模糊，而情況總是會變。將軍

56、曾經：“計劃毫無價值，但計劃的制定則?！边@個說法也適用于為項目制定財務計劃。機構最好以粗略的參數為將要來臨的財務年度分配資源（財務和人力），而不是規劃出一大套項目計劃。當需要為個性和創新項目分配資源時這個建議尤為重要，因為 IT 項目通常就是這樣。在傳統的供給過程存在的情況下，出了問題的項目（項目 A）將繼續消耗越來越多的資源，因為它一直在推遲。而后續的項目卻因為前面項目占用了其所依賴的資源而必須等待。請看圖 1-3。這種問題的原因是，項目處于機構的下而且投資了可觀的金錢。從組織上說，將項目移開并將資源給其他更加有希望的項目將是非常的。圖 1-3變更增加的帶走了其他排隊等待資源的項目所需的資源

57、，這就是影響所在。所有后續的項目（如圖 1-3 中的項目B 和C）甚至可能會因為資源的缺乏而從投資組合中完全退出。但如果這個項目要比任何其他項目都更能給機構帶來利益該如何？如果潛力更大的新項目出現（如圖 1-3 中的項目 D）卻因為過時的D 啟動難道不是一個更聰慧的做法嗎？計劃而無法競爭到資源該怎么辦？增加讓項目敏捷項目允許一個處于動態的項目選擇和供給過程，在后續章節中探討。1.5 小結，本章從企業和管理的角度揭示使用傳統開發方。本節為這一章的小結部分。摘要：敏捷項目管理第 1 章法（也稱為瀑布法）的企業要面對的共同：敏捷開發小結敏捷項目管理1.5第 1 章的目標是讓識。為了說明這些對在動態業

58、務世界中按傳統方式管理的項目相關的建立起共，我講解了機構的 IT 項目需要的四個共同領域：管理例外、加速上市周期、鼓勵革新和提供。這些將為隨后的兩章內容搭建舞臺，了解敏捷開發及其項目管理技術。接下來的兩章將為經理們給出在本章問題的詳細和 摘要：敏捷項目管理第 2 章敏捷開發，本章將定義敏捷開發所代表的含介紹的 結合在一起。本節為大家介紹敏捷是什么。：敏捷開發敏捷項目管理本章將定義敏捷開發所代表的含義，并從經理的角度來了解敏捷開發的關鍵實踐（practice）。我將把這些實踐與前一章所介紹的結合在一起。在開始了解敏捷開發的實踐之前，先了解敏捷這個詞。敏捷方法是一種能夠容納變更的工程框架。比如，通

59、常對于復雜的開發工作， 得以處理并減少這些不確定。這些機制在本章中將作為關鍵實踐列出。如果將這些關鍵 摘要：敏捷項目管理第 2 章敏捷開發，本章將定義敏捷開發所代表的含介紹的 結合在一起。本節為大家介紹敏捷過程。：敏捷開發敏捷項目管理以下敏捷過程已經成功地在廣泛的行業中采用過。這里所列出的各個過程都有物、 培訓課大量用戶社區提供支持。本書這一部分的介紹是為經理們所寫，我將為每個流行 的敏捷過程提供快速定義及其緣由。而后在本書的第三部分，深入了解 Scrum一個流極限編程（Extreme Programming，XP）是 Kent Beck、Ward Cunningham 和 Jeffries在

60、 20 世紀 90 年發的一套動態編程實踐。如今，XP 是高技術行業最常采用的敏捷方法。 development），在本章稍后內容中更詳細它們。雖然 XP 為項目管理提供計劃制 定的實踐，但通常其看作是敏捷工程過程。Ken Schwaber 和 Jeff Sutherland 在 20 世紀 90 年發了 Scrum，將其定義為一種敏 捷項目管理的框架而不是一個敏捷過程。Scrum 源自于精益制造（Lean Manufacturing，將在本節稍后介紹）、迭代-增量式開發（也就是反復與漸進式開發）和 Smalltalk 工程工具。Scrum提供了一套簡單的規則。除了這些簡單規則以外，Scrum