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

推荐订阅源

AI
AI
TaoSecurity Blog
TaoSecurity Blog
H
Heimdal Security Blog
Help Net Security
Help Net Security
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
Microsoft Azure Blog
Microsoft Azure Blog
www.infosecurity-magazine.com
www.infosecurity-magazine.com
Google DeepMind News
Google DeepMind News
爱范儿
爱范儿
The Cloudflare Blog
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
人人都是产品经理
人人都是产品经理
大猫的无限游戏
大猫的无限游戏
N
News | PayPal Newsroom
V2EX - 技术
V2EX - 技术
博客园 - 【当耐特】
D
Darknet – Hacking Tools, Hacker News & Cyber Security
S
Secure Thoughts
C
CERT Recently Published Vulnerability Notes
罗磊的独立博客
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
P
Privacy & Cybersecurity Law Blog
有赞技术团队
有赞技术团队
S
Schneier on Security
S
SegmentFault 最新的问题
Google Online Security Blog
Google Online Security Blog
H
Hacker News: Front Page
The Last Watchdog
The Last Watchdog
Schneier on Security
Schneier on Security
PCI Perspectives
PCI Perspectives
IT之家
IT之家
Project Zero
Project Zero
博客园 - 司徒正美
P
Privacy International News Feed
Recent Commits to openclaw:main
Recent Commits to openclaw:main
Jina AI
Jina AI
Security Latest
Security Latest
Hacker News - Newest:
Hacker News - Newest: "LLM"
腾讯CDC
C
CXSECURITY Database RSS Feed - CXSecurity.com
阮一峰的网络日志
阮一峰的网络日志
C
Check Point Blog
aimingoo的专栏
aimingoo的专栏
V
Vulnerabilities – Threatpost
W
WeLiveSecurity
NISL@THU
NISL@THU
Webroot Blog
Webroot Blog
N
Netflix TechBlog - Medium
L
Lohrmann on Cybersecurity

博客园 - 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. 小时数》