本书简要阐明软件开发过程中敏捷方法的工作原理、优点及应用效果，论述敏捷方法学中的过程和生命周期，涉及项目范围、时间管理、成本管理等。主要内容还包括：“PMBOK　Guide”中的思想和敏捷开发实践之间的关系，采用敏捷技术降低风险，在软件开发各个阶段实施质量保证(QA)等。本书适合软件开发人员和管理人员参考。

软件项目管理与敏捷方法
（美）　Michele Sliger
Stacia Broderick　著
李晓丽 李虎 赵华　等译

两位资深培训师构建了一座从传统开发方法转换到敏捷开发方法的桥梁。他们深入讲解了项目管理者如何成功转换到敏捷开发方法，这种转换是通过对“推动和协作”的重新关注实现的，而不是通过“命令和控制”实现的。
作者解释了敏捷开发方法与传统方法学之间的区别和这种方法的优点以及在现实世界中的应用效果，详细论述了敏捷方法学中的过程和生命周期，涉及从项目范围、时间管理到成本管理，以及和利益相关者沟通等诸多主题。　　
本书主要内容：
《PMBOK Guide》中的思想和敏捷开发实践之间的关系
理解敏捷开发方法的角色和价值，例如迭代/发布计划和回顾等
采用敏捷技术持续和系统地降低风险
在开发各个阶段实施质量保证（QA）：分析、设计、缺陷预防和持续改进
学会信任项目团队并倾听他们的声音
在敏捷、协作的开发环境中实施采购、购买和签订合同
软件项目团队转换到敏捷方法时如何避免常见的错误
同项目管理办公室和非敏捷项目团队进行协调
在自己的项目团队或组织中“推销”敏捷开发方法

本书适用于每一位希望自己更敏捷的项目管理者。

作者简介
Michele Sliger　是Sliger Consulting公司的老板。该公司的咨询业务涉及从初创的公司到财富500强公司，帮助组织采纳敏捷方法。Michele是stickyminds.com上的定期撰稿人，她拥有项目管理专业人员资格（PMP）认证和Scrum培训师认证（CST）资质，并获得MBA学位。
Stacia Broderick　创建了AgileEvolution公司，目的是帮助其他公司以更人性化、更合理的方式采纳敏捷开发实践。Stacia是具有丰富经验的敏捷教练，并且同时拥有项目管理专业人员资格（PMP）认证和Scrum培训师认证（CST）资质。

我们致力于软件开发方法中的敏捷开发实践(我们也被人们称为敏捷开发人员)，但是我们的软件开发生涯并不是以这种方法学开始的。我们最开始是项目管理专业人员(PMP) [1]，在软件开发中采用更为传统的方法。
为什么要写这本书
　　在大部分职业生涯里，我们都遵循项目管理研究所(PMI)的《A Guide to the Project Management Body of Knowledge，Third Edition》(后文简写作《PMBOK Guide》) 中的方法学, 在使用敏捷方法的过程中我们越来越清楚地意识到与这本书的主题有关的一些误区——一些我们曾经相信但不正确的思想。直到现在，作为敏捷方法的咨询师，我们仍然能听到一些客户说他们相信(这是不正确的)如果要保持PMP资格并且遵循《PMBOK Guide》中的实践，就必须采用类似瀑布模型的软件开发方法学。我们还听到一些错误的观点，认为敏捷方法缺乏纪律性和严格性。我们看到一些人带有恐惧和失望情绪，因为他们觉得如果遵循敏捷方法的路线，那么之前在PMI上的投资可能会付诸东流。
　　本书的目标是消除这些疑虑，并说明《PMBOK Guide》第3版确实支持敏捷软件开发方法，项目管理者在PMI上的投资和《PMBOK Guide》所列的实践仍然有效并且适宜采用。我们认为《PMBOK Guide》处于方法学的中立位置，无论选用了哪种软件开发方法，它都支持良好的软件开发方法学实践。尽管许多人知道这个事实，但是还有许多人并不知道。我们曾经是PMP的追随者，现在成了敏捷开发的狂热分子。我们认为另一个重要的问题是如何消除敏捷开发群体认为PMP从业者不能成为好的敏捷开发项目管理者的误解。我们希望建造一座两者之间沟通的桥梁——这便是本书想要做的事。
本书的内容和结构
　　在本书的第二部分，我们深入细节来说明与这座桥梁有关的问题，该桥梁在《PMBOK Guide》的实践和敏捷开发实践之间建立了映射关系。我们的目的是告诉项目管理者，在转向敏捷开发方法学时，他们并没有脱离PMI推荐的实践——他们仅仅是用另一种不同的方式来实施这些实践并确保这些实践背后隐藏的目的仍然是真实有效的。在一些章节中，两者之间可能存在明确的映射关系，但是在另一些章节中，这种映射关系可能不那么精确。本书的目的是成为一部指南，一个让读者将已经熟悉的词汇运用于一种新型软件开发方法的工具。本书并不能替代目前市场上任何专门介绍敏捷开发实践的书籍，我们鼓励读者额外阅读一些介绍敏捷开发具体方法(如Scrum、XP、Lean、Crystal等)的书籍。
　　下面将对本书的主要内容进行快速预览。
　　第一部分敏捷开发方法概述
　　本书的第一部分介绍敏捷软件开发的基本概念和术语。第1章首先回顾了软件开发史上的敏捷开发思想。读者可能会惊奇地发现，即使Winston Royce关于瀑布方法的文章中也推荐使用一个迭代的周期以及推荐最终用户参与项目全过程。在回顾了这段历史之后，我们开始介绍敏捷宣言(Agile Manifesto)背后隐藏的概念及有关的基本原则，它们是所有敏捷软件开发框架的基础。
　　第2章将考察PMI的历史及其对项目管理实践最重要的贡献，即《PMBOK Guide》这本书。同时我们将研究《PMBOK Guide》中描述的项目生命周期阶段和项目管理过程组如何与敏捷开发过程关联。此外我们还将反复阐明，敏捷开发人员也同时能够遵循《PMBOK Guide》中推荐的实践。
　　第3章将介绍敏捷项目生命周期(从发布计划到迭代计划再到日常计划)，以及在每个迭代周期结束时的演示、评审和回顾等活动如何让项目团队持续改进。从这一章开始，将介绍本书后面各章所要用到的概念和术语。
　　第二部分桥梁——《PMBOK Guide》中的实践和敏捷开发实践的关系
　　这一部分将回顾《PMBOK Guide》中的各个知识域，并讨论作为一名传统的项目管理者过去是如何工作的，以及敏捷方法的项目管理者应该考虑的问题。我们试图在传统方法和敏捷方法之间建造一座显式的桥梁，指导读者理解应该替换(或保留)什么任务或活动。
　　在《PMBOK Guide》中，各个知识域的编排没有按照任何形式的时间次序，本书同样如此。在传统方法和敏捷方法的项目设置中，你都将发现其中的大部分活动是并行的。
　　由于有关知识内容安排存在一定的重叠，你可能会发现一些概念和思想是重复介绍的。这是我们有意安排的，因为我们期望大部分读者能够把本书的这一部分当做一部参考指南来使用，因此每一章及其中的内容都是任意编排的。尽管如此，为了尽可能地减少重复内容，我们采用了引用其他章节的方法而不是重新介绍这些章节的内容。
　　第二部分包括下列几章：
　　 第4章集成管理
　　 第5章范围管理
　　 第6章时间管理
　　 第7章成本管理
　　 第8章质量管理
　　 第9章人力资源管理
　　 第10章沟通管理
　　 第11章风险管理
　　 第12章采购管理
　　第三部分跨过通向敏捷方法的桥梁
　　本书的第二部分涵盖了具体的、实用的行动变更，第三部分将介绍作为一个改革的推动者所需要的软技巧，以及这种变更对读者个人和职业生涯意味着什么。本书的第二部分回答了大量诸如“你需要做什么……”之类的问题，第三部分则将关注焦点转移到“如何实施这样的变更”。这些变更包括角色的变更、如何与不采用敏捷方法的团队打交道、需要注意什么等，我们逐一回答那些准备跨越桥梁的人提出的常见问题。第三部分构成了本书的主体内容，包括以下几章：
　　 第13章如何变更职责
　　 第14章如何与不采用敏捷方法的团队共事
　　 第15章项目管理办公室如何支持敏捷开发方法
　　 第16章推销敏捷开发方法的优点
　　 第17章常见错误
　　附录
　　本书包含了两个附录，我们希望对读者有用。附录A列举了一些属于敏捷开发方法的具体软件开发方法学。附录B介绍了敏捷开发项目产生的典型“制品”。
读者对象
　　尽管本书的目标读者定位于那些属于PMI成员的软件项目管理者，但是任何从事传统软件项目管理的人仍然能够从本书获益。他们能够在本书中了解到敏捷开发的一些术语，而过去他们都很熟悉这些术语。在本书中，我们将那些已经成熟应用的软件开发方法学称为“瀑布”、“计划驱动”或“传统”的方法学，它们指的是那些顺序的、分阶段的、非迭代式的软件开发方法。
最后几点说明
　　我们必须阐明一点，这就是我们没有获得PMI或任何其代表的批准。本书的内容是作者的研究、理解和经验所取得的成果。尽管在研究中采用的是《PMBOK Guide》的第3版，不过我们预期《PMBOK Guide》 将会做出进一步的修订，在修订后的版本中读者仍然会找到本书中介绍的基本概念。
尾注
　　［1］“PMP”、“PMI”和《PMBOK Guide》是项目管理研究所(Project Management Institute, PMI)的注册商标。
致谢
　　本书的作者希望对下列人员共同表示感谢，他们帮助作者使本书的出版成为现实：
　　 《Better Software》杂志和StickyMindscom网站的编辑，特别是Lee Copeland和Francesca Matteu。本书最初是一本白皮书， 2005年在San Francisco的Better Software会议上获得资助，相继在StickyMindscom网站上发表了一系列文章。Lee、Francesca和该组织的所有编辑帮助我们成为了更好的作者。
　　 Mike Cohn, 他在写作和出版本书的整个过程中给予我们鼓励并提供了一些关于章节的早期反馈意见。
　　 Dennis Bolles、Ted Boccuzzi、Greg Githens、Kent McDonald，还有Bob Tarne, 他们是本书的审阅者，花费了大量时间和做了很多努力与我们沟通意见，交流想法。
　　 敏捷开发的教员和培训师，他们在这本书没有出版之前就开始参考本书的内容。
　　 数量众多的项目团队，他们为我们提供了如此多的学习经验，并且允许我们把自己的经验与他们共享。
　　Michele Sliger希望感谢:
　　 Jean Tabaka，他教会我懂得协作和帮助他人的重要性。
　　 Rally Software 公司的员工们，他们促使我成长、竞争、观察和适应。
　　 我的敏捷开发顾问Mike Cohn和Scrum方法的合作伙伴Alicia Yanik，无论我的问题多么狂热，他们总是能够和蔼地回答。
　　 我最好的朋友Shelly Wilbanks,感谢她不断给予的鼓励和支持。
　　 “Judi之家”的孩子们——他们提醒我什么是真正重要的，并且不停地促使我想知道自我管理团队和人类灵魂中敏捷性思想的强大威力。
　　 Stacia, 感谢她完成了本书中较难的几章。
Stacia Broderick希望感谢:
　　 我的丈夫Mike Broderick，还有Bodie Broderick,一只总是面带笑容、摇着尾巴的小狗。
　　 Ken Schwaber,他指导我度过绝望的时期。
　　 Bob Schatz, 他教会我如何成为一位领导者。
　　 我的家人，他们忍受我缺席家庭事务和家庭聚会。能够回到家人中间是一件愉快的事情。
　　 我的胜利女神, 帮助我整理思路并清理大脑。
　　 Michele,他编写了较难的几章。

本书的两位资深培训师构建了一个从传统开发方法转换到敏捷开发方法的桥梁。深入讲解了项目管理者如何成功转换到敏捷开发方法，这种转换是通过对“推动和协作”的重新关注实现的，而不是通过“命令和控制”实现的。
　　作者解释了敏捷开发方法与传统方法学之间的区别和这种方法的优点以及在现实世界中的应用效果。详细论述了敏捷方法学中的过程和生命周期，涉及从项目范围、时间管理到成本管理，以及和利益相关者沟通等诸多主题。　　
本书主要内容
《PMBOK Guide》中的思想和敏捷开发实践之间的关系
理解敏捷开发方法的角色和价值，例如迭代/发布计划和回顾等
采用敏捷技术持续和系统地降低风险
在开发各个阶段实施质量保证(QA)：分析、设计、缺陷预防和持续改进
学会信任项目团队并倾听他们的声音
在敏捷、协作的开发环境中实施采购、购买和签订合同
软件项目团队转换到敏捷方法时如何避免常见的错误
同项目管理办公室和非敏捷项目团队进行协调
在自己的项目团队或组织中“推销”敏捷开发方法

本书适用于每一位希望自己更敏捷的项目管理者。

（美）Michele Sliger; Stacia Broderick　著：Michele Sliger是Sliger Consulting公司的老板。该公司的咨询业务涉及从初创的公司到财富500强公司，帮助组织采纳敏捷方法。Michele 是stickyminds.com上的定期撰稿人，她拥有项目管理专业人员资格(PMP)认证和Scrum培训师认证(CST)资质，并获得MBA学位。　　Stacia Broderick创建了AgileEvolution公司，目的是帮助其他公司以更人性化、更合理的方式采纳敏捷开发实践。Stacia是具有丰富经验的敏捷教练，并且同时拥有项目管理专业人员资格(PMP)认证和Scrum培训师认证(CST)资质。

李晓丽 李虎 赵华 等译：暂无简介

敏捷软件开发是20世纪90年代逐渐引起广泛关注的一些新型软件开发方法的总称。这些开发方法的具体名称、理念、过程、术语都不尽相同，但是它们都强调软件开发团队与业务专家之间的紧密协作，面对面的沟通（认为比书面的文档更有效），迭代交付新的软件版本、紧凑且自我管理的团队，能够很好地适应需求变化的代码编写和团队组织方法。敏捷方法虽然在过程和手段上与一些传统方法有很多相似之处，比如迭代的开发模式、注重软件的质量等，但是它和传统软件开发方法也有明显的不同。敏捷软件开发以交付而不是构造为核心，敏捷软件开发方法强调交付给客户有价值的软件，而不是用户需求中所描述的软件。
　　本书介绍了敏捷软件开发的基本思想及其与传统的“计划驱动”的软件开发方法学之间的异同，系统地总结了敏捷软件开发方法的优点和应用效果。本书的重点是论述项目管理研究所(PMI)的《A Guide to the Project Management Body of Knowledge（PMBOK Guide），Third Edition》中介绍的软件项目管理实践与敏捷软件开发方法和开发实践之间的关系，建立两者之间的桥梁。本书内容广泛，包括了项目管理中所有重要的主题，同时还包含了作者多年从事软件开发和项目管理的经验总结，为软件项目管理人员转换到敏捷方法提供了理论参考和实践指南。本书适用于高等院校相关专业的师生作为辅助教材或参考读物，更适用于每一位工程项目管理人员尤其是参与到敏捷开发方法中或对敏捷开发感兴趣的管理人员和工程技术人员。
　　本书的三位译者均长期从事软件工程和软件开发方法学的教学和科研实践工作，在软件开发过程、软件项目管理等领域积累了一定的学术成果和工程经验，为了促进国内同行在这一领域的学习和交流，特意组织翻译了此书。本书的主要内容由李晓丽、李虎翻译，赵华也承担了部分翻译工作，全书由李虎统校。参加本书技术校对的还有许福、宋淼、王晓博、刘辉、贾荣飞等。机械工业出版社华章分社的编辑均为本书付出了辛勤劳动，在此向他们表示诚挚的感谢！
　　由于译者水平有限，书中疏漏和错译之处在所难免，敬请广大读者批评指正。

译者序
前言
作者简介
绪论项目管理者如何跨过桥梁
第一部分敏捷开发方法概述
第1章敏捷方法
11敏捷方法的起源
12敏捷宣言
121个体和交互胜过过程和工具
122可工作的软件胜过全面的文档
123同客户的协作胜过合同谈判
124对变更的响应胜过遵循计划
13指导敏捷项目团队的敏捷原则
14小结
15尾注
第2章《PMBOK Guide》到敏捷方法的映射
21项目管理研究所和《PMBOK Guide》
22项目生命周期
23项目管理过程
24小结
25尾注
第3章敏捷项目生命周期详解
31敏捷项目生命周期概览
32敏捷项目
33敏捷发布
34敏捷迭代
341迭代计划
342迭代评审
343迭代回顾
35例行工作
36敏捷方法和计划驱动方法之间的区别
37小结
38尾注
第二部分桥梁——《PMBOK Guide》中的实践和敏捷开发实践的关系
第4章集成管理
41开发项目章程和初步的范围陈述
411宣贯会议
412简要比较
42开发项目管理计划
43指导和管理项目的执行、监视和控制项目工作
44集成的变更控制
45结束项目
46小结
47尾注
第5章范围管理
51范围计划
511范围定义
512创建WBS
513范围验证
514范围控制
52小结
53尾注
第6章时间管理
61战略计划VS战术计划
62发布计划:开发战略层面的时间进度计划
621发布计划：在战略层面开发时间进度计划
622发布计划: 战略层面上的时间进度控制
63迭代计划: 开发战术层面的时间进度计划
631活动定义
632活动持续时间评估
633活动排序
634活动资源评估
635迭代计划：战术层面的时间进度计划控制
64小结
65尾注
第7章成本管理
71成本评估
711敏捷项目的成本最好由产品交付团队进行评估
712敏捷项目是自顶向下评估而不是自底向上评估
713项目团队在发布计划期间可以给出选项
714成本评估在项目生命周期中逐步细化
72成本预算
73成本控制
731管理发布待完成事项列表
732锁定迭代
733将成本的变更情况通知给利益相关人
734度量成本性能的AgileEVM
74小结
75尾注
第8章质量管理
81质量计划
82质量保证
821演示、评审和回顾
822质量控制
83小结
84尾注
第9章人力资源管理
91人力资源规划
92组建项目团队
93发展项目团队
931敏捷价值观
932从价值观到行为
94管理项目团队
95小结
96尾注
第10章沟通管理
101沟通计划
102沟通基本项目信息——谁、什么、何时、何地和怎样
103信息发布
1031迭代演示和评审会议
1032通过每日站立会议进行交流
1033回顾
1034实时信息指示器
104业绩报告
105利益相关者管理
106小结
107尾注
第11章风险管理
111敏捷开发方法中的有机风险管理
1111消除进度表固有的缺陷
1112缓解规格故障
1113减轻范围蔓延的影响
1114缓解人员流失
1115缓解生产率变化
112风险管理规划
113风险识别
114风险分析
115风险应对规划
116风险监测和控制
117小结
118尾注
第12章采购管理
121采购规划
122合同规划
123要求卖方回应
124选择卖家
125合同管理
126合同结束
127小结
128尾注
第三部分跨过通向敏捷方法的桥梁
第13章如何变更职责
131允许团队进行自我管理并且根据经验调整开发过程
132在团队的不同阶段采用不同的管理方式
133服务式领导
134具有自我意识的能力
135为了团队与其他经理合作
136放弃内部管理
137促进合作
138清除障碍
139小结
1310尾注
第14章如何与不采用敏捷方法的团队共事
141在瀑布开发模式的公司中以敏捷开发团队方式工作
1411整合传统开发过程的前端需求
1412整合传统开发过程的最终需求
1413在敏捷开发过程中集成传统过程需求
142敏捷开发团队与非敏捷开发团队在同一个项目中共事
143了解瀑布式开发中的障碍
1431反对
1432文化
1433资源管理
1434供应商和承包商
1435设施和工具
1436成本计算和汇报
1437审核人员和评估人员
1438沟通
144小结
145尾注
第15章项目管理办公室如何支持敏捷开发方法
151产品管理的延伸
152项目启动
153我们符合标准吗
154资源分配
155待完成事项列表操控和变更操控
156项目度量标准
157PMO作为培训者和教练员
158回顾管理员
159谁是敏捷PMO
1510是否真的需要敏捷PMO
1511小结
1512尾注
第16章推销敏捷开发方法的优点
161推销常识
162推销给团队
1621会议太多了
1622整体估计没有意义
1623如果不进行任何技术上的计划会议，整个架构就会失败
1624不在同一地点办公，所以不能进行敏捷开发
1625一些潜在的原因
163推销给项目管理者
1631敏捷开发中没有长期计划，如何进行预算呢
1632现在就挺好的，为什么要改变
1633我们的情况太复杂了，不适用敏捷开发
1634为获得最高效率，需要对资源进行矩阵化
1635不相信员工能进行自我管理
1636没有甘特图，我们如何做出策略决定
164推销给客户和产品负责人
1641签的合同是基于时间和花费的，这样你们就可以不断要钱了
1642在每次迭代中没有足够的时间同团队一起工作
1643我不能为那个产品特性等待整个迭代
165向公司的其他部门推销敏捷开发方法
166其他推销敏捷开发的方法
167小结
168尾注
第17章常见错误
171认为敏捷开发方法就是“无文档”和“牛仔编码”
172认为可以拆分敏捷开发框架的各个部分并获取更高的利益
173认为敏捷开发只适用于工程团队并不适用于公司的其他部门
174没有拥护者
175由错误的人来领导团队
176把死亡行军作为解决方案
177敏捷团队认为：“该得到的时候就会得到。现在已经是敏捷开发，一次只计划一个迭代。”
178敏捷项目管理者认为：“团队已经自我管理，他们可以自己解决任何问题。”
179缺乏业务人员的参与
1710不进行回顾
1711价值观不同
1712小结
附录A敏捷方法
附录B敏捷制品
术语表