先划分出各端(前端、客户端、后端),每个端单独评估。需要时间最长的端即为研发所需的最少时间。
对每个端评估时,列出参与这个项目的所有人员。为了便于描述,我们把其中技术能力最强或工作效率最高的人称为 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%,具体看人的能力。
把所有技术的部分用对应的领域替换后,这种评估方法也适合产品、测试人员。
总之要做好团队合作哦~~~