敏捷其实很简单（13） 纠结的故事点

彼此上篇文章说完了计划会议，我们今天来一起探讨一下计划会议里面一个很重要的环节，那就是故事点的估计。

故事点这个概念大家应该很了解了，实际上就是对在sprint里面要开发的user story进行一个粗量级的估算，以便于团队能够知道这个user story的复杂度（工作量），但是这里有个容易引起混淆的地方，就是传统意义上的敏捷，是用来度量规模和复杂度。使用‘规模’和‘复杂度’这两个词，是要表达‘用完成任务所需时间来表示难度’。

从上面可以看出，由于故事点事对于规模和复杂度的估算，所以，首先他是一个不精确的值，第二，它应该是一个相对的值，由此来看，故事点是一个粗略的相对估算而不是精确估算。

那么故事点的估算目的是什么呢

作为PO来讲，他在梳理ＰＢＩ和ＳＢ的时候，可能是想知道团队多久能交付产品，每个迭代能够交付多少用户故事，所以故事点可以解决ＰＯ的这个困惑。我们可以通过估算故事点，然后统计多个迭代团队交付的故事点数，然后相对的得到一个团队的交付能力，比如说每个迭代交付２０个点的用户故事，那么如果PO有一个由100点的用户故事组成的产品，那么可以得知5个迭代完成这个任务。

也可以得到团队的交付速率和交付能力的历史数据，用来进行团队回顾的数据依据。

在估算的过程中，因为所有团队成员都要参与，大家对于故事的理解不一样会造成估算的不同，这样就需要PO和团队成员之间进行需求的澄清，也是一个分析用户故事需求和澄清的过程，能够让大家更好的理解用户故事。

故事点估算的到底是工作量还是复杂度

在现实开发环境中，大家往往会有一个理解上的难点，到底故事点估计的是工作量还是复杂度呢？
从PO角度来讲，肯定需要得到的是工作量，这样也能第一时间知道产品开发的进度还有风险，但是如果估计的是工作量的话，那么要和实际开发的人有关系的，因为同样一个特性，对于熟练工和新手的工作量是完全不同的。

如果只是作为复杂度来估计的话，那么产生的问题是：产品开发的复杂度在不同团队和不同人员之间也是不一样的，而且在现实开发环境中，对于复杂度的操作很难进行，有的时候大家会觉得费时费力。

从我个人来讲，在敏捷不断演进的过程中，现在故事点实际上是一个综合的对于用户故事的复杂度，规模，甚至还要加上承诺时间的一个度量了。也就是说团队可以不必过度纠结在用户故事的度量上，而是重点放在当前迭代里能否按照该用户故事的接收条件和团队定义的ＤｏＤ来完成这个用户故事，如果不能完成，给出理由，由ＰＯ来决定是否拆分或者重新设计用户故事。这样带来的一个问题可能是ＰＯ在梳理ＰＢＩ的时候无法得知整个产品的全部完成时间，因为团队的历史交付数据可能不是一个稳定的速率（每个ｓｐｒｉｎｔ交付的点数差别会比较大，因为更注重用户故事本身和交付承诺）

怎样更好的运用故事点估计在计划会议中

可以分为几种情况：
1. 如果是新的一个团队，那么建议针对用户故事进行估点，这样一个能够使得团队尽快的熟悉起来，澄清需求，建立很好的沟通机制。
2. 如果是一个很成熟的团队，对于产品比较熟悉，那么这个时候故事点估计就不是十分必要了，因为大家都很熟悉产品特性，所以对于所需的工作量也是相对准确的，这个时候可能就需要团队给出工作量的估计，让ＰＯ对于产品的开发更好的进行进度和风险控制。
3.如果可能的话，针对不同的用户故事类型设计不同的基准故事点，比如说开发的故事基准和测试的故事基准，实际上的工作量和复杂度是完全不一样的。