敏捷开发估算工作量根据以下两个方法：1、选择基准故事，赋值故事点；2、运用规划扑克，确定工作量。选择基准故事，赋值故事点是指为了确定故事点的标准，团队需要先找到一个基准故事，该基准故事需包含解决具体用户故事所要完成的标志性任务。
1、选择基准故事，赋值故事点
我们所有人对「1个小时」都有清晰的认知和共识，因为时间是一个绝对值，然而「1个故事点」到底代表多少工作量呢？为了确定故事点的标准，团队需要先找到一个基准故事，该基准故事需包含解决具体用户故事所要完成的标志性任务，例如选择一个包含前端和后端任务，后端有数据信息交互的用户故事作为基准故事，其工作量设为1个故事点，那么其他用户故事则可以基于这一基准故事进行故事点的预估。比如某团队设置基准故事 A 为1个故事点，用户故事 B 的开发任务量、复杂度、风险和不确定性综合预估是基准故事 A 的3倍，那么用户故事 B 的故事点就应该设立为3。 故事点的取值需遵循斐波那契数列数列（1、2、3、5、8、13、21、34…), 为了避免繁琐，更好的体现故事点的差异性和准确性，团队可沿用修正版的斐波那契数列（1、2、3、5、8、13、20、40…）。 ONES Project 支持新建「用户故事」，并提供斐波那契数列帮助研发团队进行故事点预估，满足企业在敏捷研发场景下的需求管理。
2、运用规划扑克，确定工作量
选择好基准故事之后，团队成员则可以开始对用户故事进行故事点估算。为了保证团队成员对同一用户故事的工作量判断达成一致，在故事点估算会议上，我们通常运用「规划扑克」的方式完成集体估算。 对于选定的10-20个待办事项，参会人员集体讨论其功能实现并提出问题，然后每个人对待办事项进行故事点预估，同时亮出扑克。对于同一待办事项，如果大家给出的故事点预估存在了很大的差异，代表大家对它的工作量、风险和不确定性、复杂度没有达成共识，估点高和估点低的人需要给他们一个机会阐述估点的理由。大家对该待办事项所包含的细节达成共识后，再对故事点数进行重新评估，直至大家对故事点数的评估基本达成一致。
延伸阅读：
什么是敏捷开发？
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷建模（AM）定义了一系列的核心原则和辅助原则，它们为软件开发项目中的建模实践奠定了基石。其中一些原则是从XP中借鉴而来，在Extreme Programming Explained中有它们的详细描述。而XP中的一些原则又是源于众所周知的软件工程学。复用的思想随处可见！基本上，本文中对这些原则的阐述主要侧重于它们是如何影响着建模工作；这样，对于这些借鉴于XP的原则，我们可以从另一个角度来看待。
文章标题：敏捷开发如何估算工作量，发布者：小编，转载请注明出处：https://worktile.com/kb/p/34808
微信扫一扫 
支付宝扫一扫 
