描述
开 本: 16开纸 张: 胶版纸包 装: 平装是否套装: 否国际标准书号ISBN: 9787302423935
详述用于估算和计划任何敏捷项目的行之有效的技巧
《敏捷软件开发实践
估算与计划 为对敏捷项目进行估算和计划提供了紧贴实用的权威指导方针。在本书中，敏捷联盟联合创始人Mike Cohn讨论了敏捷估算与计划背后的哲学思想，并通过列举现实世界的例子和项目案例具体展示了如何完成工作。本书*是你开发工具箱中必不可少的敏捷估算“利器”。
本书清晰地阐述了相关概念，并引导读者逐步找到下列问题的答案：将构建什么产品？产品规模多大？需要在何时完成？到那时我们到底能完成多少？你首先会认识到优秀的计划由哪些要素组成，接着会了解到如何才能使计划敏捷化。
采用本书中讲述的方法，你将获得敏捷估算工具，帮助你从始至终保持敏捷、节省时间、充分利用资源并且完成更多工作。本书要点如下：
为什么传统的指令性计划会失败而敏捷计划会取得成功
如何使用故事点和理想人天来预估特性的规模，以及它们分别适用于哪种情形
重设估算的方式和时机
如何同时采用财务及非财务手段来确定特性的优先级
如何将大的特性分解为更小的、更便于管理的特性
如何计划迭代周期并对团队的初始进度进行预估
如何安排具有高度不确定性或进度相关风险的项目的进度
如何对由多个团队合作开发的项目进行估算
本书介绍所有敏捷、半敏捷或者迭代流程，包括Scrum、XP、特性驱动的开发、水晶方法、自适应软件开发、DSDM、统一过程(UP)以及其他许多方式。它无疑是每位研发经理、团队经理和成员不可或缺的宝贵资源。
第Ⅰ部分
问题与目标
第1章
计划的目的 3
1.1 为何要进行估算和计划 4
1.1.1 减少风险 5
1.1.2 降低不确定性 5
1.1.3 提供更好的决策支持 5
1.1.4 建立信任 6
1.1.5 传递信息 6
1.2 优秀的计划是什么 7
1.3 敏捷计划是什么 7
1.4 小结 8
1.5 讨论题 8
第2章
计划失败的原因 9
2.1 基于活动而不是基于特性进行计划 9
2.1.1 活动不会提前完成 10
2.1.2 延误沿着计划表向下传递 10
2.1.3 活动不是互相独立的 11
2.2 多任务处理导致更多的延迟 12
2.3 不按优先级开发特性 13
2.4 忽视了不确定性 13
2.5 把估算当作承诺 14
2.6 小结 14
2.7 讨论题 15
第3章
敏捷方法 17
3.1 项目的敏捷开发方法 18
3.1.1 敏捷团队作为一个整体工作 18
3.1.2 敏捷团队按短迭代周期工作 19
3.1.3 敏捷团队每次迭代交付一些成果 19
3.1.4 敏捷团队关注业务优先级 20
3.1.5 敏捷团队进行检查和调整 21
3.2 敏捷计划方法 21
3.2.1 计划的不同层次 22
3.2.2 满意条件 23
3.3 小结 25
3.4 讨论题 25
第Ⅱ部分
估 算 大 小
第4章
使用故事点估算大小 29
4.1 故事点是相对的 29
4.2 速度 31
4.3 小结 33
4.4 讨论题 33
第5章
使用理想人天进行估算 35
5.1 理想时间和软件开发 36
5.2 以理想人天作为对大小的度量 37
5.3 给出一个而不是多个估算值 37
5.4 小结 38
5.5 讨论题 38
第6章
估算方法 39
6.1 共同估算 40
6.2 估算的尺度 41
6.3 得到估算值的方法 42
6.3.1 专家意见 43
6.3.2 类比 43
6.3.3 分解 43
6.4 计划扑克 44
6.4.1 更小规模的会议 45
6.4.2 何时玩计划扑克 45
6.5 为什么计划扑克会有效 46
6.6 小结 46
6.7 讨论题 47
第7章
重估 49
7.1 SwimStats Web站点 49
7.2 不进行重估的情况 50
7.3 需要重估的情况 51
7.3.1 场景1：不进行重估 52
7.3.2 场景2：重估完成的故事 52
7.3.3 场景3：相对大小改变时进行重估 52
7.4 重估部分完成的故事 52
7.5 重估的目的 53
7.6 小结 53
7.7 讨论题 54
第8章
在故事点和理想人天之间进行选择 55
8.1 有利于故事点的考虑因素 55
8.1.1 故事点有助于驱动跨功能的行为 55
8.1.2 故事点估算不会过期 56
8.1.3 故事点是对大小的纯粹度量 56
8.1.4 故事点估算通常更快 57
8.1.5 我的理想人天不等于你的理想人天 57
8.2 有利于理想人天的考虑因素 58
8.2.1 理想人天在团队以外更容易解释 58
8.2.2 理想人天估算更容易开始 58
8.2.3 理想人天便于预测速度 58
8.3 建议 58
8.4 小结 59
8.5 讨论题 59
第Ⅲ部分
为价值制定计划
第9章
确定主题的优先级 63
9.1 确定优先级时的因素 63
9.1.1 价值 64
9.1.2 成本 64
9.1.3 新知识 65
9.1.4 风险 66
9.2 综合4个因素 68
9.3 一些例子 68
9.3.1 基础设施 68
9.3.2 用户界面设计 69
9.4 小结 69
9.5 讨论题 70
第10章
确定经济优先级 71
10.1 收入的来源 72
10.1.1 新收入 73
10.1.2 增量收入 73
10.1.3 留存收入 73
10.1.4 操作效率 73
10.2 例子：WebPayRoll 74
10.2.1 计算新收入 74
10.2.2 计算增量收入 75
10.2.3 计算留存收入 76
10.2.4 计算操作效率 76
10.2.5 估算开发成本 77
10.2.6 整合 78
10.3 经济指标 78
10.3.1 金钱的时间价值 79
10.3.2 净现值 79
10.3.3 内部收益率 80
10.3.4 投资回收期 82
10.3.5 折现回收期 83
10.4 对利润的比较 83
10.5 小结 84
10.6 讨论题 84
第11章
确定渴望度优先级 85
11.1 客户满意度的Kano模型 85
11.2 相对权重：另一种方法 89
11.3 小结 91
11.4 讨论题 91
第12章
分解用户故事 93
12.1 何时分解用户故事 93
12.2 按照数据边界分解 94
12.3 按照操作边界分解 95
12.4 去除横切考虑 96
12.5 忽略满足性能限制 97
12.6 分解具有混合优先级的用户故事 97
12.7 不要把故事分解成任务 97
12.8 避免相关变化的诱惑 98
12.9 组合用户故事 98
12.10 小结 98
12.11 讨论题 99
第Ⅳ部分
进 度 计 划
第13章
发布计划精粹 103
13.1 发布计划 103
13.1.1 确定满意条件 105
13.1.2 估算用户故事 105
13.1.3 选择迭代周期长度 105
13.1.4 估算速度 105
13.1.5 确定用户故事优先级 105
13.1.6 选择用户故事和发布日期 106
13.2 更新发布计划 107
13.3 例子 107
13.3.1 确定满意条件 108
13.3.2 估算大小 108
13.3.3 选择迭代周期长度 108
13.3.4 估算速度 109
13.3.5 确定用户故事优先级 109
13.3.6 选择用户故事 109
13.4 小结 110
13.5 讨论题 110
第14章
迭代计划 111
14.1 迭代计划时不分配任务 113
14.2 迭代计划和发布计划的区别 113
14.3 速度驱动的迭代计划 114
14.3.1 调整优先级 115
14.3.2 确定目标速度 116
14.3.3 确定迭代目标 116
14.3.4 选择用户故事 116
14.3.5 把用户故事分解成任务 117
14.3.6 对任务进行估算 119
14.4 承诺驱动的迭代计划 121
14.5 我的建议 124
14.6 任务估算值和故事点的联系 124
14.7 小结 126
14.8 讨论题 126
第15章
选择迭代长度 127
15.1 选择迭代长度时考虑的因素 127
15.1.1 发布的总时间长度 127
15.1.2 不确定性的多少 128
15.1.3 获得反馈的难易程度 128
15.1.4 优先级可以保持多久不变 128
15.1.5 在没有外部反馈之下进行工作的意愿 129
15.1.6 迭代的系统开销 129
15.1.7 紧迫感维持 130
15.2 做出决策 130
15.3 两个案例分析 131
15.3.1 Napa项目 131
15.3.2 Goodman项目 132
15.4 小结 133
15.5 讨论题 133
第16章
估算速度 135
16.1 使用历史值 135
16.2 进行一次迭代 137
16.3 做出预测 138
16.3.1 估算可用小时数 138
16.3.2 估算一次迭代中可用的时间 139
16.3.3 扩展故事并填满可用工作时长 139
16.3.4 围绕着估算值设置一个范围 140
16.3.5 某些团队的变通方法 140
16.4 选择合适的方法 141
16.5 小结 141
16.6 讨论题 142
第17章
不确定性缓冲计划 143
17.1 特性缓冲区 144
17.2 进度缓冲区 144
17.2.1 在估算值中反映不确定性 145
17.2.2 调整项目缓冲区大小 148
17.2.3 更简单的缓冲区计算方法 150
17.2.4 缓冲区准则 150
17.3 结合多个缓冲区 150
17.4 进度缓冲区不是填料 151
17.5 一些警告 152
17.6 小结 152
17.7 讨论题 153
第18章
计划多团队项目 155
18.1 为估算建立共同基准 155
18.2 更早给用户故事添加细节 156
18.3 前瞻性计划 157
18.4 在计划中加入馈送缓冲区 158
18.4.1 缓冲的对象 159
18.4.2 确定馈送缓冲区的大小 159
18.5 工作量会很大 160
18.6 小结 160
18.7 讨论题 161
第Ⅴ部分
跟踪与交流
第19章
监督发布计划 165
19.1 对发布进行跟踪 165
19.2 发布燃尽图 167
19.3 停车场图 171
19.4 小结 172
19.5 讨论题 172
第20章
监督迭代计划 173
20.1 任务板 173
20.2 迭代燃尽图 175
20.3 跟踪已完成的工作量 176
20.4 个人速度 177
20.5 小结 177
20.6 讨论题 177
第21章
关于计划的沟通 179
21.1 就计划进行沟通 180
21.2 就进度进行沟通 181
21.3 迭代结束总结 183
21.4 小结 186
21.5 讨论题 186
第Ⅵ部分
敏捷计划有效的原因
第22章
敏捷计划有效的原因 189
22.1 经常重新计划 189
22.2 对大小和持续时间的估算是独立的 190
22.3 在不同层次上制定计划 190
22.4 基于特性而不是基于任务制定计划 191
22.5 小故事保持工作流畅 191
22.6 每次迭代都要消除未完工的工作 191
22.7 在团队层次跟踪 192
22.8 承认不确定性并为之计划 192
22.9 敏捷估算和计划的12条指导原则 192
22.10 小结 194
22.11 讨论题 194
第Ⅶ部分
案 例 分 析
第23章
案例分析：Bomb Shelter Studio 197
23.1 天—— 星期一早上 198
23.2 估算用户故事 204
23.3 准备产品调查 212
23.4 迭代和发布计划，第1轮 214
23.4.1 计划次迭代 215
23.4.2 发布计划 220
23.5 2周后 227
23.6 计划第二次迭代 228
23.7 2周后 230
23.8 修改发布计划 230
23.9 向Phil介绍修改后的计划 232
23.10 18周后 235
本书本来被命名为《估算与计划敏捷项目》。不过，书名终确定为《敏捷软件开发实践 估算与计划》。两者的差异似乎微不足道，但实际上并非如此。现在的书名明确了估算和计划过程本身就应该是敏捷的。不采用敏捷估算和计划，项目就不可能是敏捷的。
本书的大部分内容是关于计划，我把它看作是用来回答“我们要构建什么以及何时完成？”这一问题。但是，要回答关于计划的问题，我们还必须解决关于估算(“它的规模有多大？”)和进度安排(“什么时候能完成？”和“我到那时能得到多少？”)的问题。
本书由7个部分共23章组成。每一章的结尾都有对该章重点的小结和一组讨论题。由于估算和计划应该是整个团队的工作，因此我希望对本书的阅读方式是团队成员每周聚在一起，对看过的内容以及每章结尾的讨论题进行讨论。由于敏捷软件开发在全世界都受到欢迎，因此尽可能避免让本书显得过分以美国为中心。为了达到这一目的，我使用了一种通用的货币单位，将金额写作500“币”，而不是500美元或者500欧元。
本书的第I部分介绍了计划为什么重要、我们常会遇到的问题，以及敏捷方法的目标。第1章是本书的起始，介绍了计划的目的、一个优秀的计划由哪些部分组成，以及什么才是敏捷计划。第2章中介绍了为什么传统估算和计划方法是导致结果难以令人满意的重要原因。后，第3章首先简要地重述了敏捷的含义，然后概括介绍了本书其他部分在不同层次上所采取的敏捷估算和计划方法。
本书的第II部分介绍了估算的一个主要原则，即对大小和时间长度的估算应该相互独立。第4和第5章介绍了两个适用于对要开发的特性大小进行估算的计算单位：故事点和理想人天。第6章讲述了采用故事点和理想人天进行估算的技巧，并包括了对计划扑克的介绍。第7章讲述了何时以及如何进行重新估算。第8章则提供了有关如何在故事点和理想人天之间进行选择的建议。
第III部分“为价值进行计划”提供的建议告诉项目团队如何确认他们正在构建尽可能好的产品。第9章介绍了在确定特性的优先级时需要综合考虑的一些因素。第10章展示了对特性或特性集合的财务回报进行建模的一种方法，以及如何对财务回报进行比较以便开发团队首先处理价值的特性。第11章主要讲述有关如何评估产品用户对各个特性的需求程度并确定其优先级的建议。第12章对本部分进行总结，给出了一些建议，帮助将大的特性分解成更小的、更易管理的特性。
在第IV部分中，我们将注意力转移到了有关项目时间进度安排的方面。第13章首先讨论了对一个相对简单的、单一开发团队的项目安排进度表时所涉及的步骤。第14章讨论了如何制定迭代的计划。第15章和第16章讨论了如何选择合适的迭代周期长度以及如何估算开发团队的初始速率。第17章详述了如何安排一个具有很高不确定性的或是在时间进度上很可能出错的项目的进度表。第18章是这一部分的结尾，讲述了对由多个团队共同开发的项目进行估算和计划所必需的其他步骤。
一旦建立了计划，团队就必须和整个公司的其他部门进行交流，并根据计划进度对开发团队的进度进行监督。这是第V部分的3章的主要内容。第19章主要关注对发布计划进行监督，而第20章关注对迭代计划进行监督。这一部分的后一章，第21章主要解决如何就计划及其进度进行沟通。
第22章是第VI部分的一章。这一章与第2章讲述的“为什么传统方法会失败”相对照，讨论了为什么敏捷估算和计划方法会有效。
第VII部分是全书的后一部分，也只有一章。第23章是一个展开的案例分析，以小说的形式重述了本书的重点。
“你的项目进展顺利吗？对需求变更感到沮丧？前途未卜？产品质量不佳，又延误了截止期限？Mike Cohn极富洞察力，他清晰明了地展示了如何有效地开发具有卓越业务价值的软件。通过阅读本书，你可将精力专注于真正关键的行动，当环境条件变化时也将继续如此。”
——Rick Mugridge，Rimu Research有限公司总监，Fit for Developing Software 的作者
“我们是本书所述敏捷方法的忠实信徒，通过实践和持续采用这些方法，获得了许多极其重要的积极影响。我强烈向有志于使软件开发更可行、更有效的所有读者推荐此书。”
——Mark M. Gutrich，Fast 401k公司总裁兼首席执行官
评论
还没有评论。