软件项目管理与敏捷方法

章节摘录

插图：我是Stacia Broderick，我想讲一个非常私人的、有关我思想转变的故事，希望能够帮助你认识到正视自己想法以及学会如何成长的重要性，尽管这个故事可能令人十分不舒服。我在1993年成为一名项目管理者，2003年开始从事敏捷开发。我还是一名PMP，正式接受过在我之前取得项目管理专业人员资格认证的数千人的培训。在我开始管理项目的时候，我对我的能力带有一丝骄傲，我能学会如何将数据输人到一个项目管理工具中，学会如何举行状态会议，如何同承包商和第三方供应商协商有关资源和材料等事宜，如何减少项目风险，当然，还有如何控制项目的范围。我甚至在睡觉时都能完成向前或向后的推算。项目管理对我来说是一项完美的事业。作为家里的老三，我把项目管理的思想灌输给我的两个姐姐，我们把项目管理运用到每周家务杂活的时间计划上。我甚至还设计了一个过程来削减洗碗的工作量，通过一个批量抽取系统将洗碗机清空（只在需要时取出一个碗并且不再反复使用它，直到重新装碗的时候才一次把碗放进洗碗机），但是我的父亲并不支持这种新方法。对我（一个故步自封的怪物）来说，项目管理是一项完美的事业。我和Scrum的冲突始于2003年，Scrum是敏捷软件开发方法中的一种。我强烈反对这种新的、轻量级并且不被任何正式的主流开发方法学支持（也许是我自己这么认为）的方法。但是当Ken Schwaber开始培训我们的软件项目管理者和软件开发人员的团队的时候，我的看法发生了剧烈的颠倒。作为虔诚的：PMP信徒，又或许是仍然对软件开发相对陌生的原因，一开始我对。Ken教我们的自我管理团队和迭代式开发抱有一丝疑惑。随着我沉浸其中并接受了两天的“ScrumMaster”培训之后，最吸引我注意力的地方是“你没有权力”。Ken的意思是说产品的所有人和产品的交付团队这两个角色在本质上应该是相互协作的，项目管理者在Scrum方法中并不是决策者。像唱颂歌一样，我反复思考这一问题，想知道我是否能够习惯和适应这个观点。我不停地思考：“没有权力怎么管理项目或人员呢？在项目中采取强制性手段并且要求人们加班工作和周末工作（但是要承诺未来请他们吃免费馅饼）是一个先决条件吗？随着项目团队变得日益庞大和行动缓慢，是不是意味着可以更容易地迫使他们屈服？”

前言

我们致力于软件开发方法中的敏捷开发实践（我们也被人们称为敏捷开发人员），但是我们的软件开发生涯并不是以这种方法学开始的。我们最开始是项目管理专业人员（PMP），在软件开发中采用更为传统的方法。为什么要写这本书在大部分职业生涯里，我们都遵循项目管理研究所（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从业者不能成为好的敏捷开发项目管理者的误解。我们希望建造一座两者之间沟通的桥梁——这便是本书想要做的事。

内容概要

《软件项目管理与敏捷方法》作者Michele Sliger拥有丰富的敏捷软件开发经验，她的职业生涯首先是遵循传统的瀑布软件开发方法，在2000年转向Scrum和XP开发方法实践。她是一位自封的“桥梁建筑师”。她的兴趣是帮助传统软件开发环境中的人跨越通向敏捷开发的桥梁。Michele 是Sliger Consulting公司的老板, 该公司的咨询业务涉及从初创的起步公司到财富500强公司，帮助这些公司的项目团队实施敏捷方法，帮助组织为实施敏捷方法而进行变更活动。Michele 经常在一些会议上发言并且在软件界的出版物上发表文章，她还是敏捷原则和价值驱动的开发实践的强力倡导者。她拥有项目管理专业人员资格(PMP)认证和Scrum培训师认证(CST)资质。Michele 获得MIS学位和MBA学位。在不工作的时候，Michele 志愿担任“Judi之家”中十几岁孩子的引导者，帮助这些孩子应对当他们失去亲人时该怎么办。

Stacia Broderick作为一名项目管理者已经有14年的从业经验，14年中的最后8年主要从事软件开发。她是幸运的，2003年在Primavera Systems公司工作期间得到了Ken Schwaber的指导，从而跨越了从传统软件开发方法到敏捷方法的桥梁，从那以后她帮助了世界上数百个团队完成了从传统产品开发方法到敏捷方法的转变。2006年，Stacia自己创建了AgileEvolution公司，坚信敏捷实践是团队和公司交付产品的合理和自然的方法。Stacia 也拥有Scrum培训师和PMP认证,同时拥有这两个资质证明是非常有价值的，可以帮助组织完成从传统方法到敏捷方法实践的转变。Stacia 喜欢跑步、拉小提琴以及和家人待在一起。

书籍目录

对本书的赞誉

译者序

译者简介

Linda Rising的序言

Joe Rainsberger的序言

前言

致谢

作者简介

第一部分对于软件开发的感想

第1章学习是瓶颈

1.1一个假定的实验

1.2透过“学习是瓶颈”看敏捷

1.3识别并响应变化的循环周期

1.4循环周期：充分非必要

1.5为什么这很重要？从理论到实践

1.6关注瓶颈

1.7小结

第2章个体敏捷性

2.1为什么要采纳敏捷实践

2.1.1怎样才算成功的采纳

2.1.2问题：许多敏捷实施案例都不成功

2.1.3什么原因？情况有多种

2.2职责过程模型

2.2.1怎么做才能变得更积极负责

2.2.2要是团队人员不停地抱怨，我该怎么办

2.3有效的敏捷

2.3.1成功的团队拥有积极负责的队员

2.3.2认知和响应变化需要责任心

2.3.3成功的敏捷软件开发从个人做起

2.4个体敏捷性

2.5从理论到实践

第二部分实施敏捷的艺术

第3章业务价值

3.1缩短上市时间

3.2增强产品实用性(市场价值)

3.3提高产品质量

3.4提高灵活性

3.5增强透明度

3.6降低成本

3.7延长产品生命周期

3.8业务价值是组织的目标

3.9从理论到实践：确定组织的业务价值

第4章异味

4.1业务异味

4.1.1交付质量无法令客户接受

4.1.2交付新功能需要太长时间

4.1.3有些功能客户没有使用

4.1.4软件对于客户不适用

4.1.5软件开发过于昂贵

4.1.6我们与他们的对立

4.1.7客户不管三七二十一，什么都要

4.2流程异味

4.2.1客户？什么客户？无法实现直接、经常性地客户参与

4.2.2令管理层惊讶——缺乏透明度

4.2.3瓶颈资源——项目成员同时属于多个团队

4.2.4项目反复拖延

4.2.5bug跟踪系统中有数以百计的bug

4.2.6在发布前需要一个固化周期

4.2.7没能经常集成(通常是因为集成一次太痛苦了)

4.3以痛楚作为激励

4.4从理论到实践：你能找到什么异味

第5章敏捷实施策略

5.1敏捷实践

5.2敏捷模式到业务价值的映射

5.3实施敏捷的艺术

5.4下一步

5.5从理论到实践：制定适用于你的敏捷实施策略

第三部分敏捷实践模式

第6章敏捷实践实施模式

6.1什么是模式

6.2更有效地利用模式

6.3人物介绍

第7章目标

7.1业务价值

7.2小故事

7.3适用情况

7.4阻力

7.5因此

7.6采纳方法

7.7但是

7.8变化

7.9参考文献

第8章周期

8.1业务价值

8.2小故事

8.3适用情况

8.4阻力

8.5因此

8.6采纳方法

8.7但是

8.8变化

8.9参考文献

第三部分(a)反馈实践模式

第9章迭代

9.1业务价值

9.2小故事

9.3适用情况

9.4阻力

9.5因此

9.6采纳方法

9.7但是

9.8变化

9.9参考文献

第10章启动会

10.1业务价值

10.2小故事

10.3适用情况

10.4阻力

10.5因此

10.6采纳方法

10.7但是

10.8变化

10.9参考文献

第11章待办工作项

11.1业务价值

11.2小故事

11.3适用情况

11.4阻力

11.5因此

11.6采纳方法

11.7但是

11.8变化

11.9参考文献

第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参考文献

第14章完成状态

14.1业务价值

14.2小故事

14.3适用情况

14.4阻力

14.5因此

14.6采纳方法

14.7但是

14.8变化

14.9参考文献

第15章演示

15.1业务价值

15.2小故事

15.3适用情况

15.4阻力

15.5因此

15.6采纳方法

15.7但是

15.8变化

15.9参考文献

第16章回顾

16.1业务价值

16.2小故事

16.3适用情况

16.4阻力

16.5因此

16.6采纳方法

16.7但是

16.8变化

16.9参考文献

第17章频繁发布

17.1业务价值

17.2小故事

17.3适用情况

17.4阻力

17.5因此

17.6采纳方法

17.7但是

17.8变化

17.9参考文献

第18章“联合驻扎”团队

18.1业务价值

18.2小故事

18.3适用情况

18.4阻力

18.5因此

18.6采纳方法

18.7但是

18.8变化

18.9参考文献

第19章自组织团队

19.1业务价值

19.2小故事

19.3适用情况

19.4阻力

19.5因此

19.6采纳方法

19.7但是

19.8变化

19.9参考文献

第20章跨职能团队

20.1业务价值

20.2小故事

20.3适用情况

20.4阻力

20.5因此

20.6采纳方法

20.7但是

20.8变化

20.9参考文献

第21章客户作为团队成员

21.1业务价值

21.2小故事

21.3适用情况

21.4阻力

21.5因此

21.6采纳方法

21.7但是

21.8变化

21.9参考文献

第22章唤醒式文档

22.1业务价值

22.2小故事

22.3适用情况

22.4阻力

22.5因此

22.6采纳方法

22.7但是

22.8变化

22.9参考文献

第23章用户故事

23.1业务价值

23.2小故事

23.3适用情况

23.4阻力

23.5因此

23.6采纳方法

23.7但是

23.8变化

23.9参考文献

第24章用例

24.1业务价值

24.2小故事

24.3适用情况

24.4阻力

24.5因此

24.6采纳方法

24.7但是

24.8变化

24.9参考文献

第25章信息辐射器

25.1业务价值

25.2小故事

25.3适用情况

25.4阻力

25.5因此

25.6采纳方法

25.7但是

25.8变化

25.9参考文献

第三部分(b)技术实践模式

第26章自动化测试

26.1业务价值

26.2小故事

26.3适用情况

26.4阻力

26.5因此

26.6采纳方法

26.7但是

26.8变化

26.9参考文献

第27章测试后行开发

27.1业务价值

27.2小故事

27.3适用情况

27.4阻力

27.5因此

27.6采纳方法

27.7但是

27.8参考文献

第28章测试先行开发

28.1业务价值

28.2小故事

28.3适用情况

28.4阻力

28.5因此

28.6采纳方法

28.7但是

28.8变化

28.9参考文献

第29章重构

29.1业务价值

29.2小故事

29.3适用情况

29.4阻力

29.5因此

29.6采纳方法

29.7但是

29.8变化

29.9参考文献

第30章持续集成

30.1业务价值

30.2小故事

30.3适用情况

30.4阻力

30.5因此

30.6采纳方法

30.7但是

30.8变化

30.9参考文献

第31章简单设计

31.1业务价值

31.2小故事

31.3适用情况

31.4阻力

31.5因此

31.6采纳方法

31.7但是

31.8变化

31.9参考文献

第32章功能测试

32.1业务价值

32.2小故事

32.3适用情况

32.4阻力

32.5因此

32.5.1物件清单管理测试

32.5.2自动化功能测试的益处

32.6采纳方法

32.7但是

32.7.1实施异味

32.7.2架构异味

32.8变化

32.9参考文献

第33章集体代码所有权

33.1业务价值

33.2小故事

33.3适用情况

33.4阻力

33.5因此

33.6采纳方法

33.7但是

33.8变化

33.9参考文献

第34章结对编程

34.1业务价值

34.2小故事

34.3适用情况

34.4阻力

34.5因此

34.6采纳方法

34.7但是

34.8变化

34.9参考文献

第三部分(c)辅助实践模式

第35章教练

35.1业务价值

35.2小故事

35.3适用情况

35.4阻力

35.5因此

35.6采纳方法

35.7但是

35.8变化

35.9参考文献

第36章融入敏捷社区

36.1业务价值

36.2小故事

36.3适用情况

36.4阻力

36.5因此

36.6采纳方法

36.7但是

36.8变化

36.9参考文献

第37章读书会

37.1业务价值

37.2小故事

37.3适用情况

37.4阻力

37.5因此

37.6采纳方法

37.7但是

37.8变化

37.9参考文献

第38章研讨会

38.1业务价值

38.2小故事

38.3适用情况

38.4阻力

38.5因此

38.6采纳方法

38.7但是

38.8变化

38.9参考文献

第39章课堂培训

39.1业务价值

39.2小故事

39.3适用情况

39.4阻力

39.5因此

39.6采纳方法

39.7但是

39.8变化

第三部分(d)组合模式

第40章敏捷迭代

40.1业务价值

40.2小故事

40.3适用情况

40.4阻力

40.5因此

40.6采纳方法

40.7但是

40.8变化

40.9参考文献

第41章沟通组合

41.1业务价值

41.2小故事

41.3适用情况

41.4阻力

41.5因此

41.6采纳方法

41.7但是

41.8变化

41.9参考文献

第42章演进式设计

42.1业务价值

42.2小故事

42.3适用情况

42.4阻力

42.5因此

42.6采纳方法

42.7但是

42.8变化

42.9参考文献

第43章测试驱动开发

43.1业务价值

43.2小故事

43.3适用情况

43.4阻力

43.5因此

43.6采纳方法

43.7但是

43.8变化

43.9参考文献

第44章测试驱动需求

44.1业务价值

44.2小故事

44.3适用情况

44.4阻力

44.5因此

44.6采纳方法

44.7但是

44.8变化

44.9参考文献

第四部分案例研究

第45章BabyCenter

45.1BabyCenter敏捷实施——2007年一季度

45.1.1制定敏捷实施策略

45.1.2结论

45.2BabyCenter敏捷实施回访——2008年一季度

第46章X公司

46.1X公司敏捷实施过程——2007年一二季度

46.1.1报告背景

46.1.2当前业务目标

46.1.3硝烟四起

46.1.4建议在2007年余下的日子里实施的实践方法

46.1.5长远考虑

46.1.6结论

46.2X公司敏捷实施——回访

第五部分附录

附录A敏捷模式与业务价值的映射

附录B敏捷模式与异味的映射

附录C充分利用敏捷模式

附录D更多阅读资源

参考文献

编辑推荐

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

作者简介

《软件项目管理与敏捷方法》介绍单个敏捷实践与其他敏捷实践之间的联系，同时讲解制定实施策略的技巧。本书涉及的敏捷模式，不只是作者的个人意见，也不是从未试过的新方法，而是若干真实项目案例的经验总结。本书内容主要分为四部分。第一部分阐述软件开发的基本问题，是其他部分的基础。第二部分是本书的核心——为你的组织选择敏捷实践。第三部分包括反馈实践模式、技术实践模式、辅助实践模式、组合模式四个内容。第四部分分析两个组织实施情况的报告，展示组织如何一步步实施敏捷实践。

本书适合想要学习敏捷或想转向敏捷开发的管理者、开发者、架构师等。对于想要深入全面探讨敏捷实践的人来说，本书也是很好的指南。

---

 软件项目管理与敏捷方法下载

---