敏捷软件开发工作估算方法：故事点和工时

程中，我认为故事点和工时两种反映工作量的方式，可以结合使用。对于用户故事（功能需求）的评估，我们用故事点这种相对的规模估算方式，估算过程更容易，更客观，成本更低，故事点可以用来反映迭代中团队的客户价值产能；对于从用户故事分解出来的每个子任务，我们可以请具体开发人员评估任务工时，结合开发人员的单位时间成本，工时可以用来反映组织投入迭代的直接成本。这样既可以遵循敏捷Scrum的实践方法，又可以与公司软件项目以成本管理为目的工时估算对齐。

 

 

用户故事估算方法（PO创建，价值评估）

 

PO、开发团队（含测试/UI同事）共同参与需求澄清

敏捷开发中的估算扑克方式集体估算（故事点）

迭代中根据实际情况商议调整

 

开发任务估算方法（团队创建，成本评估）

 

开发团队（含测试/UI同事）共同跨职能分解每个用户故事到若干个具体任务

团队每个人对自己领取的具体任务，根据经验估算并登记（工时）

开发Leader最终核验

 

故事点评估的优势

 

1、故事点标准客观，帮助推动跨职能行为沟通，即团队从UI到DB（任务层面仍然可以估算个人工时）

2、每人都要参与估算，沟通更加充分，需求理解的更加清晰，提前暴露产品设计的不确定性，避免需求盲点

3、促进了团队成员之间的融合和互相理解，有助于工作中更好的跨职能协作以及合作完成用户故事开发

4、相对大小更容易评估，工时却不易评估，如果需要，后期可以转换成团队的平均工时

5、规模是客观的，故事点估算不会衰减，随着团队的成长，能体现团队迭代速率即产能的变化

6、通过有足够的迭代或冲刺，可以衡量出团队的开发速率，做出更合理的交付计划和客户报价

 

 

小结一下

 

故事点和工时并不互斥。它们一个用于估算工作复杂度，一个用于估算工作时长。故事点最重要的作用，是团队在产能上形成了一个参考基准。一旦团队通过几次迭代捕捉到了产能容量，就可以此为参考，与产品方、业务方达成交付效率的共识。这样既能避免拍脑袋给计划又给不准的局面，还可用数据可视化地呈现研发团队的效能变化。如果组织把记录的工时当做产出或人效的管理方式，说明组织对目标的管理缺乏掌控或缺乏信心。敏捷开发摒弃只衡量工时的思维，因为工时只代表着一种成本，我们要关注完成需求的速度和质量就足够了，这才是唯一重要的事情。此外，敏捷团队还应该在合作开发的同时，思考如何真正集中力量少量多批次持续输出优先级更高的用户故事。

 

最后，不论采用故事点还