<>强敏捷估算的基础:
- <李>为什么要估算:估算可以让团队了解项目规格计算ROI和IRR,形成可执行许可的基础,有了估算,市场也可以提前的为后期产品上市做准备; <李>谁执行估算?:产品负责人,敏捷教练;李 <>李会议什么时候进行?自然是越快越好,在整个项目进行之间,同样随着逐步完善更多的信息,估算也要持续进行。敏捷提倡:拥抱变化,那既然拥抱变化,估算也要做调整,该加人手就要加人手。不要一味指望加班来压缩成本,随着90后,00后步入市场,这一代更注重生活品质,毕竟工作是为了生活,李 <>李估算如何创建?方式有多种:从各个维度,如时间,人工,物料等方面入手,李 <李>相对尺码:主要用于用户故事上,李 <>李价值点:交付价值和成果。也只有交付可用的软件,将客户利益最大化,客户才会把尾款付给我们。
<强>项目规模测量:强通过代码量,时间维度,人力维度,功能复杂性几点考虑。
- <李>故事点:是相对测量,相对独立,相互进行对比,李 <>李分配故事点要考虑:复杂性,投入量,风险等因素,李 <>李故事点估算的步骤:故事应拆分为小的,独立的。每个故事应由一个人不超过两天的时间内完成,否则,就会陷入胶着状态,其代价往往是巨大的。同时团队要达成共识,敏捷是一种思想,需要团队成员转变思想,有一个人员掉线,就会影响行进速度和稳定向。在过程中需要不断的对话,协调,改进(年假,事假等未知因素,往往会影响团队的进度和故事点的完整性)。
<强>故事点之类比估算:讲一个故事和其他故事相比,如果故事类似,其精确性,完成时间不能相差太大,同时建议研发团队一起评估,避免一言堂。
- <李>理想日:没人任何打扰,所有信息都可用的情况下专注的进行唯一一项工作,很多企业提倡多面手,即一个人可以做一个岗位也可以做B岗位,认为这种就是高效?这是错误的,试想一下,编码10分钟开会1小时,开会想着编码,编码想着准备开会的发言。嘿嘿……代价也蛮高的，奇怪的是很多企业高层选择视而不见，没人向CEO提出这种不良现象。
- “编程10分钟，吹水1小时”通过这句玩笑，我们可以看出，研发人员不是机械的工作是创作，就要保持一个相对私密的空间，不受外部的打扰。这里多说几句：”很多初次走上管理岗位的研发兄弟们，往往会犯一个错误，亲自上阵；对各项评估会议不屑一顾，认为是瞎搞。这其实是思维没有转变过来，岗位的高度，决定岗位日常所要工作的重点。管理岗位的重点是规划、协调、避免风险、掌控进度，而不是亲自介入进来开发。用一句话总结：进化成人了，别再用猴子的思维了，你要关注的是一片香蕉林，而不是一两个香蕉的好坏“。
故事点和理想日的对比：更有助于驱动跨职能行为（协调资源、答疑等等支持行的工作）；故事点的估算不会衰败：通过不断的对话确定思想统一；故事点特性：挟制了估算时间的增长。后者：有差异，来自团队成员；理想日的不确定性，会使外界认为是靠谱的，事实上即为不靠谱。
估算规模：敏捷评估建立在合理的预测估算，不应追求100%的精确性。有以下几种方法：
- 宽带德尔菲：用来收集项目的准确估算，在会议中只讨论估计是可能会遇到的问题，估计本身和所花的成本不做讨论。会议结束后，团队每个人进行单独的估算，一定要独立，拒绝结对式的估算。组员估算完毕后，收集所有估算，并在画表中画出来，展示差异，进行讨论。需要注意的一点，这是匿名的，即不要展示其姓名，记得有一次，集团做满意度调查，调查卷上还有姓名一栏，结果也如我所料，行政部门收集到的是100%满意。真正的问题反而被遮盖，失去本应起的作用，这是一种浪费。
- 步骤：团队选择组建成员、启动会议：讲明游戏规则和进行的程序、个人准备、估算会议、配置任务：收集估算单，汇总、任务评审：找出差异，达成共识。
- 计划扑克：由于本人极度反感扑克和麻将，这里不介绍，自己百度；
亲和估算：主要用来进行大规模的估算，优势：快速、简单、决策制定过程透明可见、积极合作而非对抗；
步骤：
- 沉默的相对尺码：产品负责人提供产品待办事项，排列在墙上，由组员考虑每样物品在执行中所花费的时间、付出的努力。不讨论技术；
敏捷估计与规模测量
