惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
美团技术团队
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
月光博客
月光博客
J
Java Code Geeks
Jina AI
Jina AI
罗磊的独立博客
宝玉的分享
宝玉的分享
S
SegmentFault 最新的问题
D
DataBreaches.Net
博客园 - 叶小钗
腾讯CDC
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Last Week in AI
Last Week in AI
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
Google DeepMind News
Google DeepMind News
阮一峰的网络日志
阮一峰的网络日志
B
Blog
V
Visual Studio Blog
雷峰网
雷峰网
博客园 - 【当耐特】
Apple Machine Learning Research
Apple Machine Learning Research
Engineering at Meta
Engineering at Meta
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报

博客园 - xiaosonl

学习手札#3 NHibernate缓存 产品的简单性 关于过度设计的思考(上) 让ASP.NET MVC的Controller输出不同类型数据 学习笔记#1 键值对数据库 SQLite数据迁移 探讨一种在Silverlight不普及情况下的部署策略 有用的文档 Silverlight产品布署策略 探讨一种Silverlight的异步编程模式 代码的注释 下半年要看完消化的技术类书籍 中小型企业的人员流失 谈谈Ruby On Rails和ASP.NET 工作中的系统学习 Uml中的关联与依赖关系 TDD与重构设计 C#中使用位运算来实现权限管理 Silverlight中JavaSciprt无法访问托管类抽象成员的解决方法
学习手札#2 故事点和小时数的思考
xiaosonl · 2010-05-26 · via 博客园 - xiaosonl

2010-05-26 21:27  xiaosonl  阅读(292)  评论()    收藏  举报

故事点与小时数这两种度量单位,最大的区别在于, 故事点数是整个团队中通用的度量方式,不会因为经验、个人技术水平或团队某个人而受到影响。比如第一周完成的故事点和第二周完成的故事点差不多,就可以基本认为两周的任务完成量相当;而如果第一周所消耗的小时数和第二周差不多话,是很难能确定工作量也差不多的,因为这些小时数可能是由不同的人来完成的,即在相同的时间内的完成量是有差异的。

但是评估故事点却不是一件容易的事。不同水平的人,去评估同样的一个任务,结果应该是差不多的。而事实上,评估结果又很容易受自身技术水平影响,水平高的人会评的低,水平低的人会评的高,这是最常见的一个问题:如何客观的评估一个任务的工作量?如果不考虑个人技能因素,那哪些标准又可以用来相对比较呢?代码量,还是其它?这个问题我也没想出答案,所以这种方法我没在用。

所以,看来评估是很难脱离个人因素的。无法直接计算出团队的速率,就只能分别计算每个成员的速率。每个成员自己领任务,自己做评估,优点是评估的更加精确,缺点是估算剩余工作量所需的时间变的困难。

参考文章:《Sprint规划:故事点数 vs. 小时数》