敏捷項目管理-美施著management

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

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

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

4、們已經(jīng)轉(zhuǎn)移到新的項目上了。的事情。在分析之前或在分析過程中，想知道總共有多少分析量是不可能的。如果不知道總享。這些觀察的結(jié)果有許多都能追溯到同一個根本原因：在機(jī)構(gòu)內(nèi)，我所目睹到的各個方面都缺乏信任。的風(fēng)險問題。將使得執(zhí)行官、項目經(jīng)理以及項目團(tuán)隊得以掌好項目的舵，帶領(lǐng)項目駛向并不精確的愿景。想轉(zhuǎn)變?yōu)槊艚莘椒ú⒉皇且患菀椎氖虑椤８淖儙頇C(jī)會，也總需承擔(dān)風(fēng)險，敏捷開發(fā)的機(jī)這是造成這種問題的原因之一。為了解決這個問題，許多機(jī)構(gòu)采用或試用敏捷開發(fā)方法這是一種基于迭代-增量開發(fā)的方法，它將項目的范圍分解為更小的、可管理的塊。從管理的角度看，這是一種理想方法，前言本節(jié)為前言部分。敏捷項目管理 前言本書適合

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

24、書般的管理實踐緊抓大設(shè)計在先的提供與 驅(qū)動的世界中，這個框架的構(gòu)建是為了機(jī)構(gòu)的和實踐方式，以便獲取最大的機(jī)構(gòu)敏 捷性并創(chuàng)造最大價值。我將把 Jochen 的書給我所有的 CXO 客戶閱讀，因為他們希望能夠?qū)θ绾巫詈煤陀行У毓芾聿⒗脤ι婧拖到y(tǒng)性革新都如此關(guān)鍵的敏捷工程實踐有更好的理本書贊譽(yù)本書講述企業(yè)在投資組合管理應(yīng)用敏捷方法丟失的環(huán)節(jié)。Mike Cohn，Agile Estimating and Planning的作者大型機(jī)構(gòu)中存在的各種相互依賴關(guān)系會讓想要朝向敏捷方法前進(jìn)的團(tuán)隊感到困惑，而Jochen Krebs 著的就是一本為他們解惑的書。本書應(yīng)該位于那些有前瞻想法的各個層次的執(zhí)由于時

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

40、限，所以會必須是簡短的，而且業(yè)務(wù)分析師無法給出 足夠的時間來探究需求的細(xì)節(jié)即使是那些在項目啟動時最重要的需求?！按绷斜淼捻椖恐小Ｈ绻枨筇?，那么要想獲得早期或初始的評估，或者對計劃進(jìn)行迭代，都將會是個挑 戰(zhàn)。然而，事實是，需求終究會出現(xiàn)。在項目要結(jié)束的時候需求才出現(xiàn)，這會是傳統(tǒng)項目面 對的最糟糕的情況。這種情況經(jīng)常發(fā)生在雖然剛剛交付了第一個或主要的版本，而項目團(tuán)隊 卻得繼續(xù)為新版本工作時。最可能的情況是，團(tuán)隊所做的、所修補(bǔ)的是一開始沒想到的事情。包括對先前批準(zhǔn)的變更所作的變更。最后但并不是不重要的一點：范圍受限于在項目的第一 部分所表達(dá)的需求。所以，許多新發(fā)現(xiàn)的需求都是為實際項目之后的所

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

42、多傳統(tǒng)項目會完成對需求的優(yōu)先級排序和過濾這一步驟。遺憾的是，這一步驟只執(zhí)行一次。一旦某些需求被認(rèn)為超過項目的范圍，以后要想把它們加入到范圍內(nèi)將會相當(dāng)費勁。你在本書中自始至終都將看到開放范圍的需求管理在敏捷項目管理中的強(qiáng)大之處。你也將看到，真正的需要總能在最終系統(tǒng)中找到自己的位置。1.1.5 需求太少許多 IT 項目團(tuán)隊非常嚴(yán)肅地對待需求規(guī)范。我在職業(yè)開始的時候也是這樣的。然而，當(dāng)我與業(yè)務(wù)用戶實際操演之后，我發(fā)現(xiàn)需求經(jīng)常只是個人的愿望列表。這些愿望列表經(jīng)常是以個人的工作慣例為基礎(chǔ)的個人需求。我與一些涉眾交談，了解他們?yōu)槭裁磳δ承┬枨竽敲磮悦艚蓓椖坎蛔非蠼⒁粋€完美的需求集合，但你將看到這個模型在

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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