敏捷软件开发工作估算方法 – 故事点和工时
By 老彦
你如果无法度量它，就无法管理它
– 彼得.德鲁克
软件开发组织工作估算的思考
我们人类天生不善于估算，要不就是过于乐观，要不就是过于悲观，就是很少有现实主义。尤其是我们软件开发行业，有太多的未知数：技术一直在变；新需求不断涌现；任务之间或人与人之间错综复杂的依赖关系；还有外界环境存在的各种因素。工作量主要与三方面因素有关，任务的规模，任务的复杂度以及完成该任务的人员能力水平。
为什么要做估算？
第一个原因是帮助我们做出周全的决定。有了估算，我们就知道软件产品清单上的需求是否能在指定的期限实现或需要多久才能完全实现。
第二个原因是设定目标。如果我们给自己制定了一个最后期限，就会全力以赴确保达到目标，当然，也有完全不靠谱的时候。当然，估算和设定目标毫无疑问可以帮助我们保持专注并取得最大成果。
一句话：了解团队在软件开发过程中的客户价值产能、组织投入的成本并做出更合理的交付计划和客户报价。
理解故事点和工时
在很长时间里，工时（人天/人时）是研发团队中的指标，能直接反映出：完成某项工作需要几个人做多长的时间。这一指标确实让许多研发团队获得了评估项目人力成本的基础数据。
然而在实际操作中，开发者的工作几乎无法被标准量化。不同的开发人员，其能力本就有所差距；更重要的是，每一项具体的开发任务，它的规模、复杂度和风险等可能有着巨大差异。仅仅统计工时，并不能反映团队的开发速率。因此，在敏捷开发中，提出了应当用故事点来估算工作量。
1个故事点是1个标准单位的工作量，是对工作规模的相对度量，它估算出的是对于完成此需求所要的开发规模的大小。这个单位并不能直接指代该项需求需要的开发时间。工时是绝对的度量单位，故事点是相对的度量单位。举个例子：在同一个餐桌上，同样是一碗饭，小强10分钟就能吃完了，小美需要20分钟才能吃饭。在这个例子中1碗饭就是标准单位，每个人吃饭的效能是不同的，小强20分钟可以完成2个标准单位，而小美只能完成一个标准单位。在软件开发行业，同样的用户故事，交给不同的人实现，用不同的时间，就表明每个人的产能不同。故事点作为标准单位更客观地衡量了团队产出的客户价值，而工时却无法反映这点。
价值评估和成本评估可以并行
前几天与公司的同事和领导就故事点和工时，这两种敏捷软件开发的工作量度量方式有过一些探讨，在适应公司现状的敏捷开发过程中，我认为故事点和工时两种反映工作量的方式，可以结合使用。对于用户故事（功能需求）的评估，我们用故事点这种相对的规模估算方式，估算过程更容易，更客观，成本更低，故事点可以用来反映迭代中团队的客户价值产能；对于从用户故事分解出来的每个子任务，我们可以请具体开发人员评估任务工时，结合开发人员的单位时间成本，工时可以用来反映组织投入迭代的直接成本。这样既可以遵循敏捷Scrum的实践方法，又可以与公司软件项目以成本管理为目的工时估算对齐。
| 评估对象 | 评估方式 | 采用概念 | 度量单位 | 说明 | 优势 |
|---|---|---|---|---|---|
| 用户故事（需求） | 集体评估 | 价值评估 | 故事点 story point | 用来计算交付的客户价值 | 数据生成快速，客观；团队共同参与更加全面；绩效的依据 |
| 开发任务(用户故事拆分子任务) | 个人评估、Leader 核验 | 成本评估/工时评估 | 人时或天 man hour/ man day | 用来计算组织的投入成本 | 便于组织的成本管理 |
用户故事估算方法（PO创建，价值评估）
- PO、开发团队（含测试/UI同事）共同参与需求澄清
- 敏捷开发中的估算扑克方式集体估算（故事点）
- 迭代中根据实际情况商议调整
开发任务估算方法（团队创建，成本评估）
- 开发团队（含测试/UI同事）共同跨职能分解每个用户故事到若干个具体任务
- 团队每个人对自己领取的具体任务，根据经验估算并登记（工时）
- 开发Leader最终核验
故事点评估的优势
- 故事点标准客观，帮助推动跨职能行为沟通，即团队从UI到DB（任务层面仍然可以估算个人工时）
- 每人都要参与估算，沟通更加充分，需求理解的更加清晰，提前暴露产品设计的不确定性，避免需求盲点
- 促进了团队成员之间的融合和互相理解，有助于工作中更好的跨职能协作以及合作完成用户故事开发
- 相对大小更容易评估，工时却不易评估，如果需要，后期可以转换成团队的平均工时
- 规模是客观的，故事点估算不会衰减，随着团队的成长，能体现团队迭代速率即产能的变化
- 通过有足够的迭代或冲刺，可以衡量出团队的开发速率，做出更合理的交付计划和客户报价
小结一下
故事点和工时并不互斥。它们一个用于估算工作复杂度，一个用于估算工作时长。故事点最重要的作用，是团队在产能上形成了一个参考基准。一旦团队通过几次迭代捕捉到了产能容量，就可以此为参考，与产品方、业务方达成交付效率的共识。这样既能避免拍脑袋给计划又给不准的局面，还可用数据可视化地呈现研发团队的效能变化。如果组织把记录的工时当做产出或人效的管理方式，说明组织对目标的管理缺乏掌控或缺乏信心。敏捷开发摒弃只衡量工时的思维，因为工时只代表着一种成本，我们要关注完成需求的速度和质量就足够了，这才是唯一重要的事情。此外，敏捷团队还应该在合作开发的同时，思考如何真正集中力量少量多批次持续输出优先级更高的用户故事。
最后，不论采用故事点还是工时又或者两者结合，都需要每个团队不断探索更适合自己的方式，找到能有效估算并呈现自身产能的最佳道路。
—
END
感谢你阅读本文，希望能在评论区学习到大家的经验和想法~
如果对相关内容感兴趣可以关注我的公众号：捷伴行Agile。会有更多更及时的内容与君分享。