《敏捷软件开发实践：估算与计划》第22章 敏捷计划有效的原因，重点和要点的思维导图及文字内容。
第22章 敏捷计划有效的原因
If you want a guarantee buy a toaster.
计划是尝试为产品开发综合问题——特性、资源和进度——寻找出最佳解决方案。其中任何一点发生变化都会牵一发而动全身。
在做计划时，我们是在对所有潜在的解决方案范围进行探索，找出如何组合这 3 个参数以便尽可能创建出最佳产品的方法。
我们制订的估算和计划必须足以成为公司做决策的基础。
22.1 经常重新计划当每次新迭代开始时，团队都要创建当前迭代的计划。
团队通常在每次迭代之后更新发布计划，至少每隔几次迭代就更新发布计划。
承认我们不可能建立一个完美的计划，可以大量地减少伴随着这样一个目标的焦虑。
当团队知道可以在下次迭代时修正计划，就会把关注点从建立完成的计划(一个不可能的目标)转移到建立当前有用的计划上来。
计划要有用，就必须是准确的，但是我们应认可早期的计划通常是不精确的。重新计划的原因之一是要逐步地消除这种不精确性。
我们的知识总是不完整的，所以在我们了解到更多的知识后，就有必要修正计划。计划要保持有用，就需要把了解到的新知识结合到计划中。
22.2. 对大小和持续时间的估算是独立的
虽然某项工作的大小及其完成时间有关系，但是很多其他因素会影响到持续时间。对具有不同技能和经验水平的开发人员来说，同样大小的项目所需的时间是不一样的。相应的，项目的持续时间会受到负责这个项目的团队规模的影响。
通常我们需要先估算大小，再估算持续时间。
敏捷估算和计划之所以会成功，是因为对大小的估算和对持续时间的估算是独立的。主要分三步：
一，使用故事点来估算项目中用户故事的大小。故事点是抽象的概念上的，它是纯粹的对大小的估算。
二，估算进度率，即速度。
三，把我们对规模和速度的估算结合起来，得到对持续时间的估算。
22.3 在不同层次上制定计划
敏捷计划覆盖 3 个不同的层次：发布计划、迭代计划和每日计划。这三个计划可以具有不同水平的精度。
使用具有不同时间范围和不同精度水平的计划的好处有两个：
一，不同计划用于不同目的。
每日计划是由每个团队成员在团队的每日例会上承诺的，相当精确：每个人表示他承诺在当天完成某项特定任务，或者至少是取得进展。
迭代计划相对每日计划没有那么精确，只列出将在一次迭代中开发的用户故事，和为了完成这些故事被认为是必需的任务。
发布计划是 3 个计划中最不精确的，它只包含一个期望的用户故事的优先级列表，和一个或几个关于在要求的发布日期前可能交付多少期望的功能的估算值。
二，帮助开发团队从不同角度来看待这个项目。
一个跨功能的开发团队要在一次短时间的迭代内完成高度协调的工作，迭代计划是必需的。
发布计划为项目提高更宽广的视角。如果迭代计划是一棵树，那么发布计划就是一片森林。
22.4 基于特性而不是基于任务制定计划
传统计划(通常以甘特图、PERT图或工作分解结构形式出现)着眼于创建一个产品所需的任务。
敏捷开发计划着眼于产品中所需要的特性。这就使得敏捷团队在正确的层次，即特性上来考虑产品。
以迭代方式开发特性时，团队可以少做一些关于特定任务的预先考量。开发团队可以在需要时才考虑或发现所有的任务。更重要的是让团队思考正在开发的特性。
22.5 小故事保持工作流畅
周期时间(cycle time)是指一件事从开始处理到结束处理所需要的时间长度。
在软件开发项目中，周期时间是团队开始处理一个功能到这个功能可以向用户交付价值的时间。周期时间越短越好。
开发新特性所需时间的差异性是影响周期时间的一个关键因素。把要处理的工作分解成相当小规模的单位是减少差异性的最好方法之一。
建议团队在大约一个数量级内估算他们的短期工作。
在项目的需求优先级列表更低的地方，可以有更大的用户故事。
随着故事逐渐接近优先级列表的顶部(快要编排进即将开始的迭代时)，要将它们分解成较小的故事。
22.6 每次迭代都要消除未完成的工作
大量未完成的工作(work in process, WIP)会减慢团队的开发速度。在软件项目中，团队已经开始开发但尚未结束的所有特性中都存在未完成的工作。
处理中的工作会导致周期时间的增加。
在每次迭代结束时会消除所有未完工的工作是敏捷计划取得成功的原因之一。
在每次迭代开始时消除了未完成的工作使得团队可以更容易采用短迭代来有效地工作。这意味着从用户到项目团队的反馈环更短，使得团队对产品和项目的学习可以更迅速，而对风险的缓解和控制也更及时。
22.7 在团队层次跟踪
传统估算和计划方法在团队成员的个人层次上对进度进行度量和奖励。
敏捷估算和计划通过只在团队层次上跟踪进度。相应的，不要准备个人燃尽图，而只绘制团队层次的燃尽图。
22.8 承认不确定性并为之计划
采用敏捷估算和计划方法时，开发团队承认存在目标不确定性和方法不确定性。
目标不确定性(关于最终构建的产品)随着在每次迭代结束时把产品的增量展示给潜在用户和其他的项目相关方而降低。他们的反馈和反应有助于对未来的计划进行精细的调整。
方法不确定性(关于如何构建产品)随着团队更深入的了解使用的技术和团队自身而减少。
22.9 敏捷估算和计划的 12 条指导原则
1. 让整个团队参与
某些特定活动的主要职责可能会落在某个人或某个团队的身上，但在追求可能具有最高价值的项目时，整个团队都应该参与进来并做出承诺。
团队成员间分担的职责越多，团队可能共享的成功也就越多。
2. 在不同层次上进行计划
发布计划、迭代计划和每日计划分别以不同的精度覆盖了不同的时间范围，而且各有其特定的用途。
3. 使用不同度量单位，让对大小和持续时间的估算保持独立
最好的方法是使用不会造成混淆的独立度量单位。
使用故事点来估算大小，再使用速度把大小转换到持续时间是完成这一工作的好办法。
4. 用功能或日期来体现不确定性
没有哪个计划是确定的。
要确保在你制定的任何发布计划中都包含对不确定性的体现。
若新功能的数量是固定的，就把不确定性表示为一个日期范围。
若日期是固定的，就在要交付的明确功能上表示出不确定性。
当不确定性比较大时，就使用较大的单位。例如，迭代、月、季度。
5. 经常重新计划
在每次新迭代开始时评估当前发布计划的相关度。
如果发布计划是根据过时的信息或现在被证实为错误的假设制定的，就更新它。
使用重新计划的机会来保证项目总是瞄准着为公司交付最大价值的方向。
6. 跟踪进度并沟通
通过经常发布关于团队进展的简单而易于理解的指示器来让项目相关方了解进度。
燃尽图和其他让人一眼就能看明白的项目进度指示器是最好的。
7. 承认学习的重要性
项目既能向产品增加新能力，也能产生新的知识，因此必须更新计划来包含这些新知识。
随着我们更多地了解客户的需要，新的特性会增加到项目中。
随着我们更多地了解我们使用的技术或协作的情况，我们会调整对进度率的期望和希望采用的方法。
8. 计划具有适当大小的特性
在不久的将来(接下来的几次迭代中)就要增加的功能应该分解成相对较小的用户故事：往往是只需要 1~2 天，最多不超过 10 天的故事。
我们最善于估算大小处于一个数量级以内的工作。让用户故事都处于这一范围内，可以让我们在估算和计划中付出的工作量和得到的准确度达到最佳的组合。足够小的用户故事可以让大多数团队在一次迭代中完成。
若建立的发布计划覆盖的时间范围超过 2~3 个月，可以编写一些更大型的故事(如史诗)或使用主题来对时间更遥远的工作进行估算，从而避免过于提前把大故事分解成小故事。
9. 确定特性优先级
按照让项目总价值最高的顺序来开发特性。
确定优先级时除了考虑功能的价值和成本，还要考虑它能带来的学习效果以及开发它能够减少的风险。通常价值高风险也高的特性应该优先开发。
若开发特定的功能可以让团队获得大量关于产品或关于开发产品的知识，团队也应该考虑尽早开发这个功能。
10. 最好的估算和计划来源于事实
只要有可能，就要把你的估算和计划建立在现实基础上，即应该根据真实的测量值来建立估算和计划。
我们很容易知道一个特性完成了 0%，即我们还没有开始处理它；也很容易知道特性已经 100% 完成了，即产品负责人的所有满意条件测试都已经通过了。但在这两者之间就很难度量，花过多时间去度量无益，最好坚持只要未完成的都为 0%，只有完成了的为 100%。
11. 保留一些松弛度
在计划一次迭代时，不要计划用掉所有团队成员 100% 的时间。
如果将所有人的时间都计划成满负荷工作，开发团队的进度也会减慢。
12. 通过前瞻性计划协调多个团队
在涉及多个开发团队的项目时，应该通过滚动性前瞻计划来协调他们的工作。
通过提前观瞻以及把特定的特性分派到即将到来的特定迭代，团队间的依赖就可以很好地计划和调节。
22.10 小结
敏捷计划的目的是以迭代的方式为产品开发的综合问题寻找到最佳解决方案，即在哪段时间内使用哪些资源来得到哪些功能？
敏捷估算和计划方法可以成功找到这样的解决方案的原因包括：
计划是在不同层次上做出的，并且频繁地重新计划；
计划是根据特性而不是根据任务做出的；
首先估算大小，然后根据大小的估算值推算出持续时间；
小故事保持工作的流动，而且每次迭代结束时会消除未完成的工作；
在团队层次而不是个人层次对进度进行试题；
承认不确定性并为之做计划。
版权声明
本人所读图书的版权属于原著者和译者。这里仅为个人学习使用。但由本人学习整理所形成的音频、图片、文字和视频等的版权为本公众号拥有，任何人不得未经授权转载。 如果你觉得本文有用，欢迎分享给其他人。谢谢。
2030
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
