相关图书推荐 |
|
 |
|
|
最近热书 |
|
|
|
|
|
| 出版日期：2007年7月 |
| 版别版次：2007年7月第1次印刷 |
本书勘误：有(0)条勘误 |
|
| 字数 ：361千字 印张：19.5 |
| 印数 ：1-4000 页数：0 |
| 附带物 ：
无附带物 |
|
|
前言
|
本书名差点被定为《估计与规划敏捷项目》。不过，最终确定的是《敏捷估计与规划》。两者的差异似乎微不足道，但实际上并非如此。现在的书名明确了估计和规划过程本身就应该是敏捷的。不采用敏捷估计和规划，就不可能有敏捷开发项目。本书的大部分是关于规划的，我把它看作是用来回答“我们要建立什么以及何时建立？”这一问题。但是，要回答关于规划的问题，我们还必须解决关于估计(“它有多大规模？”)和进度安排(“什么时候能完成？”和“到那时我能得到多少？”)的问题。本书由7个部分共23章组成。每一章的结尾都有对重点的小结和一组讨...
本书名差点被定为《估计与规划敏捷项目》。不过，最终确定的是《敏捷估计与规划》。两者的差异似乎微不足道，但实际上并非如此。现在的书名明确了估计和规划过程本身就应该是敏捷的。不采用敏捷估计和规划，就不可能有敏捷开发项目。
本书的大部分是关于规划的，我把它看作是用来回答“我们要建立什么以及何时建立？”这一问题。但是，要回答关于规划的问题，我们还必须解决关于估计(“它有多大规模？”)和进度安排(“什么时候能完成？”和“到那时我能得到多少？”)的问题。
本书由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讨论了敏捷估计与规划的思想，并使用现实的例子与案例分析向您详细地展示了如何完成工作。本书清晰地阐述了有关的概念，并引导读者逐步认识到下列一些问题的答案：我们要构建什么？它的规模有多大？需要在什么时候完成？到那个时候我们到底能完成多少？您首先会认识到优秀的计划由哪些东西组成，接着会了解到如何才能使计划成为敏捷的。《敏捷估计与规划》支持所有敏捷的、半敏捷的或迭代的开发过程，包括Scrum、极限...
《敏捷估计与规划》一书为对敏捷项目进行估计与规划提供了权威实际的指导方针。在本书中，敏捷联盟的共同创始人Mike Cohn讨论了敏捷估计与规划的思想，并使用现实的例子与案例分析向您详细地展示了如何完成工作。本书清晰地阐述了有关的概念，并引导读者逐步认识到下列一些问题的答案：我们要构建什么？它的规模有多大？需要在什么时候完成？到那个时候我们到底能完成多少？您首先会认识到优秀的计划由哪些东西组成，接着会了解到如何才能使计划成为敏捷的。
《敏捷估计与规划》支持所有敏捷的、半敏捷的或迭代的开发过程，包括Scrum、极限编程、功能驱动的开发、Crystal开发、自适应软件开发、DSDM、统一过程以及许多其他开发方式。它将是每个开发经理、开发小组领导和开发小组成员不可或缺的宝贵资源。
<<
显示内容简介详情
|
|
序
|
“除了一些小型项目以外，敏捷开发在Yahoo！公司根本就行不通，原因是那样的话开发小组就不会做任何计划，小组成员也无法对自己的工作进行估计。需要有人告诉他们应该做些什么。”这是人们的原话，从我在Yahoo！公司开始指导采用敏捷开发方法以来就反复听到这样的话。那些不理解敏捷开发概念的人认为敏捷开发不过是消灭掉所有的文档和规划，让开发小组到处乱逛的许可。事实与真相的距离不会比这种看法更远(译者注：即这种看法并非事实真相)。“小组不做任何计划。”说这种话的人忘记了敏捷开发小组每隔一周就会花半天的时间来列出任务列表...
“除了一些小型项目以外，敏捷开发在Yahoo！公司根本就行不通，原因是那样的话开发小组就不会做任何计划，小组成员也无法对自己的工作进行估计。需要有人告诉他们应该做些什么。”
这是人们的原话，从我在Yahoo！公司开始指导采用敏捷开发方法以来就反复听到这样的话。那些不理解敏捷开发概念的人认为敏捷开发不过是消灭掉所有的文档和规划，让开发小组到处乱逛的许可。事实与真相的距离不会比这种看法更远(译者注：即这种看法并非事实真相)。
“小组不做任何计划。”说这种话的人忘记了敏捷开发小组每隔一周就会花半天的时间来列出任务列表，表上是为了在2周的时间结束时他们能够交付一些对用户有价值的功能所需要完成的工作。开发小组让规划活动扩展到了项目开发的整个过程，而不只是在一开始就先期完成所有规划，结果常被看作缺乏计划。事实并非如此。在Yahoo！公司，与传统开发小组相比，敏捷开发小组所创建的产品让我们的产品经理更为满意。
“小组成员无法对自己的工作进行评估，需要有人告诉他们应该做些什么。”这是一个非常典型的错觉。从商务角度来看，让产品经理或者项目经理具有圣人一样的能力，预计其他在其所从事的行业是专家的人到底能做些什么，简直就是自杀行为。通常，这是一种在被要求交付不现实的目标时，用来向销售人员做出承诺的办法。然后，开发小组的成员被迫连轴转或投机取巧。难怪在我们的行业中大家总是显得筋疲力尽而且士气低落了。
在人们向我提出的问题中，最多的疑问集中在估计和规划等方面，新小组尤其如此。获得一个简单的方法为整个项目过程而不仅仅是一个迭代周期进行规划，其价值是无法估计的。产品经理需要注意满足财务目标并获得一个可预测的发布计划。开发小组仍然可以保持灵活性，并根据需要改变进程，但遵循一个路线图是非常重要的。如果走错了方向，仅仅加快速度是不够的。如果想在公司中成功地实现敏捷开发，学会如何进行估计和规划是最重要的内容之一。
Mike的估计和规划课是我们在Yahoo！的敏捷开发课程中最受欢迎的。它为开发小组提供了技巧与工具，让他们可以为得到最佳的结果而进行恰到好处的规划。如果遵循Mike的建议，真会起作用吗？是的。敏捷开发在Yahoo！公司取得的成功是不可思议的。我看到过小组成员一从Mike的课上回来就把他的建议投入应用。我们可以更快地向市场上推出产品，而开发小组真实地爱上了敏捷开发方法。
为什么敏捷估计和规划方法比传统方法更有效？因为它们专注于交付价值，在销售小组与项目小组间建立信任。让所有的事保持高度透明，让销售人员从一开始就了解发生的所有变化，意味着业务人员可以迅速调整以做出最佳的决策。在我工作的上一家公司，我亲眼看着我们从只有一张非常模糊的路线图而无法交付产品的长期混乱状态，转变成了终于可以给我们能够交付的产品签字的可预测状态。业务部门说也许他们不总是那么喜欢我们的答案(他们第二天总会想要些新东西)，但至少他们可以相信我们的答案，而不用因为觉得总是被欺骗而沮丧了。
本书真实地反映了事实。它并不会告诉您如何使您的估计百分之百地准确。那是不可能实现的，只能是白白浪费精力。Mike的书并未试图给您一个完美的填空式的模板，而是让您思考和学习如何分析问题、解决问题。没有两个项目、产品或者公司是完全一样的，所以学会思考方式和基本原则更为重要。Mike在本书中生动地再现了他的亲身经历和个性特点。本书是真实的、诚实的。毫无疑问，本书应该排在您的阅读书目的最上面。
Gabrielle Benefield
Yahoo！公司敏捷产品开发部主任
<<
显示序详情
|
|
作者序
|
在敏捷开发的世界中，我总会听到这样一些相同的问题：● 我应该如何为大型开发小组做计划？● 我们应该采用多长的迭代周期？● 我应如何向管理层作进度汇报？● 我如何确定用户故事的优先级？● 我如何得到有关项目的全景？这些问题，以及很多其他的问题，都在本书中得到了巧妙的回答。无论您是项目经理、项目领导、开发人员还是指导者，本书都为您提供了必需的工具，可以用来对任何规模的敏捷项目进行估计、规划和管理。我已经认识Mike Cohn 5年了。在敏捷宣言签署之后不久我就遇到了他。Mike带着独特的热情和活力加入了敏捷联...
在敏捷开发的世界中，我总会听到这样一些相同的问题：
● 我应该如何为大型开发小组做计划？
● 我们应该采用多长的迭代周期？
● 我应如何向管理层作进度汇报？
● 我如何确定用户故事的优先级？
● 我如何得到有关项目的全景？
这些问题，以及很多其他的问题，都在本书中得到了巧妙的回答。无论您是项目经理、项目领导、开发人员还是指导者，本书都为您提供了必需的工具，可以用来对任何规模的敏捷项目进行估计、规划和管理。
我已经认识Mike Cohn 5年了。在敏捷宣言签署之后不久我就遇到了他。Mike带着独特的热情和活力加入了敏捷联盟。无论他参与哪一个项目，都会完成那个项目，并且很好地完成它。他非常引人注目，对大家都有所帮助。他很快就成为了新生的敏捷联盟中不可或缺的人物。
现在，他将同样的能力、透彻性和活力注入到这本书中。本书展现出他的这些品质，并且是以一流的水准(完全可行的建议)展现出来。
这不是一本关于抽象理论的书。作为读者，您不需要花费大量的时间，好像在30 000英尺高空的云雾中一样考虑问题。与之相反，Mike提供了具体的实践、方法、工具、图表、公式，而且最为重要的是，他还提供了恰到好处的建议。本书是一本有关“如何进行”估计和规划的手册。
本书从头至尾点缀了大量的轶事来说明Mike在使用他所说明的方法和工具时的经历。他会告诉您这些方法和工具何时有效，何时又没有效果。他会告诉您什么地方会出错，以及怎样做才是正确的。他不会给您什么承诺，提供什么“银弹”，或者做出什么保证。但是他为您提供了许多来之不易的经验。
曾经有许多书涉及过有关敏捷估计和规划的问题。确实有几本书是把它作为主题来写的。但是没有一本能够与本书的深度和实用性相媲美。本书完整地、有效地覆盖了这一主题，以至于我认为它应该被看作是权威之作。
好了，我知道我看起来过于激动，但我确实非常兴奋。我兴奋的原因是许多长久以来就存在的问题终于被足够称职的人回答了。我兴奋的原因是当客户提出一些困难的问题时，我终于可以向他们提供一个工具。我兴奋的原因是本书已经写好，而您即将读到它。
我很高兴并且荣幸地在我的丛书中加入本书。我认为它是一本成功的书。
Robert C. Martin 系列书籍编辑
<<
显示作者序详情
|
|
目录
|
第1章 规划的目的 3
1.1 作规划的原因 4
1.1.1 减少风险 5
1.1.2 降低不确定性 6
1.1.3 提供更好的决策支持 6
1.1.4 建立信任 7
1.1.5 传递信息 7
1.2 优秀计划的组成部分 8
1.3 敏捷规划过程的特点 8
1.4 小结 9
1.5 讨论题 10
第2章 规划失败的原因 11
2.1 基于活动而不是基于功能进行规划 11
2.1.1 活动不会提前完成 12
2.1.2 延误沿着进度表向下传递 13
2.1.3 活动不是独立的 14
2.2 多任务处理导致更多的延迟 14
2.3 不按优先级开发功能 16
2.4 忽视了不确定性 17
2.5 把估计当作承诺 17
2.6 小结 18
· · · · · ·
第1章 规划的目的 3
1.1 作规划的原因 4
1.1.1 减少风险 5
1.1.2 降低不确定性 6
1.1.3 提供更好的决策支持 6
1.1.4 建立信任 7
1.1.5 传递信息 7
1.2 优秀计划的组成部分 8
1.3 敏捷规划过程的特点 8
1.4 小结 9
1.5 讨论题 10
第2章 规划失败的原因 11
2.1 基于活动而不是基于功能进行规划 11
2.1.1 活动不会提前完成 12
2.1.2 延误沿着进度表向下传递 13
2.1.3 活动不是独立的 14
2.2 多任务处理导致更多的延迟 14
2.3 不按优先级开发功能 16
2.4 忽视了不确定性 17
2.5 把估计当作承诺 17
2.6 小结 18
2.7 讨论题 18
第3章 敏捷方法 19
3.1 项目的敏捷开发方法 21
3.1.1 敏捷小组作为一个整体工作 21
3.1.2 敏捷小组按短迭代周期工作 22
3.1.3 敏捷小组每次迭代交付一些成果 22
3.1.4 敏捷小组关注业务优先级 23
3.1.5 敏捷小组进行检查和调整 24
3.2 敏捷规划方法 25
3.2.1 规划的不同层次 25
3.2.2 满意条件 27
3.3 小结 29
3.4 讨论题 30
第II部分 规 模 估 计
第4章 使用故事点估计规模 33
4.1 故事点是相对的 34
4.2 速度 36
4.3 小结 38
4.4 讨论题 39
第5章 使用理想日进行估计 41
5.1 理想时间和软件开发 42
5.2 以理想日作为对规模的度量 43
5.3 给出一个而不是多个估计值 44
5.4 小结 45
5.5 讨论题 45
第6章 估计方法 47
6.1 共同估计 49
6.2 估计的尺度 50
6.3 得到估计值的方法 52
6.3.1 专家意见 52
6.3.2 类比 52
6.3.3 裂解 53
6.4 规划扑克 53
6.4.1 更小的会议 55
6.4.2 何时打规划扑克 55
6.5 为什么规划扑克会有效 56
6.6 小结 56
6.7 讨论题 57
第7章 重估 59
7.1 SwimStats Web站点 59
7.2 不进行重估的情况 60
7.3 需要重估的情况 62
7.3.1 场景1：不进行重估 62
7.3.2 场景2：重估完成的故事 63
7.3.3 场景3：相对规模改变时进行重估 63
7.4 重估部分完成的故事 63
7.5 重估的目的 64
7.6 小结 65
7.7 讨论题 65
第8章 在故事点和理想日之间进行选择 67
8.1 有利于故事点的考虑因素 67
8.1.1 故事点有助于驱动跨功能的行为 68
8.1.2 故事点估计不会过期 68
8.1.3 故事点是对规模的纯粹度量 69
8.1.4 故事点估计通常更快 69
8.1.5 我的理想日不等于您的理想日 70
8.2 有利于理想日的考虑因素 70
8.2.1 理想日在小组以外更容易解释 70
8.2.2 理想日估计更容易开始 71
8.3 建议 71
8.4 小结 72
8.5 讨论题 73
第III部分 为价值作规划
第9章 确定主题的优先级 77
9.1 确定优先级时的因素 78
9.1.1 价值 78
9.1.2 成本 79
9.1.3 新知识 79
9.1.4 风险 81
9.2 综合4个因素 83
9.3 一些例子 84
9.3.1 基础结构 84
9.3.2 用户界面设计 85
9.4 小结 85
9.5 讨论题 86
第10章 确定经济优先级 87
10.1 收入的来源 89
10.1.1 新收入 89
10.1.2 增量收入 89
10.1.3 留存收入 90
10.1.4 操作效率 90
10.2 例子：WebPayRoll 91
10.2.1 计算新收入 91
10.2.2 计算增量收入 92
10.2.3 计算留存收入 93
10.2.4 计算操作效率 94
10.2.5 估计开发成本 94
10.2.6 整合 96
10.3 经济指标 96
10.3.1 金钱的时间价值 96
10.3.2 净现值 97
10.3.3 内部收益率 98
10.3.4 回收期 100
10.3.5 贴现回收期 101
10.4 对利润的比较 102
10.5 小结 103
10.6 讨论题 104
第11章 确定合意性优先级 105
11.1 客户满意度的Kano模型 106
11.1.1 用Kano模型评估主题 108
11.1.2 将答案分类 109
11.2 相对权重：另一种方法 111
11.3 小结 112
11.4 讨论题 113
第12章 分割用户故事 115
12.1 何时分割用户故事 115
12.2 按照数据边界分割 116
12.3 按照操作边界分割 118
12.4 去除横切考虑 119
12.5 不用满足性能限制 120
12.6 分割具有混合优先级的用户故事 120
12.7 不要把故事分割成任务 121
12.8 避免相关变化的诱惑 121
12.9 组合用户故事 121
12.10 小结 122
12.11 讨论题 123
第IV部分 进 度 安 排
第13章 发布规划基础 127
13.1 发布计划 128
13.1.1 确定满意条件 129
13.1.2 估计用户故事的规模 129
13.1.3 选择迭代周期长度 130
13.1.4 估计速度 130
13.1.5 确定用户故事优先级 130
13.1.6 选择用户故事和发布日期 130
13.2 更新发布计划 132
13.3 例子 132
13.3.1 确定满意条件 133
13.3.2 估计规模 133
13.3.3 选择迭代周期长度 134
13.3.4 估计速度 134
13.3.5 确定用户故事优先级 134
13.3.6 选择用户故事 134
13.4 小结 136
13.5 讨论题 136
第14章 迭代规划 137
14.1 迭代规划时不分配任务 139
14.2 迭代规划和发布规划的区别 140
14.3 速度驱动的迭代规划 141
14.3.1 调整优先级 142
14.3.2 确定目标速度 143
14.3.3 确定迭代目标 143
14.3.4 选择用户故事 143
14.3.5 把用户故事分解成任务 144
14.3.6 对任务进行估计 147
14.4 承诺驱动的迭代规划 149
14.5 我的建议 153
14.6 任务估计值和故事点的联系 154
14.7 小结 156
14.8 讨论题 156
第15章 选择迭代长度 157
15.1 选择迭代长度时考虑的因素 157
15.1.1 发布的总时间长度 158
15.1.2 不确定性的多少 158
15.1.3 获得反馈的难易程度 159
15.1.4 优先级可以保持多久不变 159
15.1.5 不用外部反馈自行工作的意愿 160
15.1.6 迭代的系统开销 160
15.1.7 紧迫感的产生有多快 160
15.2 做出决策 161
15.3 两个案例分析 162
15.3.1 Napa项目 163
15.3.2 Goodman项目 163
15.4 小结 165
15.5 讨论题 165
第16章 估计速度 167
16.1 使用历史值 168
16.2 进行一次迭代 169
16.3 做出预测 171
16.3.1 估计可用小时数 171
16.3.2 估计一次迭代中可用的时间 172
16.3.3 扩展故事并寻找适当的技能集 173
16.3.4 在点值周围设置一个范围 174
16.3.5 某些小组的变通方法 174
16.4 选择合适的方法 175
16.5 小结 176
16.6 讨论题 176
第17章 为不确定性缓冲计划 177
17.1 功能缓冲区 178
17.2 进度缓冲区 179
17.2.1 在估计值中反映不确定性 180
17.2.2 调整项目缓冲区大小 180
17.2.3 更简单的缓冲区计算方法 186
17.2.4 缓冲区准则 186
17.3 结合多个缓冲区 187
17.4 进度缓冲区不是填料 188
17.5 一些警告 188
17.6 小结 189
17.7 讨论题 190
第18章 规划多小组的项目 191
18.1 为估计建立共同基准 192
18.2 更早给用户故事添加细节 193
18.3 前瞻规划 193
18.4 在计划中加入馈送缓冲区 195
18.4.1 缓冲的对象 196
18.4.2 确定馈送缓冲区的大小 196
18.5 工作量会很大 197
18.6 小结 197
18.7 讨论题 198
第V部分 跟踪与交流
第19章 监督发布计划的执行 201
19.1 对发布进行跟踪 202
19.2 发布耗散图 204
19.3 停车场图 209
19.4 小结 210
19.5 讨论题 211
第20章 监督迭代计划的执行 213
20.1 任务板 213
20.2 迭代耗散图 216
20.3 跟踪已完成的工作量 217
20.4 个人速度 217
20.5 小结 218
20.6 讨论题 218
第21章 与计划有关的沟通 219
21.1 就计划进行沟通 220
21.2 就进度进行交流 222
21.3 迭代结束小结 224
21.4 小结 227
21.5 讨论题 228
第VI部分 敏捷规划有效的原因
第22章 敏捷规划有效的原因 231
22.1 经常进行重规划 231
22.2 对规模和持续时间的估计是独立的 232
22.3 在不同层次上制定计划 233
22.4 基于功能而不是基于任务制定计划 233
22.5 小故事保持工作流畅 234
22.6 每次迭代都要消除处理中的工作 234
22.7 在小组层次跟踪 235
22.8 承认不确定性并为之做计划 235
22.9 敏捷估计和规划的12条指导原则 236
22.10 小结 238
22.11 讨论题 238
第VII部分 案 例 分 析
第23章 案例分析：Bomb Shelter Studio 241
23.1 第一天—— 星期一早上 242
23.2 估计用户故事 250
23.3 准备产品调查 260
23.4 迭代和发布规划，第1轮 262
23.4.1 规划第一次迭代 263
23.4.2 发布规划 270
23.5 2周后 278
23.6 规划第二次迭代 280
23.7 2周后 281
23.8 修改发布计划 282
23.9 向Phil介绍修改后的计划 285
23.10 18周后 288
<<
显示目录详情
|
|
- 全部评论(0)
- 力荐(0)
- 推荐(0)
- 还行(0)
- 较差(0)
- 很差(0)
|
前5位评价用户：
发表评价即可获得华元，前五位评价用户可获得多倍华元！
 目前还没有评论
|
评论(0条)
读过(0人)
在读(0人)
想读(0人) 
（库存状况：无货）
