敏捷软件开发实践

详述用于估算和计划任何敏捷项目的行之有效的技巧     《敏捷软件开发实践 估算与计划 为对敏捷项目进行估算和计划提供了紧贴实用的非常不错指导方针。在本书中，敏捷联盟联合创始人Mike Cohn讨论了敏捷估算与计划背后的哲学思想，并通过列举现实世界的例子和项目案例具体展示了如何完成工作。本书保证是你开发工具箱中必不可少的敏捷估算“利器”。     本书清晰地阐述了相关概念，并引导读者逐步找到下列问题的答案：将构建什么产品？产品规模多大？需要在何时完成？到那时我们到底能完成多少？你首先会认识到很好的计划由哪些要素组成，接着会了解到如何才能使计划敏捷化。     采用本书中讲述的方法，你将获得敏捷估算工具，帮助你从始至终保持敏捷、节省时间、充分利用资源并且完成更多工作。本书要点如下： 为什么传统的指令性计划会失败而敏捷计划会取得成功 如何使用故事点和理想人天来预估特性的规模，以及它们分别适用于哪种情形 重设估算的方式和时机 如何同时采用财务及非财务手段来确定特性的优先级 如何将大的特性分解为更小的、更便于管理的特性 如何计划迭代周期并对团队的初始进度进行预估 如何安排具有高度不确定性或进度相关风险的项目的进度 如何对由多个团队合作开发的项目进行估算     本书介绍所有敏捷、半敏捷或者迭代流程，包括Scrum、XP、特性驱动的开发、水晶方法、自适应软件开发、DSDM、统一过程(UP)以及其他许多方式。它无疑是每位研发经理、团队经理和成 员不可或缺的宝贵资源。

科恩（Mike Cohn），Mountain Goat Software创办人，以帮助客户公司成长为很好软件开发组织为己任，专门提供Scrum与敏捷软件开发培训。Mike Cohn是敏捷运动两大认可名著（《用户故事与敏捷方法》和《敏捷估算与规划》）的作者。他曾经历任多个软件开发公司（从新创公司到《财富》40强）的技术总监，曾服务子BBC（英国靠前广播公司）、Capital One（美国第―投资集团），Electronic Arts（艺电）、Experian（益百利）、Gooqle（谷歌）、Intuit（直觉软件公司）、Lexis Nexis（律商联讯）、Lockheed Martin（洛希德·马丁）、微软、诺基亚、飞利浦、Sabre、Salesforce.com、西门子、索尼、时代华纳、雅虎等客户。他参与创力了敏捷联盟、敏捷项目领导网络和Scrum联盟。

第Ⅰ部分问题与目标
第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.1SwimStatsWeb站点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例子：WebPayRoll74
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.1Napa项目131
15.3.2Goodman项目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章案例分析：BombShelterStudio197
23.1天——星期一早上198
23.2估算用户故事204
23.3准备产品调查212
23.4迭代和发布计划，第1轮214
23.4.1计划次迭代215
23.4.2发布计划220
23.52周后227
23.6计划第二次迭代228
23.72周后230
23.8修改发布计划230
23.9向Phil介绍修改后的计划232
23.1018周后235