敏捷估计与规划
出版社:清华大学
出版日期:2007-7
ISBN:9787302154808
作者:[美] Mike Cohn
页数:288页
作者简介
《敏捷估计与规划》一书为对敏捷项目进行估计与规划提供了权威实际的指导方针。在本书中，敏捷联盟的共同创始人Mike Cohn讨论了敏捷估计与规划的思想，并使用现实的例子与案例分析向您详细地展示了如何完成工作。本书清晰地阐述了有关的概念，并引导读者逐步认识到下列一些问题的答案：我们要构建什么？它的规模有多大？需要在什么时候完成？到那个时候我们到底能完成多少？您首先会认识到优秀的计划由哪些东西组成，接着会了解到如何才能使计划成为敏捷的。
《敏捷估计与规划》支持所有敏捷的、半敏捷的或迭代的开发过程，包括Scrum、极限编程、功能驱动的开发、Crystal开发、自适应软件开发、DSDM、统一过程以及许多其他开发方式。它将是每个开发经理、开发小组领导和开发小组成员不可或缺的宝贵资源。此书也获得了亚马逊网站“五星级”赞誉！
书籍目录
第Ⅰ部分 问题与目标
第1章 规划的目的
第2章 规划失败的原因
第3章 敏捷方法
第Ⅱ部分 规 模 估 计
第4章 使用故事点估计规模
第5章 使用理想日进行估计
第6章 估计方法
第7章 重估
第8章 在故事点和理想日之间进行选择
第Ⅲ部分 为价值作规划
第9章 确定主题的优先级
第10章 确定经济优先级
第11章 确定合意性优先级
第12章 分割用户故事
第IV部分 进 度 安 排
第13章 发布规划基础
第14章 迭代规划
第15章 选择迭代长度
第16章 估计速度
第17章 为不确定性缓冲计划
第18章 规划多小组的项目
第Ⅴ部分 跟踪与交流
第19章 监督发布计划的执行
第20章 监督迭代计划的执行
第21章 与计划有关的沟通
第Ⅵ部分 敏捷规划有效的原因
第22章 敏捷规划有效的原因
第Ⅶ部分 案例分析
第23章 案例分析：Bomb Shelter Studio
编辑推荐
"您的项目进行得怎么样？遇到了令人沮丧的变化？不确定性？还是产品错过了标志点和最终期限？MikeCohn清晰明了地展示了如何有效地开发具有高商业价值的软件。通过敏捷估计与规划，即使环境发生了变化，您仍可以将精力专注于真正需要的地方。"——Rick Mugridge，Rimu Research有限公司，Fit for Developing Software的第一作者。"我们是《敏捷估计与规划》所述的敏捷方法的忠实信徒，并通过实现和继续采用这些方法获得了许多极其重要的积极影响。我向所有希望使自己的软件开发过程更为实际和有效的人极力推荐此书。"——Mark M．Gutrich，Fast 401k公司总裁兼首席执行官为什么传统的指令性规划会失败而敏捷规划会成功；如何使用故事点或理想日来估计功能的规模，以及它们分别适用于哪种情况；如何以及何时进行重估；如何同时采用经济和非经济手段确定功能的优先级；如何将大的功能分解成更小的更易管理的功能；如何规划迭代周期并对开发小组的初始进度率进行预测；如何安排具有高不确定性或者进度易受影响的项目的进度；如何对由多个开发小组合作开发的项目进行评估。通过，您首先会认识到优秀的计划由哪些东西组成，接着会了解到如何才能使计划成为敏捷的。
内容概要
Mike Cohn是专门进行过程和项目管理咨询与培训的Mountain Goat Software公司的创始人。Mike拥有超过20年的行业经验，担任过从刚起步的新公司到财富40强企业的技术负责人，还是敏捷联盟的发起成员之一。他经常在业界相关杂志上发表文章并出席有关会议，也是User Stories Applied（Addison-wesley公司2004年出版）一书的作者。
发布书评
精彩书评 (总计7条)
-
* 好的规划过程通过一下活动来支持对价值的探求- 减少风险- 降低不确定性- 提供更好的决策支持- 建立信任- 传递信息* 导致规划失败的五个原因1，基于活动而不是基于功能进行规划- 活动不会提前完成- 延误随进度表传递- 活动不是独立的2，多任务处理导致更多的延迟（Clark，Wheelwright（1993），多任务处理的影响）3，不按优先级开发功能4，忽视了不确定性5，把估计当作承诺* 故事点是用于表达用户故事、功能或其他工作的总体规模的度量单位- 故事点估计是对开发该功能所需的工作量、开发工作的复杂性以及蕴藏的风险等方面的综合。- 把对工作量（effort）的估计和对持续时间（duration）的估计完全隔离开。* 得到估计值的方法- 专家意见（Expert Opinion）- 类比（Analogy）- 裂解（Disaggregation）* 为什么规划扑克会有效？1，规划扑克在做估计的时候把多条专家意见放到了一起2，在规划扑克期间会进行活跃的对话，规划者会被同事要求证明自己的估计的正确性3，对个人估计的平均可以引向更好的结果（Hoest， Wholin，1998），对估计进行团体讨论也可以得到同样的效果（Jorgensen，Molokken，2002）4，它很有趣* 你应该只在用户故事的相对规模发生变化的时候进行重估。* 故事点 vs 理想日- 故事点有助于驱动跨功能的行为- 故事点估计不会过期- 故事点是纯粹对规模的度量- 故事点估计通常更快- 我的理想日不等于你的理想日- 理想日在小组以外更容易理解- 理想日估计更容易开始* 确定开发活动优先级时的因素1，获得这些功能带来的经济价值2，开发（可能还包含支持）新功能所需的成本3，开发新功能所产生的学习和知识的量及重要性（降低不确定性：End Uncertainty; Means Uncertainty）4，开发这些功能所减少的风险- 进度风险（“我们也许不能在10月前完成”）- 成本风险（“我们也许无法购买到合适价格的硬件”）- 功能风险（“我们也许无法让它工作”）* 经济指标：Steven Tockey 《Return on Software: Maximizing the Return on Your Software Investment》（2004）* Kano模型- Noriaki Kano（狩野纪昭）- 功能分3个类别1，作为阈值的功能，或者说必须的功能2，线性功能3，兴奋点和惊喜点- 通过两个问题确定一个功能的分类1，功能存在形式（functional form）：有该功能时如何2，功能缺失形式（dysfunctional form）：没有该功能时如何* 分割用户故事1，按照用户故事所支持数据的边界来分割2，按照大型用户故事中进行的操作对其进行分割- 例如，独立的建立、读取、更新和删除操作3，考虑去除横切考虑（例如安全处理、日志记录、错误处理等），为用户故事建立两个版本：一个具备对横切考虑的支持，另一个不具备这种支持；4，考虑把功能性和非功能性需求隔离到不同的用户故事5，如果大型故事中的小故事具有不同的优先级，则可以对它们进行分割6，不要把大型故事分割成任务，而是寻找一个方法来让一个曳光弹穿过这个故事7，避免在具有适当规模的功能中增加相关变化而把事情搞糟，除非这些变化具有同样的优先级* 迭代计划：把用户故事分解为任务1，只包含为此项目增加价值的工作2，尽量明确（某项任务）直到养成习惯3，考虑到会议（很重要）4，故障（bug）5，处理依赖性6，难以分割的工作* 选择合适的迭代长度- 正在处理的发布的时间长度- 不确定性的多少- 获得反馈的难易程度- 优先级可以保持多久不改变- 不用外部反馈自行工作的意愿的强弱- 迭代的系统开销- 紧迫感的产生有多快* 对开发过程产生影响的力量1，已完成的工作2，改变的需求3，修改的估计值* 敏捷规划有效的原因- 经常进行重规划- 对规模和持续时间的估计是独立的- 在不同层次上制定计划- 基于功能而不是基于任务制定计划- 小故事保持工作流畅- 每次迭代都要消除处理中的工作- 在小组层次追踪- 承认不确定性并为之做计划【敏捷估计与规划的12条指导原则】1，让整个小组参与2，在不同层次上进行规划3，使用不同度量单位，保持对规模和持续时间的估计独立4，使用功能或日期来体现不确定性5，经常重规划6，跟踪进度并沟通7，承认学习的重要性8，规划具有适当规模的功能9，确定功能优先级10，把估计和计划建立在事实上11，保留一些松弛度12，通过前瞻规划协调多个小组 -
前段读了《敏捷估计与规划》，这本书很适合开发经理看，我只是很快的浏览了一下，摘录一些体会。原文在 http://iamsujie.com/7000/7009/，欢迎大家来探讨相关话题Ø 敏捷的里程碑是功能驱动的，先完成可交付的最“重要”功能，重要取决于功能商业价值、生命周期、实现难度等综合的结果。而传统的瀑布模型的里程碑是任务阶段驱动的，到了项目50%的时间，可能进入“编码”，但对客户来说，等于0%。而且这样的模式会陷入“实现难度决定开发顺序”的不合理模式，因为这里有个不合理的假设前提：所有功能都能够完成、必须完成，中间过程对客户是透明的。Ø 项目估计的不确定性是会累积的，80%×80%×……，所以开始订的项目计划，在一个月后已经面目全非，强行的遵守是没有意义的，而应该不断的修正计划，当然，更好的做法是一开始的计划中间留有一些柔性的内容。Ø 随着时间变化，必然有新的信息出现，特别是瞬息万变的互联网业界，死守着开始的项目计划不调整是没有逻辑的做法，敏捷的迭代刚好权衡了变化的成本和不变的成本，就是：不变本次迭代，更新下次迭代，这是一个将项目计划细化粒度的做法。Ø 需求唯一不变的特征就是“不断变化”（plus不断细化），敏捷的思想就是欢迎变化，拥抱变化。瀑布模型一次性完成的需求分析，会存在“过度需求”的问题，降低整体效率。项目管理理论的发展，从开始混乱，每个项目自有一套，每个PM自有一套；到后来人们非常想订出一个统一的简单的流程，减少人为影响（瀑布模型等出现），；再后来进入灵活的敏捷，看似又变得混乱，实则有序。又是宛如那个哲学的三段论：见山是山—见山不是山—见山还是山；也如管理的三个境界：人治—法治—无为而治。 -
8.2.1 理想日在小组以外更容易解释“常常会有必要向外部人员(以及首先是对小组成员)解释采用功能点进行规模估计的概念。不过，您经常可以把对功能点作解释的要求当作对项目将要采取的总体估计和规划方法进行说明的机会。”这里用到了“功能点”，而英文原文为“story points”。功能点和故事点是两个不同的概念，并且中文版中“story points”在8.2.1之前一直是被翻译成故事点的，唯独这里被译成功能点，不知是何原因。这么翻译对理解这段话会造成一定的障碍。
精彩短评 (总计23条)
-
比起敏捷，我觉得对规划的一小部分讨论真是真知灼见啊。 -
挺实用的敏捷估算方面的书籍，对于刚接触敏捷的团队，挺有借鉴意义 -
以往看大多是敏捷的理念和技术实践，此书讲解的是敏捷的管理方法，是个有力的补充。 -
好早前读过的一本书，做项目的时候实践过，不过对学生可能要求有点高，最后的结果不太好，想好后，还是得看执行力 -
中英文都读过，敏捷下如何进行估计和规划的活动，必看书籍，给出了很多的意见和建议，当然也有很多实操的动作。 -
规模与进度的估算值得借鉴与实践。 -
受益良多。 -
关于项目估计和规划的敏捷方法阐释 -
敏捷也有计划 -
对于实践敏捷开发的新手来说，这本书简直是有用的一腿！ -
一年多以前读过的书，翻译得不是很通顺，理论比较多。 -
南图借的.
书内容还不错, 但是中文版翻译的不是太好, 建议直接读英文版. -
可以简单看看，了解一下。最后的例子还有点参考价值 -
有关于人性的东西 -
适合开发经理看 -
内容很实用，但是作为我来说，我的做法比他们的更加令我满意。 -
多年敏捷图书中排名第一。值得收藏。 -
感觉不如software estimation这本书，可能是因为我更关注估计的原因吧。 -
真是无聊 -
这本书断断续续看了很长时间, 内容非常不错, 基本涵盖了scrum, 用户故事, 迭代计划. 是对项目进行敏捷管理的不错参考. 另外最后一章的案例分析非常赞, 前面的你可以不看, 但是案例一定要看, 看完案例基本上你就可以知道该如何操作敏捷项目管理了 -
这本书翻译的问题多多，一定要结合英文版一起看，或者直接看英文版。 -
还不错，对于故事的估算还是有帮助的。 -
最后的case不错