51Testing软件测试论坛

标题: JIRA工具之项目估时 [打印本页]

作者: lsekfe 时间: 2023-6-7 10:45
标题: JIRA工具之项目估时
项目的估时对于做整个项目规划起到至关重要的位置。
　　哪些阶段需要去做项目估时？
　　1 交付类项目初期，需要基于项目范围做规模估算，这样的估算不需要特别精确，但是要基于此估算做整个项目的成本预算和交付时间预估。
　　2 产品类项目，在产品规划初期，我们需要对产品的建设周期，回报周期有一个评估。这里也是规模估计。
　　3 如果是瀑布式开发，那么在详细设计阶段，就需要对项目进行一个精确估时，做出详细的项目计划。
　　4 敏捷开发的每个冲刺启动阶段，需要对冲刺范围做一个时间预估，以确定合理的能够交付的项目范围。
　　5 在项目运行一段时间后，发现后面的计划和前面估计的差距比较大，或者随着时间的推移，大家都变得更有经验了，对于完成时间有了新的评估，这时候也需要进行项目重估。
　　估算的两种度量方式：故事点和理想时间
　　理想时间：
　　理想时间就是自然日评估，也就是一个任务的实际完成时间，4h/1d/2d 这样的时间。在[url=]JIRA[/url]之任务分解的文章里，我们已经将故事拆解为更小的责任到人的任务了，那么下一步就是对这些任务进行工作量的评估。这里的时间评估只考虑任务本身的时间，不考虑开会，日常沟通等占用的时间。
　　评估的几种方式如下，有的虽然不那么合理，但有时候为了提高效率，还是这么实践了。
　　1 拆解后的任务分配到经办人，每个人根据任务描述评估工作量，再由团队负责人对大家评估的工作量进行审核，对不合理的评估提出异议，再由任务经办人重新评估，直到审核通过。
　　2 团队负责人或者团队中比较有经验的工程师对所有的任务进行工作量评估，再分配到经办人，经办人对于评估不合理的任务提出异议，再由团队负责重新评估，直到达成一致。
　　3 或大家以开会的形式，在会上共同评估工作量，对于评估不合适的当场给出建议。会议结束，工作量评估即确定。
　　由于一个冲刺2周的时间，团队并不是100%时间用于任务开发的，还有一些固定的会议开销，日常问题沟通开销以及不可预测的缺陷开销等等。可以用一个开发效率来表述团队实际用于任务开发的时间比率，建议值：0.7~0.8。这个值越高表示团队效率越高。
　　举例：团队6个人，2周为一个冲刺周期，6(人）*2（周）*5（天）*8（小时）* 0.7 （开发效率）= 336 manhours
　　那么冲刺范围就定位 336manhours的工作量，如果产品经理给的范围超出了这个工作量，冲刺计划会上，产品经理根据优先级调整冲刺范围，直到大致为这个工作量为止。当一次冲刺结束后，我们根据实际完成了任务情况，重新计算开发效率（300/480= 0.625），并把这个效率带入到下一个冲刺作为参考值。
　　很多公司有固定加班的习惯，那么冲刺工作量可以调整为 6*2*6*10*0.7 = 504 manhours
　　不建议无规划地要求团队加班
　　自然日评估的缺陷在于，团队成员会随着自己的经验增加，调整自己对任务的估时。这样每个冲刺周期，完成的工作量基本是一致的。无法得到团队速率，也就无法判断团队的速率是否有提升。
　　故事点：
　　相比较理想时间，故事点相对难以理解一些。故事点是一种相对的估计，它并不能和类似“人/天”这样的单位画等号，因为每个人完成同样复杂度的工作所需的时间是不同的。故事点是一种任务复杂度估计，基于对需求的拆分，我们选择其中一个较小的（不超过2day工作量的）且大家都能理解的需求作为1个故事点，然后评估其它的需求只需要评估出是这个需求工作量的几倍就可以了。由于是相对估计，有可能我们并不能准确说出具体的倍数，所以评估的点数只符合循斐波那契数列（1、2、3、5、8、13、21、34… ）就可以。
　　规模估算一般使用故事点的方式来估算。
　　故事点估算的具体操作方式是扑克估算，具体操作流程如下:
　　每个团队成员分发一套写着0、0.5、1、2、3、5、8、13、20、40、∞、？的卡片。
　　产品负责人负责讲解需求待办列表挑选出来的需求，团队成员提出自己的疑问，产品负责人一一解答。
　　团队成员进行估算，选出自己估算结果对应的卡片盖在桌上，不要告知其他团队成员。
　　所有人都确认自己的估算结果后，大家一起翻开卡片，展示自己的估算结果。
　　团队评估估算结果，让给出估算点数最大和最小的成员分别陈述自己给出当前结果的理由，团队讨论，消除分歧，得到一致的结果。（这一步尤为重要，讨论过程是团队分享知识和经验绝佳机会。）
　　选择下一个故事，重复第2步。
　　直到最后我们得到所有的需求的故事点数（如下图），以及一个冲刺总计故事点数 56。

　　如果没有扑克牌，还可以找对应的小程序来完成评估。
　　如果这是团队的第一个冲刺，我们可以完全不考虑故事点对应的自然日时间，也不考虑一个冲刺能不能完成这些需求，而是基于需求的优先级，能完成多少是多少，如果还有多余的时间，就加入更多的需求。在冲刺结束的时候，我们回顾下，一共完成了多少个故事点，这个数字将被带入到下个冲刺，作为下个冲刺需求范围的一个评估标准。
　　如果大家还不习惯（我遇到的团队，大都不太能接受纯故事点的评估方式），大家对一个故事点还是有一个最基本的自然日评估的，假设这里的一个故事点等于1day。那么完成这些需求就是56day，再根据这个时间评估再调整冲刺范围。最后冲刺结束的时候，我们重新评估下一个故事点对应的自然日时间。由于同一个故事点对应不同的人来说，其实完成时间是不一样的。所以这里一个故事点对应的自然日时间，指的是团队的平均评估时间，而非个人的。为了保证评估的准确性，其实期望团队是稳定的，人员基本不变动的。人员有较大调整的时候，故事点的评估就要重新调整了。
　　故事点评估的方式还可以作为团队效能提升的一种考核方式。

　　敏捷里关于估算的方法有很多，比如宽带德尔非法，相对估算，亲和估算等等，计划扑克等，个人觉得计划扑克是最简单容易操作的。其它的方法，大家去看看PMP的书籍，这里就不一一介绍了。
　　JIRA估时演示
　　1 设置预估方式

　　2 填写预估数据

　　3 查看团队工作量
　　Custom Chart for Jira 小程序
　　设置小程序

　　团队工作量显示结果：

　　人员工作量报告

　　报告显示结果：

　　4 生成燃尽图
　　当有了工作量评估后，就可以从报告中看到项目燃尽图，得到项目的总估时。根据项目的总估时，在冲刺计划会上调整项目范围，知道团队对冲刺范围和工作量达成一致。
　　关于燃尽图的更多信息，参考 JIRA之研发进度管理。

作者: oliver.tang 时间: 2023-6-15 11:31

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)