19、敏捷开发中的故事点、速度与燃尽图运用

敏捷开发中的故事点、速度与燃尽图运用

1. 范围与进度衡量

在协助团队实施敏捷方法时，部分团队成员难以理解用故事点“估算”用户故事。这与理解故事点所带来的相对规模有关，有些成员（包括管理层）希望将故事点与天数或小时数对应起来。实际上，使用“估算”一词会让人联想到传统的以进度为衡量标准（小时、天、周、月、年）的估算方式。

在敏捷开发中，建议用“规模”来衡量用户故事，因为这与所构建的功能量相关。这不仅仅是语义上的区别，它使我们摆脱以进度为王的传统思维，转向更重要的范围关注。对客户而言，功能才是有价值且愿意为之付费的，虽然进度和范围之间总会有取舍，但满足客户需求范围并提供价值的可用软件更为重要。

以下是相关要点总结：
- 故事点是一种抽象的范围衡量方式，专注于工作本身，不宜用小时和天等进度衡量方式，而应使用故事点来表示工作的数量和复杂性。
- 敏捷开发旨在根据为故事构建的功能确定工作的单位规模，范围是基于工作量和工作复杂度的进度衡量标准。试图用进度衡量范围就像方枘圆凿，最终需要范围（故事点）和进度（每个冲刺的长度）来了解团队的工作节奏（速度）。

2. 故事点

故事点是一种相对衡量方式，用于表达功能量和工作复杂性。每个团队会根据自身的工作类型、技能和经验，以及对小、中、大规模工作的个人认知，创建自己的故事点规模框架。所以，管理层不应比较不同团队的故事点速度。

这种相对规模框架使关注点从实际的进度衡量（小时或天）转移到描述功能与其他功能相比的规模和复杂性上。如果熟悉功能点，故事点的作用与之类似，都是试图确定工作的单位规模或范围。

以下是相关要点总结：
- 故事点规模框架是每个团