聊聊敏捷中的估算
@Seaborn Lee 小波老师：关于估点？
正规的估点方式是什么样的？ 如何处理上下文不足的估点活动（如只有线框图，只有title 级别的需求等，只有UI设计图） 一个新项目只有线框图，能估点么？
我遇到的问题是，tech lead 经常需要为一个非常不确定的项目估点。一般是只有整体的ui设计图，来不及等到BA拆卡写AC？ 我是这样做的
- 识别客户估点的目的？目的是安排未来的人员plan和经费申请。
- 在假设的技术栈上估点。
- 在快速识别可以估点的基本单位（model，page，component等）。
- 以估点的基本单位来估点。
- 方法基本上有（排序比较大小，参考相似项目相似技术栈等）
- 最终的往往点数需要换算成人天加上一些buffer。
- （人天项目）后续真正起项目的时候，需要在preipm 和ipm 中做详细估点。在多个迭代中让客户做功能的取舍。
再补充一下，我这样做的带来的一些负面效果。
- 等到项目开始的时候，有机会和时间做全盘的详细估点时，往往和开始的highlevel 估点有出入。（我需要花时间和找理由，让客户理解两次估点的gap是合理的）
- 如果客户找了其他的组织和个人估出来的点数远远小于我highlevel 估算出来的点数（换算人天后），我会需要接受客户的质疑。
- 如果客户找了其他组织和个人做了这个项目，结果用时也远远少于我highlevel 估算出来的点数（换算人天后），我会需要接受客户的质疑。
小波老师，我遇到一个估点的问题，不是特别华丽。我们组是按照complexity为基准来估点，但是客户因为report和预算的需要，需要换算成人天。比较麻烦的是，我们组feature级的估点往只基于1ba，1dev和1qa，而不是整个组。有没有什么好的实践，能够来转换不同估点方式估出的点数呢？
所以其实是两个问题: 1. 基于complexity的点数如何和基于人天的点数比较合理的转换; 2. 我们组这样的估点方式实际上科学吗？
估算的问题确实比价难解决的，我也遇到过类似的问题。 正常来说估算是基于story的大小，估算之估算工作量，这样每个团队成员对于工作量的评估近似一致，使用参照物法可以达到。但是我们在实际操作中还是有些问题， 1） 一些功能需要更精确的估算，velocity的计算会出现偏差，比如一些初级开发，做了一些比较复杂的story，虽然工作量不变，但花的时间会查很多， 虽说长期来说，velocity会趋于稳定，但是实践起来比较难 2) 团队成员对估算的理解需要时间， 这也会引起估算不准确。 我的做法是基于时间来估算，时间的点数也按照fibonacci增长，sprint planning的时候，把任务分配给每个人，估算开始已team开始，但最终的point是由真正做的人最后确定。然后再确实sprint的环节，基于历史完成的点数确定sprint的内容，因为都是每个人自己估算的，所以每个人每周的点数是近似固定。这样的话，基本上能够规划出确定的几个sprint。对于中期计划比较好
其实现在我自己遇到一个问题就是做项目的需求评估不够准确，经常出现延期，尤其是初始团队而言，仅仅几个人，很多流程没法和大公司那样规范化，同时有些问题是在实际做后才发现，那么团队的开发效率自然就拉低，很难高效起来，小波老师从您的角度来说，有什么建议吗
为什么要做预估？
利益相关人，需求方）：我要花多少钱？ 制定合理的发布计划， 交付负责人 团队成员
原则 模型 操作