聊聊敏捷中的估算

@Seaborn Lee 小波老师:关于估点?

正规的估点方式是什么样的?
如何处理上下文不足的估点活动(如只有线框图,只有title 级别的需求等,只有UI设计图)
一个新项目只有线框图,能估点么?

我遇到的问题是,tech lead 经常需要为一个非常不确定的项目估点。一般是只有整体的ui设计图,来不及等到BA拆卡写AC?
我是这样做的

  1. 识别客户估点的目的?目的是安排未来的人员plan和经费申请。
  2. 在假设的技术栈上估点。
  3. 在快速识别可以估点的基本单位(model,page,component等)。
  4. 以估点的基本单位来估点。
  5. 方法基本上有(排序比较大小,参考相似项目相似技术栈等)
  6. 最终的往往点数需要换算成人天加上一些buffer。
  7. (人天项目)后续真正起项目的时候,需要在preipm 和ipm 中做详细估点。在多个迭代中让客户做功能的取舍。

再补充一下,我这样做的带来的一些负面效果。

  1. 等到项目开始的时候,有机会和时间做全盘的详细估点时,往往和开始的highlevel 估点有出入。(我需要花时间和找理由,让客户理解两次估点的gap是合理的)
  2. 如果客户找了其他的组织和个人估出来的点数远远小于我highlevel 估算出来的点数(换算人天后),我会需要接受客户的质疑。
  3. 如果客户找了其他组织和个人做了这个项目,结果用时也远远少于我highlevel 估算出来的点数(换算人天后),我会需要接受客户的质疑。

小波老师,我遇到一个估点的问题,不是特别华丽。我们组是按照complexity为基准来估点,但是客户因为report和预算的需要,需要换算成人天。比较麻烦的是,我们组feature级的估点往只基于1ba,1dev和1qa,而不是整个组。有没有什么好的实践,能够来转换不同估点方式估出的点数呢?

所以其实是两个问题: 1. 基于complexity的点数如何和基于人天的点数比较合理的转换; 2. 我们组这样的估点方式实际上科学吗?

估算的问题确实比价难解决的,我也遇到过类似的问题。 正常来说估算是基于story的大小,估算之估算工作量,这样每个团队成员对于工作量的评估近似一致,使用参照物法可以达到。但是我们在实际操作中还是有些问题, 1) 一些功能需要更精确的估算,velocity的计算会出现偏差,比如一些初级开发,做了一些比较复杂的story,虽然工作量不变,但花的时间会查很多, 虽说长期来说,velocity会趋于稳定,但是实践起来比较难 2) 团队成员对估算的理解需要时间, 这也会引起估算不准确。 我的做法是基于时间来估算,时间的点数也按照fibonacci增长,sprint planning的时候,把任务分配给每个人,估算开始已team开始,但最终的point是由真正做的人最后确定。然后再确实sprint的环节,基于历史完成的点数确定sprint的内容,因为都是每个人自己估算的,所以每个人每周的点数是近似固定。这样的话,基本上能够规划出确定的几个sprint。对于中期计划比较好

其实现在我自己遇到一个问题就是做项目的需求评估不够准确,经常出现延期,尤其是初始团队而言,仅仅几个人,很多流程没法和大公司那样规范化,同时有些问题是在实际做后才发现,那么团队的开发效率自然就拉低,很难高效起来,小波老师从您的角度来说,有什么建议吗

为什么要做预估?

利益相关人,需求方):我要花多少钱?
制定合理的发布计划,
交付负责人
团队成员

原则
模型
操作

适应性计划还是预测性计划

关注宏观而不是微观

KPI 的利弊

预先分配工作的问题

高效和延期是两回事

如果不做估算呢