我在技术文化团队的估算实践

在我做敏捷教练相关的工作以来，有一个实践一直困扰着我，那就是估算到达该如何有效导入？在辅导团队过程中也一直有在探索，但大多都是失败告终。今年终于有机会在技术文化的团队完整的将估算实践成功导入，并且达到了预期的效果。我觉得有必要总结一些到底真正发挥作用的东西是什么。

1、如果没有固定的迭代周期，谈估算有没有意义？

我觉得意义不大，因为固定的工作周期，我们就很难度量团队的velocity，不知道velocity的话我们有了估算，也不知道预测一个迭代能做多少事情。

2、合适引入估算的时机是什么？为什么不要在团队刚启动的时候引入估算。

第一个原因是团队刚启动的时候，对所做的事情没有经验，很难找到基准需求。同时团队还需要时间消化更基础的敏捷实践（eg Scrum framework），一上来就谈估算，没有太多的上下文团队没那么容易理解。

第二是因为团队刚启动时面对更多的是探索性任务，没办法很好的对工作进行规划、预测。这个时候最重要的事情就是去响应组织的诉求，这个时候如果你采用估算，你会发现大多的事情都没办法估，因为你根本不知道他有多大，需要很多的探针需求才可以。所以更建议让团队跑过一轮，再引入估算会更合理一些。

3、没有估算的时候我们如何排期？

把所有的事情列出来，按照优先级排序。一个一个往迭代内塞，一直到团队说我做不了了就停止。

4、我是在什么场景下考虑引入估算的？带来的好处是什么？

我是在团队运转了小半年之后，所面对的工作相对比较熟悉了才考虑为团队引入估算的。当时主要的原因：

• 更合理的规划，团队每个迭代到底能做多少事情？

• 更靠谱的预测，一个项目过来我们需要多久能交付？

• 团队效能情况到底怎么样？我怎么知道团队产能是不是越来越高？

5、我具体是怎么引入估算的？

首先第1个点给团队介绍当前遇到的问题，为什么要考虑引入估算。然后紧接着和团队去介绍相对估算的概念。基于此，我们确定一个团队的估算基准估值点。

确定基准故事的方式也非常简单，找到过往的一些需求中最简单的那个需求，把它当做基准需求就可以。

有了基准点之后，我们就可以引入估算体系。最早的时候，我使用t shirt size的方式进行估算。我们将最小的基准点需求定为small的需求，然后按照SML的方式为需求进行分类。可是运转了三个迭代之后，我们发现T shirts的问题是：我们不能精确估算1个迭代能够做多少个需求？并不是每个迭代都是固定数量的S需求、M需求、L需求，而且 SML 之间换算关系也没有明确出来。

所以接下来我们尝试跟团队确定T-shirt Size 和故事点之间的映射关系，我们把small当做1，medium当做1.5，large当做3个故事点。有了这一个映射之后，我们就把相对估算的体系建立了起来。

导入故事点之后带来了哪些好处？你们的演进过程是怎么样的？

最大的好处就是迭代规划更清晰更精准了一些。另一个好处就是能够通过故事点来给团队一些压力测试，帮助团队不断拉升。隔一段时间就会尝试去拉升一下团队的效能，这个迭代我们能不能做更多的事情，能不能多接1-2点多需求？

全文完。