关于story point的单位
克强
中，讨论到了user story或story point的单位。很是有启发，为便于阅读，并保持各自关注点，新开此贴。
先罗列下已经写的相关文字。大家一起晒晒实践和观点，绝无抬杠之意。
10月4日, 下午10时11分, Xu Yi <kaverj...@gmail.com> wrote:
"story point" is unitless...
Daniel Teng 10月5日, 下午4时39分 ：
User Story是无单位的.
10月5日, 下午5时09分, Xu Yi <kaverj...@gmail.com> wrote:
哈哈，犯了和我一样的错误嘛~ 无单位的是story point，而不是user story。
是的。user story用于评估user
story的相对大小（bigness），它并无一个可用于度量的单位值。时间或是长度单位，例如"小时"和"米"，乃是全世界同一的度量。
一定程度上可以说story
point最终会达到具有一定的单位效用。当某产品开发大团队（包括若干scrum团队）保持团队稳定，以及开发足够长时间后达到velocity稳定
时，可以-借由建立一定程度上story
point向"成本"、"时间"等度量的映射，使其成为"虚单位"。
例如，平均下来大团队（5个人/scrum团队 *
5个scrum团队）每个sprint（4周）能完成50个point，那么可以将一个point等同为一个时间范围，1 point =
40~70h
(假设scrum团队的capacity为可用时间的80%到50%之间，5*5*140/50 和5*5*80/50)。
同样，也可以将point和费用、收入联系在一起。假设上述25人大团队的每月总费用是12.5万元。那么可以认为一个point的成本是2500元，
需要的时-候，可以通过计算某个user
story的可能性收入，并与其成本做比较进行决策。
但问题在于，对于不同的组织或是产品大团队，其成本因素以及开发效率都不同，这也造成其每个point的相对应时间、成本虚单位不同。而且形成稳定的
point-虚单位，需要维持point的相对大小一致很长时间，一年两年甚至更长时间。
盲目的将point和时间、价值单位联系起来是非常危险的。
发件人：姜志辉 <ibags...@gmail.com>
当地时间：2009年10月6日(星期二) 上午3时30分
HI，Xu Yi：
Thanks
我刚刚查阅了一下资料。story point确实是无单位的。这里找到了一个摘录：
"Next we take the stories that the customer selected and break
them
down into tasks.A task is much smaller than a story.It is a unit of
work on the order of four to 10 man-hours is size."
他只说了大小约是4到10人时，确并没有指定单位是多少。我又查阅了一些相关资料，都没有指明单位，只是说大约多少人时
而Joel的任务划分是人.时为单位的，但没有说是故事点，只说是任务。
发件人：张克强 <zhangkeqi...@gmail.com>
当地时间：2009年10月6日(星期二) 上午6时57分
就算是学术上确实认为user story point是"无单位"的，也不能禁止有组织以user story point的数量来作为
sprint
的范围的限制，说"这个sprint做32个story points"是常见的做法，在这个语境下，story point就是单位。 user
story point不是一个像"Function point"一样在全球有完全一样尺度的单位，每个团队的story point都有各自的
尺
度，无法横向比较，但可以纵向比较，将point和时间、价值单位联系起来, 是story point数量统计的目的。
张克强
)
*************************
例如，表1.1中描述的是在项目中的所有User Story，他们按照优先级降序排列。开发团队估计每轮迭代可以完成13个Story Point的
工作量。那么，整个User Story就需要按照表1.2的方式进行分配。
Story Story Point
Story A 3
Story B 5
Story C 5
Story D 3
Story E 1
Story F 8
Story J 5
*************************
在上表中，一般的理解 story point就是单位。
“story point是没有单位的”，到底是什么意思？ 仅从字面上理解，理解起来比较困难。
是不是可以这样理解：
1，不同团队的story point不具备可比性，不宜将两个团队的story point数量进行比较。
2，同一团队的story point在不同的时间段，也不具备可比性，3个月前的sprint完成了20个story points，与3个月后的
sprint完成的20个story points，可能实际工作量付出相差很大，不宜比较。
Xu Yi
--
- - - - - - - - - -
Xu Yi, Kaverjody
Agile Coach.CSP
Test Automation Coach
Blog : http://damianji.spaces.live.com
- - - - - - - - - -
张克强
1, http://en.wiktionary.org/wiki/unitless
unitless
1. The property of a number as having no units of measurement, such
as a ratio or percentage of two numbers which have the same units.
2, http://en.wikipedia.org/wiki/Units_of_measurement
Treat units algebraically. Only add like terms. When a unit is divided
by itself, the division yields a unitless one. When two different
units are multiplied, the result is a new unit, referred to by the
combination of the units. For instance, in SI, the unit of speed is
metres per second (m/s). See dimensional analysis. A unit can be
multiplied by itself, creating a unit with an exponent (e.g. m²/s²).
以上可以看到，比率是无单位的，两个相同的单位相除得到无单位的结果。
3，http://agilesoftwaredevelopment.com/2006/12/measures-of-size
More difficult to explain. The benefits of using unitless
measurements and the power of relative estimations have to be
explained
3处的unitless的用法已经与1，2不一致了。
3处的用法是为了区别story point、Function point、LOC等等，强调的是story point不像Function
point和LOC一样有统一的标准。
Xuyi也提到了"时间或是长度单位，例如"小时"和"米"，乃是全世界同一的度量。"(而story point不是）
因此，Agile环境下的unitless，应当理解为“非标准单位的”。
Agile语境下，借用unitless来表达与英文字面意思并不一致的意思，这不是好做法。我们不必跟随。
用字面意思表达真实意思就不需要再解释了，才是敏捷的做法。
In English, "non-standard unit" is better than "unitless“ in Agile
environment。
So story point is a non-standard unit, but it is a type of unit.
至于如何利用story point，”昨日天气“也好，各种Velocity也好，都是可选的。
--
-----------------------------
blog:http://hi.baidu.com/hespr 高效过程研究
张克强
--
-----------------------------
blog:http://hi.baidu.com/hespr高效过程研究
Daniel Teng
archive/2009/10/07/1578890.html).
简要说,我认为:
首先，故事点是一个相对量，相对值是没有单位的；
其次每个团队的单位"故事点"是不同的，很难也不需要统一。
Daniel
张克强
留下的只是个说法的问题。
---以下只做做学术探讨---
1， 判断一个user story的story point的多少的过程，可以形象的想象有这样的一架天平，一边放着砝码，这个砝码就是团队
达成共识的最小user story；另一边放着要判断的user story。判断的结果是最小user story的N倍，N是自然数，N是倍数，
是没有单位的。
实际的天平称重时，两边一样重，所称物体的重量是砝码的1倍。1倍是没有单位的，砝码本身有单位，比如是1克的砝码，这样所称物体也是1
克。
回到故事点，团队达成共识的最小user story的大小，定为1个故事点。是最小user story的N倍的user story的大小
是N个故事点。
物体的重量以克为单位，"克"在全球有统一标准，user story以"story point"为单位，"story point"没有统
一标准，团队之间一般不能共享。
还有个例子，斗是中国古时的粮食计量单位，但各地的斗不太一样，黑心地主有"大斗进，小斗出"的手段。村民公认某只斗是最准的，用这只斗装出
100下，就定为100斗。不管这个斗随着使用，会稍微增大些。并不因为"斗"在变化，就说斗是无单位的。
绝对单位是单位，相对单位也是单位。
2，http://en.wikipedia.org/wiki/Story_points
The first sentence is "In agile software development, story points are
units of relative size used in estimating requirements as an
alternative to units of time."
.......
References
[1] Mike Cohn, "Agile estimating and planning", Prentice Hall, 2005.
[2] Mike Cohn, "User Stories Applied for Agile Software Development",
Addison-Wesley, 2004.
Xu Yi
andy
Xu Yi
我自己的体会是：IMD（Ideal Man Day）在团队应用Scrum初期的效果是不错的，一点心得，分享在：http://blog.vsharing.com/agiledo/A969391.html
能否分享下你得出“在团队应用Scrum初期的效果是不错的”这个结论的具体分析，比如你对哪些方面感到满意，哪些方面觉得还不尽如人意，等等。
andy
Xu Yi
在Scrum应用初期，大家对Scrum的很多概念不是很熟悉，Team、PO或者管理层更熟悉评估功能完成的时间，更直接，减少了很多沟通成本。SP反映了故事相对的工作量，涉众（Stakeholders）最关心的是你完成这些功能需要多长时间，IMD会给出最直接的答案。我们团队经常被问到的问题是：这个功能你需要多长时间完成？哦，所以你需要这样一些资源，在这个开发周期只能完成这些功能...
Daniel Teng
Daniel
On 10月9日, 下午4时47分, "andy" <a...@agiledo.cn> wrote:
> 在Scrum应用初期，大家对Scrum的很多概念不是很熟悉，Team、PO或者管理层更熟悉评估功能完成的时间，更直接，减少了很多沟通成本。SP反映了故 事相对的工作量，涉众（Stakeholders）最关心的是你完成这些功能需要多长时间，IMD会给出最直接的答案。我们团队经常被问到的问题是：这个功能你 需要多长时间完成？哦，所以你需要这样一些资源，在这个开发周期只能完成这些功能...
>
> 2009-10-09
>
> Andy Yuan
> 敏捷开发，Scrum实践，每日纪录：http://blog.vsharing.com/agiledo/
>
> 发件人： Xu Yi
> 发送时间： 2009-10-09 15:58:59
> 收件人： agile...@googlegroups.com
> 抄送：
> 主题： [agilechina] Re: 关于story point的单位
> 2009/10/9 andy <a...@agiledo.cn>
andy
andy
Xu Yi
是要有一个折算比例，因为要考量因为会议、技术支持、生病等因素。现在我们是这样计算Velocity，其中的资源利用率应该就是你说的“折算比例”了。1. 记录每个Sprint可以实现功能的IMD（Ideal Man Day），实现功能的标准是任务可以发布（编码、测试、部署、文档等），而不是仅仅编码完成2. 记录每个Sprint实际的可以利用的资源。例如我们在第三个Sprint时，团队7个成员（A，B，C，D,E，F，G），3个星期的开发周期，A，C，E,F,G将全勤，B会请假2天，D最后一个星期才会加入团队，所以此次Sprint团队实际的可利用资源为：5*15＋13+7=95(MD)3. 计算资源利用率：实际完成功能的IMD / 实际可利用的资源。以我们的第三个Sprint为例，当时完成的实际功能的IMD为52IMD，资源利用率为：52 / 95 ＝ 54.7%。我总结了团队资源利用率不高的一些原因：a) 团队刚接触新的业务，对需求的理解花费较长的时间，同时测试也发现了实现和需求不符的地方，这是由于开发人员和PO的沟通较少所致b) 技术架构不成熟，还在不断构建，影响了实际业务层面的实现c) 有一些技术支持的工作4. 平均前三期sprint的资源利用率。我们没有按照上一期Sprint的资源利用率来作为参考，是因为我们对于任务的完成按照100%完成的标准。按照前三期的平均值，更加可行5. 用第四步得到的资源利用率，乘以即将开始的Sprint内可以利用的资源，基本可以得到此次Sprint的团队开发能力（Velocity）
我们评估user story是这样的：对每一个story分解为任务，然后对任务做出IMD，相加后得到story的IMD。
Jacky Li
--
Jacky Li
Agile Consultant @ThoughtWorks
Editor @InfoQ China/Agile
Kaopubulity Evangelist
+86 138 1045 9095
andy
张克强
On 10月10日, 上午8时54分, "andy" <a...@agiledo.cn> wrote:
> 大家好，我把我们怎么做的和大家交流一下，只是想抛砖引玉...
>
> 2009-10-10
Xu Yi
Daniel Teng
生病，除非是可以预期的，比如生孩子、H1N1被隔离等等，否则对这种突发事件不用做计划。毕竟我们的sprint中有Slack可以用来作为缓冲。
资源利用率的问题，我觉得这要看Team自己的感觉，Team自己感觉是否利用率低。当然你可以在Retrospective中提出自己的看法，大家可
以讨论，找到RootCause。如果大家不觉得低，那就不是问题了。
我觉得a),b)不应该是利用率低的的理由，其实这些事情都应该算是能够直接给客户带来价值的，算是Story开发的一部分。
Daniel
On 10月9日, 下午6时13分, "andy" <a...@agiledo.cn> wrote:
> 是要有一个折算比例，因为要考量因为会议、技术支持、生病等因素。现在我们是这样计算Velocity，其中的资源利用率应该就是你说的"折算比例"了。
> 1. 记录每个Sprint可以实现功能的IMD（Ideal Man Day），实现功能的标准是任务可以发布（编码、测试、部署、文档等），而不是仅仅编码完成
> 2. 记录每个Sprint实际的可以利用的资源。例如我们在第三个Sprint时，团队7个成员（A，B，C，D,E，F，G），3个星期的开发周期，A，C，E, F,G将全勤，B会请假2天，D最后一个星期才会加入团队，所以此次Sprint团队实际的可利用资源为：5*15＋13+7=95(MD)
> 3. 计算资源利用率：实际完成功能的IMD / 实际可利用的资源。以我们的第三个Sprint为例，当时完成的实际功能的IMD为52IMD，资源利用率为：52 / 95 ＝ 54.7%。我总结了团队资源利用率不高的一些原因：
> a) 团队刚接触新的业务，对需求的理解花费较长的时间，同时测试也发现了实现和需求不符的地方，这是由于开发人员和PO的沟通较少所致
> b) 技术架构不成熟，还在不断构建，影响了实际业务层面的实现
> c) 有一些技术支持的工作
> 4. 平均前三期sprint的资源利用率。我们没有按照上一期Sprint的资源利用率来作为参考，是因为我们对于任务的完成按照100%完成的标准。按照前三期的 平均值，更加可行
> 5. 用第四步得到的资源利用率，乘以即将开始的Sprint内可以利用的资源，基本可以得到此次Sprint的团队开发能力（Velocity）
>
> 2009-10-09
>