《敏捷软件开发实践：估算与计划》第21章 关于计划的沟通，重点和要点的思维导图及文字内容。
第21章 关于计划的沟通
The more elaborate our means of communication the less we communicate.
我们希望所有的沟通(尤其是有关估算和计划的沟通)是频繁的、坦诚的和双向的。
因为敏捷计划是频繁更新的，所以频繁地就计划进行沟通很重要。
如果开发团队和客户团队希望彼此信任，坦诚的沟通就很重要。
我们鼓励针对计划展开对话和讨论，并根据反馈和新知识对计划进行迭代和细化。
我们要承担起让所有接收者都理解我们所传递的信息的责任。他们不仅需要听到有关的信息，还需要理解它。
敏捷开发团队通常使用大幅的、可见的图表作为沟通手段，即在团队的工作区中悬挂几张大幅的、可见的图表，项目团队的每个人都能了解每张图表显著传递的信息(信息发射源)。
21.1 就计划进行沟通当我们就项目进度表与相关方进行沟通时，应该包含团队对这个估算的确信程度，或者包含可能的日期范围，或者两者都包含。
在传统项目中，甘特图通常用于预测、编排和协调任务。在敏捷项目中，我们可以利用甘特图很好地显示分派到各次迭代的特性。
在敏捷项目中，我们将甘特图停留在特性层面，不把每个用户故事分解成它的组成任务。即显示项目的特性分解结构(feature breakdown structure)而不是工作分解结构(work breakdown structure)。因为产品价值的增加是来自于特性的完成，而不是由组成特性的任务的完成所带来的，所以只显示到特性即可。
敏捷项目的甘特图中，每个特性都占据了它所编排进的迭代的整个长度。因为无论特性在迭代中任何时候完成，都不会在迭代结束前就提供。
敏捷项目的甘特图中不显示对资源的分配。因为在敏捷项目中，由整个团队负责交付所有的特性。
21.2 就进度进行沟通
沟通项目进度的主要方法是发布燃尽图。
发布燃尽图上显示的进度是剩余工作量和团队速度的一个函数。
预测剩余迭代次数的简单方法就是将还要开发的点数除以团队的速度，然后把它向上舍入到最近的整数。
团队对速度的测量是不精准的，而且我们预期速度会发生波动。
在预测剩余迭代次数时，通常最好是使用可能的速度范围。
选择速度范围的方法，是使用团队在过去 8 次迭代中的速度。在选择速度值范围时，建议最多考虑过去 8 次迭代。如果团队没有 8 次迭代，就使用所有的迭代。
在 8 次迭代中寻找 3 个值：
1. 最近一次迭代的速度。
2. 平均速度。
3. 最慢的 3 次迭代的平均速度。
这 3 个值很好地描绘出刚发生的情况、“长期”平均的情况和最坏条件下可能发生的情况。使用这 3 个不同的速度值来预测在给定日期之前可以完成工作的大致数量。
21.3 迭代结束总结
每次迭代结束后可以用不到 30 分钟的时间来完成小结。对于使用 2 周长度的迭代，意味着每周花在写报告上的时间最多只有 15分钟。
21.4 小结
我们希望针对估算和计划进行的沟通是频繁的、坦诚的和双向的。
甘特图可以用作对计划进行沟通的有益工具，在甘特图中应采用特性分解结构而不是工作分解结构，并且图中的特性应该显示为在整个迭代持续期内都在进行处理。
燃尽图是对进度进行沟通的主要手段，但还需要有一个图显示开发团队在每次迭代中的速度。
把速度考虑成一个取值范围而不是单个值是有益的。
考虑速度的取值范围的好方法是同时使用最近一次迭代的速度、前 8 次迭代的平均速度和前 8 次迭代中最差的 3 次迭代的平均速度。这 3 个值很好地描绘出刚发生的情况、长期平均的情况和最坏条件下可能发生的情况。
迭代结束总结可以传递当前信息，也可作为供将来使用的历史文档。
版权声明
本人所读图书的版权属于原著者和译者。这里仅为个人学习使用。但由本人学习整理所形成的音频、图片、文字和视频等的版权为本公众号拥有，任何人不得未经授权转载。 如果你觉得本文有用，欢迎分享给其他人。谢谢。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
