敏捷开发估算工作量根据以下两个方法: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