《敏捷估计与规划》笔记

猫time
2020-01-26 看过

本书一共分为7个部分,23章。每个章节都总结了本章的关键点,并提出了一组可供讨论的问题。作者建议,如果是一个团队在用本书进行学习的话,最好每周都来开个会来讨论这些章节后的问题。

第一部分 主要讲的是为什么做计划很重要,以及(关于计划这件事)我们经常遇到的问题,以及敏捷方法所要达到的目标。

第1章,以“计划的目的,以及什么是好计划、如何让计划敏捷”开头。

第2章,讲的是传统的计划方式为什么会让事情的结果让人不满。

第3章,重述了“什么是敏捷”,简述了后文所述的高级敏捷估计与计划的方法。

第二部分 介绍了评估的主原则,即:对(事件)大小与持续时间的评估应当分开做。

第4章和第5章介绍了故事要点理想天数,这两个单位适合于估计要开发的功能的大小。

第三部分“价值规划”提供有关项目团队如何确保他们正在构建最佳产品的建议。

第9章介绍了对功能进行优先级排序时需要考虑的各种因素。

第10章介绍了一种对来自功能部件或功能部件集的财务回报进行建模的方法,并介绍了如何比较各个项目的回报以对最有价值的工作进行优先级排序。

第11章提供了有关如何评估产品用户对功能的需求并对其进行优先级排序的建议。

第12章在结尾部分提供有关如何将大型功能拆分为较小的,更易于管理的功能的建议。

第四部分中,我们将注意力转移到围绕计划项目的问题上。

第13章首先介绍安排一个相对简单的单团队项目所涉及的步骤。

第14章研究如何计划迭代。

第15和16章介绍了如何为项目选择合适的迭代长度以及如何估算团队的初始进度。

第17章详细介绍了如何在不确定性较高或对进度表有较大误解的情况下计划项目。

本部分以第18章结尾,该章描述了估算和规划多个团队正在研究的项目所需的其他步骤。

第五部分三章的主题,是一旦制定了计划,就必须将其传达给组织的其他部门,并监督团队针对该计划的进度。

第19章专门研究发布计划的追踪;

第20章专门研究迭代计划的追踪;

第21章专门讨论计划的制定和进度。

第六部分

第22章(第六部分的唯一一章)。

本章讨论了为什么进行敏捷估计和规划的情况,并与第二章相对应,第二章描述了为什么传统方法如此频繁地失败。

第七部分(最后一部分)也仅包含一章。

第23章是一个扩展的案例研究,它重申了本书的要点,但在虚构的背景下进行。


第一章 做计划的目的

计划可以然我们提前考虑一个项目的总时间、总金钱投入。如果过多,可以选择不做。

计划可以让我们知道,对于一个特定的项目,某个人在指定时间段内是否应当处于可工作的状态(分配任务)。

计划让我们知道一个项目是否正按预期执行,以向用户提供他们所需和想要的功能。

没有计划,我们相当于将我们的项目向无数个问题敞开了怀抱。

然而做计划很难,而且计划常常是错的。团队常常走极端来处理这个问题:

1要不不计划

2要不计划好后花了过多精力追随计划,以至于他们确信自己的计划不可能是错的。

不计划的人,回答不出来很多基本问题:“你什么时候能做完?”“我们能计划在6月发布它吗?”

计划过度的人常常觉得一切计划都可以是“正确的”。他们的计划可能会更详细,但并不一定会更准确,或更有用。

项目时间预估的难度:In 1981, Barry Boehm drew the first version of what Steve McConnell(1998) later called the “cone of uncertainty.”

随时间推移,项目的日程越来越确定。在一开始的时候,对于项目所需时间的预估,最高与实际相差可能是在+60% to -40%。

The Project Management Institute (PMI) 认为预估的差异会在+75% to -25%;对预算的预估与实际相差可能+25% to -10%。

估算和规划不仅仅是确定适当的期限或时间表。 计划(尤其是计划的一种持续迭代方法)是对价值的追求。

计划是为了找到针对整个产品开发问题的最佳解决方案的尝试:我们应该构建什么?为了回答这个问题,团队会要考虑功能,资源和时间表。 这个问题不能一次全部回答。 必须以迭代(依次列举)和渐进方式回答。 在项目开始时,我们可能会决定某个产品应包含一组特定的功能,并于8月31日发布。但是在6月,我们可能会决定将功能稍多一些的日期稍晚一些会更好。 或者我们可能会决定,功能越少、越早发布越好。

一个好的计划可以从几个方面给我们提供支持:

·减少风险。

当你了解了一些项目的风险,你可能一开始就不会去做那个项目;或者很多风险被早期注意到,就容易避免。比如将新项目与我不了解的老系统所结合,我就可以将这块预估的工作量加大,从而避免风险。

·减少不确定性。

团队开发新功能时,产生了各种关于产品本身及团队自身等等的新的知识。这些新的知识需要被纳入计划中,并让所有人知道计划的变更,才算是做好敏捷计划,才能做出正确的东西来。如果我要定义一个失败的项目,那么我的标准之一当然应该是“没有产生比最初的需求清单上的想法更好的想法的项目。”(因为在执行中总会有新的信息、新的想法)我们要鼓励那些投资,进度计划良好的项目 ,并定期重新评估要开发的功能的决策。 在初始计划中提供所有功能的项目不一定成功。 如果仅因为中等或平庸的功能已经在最初的计划中而拒绝了奇妙的新功能,而偏爱中等或平庸的功能,那么产品的用户和客户可能就不会满意。

·帮助做出更好决策

相当于做提案给领导看,领导才能选出哪个项目更值得做,或是否可以同时做,或都不做。

有时,项目的人员配备状况可能比计划时间表更为重要。例如,如果一个项目涉及到组织的首席架构师的时间,而他已经完全致力于另一个项目,那么该项目就可能不值得一开始。 但是,如果可以制定一个计划来显示如何在没有该架构师参与的情况下完成新项目,那么该项目可能值得开始。

计划项目时做出的许多决定都是权衡的决定。

例如,在每个项目上,我们都会在开发时间和成本之间做出权衡决策。开发系统的最便宜的方法通常是雇用一名优秀的程序员,并允许她十或二十年的时间来编写系统,允许她绕道而行数年以掌握该领域,成为数据库管理方面的专家,等等。但是,显然,我们很少等待二十年才能建立一个系统,因此我们要与团队合作。一个三十人的团队可能要花一年(三十个人年thirty person-years)的时间来开发一个孤独的程序员可能会在二十中完成的工作。开发成本增加了,但是十九年前拥有应用程序的价值将成本的增加合理化了。

我们一直在功能,工作量,成本和时间之间做出类似的权衡决策。值得延迟发布的特定功能吗?我们是否应该再雇用一个开发人员,以便在即将发布的版本中包含特定功能?我们应该在6月发布还是推迟到8月发布并具有更多功能?我们应该购买这个开发工具吗?为了做出这些决定,我们需要估算成本和收益。

·传达信息、建立信任 让顾客相信你可以做完它。

假设您问我什么时候完成一个项目。 我告诉您七个月,但没有提供有关我在这段时间内到达的方式的说明。 您应该对我的估计表示怀疑。 没有其他信息,您将无法确定我是否已经充分考虑了这个问题,或者我的估计是否现实。

相反,假设我为您提供了一个计划,该计划将估计在7到9个月内完成,显示在前一或两个月内将完成哪些工作,记录关键假设,并建立一种方法来协作评估进度 。 在这种情况下,您可以查看我的计划并得出有关您应该对此有信心的结论。

-什么是好计划?

能对需要开发的功能给出明确的截止日期,且计划日期与截止日期相差不大的计划。

-什么让计划变得敏捷?

发现错误,更改计划中的错误。将“做一个计划”,变成持续修正、迭代计划。

因此,在定义敏捷计划时,我们发现它:

◆相比做一个计划,更注重做计划这个行为

◆鼓励改变

◆制作易于更改的计划

◆遍及整个项目

计划的目的是找到关于构建什么的整体产品开发问题的最佳答案。 这个答案包括功能,资源和时间表。回答此问题的计划过程可以降低风险,减少不确定性,支持可靠的决策制定,建立信任并传达信息。良好的计划是足够可靠的计划,可以用作做出有关产品决策的基础 和项目。 敏捷计划更着重于计划,而不是计划的创建,鼓励变更,产生易于更改的计划的结果,并遍布整个项目。


0 有用
0 没用

查看更多豆瓣高分好书

评论 0条

添加回应

敏捷估计与规划的更多书评

推荐敏捷估计与规划的豆列

了解更多图书信息

豆瓣
免费下载 iOS / Android 版客户端