敏捷开发之故事点估算与故事点燃尽图
2011-12-29 09:16
260 查看
一个团队/个人花 10 小时能完成的任务,另一个团队/个人或许需要 100小时;
也有可能团队花了 100小时但是什么都交付不出来;
作为一个用户故事,只有“完成”与“未完成”两种状态,不能使用一个百分比来表达“部分完成”,例如我们不能燃烧掉一个用户故事 1/3 的故事点=来表达它已经完成 1/3了;
基于小时的估算是不精确的,不同人在同一个任务上要花不同的小时数;
花了几个小时在一个任务上不等于这个任务有一部分被完成了, “部分完成”是一个隐藏问题的危险状态,应该避免使用;
故事点估算更简单和敏捷,虽然它很难使用。
基于“小时估算”及基于“故事点”监控的差异,一直是一个具体而微妙的问题,令很多初涉敏捷的组织迷惑。(引用作者的用词,)这真是一个“干净利落”的案例。 能正确使用“故事点”来估算及后续监控,理应不会出现任何异议。但学界也仍然有诸如Mike Cohn 等导师级人物仍认为 Ideal Hours是可用的。我个人的理解,其思路与作者有一点关键不同:在燃尽图更新时,视角并不是记录“已消耗工时”,而是再次估算“剩余工时”。换个角度看,燃尽图的更新体现了一个不断估算的过程。再者,遵守“只有彻底完成的Task才能在燃尽图上获得分数”的规则,也可能有效的避免此问题。
个人体会:从 Burn down的价值取向分析,(彻底)完成了多少、(到底)剩余多少,是重要的;既有的成本投入,不太重要。
也有可能团队花了 100小时但是什么都交付不出来;
作为一个用户故事,只有“完成”与“未完成”两种状态,不能使用一个百分比来表达“部分完成”,例如我们不能燃烧掉一个用户故事 1/3 的故事点=来表达它已经完成 1/3了;
基于小时的估算是不精确的,不同人在同一个任务上要花不同的小时数;
花了几个小时在一个任务上不等于这个任务有一部分被完成了, “部分完成”是一个隐藏问题的危险状态,应该避免使用;
故事点估算更简单和敏捷,虽然它很难使用。
基于“小时估算”及基于“故事点”监控的差异,一直是一个具体而微妙的问题,令很多初涉敏捷的组织迷惑。(引用作者的用词,)这真是一个“干净利落”的案例。 能正确使用“故事点”来估算及后续监控,理应不会出现任何异议。但学界也仍然有诸如Mike Cohn 等导师级人物仍认为 Ideal Hours是可用的。我个人的理解,其思路与作者有一点关键不同:在燃尽图更新时,视角并不是记录“已消耗工时”,而是再次估算“剩余工时”。换个角度看,燃尽图的更新体现了一个不断估算的过程。再者,遵守“只有彻底完成的Task才能在燃尽图上获得分数”的规则,也可能有效的避免此问题。
个人体会:从 Burn down的价值取向分析,(彻底)完成了多少、(到底)剩余多少,是重要的;既有的成本投入,不太重要。
相关文章推荐
- 敏捷开发绩效管理之五:敏捷开发生产率(上)(故事点估算)
- 敏捷开发绩效管理之五:敏捷开发生产率(上)(故事点估算)
- 敏捷开发实践(1)-故事工作量估算导致的问题
- 开发管理 CheckLists(13) -敏捷开发-估算故事
- 敏捷开发-故事与估算
- 敏捷开发绩效管理之五:敏捷开发生产率(上)(故事点估算)
- 敏捷开发实践(1)-故事工作量估算导致的问题 .
- 敏捷开发绩效管理之五:敏捷开发生产率(上)(故事点估算)
- 敏捷开发绩效管理之五:敏捷开发生产率(上)(故事点估算)
- 敏捷开发(三)- 估算故事
- 敏捷开发绩效管理之五:敏捷开发生产率(上)(故事点估算)
- [原]敏捷开发-故事与估算
- 敏捷开发--如何准确估算故事
- 敏捷开发绩效管理之五:敏捷开发生产率(上)(故事点估算)
- 敏捷开发绩效管理之五:敏捷开发生产率(上)(故事点估算)
- 【在线研讨-现场文字】《敏捷开发用户故事分类与组织结构(一期-4)》2012-06-26
- 敏捷开发“松结对编程”实践之二:计划与设计篇(大型研发团队,学习型团队,139团队,师徒制度,设计评审,预想陈述,共同估算,扑克牌估算)
- 【敏捷开发每日一贴】敏捷估算方法
- 敏捷开发“松结对编程”实践--共同估算篇
- 敏捷开发的一些思考--故事拆分