先划分出各端(前端、客户端、后端),每个端单独评估。需要时间最长的端即为研发所需的最少时间。

对每个端评估时,列出参与这个项目的所有人员。为了便于描述,我们把其中技术能力最强或工作效率最高的人称为 A。

A 一天(除去加班、小憩时间)能完成的工作量定义为 1 人天(也有叫”人日“的,注意两个字合起来是一个量词/单位),同时 A 的战斗力定为 1.0。这个需求按照 A 的标准要几天才能完成,则它的工作量可量化为多少人天。

再把其他人员逐一跟 A 比较做评估,如果 B 一天能完成的工作量是 A 的 70%,则把 B 的战斗力定为 0.7。假如还有 C 的战斗力 0.5,则这个团队的总战斗力为 1.0 + 0.7 + 0.5 = 2.2

如果某个需求的工作量是 11 人天,则最理想的情况下,这个3人团队需要用 11 / 2.2 = 5 天来完成。

团队的人数越多,花在沟通上的时间也会增多。再加上可能有技术评估不准、部门会议、临时请假的情况,在估算整体所需时间时,应乘以一个大于1的浮动系数(例如 1.2)来作为最终时间。在上例中,向项目组报备的工作量应为 5 * 1.2 = 6 天。类似地,如果要 996,则可乘以一个小于 1 的系数,可以是 0.85。

在实际情况下,并非所有团队成员都全天参与此项目,同时参加多个项目的情况很常见。如果 A 对本项目只投入一半的时间,则团队的总战斗力应算成 1.0 * 0.5 + 0.7 + 0.5 = 1.7

除了编码技能外,影响一个人或团队的战斗力的因素还有:

  • 代码熟悉程度,是否需要先学习前人写的代码
  • 需求是否可拆分给多人合作;多人合作会不会反而更慢
  • 历史遗留问题多不多,会不会踩坑
  • 修改的地方是否重要,牵扯面是否广,引起的回归测试量是否大
  • 是否有技术方案未确定、需要预研的部分
  • 跨团队合作的部分是否有依赖,沟通是否顺畅
  • 代码质量,bug 产出率
  • 工作配套的硬件设施是否满足要求,如电脑配置

另外特别注意的是如何定义“完成”,“完成”是指编写完代码还是自测完毕还是解bug完毕?要明确好这个概念的意思再向项目组报备所需工作时间。测试过程的时间一般是写代码时间的5%~15%,具体看人的能力。

把所有技术的部分用对应的领域替换后,这种评估方法也适合产品、测试人员。

总之要做好团队合作哦~~~

声明:本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。