敏捷软件开发实践：估算与计划

　　详述用于估算和计划任何敏捷项目的行之有效的技巧《敏捷软件开发实践 估算与计划 为对敏捷项目进行估算和计划提供了紧贴实用的权威指导方针。在本书中，敏捷联盟联合创始人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章  计划的目的 31.1  为何要进行估算和计划 41.1.1  减少风险 51.1.2  降低不确定性 51.1.3  提供更好的决策支持 51.1.4  建立信任 61.1.5  传递信息 61.2  优秀的计划是什么 71.3  敏捷计划是什么 71.4  小结 81.5  讨论题 8第2章  计划失败的原因 92.1  基于活动而不是基于特性进行计划 92.1.1  活动不会提前完成 102.1.2  延误沿着计划表向下传递 102.1.3  活动不是互相独立的 112.2  多任务处理导致更多的延迟 122.3  不按优先级开发特性 132.4  忽视了不确定性 132.5  把估算当作承诺 142.6  小结 142.7  讨论题 15第3章  敏捷方法 173.1  项目的敏捷开发方法 183.1.1  敏捷团队作为一个整体工作 183.1.2  敏捷团队按短迭代周期工作 193.1.3  敏捷团队每次迭代交付一些成果 193.1.4  敏捷团队关注业务优先级 203.1.5  敏捷团队进行检查和调整 213.2  敏捷计划方法 213.2.1  计划的不同层次 223.2.2  满意条件 233.3  小结 253.4  讨论题 25第Ⅱ部分  估 算 大 小第4章  使用故事点估算大小 294.1  故事点是相对的 294.2  速度 314.3  小结 334.4  讨论题 33第5章  使用理想人天进行估算 355.1  理想时间和软件开发 365.2  以理想人天作为对大小的度量 375.3  给出一个而不是多个估算值 375.4  小结 385.5  讨论题 38第6章  估算方法 396.1  共同估算 406.2  估算的尺度 416.3  得到估算值的方法 426.3.1  专家意见 436.3.2  类比 436.3.3  分解 436.4  计划扑克 446.4.1  更小规模的会议 456.4.2  何时玩计划扑克 456.5  为什么计划扑克会有效 466.6  小结 466.7  讨论题 47第7章  重估 497.1  SwimStats Web站点 497.2  不进行重估的情况 507.3  需要重估的情况 517.3.1  场景1：不进行重估 527.3.2  场景2：重估完成的故事 527.3.3  场景3：相对大小改变时进行重估 527.4  重估部分完成的故事 527.5  重估的目的 537.6  小结 537.7  讨论题 54第8章  在故事点和理想人天之间进行选择 558.1  有利于故事点的考虑因素 558.1.1  故事点有助于驱动跨功能的行为 558.1.2  故事点估算不会过期 568.1.3  故事点是对大小的纯粹度量 568.1.4  故事点估算通常更快 578.1.5  我的理想人天不等于你的理想人天 578.2  有利于理想人天的考虑因素 588.2.1  理想人天在团队以外更容易解释 588.2.2  理想人天估算更容易开始 588.2.3  理想人天便于预测速度 588.3  建议 588.4  小结 598.5  讨论题 59第Ⅲ部分  为价值制定计划第9章  确定主题的优先级 639.1  确定优先级时的因素 639.1.1  价值 649.1.2  成本 649.1.3  新知识 659.1.4  风险 669.2  综合4个因素 689.3  一些例子 689.3.1  基础设施 689.3.2  用户界面设计 699.4  小结 699.5  讨论题 70第10章  确定经济优先级 7110.1  收入的来源 7210.1.1  新收入 7310.1.2  增量收入 7310.1.3  留存收入 7310.1.4  操作效率 7310.2  例子：WebPayRoll 7410.2.1  计算新收入 7410.2.2  计算增量收入 7510.2.3  计算留存收入 7610.2.4  计算操作效率 7610.2.5  估算开发成本 7710.2.6  整合 7810.3  经济指标 7810.3.1  金钱的时间价值 7910.3.2  净现值 7910.3.3  内部收益率 8010.3.4  投资回收期 8210.3.5  折现回收期 8310.4  对利润的比较 8310.5  小结 8410.6  讨论题 84第11章  确定渴望度优先级 8511.1  客户满意度的Kano模型 8511.2  相对权重：另一种方法 8911.3  小结 9111.4  讨论题 91第12章  分解用户故事 9312.1  何时分解用户故事 9312.2  按照数据边界分解 9412.3  按照操作边界分解 9512.4  去除横切考虑 9612.5  忽略满足性能限制 9712.6  分解具有混合优先级的用户故事 9712.7  不要把故事分解成任务 9712.8  避免相关变化的诱惑 9812.9  组合用户故事 9812.10  小结 9812.11  讨论题 99第Ⅳ部分  进 度 计 划第13章  发布计划精粹 10313.1  发布计划 10313.1.1  确定满意条件 10513.1.2  估算用户故事 10513.1.3  选择迭代周期长度 10513.1.4  估算速度 10513.1.5  确定用户故事优先级 10513.1.6  选择用户故事和发布日期 10613.2  更新发布计划 10713.3  例子 10713.3.1  确定满意条件 10813.3.2  估算大小 10813.3.3  选择迭代周期长度 10813.3.4  估算速度 10913.3.5  确定用户故事优先级 10913.3.6  选择用户故事 10913.4  小结 11013.5  讨论题 110第14章  迭代计划 11114.1  迭代计划时不分配任务 11314.2  迭代计划和发布计划的区别 11314.3  速度驱动的迭代计划 11414.3.1  调整优先级 11514.3.2  确定目标速度 11614.3.3  确定迭代目标 11614.3.4  选择用户故事 11614.3.5  把用户故事分解成任务 11714.3.6  对任务进行估算 11914.4  承诺驱动的迭代计划 12114.5  我的建议 12414.6  任务估算值和故事点的联系 12414.7  小结 12614.8  讨论题 126第15章  选择迭代长度 12715.1  选择迭代长度时考虑的因素 12715.1.1 发布的总时间长度 12715.1.2  不确定性的多少 12815.1.3  获得反馈的难易程度 12815.1.4  优先级可以保持多久不变 12815.1.5  在没有外部反馈之下进行工作的意愿 12915.1.6  迭代的系统开销 12915.1.7  紧迫感维持 13015.2  做出决策 13015.3  两个案例分析 13115.3.1  Napa项目 13115.3.2  Goodman项目 13215.4  小结 13315.5  讨论题 133第16章  估算速度 13516.1  使用历史值 13516.2  进行一次迭代 13716.3  做出预测 13816.3.1  估算可用小时数 13816.3.2  估算一次迭代中可用的时间 13916.3.3  扩展故事并填满可用工作时长 13916.3.4  围绕着估算值设置一个范围 14016.3.5  某些团队的变通方法 14016.4  选择合适的方法 14116.5  小结 14116.6  讨论题 142第17章  不确定性缓冲计划 14317.1  特性缓冲区 14417.2  进度缓冲区 14417.2.1  在估算值中反映不确定性 14517.2.2  调整项目缓冲区大小 14817.2.3  更简单的缓冲区计算方法 15017.2.4  缓冲区准则 15017.3  结合多个缓冲区 15017.4  进度缓冲区不是填料 15117.5  一些警告 15217.6  小结 15217.7  讨论题 153第18章  计划多团队项目 15518.1  为估算建立共同基准 15518.2  更早给用户故事添加细节 15618.3  前瞻性计划 15718.4  在计划中加入馈送缓冲区 15818.4.1  缓冲的对象 15918.4.2  确定馈送缓冲区的大小 15918.5  工作量会很大 16018.6  小结 16018.7  讨论题 161第Ⅴ部分  跟踪与交流第19章  监督发布计划 16519.1  对发布进行跟踪 16519.2  发布燃尽图 16719.3  停车场图 17119.4  小结 17219.5  讨论题 172第20章  监督迭代计划 17320.1  任务板 17320.2  迭代燃尽图 17520.3  跟踪已完成的工作量 17620.4  个人速度 17720.5  小结 17720.6  讨论题 177第21章  关于计划的沟通 17921.1  就计划进行沟通 18021.2  就进度进行沟通 18121.3  迭代结束总结 18321.4  小结 18621.5  讨论题 186第Ⅵ部分  敏捷计划有效的原因第22章  敏捷计划有效的原因 18922.1  经常重新计划 18922.2  对大小和持续时间的估算是独立的 19022.3  在不同层次上制定计划 19022.4  基于特性而不是基于任务制定计划 19122.5  小故事保持工作流畅 19122.6  每次迭代都要消除未完工的工作 19122.7  在团队层次跟踪 19222.8  承认不确定性并为之计划 19222.9  敏捷估算和计划的12条指导原则 19222.10  小结 19422.11  讨论题 194第Ⅶ部分  案 例 分 析第23章  案例分析：Bomb Shelter Studio 19723.1  第一天—— 星期一早上 19823.2  估算用户故事 20423.3  准备产品调查 21223.4  迭代和发布计划，第1轮 21423.4.1  计划第一次迭代 21523.4.2  发布计划 22023.5  2周后 22723.6  计划第二次迭代 22823.7  2周后 23023.8  修改发布计划 23023.9  向Phil介绍修改后的计划 23223.10  18周后 235