軟件項目管理與敏捷方法

出版時間:2010年06月  出版社:機械工業(yè)出版社  作者:Michele Sliger,Stacia Broderick  頁數(shù):246  譯者:初悅欣,亢江妹  
Tag標簽:無  

前言

我們致力于軟件開發(fā)方法中的敏捷開發(fā)實踐(我們也被人們稱為敏捷開發(fā)人員),但是我們的軟件開發(fā)生涯并不是以這種方法學(xué)開始的。我們最開始是項目管理專業(yè)人員(PMP),在軟件開發(fā)中采用更為傳統(tǒng)的方法。為什么要寫這本書在大部分職業(yè)生涯里,我們都遵循項目管理研究所(PMI)的《A Guide to the Project Management Body of Knowledge,Third Edition》(后文簡寫作《PMBOK Guide》)中的方法學(xué),在使用敏捷方法的過程中我們越來越清楚地意識到與這本書的主題有關(guān)的一些誤區(qū)——一些我們曾經(jīng)相信但不正確的思想。直到現(xiàn)在,作為敏捷方法的咨詢師,我們?nèi)匀荒苈牭揭恍┛蛻粽f他們相信(這是不正確的)如果要保持PMP資格并且遵循《PMBOK Guide》中的實踐,就必須采用類似瀑布模型的軟件開發(fā)方法學(xué)。我們還聽到一些錯誤的觀點,認為敏捷方法缺乏紀律性和嚴格性。我們看到一些人帶有恐懼和失望情緒,因為他們覺得如果遵循敏捷方法的路線,那么之前在PMI上的投資可能會付諸東流。本書的目標是消除這些疑慮,并說明《PMBOK Guide》第3版確實支持敏捷軟件開發(fā)方法,項目管理者在。PMI上的投資和《PMBOK Guide》所列的實踐仍然有效并且適宜采用。我們認為《PMBOK Guide》處于方法學(xué)的中立位置,無論選用了哪種軟件開發(fā)方法,它都支持良好的軟件開發(fā)方法學(xué)實踐。盡管許多人知道這個事實,但是還有許多人并不知道。我們曾經(jīng)是PMP的追隨者,現(xiàn)在成了敏捷開發(fā)的狂熱分子。我們認為另一個重要的問題是如何消除敏捷開發(fā)群體認為PMP從業(yè)者不能成為好的敏捷開發(fā)項目管理者的誤解。我們希望建造一座兩者之間溝通的橋梁——這便是本書想要做的事。

內(nèi)容概要

  《軟件項目管理與敏捷方法》重點論述了項目管理研究所(PMI)的《PMBOK Guide》一書中介紹的軟件項目管理實踐與敏捷軟件開發(fā)方法之間的關(guān)系,同時建立兩者之間的橋梁。《軟件項目管理與敏捷方法》的內(nèi)容廣泛,包括了項目管理中所有重要的主題,同時還包含了作者多年從事軟件開發(fā)和項目管理的經(jīng)驗總結(jié),為軟件項目管理人員轉(zhuǎn)換到敏捷方法給出了理論參考和實踐指南?!  盾浖椖抗芾砼c敏捷方法》適用于高等院校相關(guān)專業(yè)的師生作為輔助教材或參考讀物,同時適合于每一位參與到敏捷開發(fā)方法中的管理人員和工程技術(shù)人員。

作者簡介

作者:(美國)斯里格(Michele Sliger) (美國)Stacia Broderick 譯者:李曉麗 李虎 趙華 等Michele Sliger是Sliger CotlsLdting公司的老板。該公司的咨詢業(yè)務(wù)涉及從初創(chuàng)的公司到財富500強公司,幫助組織采納敏捷方法。Michele是stickyrmids.com上的定期撰稿人,她擁有項目管理專業(yè)人員資格(PMP)認證和Scrum培訓(xùn)師認證(CST)資質(zhì),并獲得MBA學(xué)位。Stacia Broderick創(chuàng)建了AgileEvoltution公司,目的是幫助其他公司以更人性化、更合理的方式采納敏捷開發(fā)實踐。Stacia是具有豐富經(jīng)驗的敏捷教練,并且同時擁有項目管理專業(yè)人員資格(PMP)認證和Scrum培訓(xùn)師認證(CST)資質(zhì)。

書籍目錄

譯者序前言作者簡介緒論項目管理者如何跨過橋梁第一部分敏捷開發(fā)方法概述第1章 敏捷方法1.1 敏捷方法的起源1.2 敏捷宣言1.2.1 個體和交互勝過過程和工具1.2.2 可工作的軟件勝過全面的文檔1.2.3 同客戶的協(xié)作勝過合同談判1.2.4 對變更的響應(yīng)勝過遵循計劃1.3 指導(dǎo)敏捷項目團隊的敏捷原則1.4 小結(jié)1.5 尾注第2章 《PMBOKGuide》到敏捷方法的映射:2.1 項目管理研究所和《PMB0KGuide》2.2 項目生命周期2.3 項目管理過程2.4 小結(jié)2.5 尾注第3章 敏捷項目生命周期詳解3.1 敏捷項目生命周期概覽3.2 敏捷項目3.3 敏捷發(fā)布3.4 敏捷迭代3.4.1 迭代計劃3.4.2 迭代評審3.4.3 迭代回顧3.5 例行工作3.6 敏捷方法和計劃驅(qū)動方法之間的區(qū)別3.7 小結(jié)3.8 尾注第二部分 橋梁——《PMBOKGuide》中的實踐和敏捷開發(fā)實踐的關(guān)系第4章 集成管理4.1 開發(fā)項目章 程和初步的范圍陳述4.1.1 宣貫會議4.1.2 簡要比較4.2 開發(fā)項目管理計劃4.3 指導(dǎo)和管理項目的執(zhí)行、監(jiān)視和控制項目工作4.4 集成的變更控制4.5 結(jié)束項目4.6 小結(jié)4.7 尾注第5章 范圍管理5.1 范圍計劃5.1.1 范圍定義5.1.2 創(chuàng)建wBs5.1.3 范圍驗證5.1.4 范圍控制5.2 小結(jié)5.3 尾注第6章 時問管理6.1 戰(zhàn)略計劃Vs戰(zhàn)術(shù)計劃6.2 發(fā)布計劃:開發(fā)戰(zhàn)略層面的時間進度計劃6.2.1 發(fā)布計劃:在戰(zhàn)略層面開發(fā)時間進度計劃6.2.2 發(fā)布計劃:戰(zhàn)略層面上的時間進度控制6.3 迭代計劃:開發(fā)戰(zhàn)術(shù)層面的時間進度計劃6.3.1 活動定義6.3.2 活動持續(xù)時間評估6.3.3 活動排序6.3.4 活動資源評估6.3.5 迭代計劃:戰(zhàn)術(shù)層面的時間進度計劃控制6.4 小結(jié)6.5 尾注第7章 成本管理7.1 成本評估7.1.1 敏捷項目的成本最好由產(chǎn)品交付團隊進行評估7.1.2 敏捷項目是自頂向下評估而不是自底向上評估7.1.3 項目團隊在發(fā)布計劃期間可以給出選項7.1.4 成本評估在項目生命周期中逐步細化7.2 成本預(yù)算7.3 成本控制7.3.1 管理發(fā)布待完成事項列表7.3.2 鎖定迭代7.3.3 將成本的變更情況通知給利益相關(guān)人7.3.4 度量成本性能的AgileEVM7.4 小結(jié)7.5 尾注第8章 質(zhì)量管理8.1 質(zhì)量計劃8.2 質(zhì)量保證8.2.1 演示、評審和回顧8.2.2 質(zhì)量控制8.3 小結(jié)8.4 尾注第9章 人力資源管理9.1 人力資源規(guī)劃9.2 組建項目團隊9.3 發(fā)展項目團隊9.3.1 敏捷價值觀9.3.2 從價值觀到行為9.4 管理項目團隊9.5 小結(jié)9.6 尾注第10章 溝通管理10.1 溝通計劃10.2 溝通基本項目信息——誰、什么、何時、何地和怎樣10.3 信息發(fā)布10.3.1 迭代演示和評審會議10.3.2 通過每日站立會議進行交流10.3.3 回顧10.3.4 實時信息指示器10.4 業(yè)績報告10.5 利益相關(guān)者管理10.6 小結(jié)10.7 尾注第11章 風(fēng)險管理11.1 敏捷開發(fā)方法中的有機風(fēng)險管理11.1.1 消除進度表固有的缺陷11.1.2 緩解規(guī)格故障11.1.3 減輕范圍蔓延的影響11.1.4 緩解人員流失11.1.5 緩解生產(chǎn)率變化11.2 風(fēng)險管理規(guī)劃11.3 風(fēng)險識別11.4 風(fēng)險分析11.5 風(fēng)險應(yīng)對規(guī)劃11.6 風(fēng)險監(jiān)測和控制11.7 小結(jié)11.8 尾注第12章 采購管理12.1 采購規(guī)劃12.2 合同規(guī)劃I12.3 要求賣方回應(yīng)12.4 選擇賣家12.5 合同管理12.6 合同結(jié)束12.7 小結(jié)12.8 尾注第三部分 跨過通向敏捷方法的橋梁第13章 如何變更職責(zé)13.1 允許團隊進行自我管理并且根據(jù)經(jīng)驗調(diào)整開發(fā)過程13.2 在團隊的不同階段采用不同的管理方式13.3 服務(wù)式領(lǐng)導(dǎo)13.4 具有自我意識的能力13.5 為了團隊與其他經(jīng)理合作13.6 放棄內(nèi)部管理13.7 促進合作13.8 清除障礙13.9 小結(jié)13.10 尾注第14章 如何與不采用敏捷方法的團隊共事14.1 在瀑布開發(fā)模式的公司中以敏捷開發(fā)團隊方式工作14.1.1 整合傳統(tǒng)開發(fā)過程的前端需求14.1.2 整合傳統(tǒng)開發(fā)過程的最終需求14.1.3 在敏捷開發(fā)過程中集成傳統(tǒng)過程需求14.2 敏捷開發(fā)團隊與非敏捷開發(fā)團隊在同一個項目中共事14.3 了解瀑布式開發(fā)中的障礙14.3.1 反對14.3.2 文化14.3.3 資源管理14.3.4 供應(yīng)商和承包商14.3.5 設(shè)施和工具14.3.6 成本計算和匯報14.3.7 審核人員和評估人員14.3.8 溝通14.4 小結(jié)14.5 尾注第15章 項目管理辦公室如何支持敏捷開發(fā)方法15.1 產(chǎn)品管理的延伸15.2 項目啟動15.3 我們符合標準嗎15.4 資源分配15.5 待完成事項列表操控和變更操控15.6 項目度量標準15.7 PMO作為培訓(xùn)者和教練員15.8 回顧管理員15.9 誰是敏捷PMO15.10 是否真的需要敏捷PMO15.11 小結(jié)15.12 尾注第16章 推銷敏捷開發(fā)方法的優(yōu)點16.1 推銷常識16.2 推銷給團隊16.2.1 會議太多了16.2.2 整體估計沒有意義16.2.3 如果不進行任何技術(shù)上的計劃會議,整個架構(gòu)就會失敗16.2.4 不在同一地點辦公,所以不能進行敏捷開發(fā)16.2.5 一些潛在的原因16.3 推銷給項目管理者16.3.1 敏捷開發(fā)中沒有長期計劃,如何進行預(yù)算呢16.3.2 現(xiàn)在就挺好的,為什么要改變16.3.3 我們的情況太復(fù)雜了,不適用敏捷開發(fā)16.3.4 為獲得最高效率,需要對資源進行矩陣化16.3.5 不相信員工能進行自我管理16.3.6 沒有甘特圖,我們?nèi)绾巫龀霾呗詻Q定16.4 推銷給客戶和產(chǎn)品負責(zé)人16.4.1 簽的合同是基于時間和花費的,這樣你們就可以不斷要錢了16.4.2 在每次迭代中沒有足夠的時間同團隊一起工作……第17章 常見錯誤附錄A 敏捷方法附錄B 敏捷制品術(shù)語表

章節(jié)摘錄

插圖:我是Stacia Broderick,我想講一個非常私人的、有關(guān)我思想轉(zhuǎn)變的故事,希望能夠幫助你認識到正視自己想法以及學(xué)會如何成長的重要性,盡管這個故事可能令人十分不舒服。我在1993年成為一名項目管理者,2003年開始從事敏捷開發(fā)。我還是一名PMP,正式接受過在我之前取得項目管理專業(yè)人員資格認證的數(shù)千人的培訓(xùn)。在我開始管理項目的時候,我對我的能力帶有一絲驕傲,我能學(xué)會如何將數(shù)據(jù)輸人到一個項目管理工具中,學(xué)會如何舉行狀態(tài)會議,如何同承包商和第三方供應(yīng)商協(xié)商有關(guān)資源和材料等事宜,如何減少項目風(fēng)險,當(dāng)然,還有如何控制項目的范圍。我甚至在睡覺時都能完成向前或向后的推算。項目管理對我來說是一項完美的事業(yè)。作為家里的老三,我把項目管理的思想灌輸給我的兩個姐姐,我們把項目管理運用到每周家務(wù)雜活的時間計劃上。我甚至還設(shè)計了一個過程來削減洗碗的工作量,通過一個批量抽取系統(tǒng)將洗碗機清空(只在需要時取出一個碗并且不再反復(fù)使用它,直到重新裝碗的時候才一次把碗放進洗碗機),但是我的父親并不支持這種新方法。對我(一個故步自封的怪物)來說,項目管理是一項完美的事業(yè)。我和Scrum的沖突始于2003年,Scrum是敏捷軟件開發(fā)方法中的一種。我強烈反對這種新的、輕量級并且不被任何正式的主流開發(fā)方法學(xué)支持(也許是我自己這么認為)的方法。但是當(dāng)Ken Schwaber開始培訓(xùn)我們的軟件項目管理者和軟件開發(fā)人員的團隊的時候,我的看法發(fā)生了劇烈的顛倒。作為虔誠的:PMP信徒,又或許是仍然對軟件開發(fā)相對陌生的原因,一開始我對。Ken教我們的自我管理團隊和迭代式開發(fā)抱有一絲疑惑。隨著我沉浸其中并接受了兩天的“ScrumMaster”培訓(xùn)之后,最吸引我注意力的地方是“你沒有權(quán)力”。Ken的意思是說產(chǎn)品的所有人和產(chǎn)品的交付團隊這兩個角色在本質(zhì)上應(yīng)該是相互協(xié)作的,項目管理者在Scrum方法中并不是決策者。像唱頌歌一樣,我反復(fù)思考這一問題,想知道我是否能夠習(xí)慣和適應(yīng)這個觀點。我不停地思考:“沒有權(quán)力怎么管理項目或人員呢?在項目中采取強制性手段并且要求人們加班工作和周末工作(但是要承諾未來請他們吃免費餡餅)是一個先決條件嗎?隨著項目團隊變得日益龐大和行動緩慢,是不是意味著可以更容易地迫使他們屈服?”

編輯推薦

《軟件項目管理與敏捷方法》:兩位資深培訓(xùn)師構(gòu)建了一座從傳統(tǒng)開發(fā)方法轉(zhuǎn)換到敏捷開發(fā)方法的橋梁。他們深入講解了項目管理者如何成功轉(zhuǎn)換到敏捷開發(fā)方法,這種轉(zhuǎn)換是通過對“推動和協(xié)作”的重新關(guān)注實現(xiàn)的,而不是通過“命令和控制”實現(xiàn)的。作者解釋了敏捷開發(fā)方法與傳統(tǒng)方法學(xué)之間的區(qū)別和這種方法的優(yōu)點以及在現(xiàn)實世界中的應(yīng)用效果,詳細論述了敏捷方法學(xué)中的過程和生命周期,涉及從項目范圍、時間管理到成本管理,以及和利益相關(guān)者溝通等諸多主題?!盾浖椖抗芾砼c敏捷方法》主要內(nèi)容:《PMBOK Guide》中的思想和敏捷開發(fā)實踐之間的關(guān)系。理解敏捷開發(fā)方法的角色和價值,例如迭代/發(fā)布計劃和回顧等。采用敏捷技術(shù)持續(xù)和系統(tǒng)地降低風(fēng)險。在開發(fā)各個階段實施質(zhì)量保證(QA):分析、設(shè)計、缺陷預(yù)防和持續(xù)改進。學(xué)會信任項目團隊并傾聽他們的聲音。在敏捷、協(xié)作的開發(fā)環(huán)境中實施采購、購買和簽訂合同。軟件項目團隊轉(zhuǎn)換到敏捷方法時如何避免常見的錯誤。同項目管理辦公室和非敏捷項目團隊進行協(xié)調(diào)。在自己的項目團隊或組織中“推銷”敏捷開發(fā)方法?!盾浖椖抗芾砼c敏捷方法》適用于每一位希望自己更敏捷的項目管理者。

圖書封面

圖書標簽Tags

評論、評分、閱讀與下載


    軟件項目管理與敏捷方法 PDF格式下載


用戶評論 (總計4條)

 
 

  •   剛拿到書,隨便翻開到91頁,看了一遍“真實的評估”,結(jié)果,語言不通?!捌渲?1個組都要交付一個對遺留系統(tǒng)的重新改寫。”這絕對是一個病句,所有中國字都認識,但你就不是能知道是什么意思。我猜測是想說每一個組都要交付一個對存有遺留問題的系統(tǒng)的一個重新改寫的計劃,或者說最終交付物。另外,邏輯也不通。8月份作項目計劃,項目需要8個月完成,實際次年5月完成項目。文中卻說“最終在5月份完成了全部特性的交付,整整比計劃拖延了9個月……和實際完成情況只偏差了一個月?!弊g者與出版社都很不負責(zé)任。但我相信英文版水平應(yīng)該還是不錯的。有時間和精力的人,我建議直接讀英文版。
  •   感覺還可以,但有些晦澀的翻譯
  •   紙質(zhì)非常薄,從正面可以看到背面的字,非常不爽。
  •   幫朋友買的,據(jù)說不錯。但是亞馬遜現(xiàn)在也玩兒第三方這塊了,漸漸變淘寶第二了。中國特色。呵呵
 

250萬本中文圖書簡介、評論、評分,PDF格式免費下載。 第一圖書網(wǎng) 手機版

京ICP備13047387號-7