领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
Sprint规划：故事点数 vs. 小时数
作者 Vikas Hazrati 译者 郑柯 发布于 2009年9月23日
长久以来，对于sprint规划中应该使用故事点数还是小时数，一直有着不分胜负的争论。双方阵营似乎都有一系列理由，支持人们采纳自己的方式而不是对方的做法。Mike Cohn坚决支持将用户故事拆散成任务，然后再用小时数估算。而Jeff Sutherland提出：有些跟他一起工作过的、非常出色的团队一直在使用故事点数，并用其绘制燃尽图。很多敏捷资深人士都表达了自己的观点，说明自己喜欢哪种方式及其原因。
在Mike看来，他不喜欢在spring规划中使用故事点数，因为故事点数更适合用作长期度量，对于短时间规划没有帮助。他觉得：
假设有一支棒球队已经进入赛季中段。他们在已经进行过的41场比赛中，场均得分98分。他们可以说：“我们在剩下的赛季里大概每场平均也能得到98分。”但是他们不会在某场比赛前这样说：“我们之前的平均得分是98分，所以今晚我们会得到98分。”这就是为什么我说速度可以用作长期预测，而不适合进行短期规划。
Tara Lee Whitaker不同意故事点数可以用作短期度量。在她看来：
如果每个故事都足够小，并因此可以“准确”估算，而且可测试性足够好，人们可以据之创建用以确认验收的测试，那么把故事拆成更小的部分，或是重新以小时数估算之，这样做也就没多大好处了。
对于以小时数估算故事这样的方式，她非常担忧：
当我们开始讨论将故事拆分成小时任务时，我主要担心的是：我们无法从这样做得到的早期警告信号中获益，并且当我们发现完成一个故事所需时间超过预期时，那已经太晚了。
Jim Schiel提出：也许有可能以故事点数和小时数两种方式来做sprint规划。然而，用小时估算的回报也许会让这种做法看起来不值得这么做。他认为：
现在咱们来看这样一个Scrum团队，他们承诺要完成10个2点的产品Backlog条目。如果他们能够全部完成，他们在这个sprint中的速度就会达到20个故事点数。下一个sprint，他们大概会尝试再次完成20个故事点数。此后的sprint的速度多少都会受上个sprint的影响。这种关系会一个一个sprint传下去，团队会得到一个大概的速度，在18与22之间。
你能用小时数来达到同样的效果么？可以，但是要想做好就得付出非常多的成本。你到底想为什么买单？是完整的、可用的软件，还是非常准确的估算？
Jack Milunsky进一步阐述了故事点数的意义，他提到了下列优势：
- 通用度量——故事点数是整个团队中通用的度量方式，不会因为经验、个人技术水平或团队某个人而受到影响。
- 稳定状态——等到第三个或第四个sprint过后，团队的产出就会达到稳定状态，产品负责人也更易于把稳定的故事点数填写到backlog列表中。不会多，也不会少。
- 鼓舞士气——一旦团队达到稳定状态，业务人员就能相信技术团队的能力，这能让团队士气高昂、充满自信。
Tomas Björkholm提到选择故事点数方式的下列原因：
- 原因之一：估算是为了描述故事的大小，而不是要知道实现这个故事需要多久。
- 原因之二：理想化的人日作为度量标准，它会随时间推移根据团队的表现发生变化。故事点数相对稳定。
- 原因之三：已经证明，相对估算要比绝对而且理想化的人日正确性更高；同时，由于人日是时间度量单位，尽管可以用其做出相对估算，但还是很容易偏向绝对的使用方式。
Tomas补充道：
Staffan Nöteberg在关于Pomodoro技术的演讲中提到：大多数人对于按实际时间估算都感到不舒服。由此我想到：不舒服的人，工作效率都不高；因此，按照天估算就会导致工作效率不高。
Mike Cohn提及：在故事点数和工作小时之间没有线性的对应关系。在他看来，每个故事的大小都会基于标准差有个分布范围。
一个点数等同于一个分布范围，等同于x和某个标准差的结果。同样的，2点的故事也可以依此类推……
因此，人们不能告诉项目干系人：按照以故事点数方式计算的速度，团队能在某个确定的时间完成任务。一定是个时间范围：
这个范围可是是日期范围，比如“我们可以完成你的产品backlog中所有的条目，但是完成时间大概在5月或者6月。”或者可以是功能范围，“我们可以在5月20号完成，你也是这么要求的，不过我们到时会完成120个到140个点数，也就是在这两个产品backlog条目之间。”
Mike Cohn还提供另一种方式，它可能符合精益原则，名为“承诺驱动的sprint规划 ”。使用这种方法，团队不会讨论故事点数或是速度。他们就是从backlog中取出优先级高的条目，根据各自的能力，把任务分配下去，按小时估算，并实现自己的承诺。
因此，这两种用作sprint规划的技巧各有优劣。到最后，可能还要看团队更习惯哪一种做法。您喜欢哪一种呢？原因何在？
查看英文原文：Sprint Planning: Story Points Versus Hours
译者 郑柯 InfoQ中文站总编。做过开发，当过PM，干过销售，搞过市场，最终还是回到媒体。实用的理想主义者，相信：每天改变一点点，这个世界会更好。
Sprint规划：故事点数 vs. 小时数
发表人
cao Alex
发表于
小时数
发表人
Jun Ran
发表于
Re: 小时数
发表人
鲍 央舟
发表于
并不冲突吧!
发表人
Shichao Liu
发表于
Re: 并不冲突吧!
发表人
峻申 吴
发表于
Re: 并不冲突吧!
发表人
王 毅
发表于
小时数
发表人
Fan Jun
发表于
-
故事点数需要团队有一段时间的习惯和认识，才能利用的更好， 理想日比较容易实施，也容易理解。但就像前面说的： “理想日会随时间推移根据团队的表现发生变化。故事点数相对稳定。”
如果团队成员相对比较稳定，而且项目时间也不是非常的短。 用故事点数会比较好。这样等过了几个sprint，团队的速度基本稳定在一个范围内。对项目后面的发布计划等等都会有正面的影响。
若选择理想日来估算。那就一定要清楚的明白，理想日不等于工作时间，否则就会产生错觉。从而会对规模相同的用户故事给出不同的理想日。 这样团队就会不容易找到自己的比较真实的速度范围。 -
我比较倾向于用小时数，用故事点比较困难，也比较复杂，而简单是敏捷的基本原则之一；
用故事点的难处在于去定义每个任务的故事点数量，若没有一套通用的标准，很难使每个任务的故事点代表相同或相近的意义；
有人建议简单地用 1个理想人日（8小时） 作为一个故事点，这种转换使得故事点建立在小时数的基础上，本质上还是在使用小时数，额外去增加一个转换过程又有什么意义呢； -
同意，如果任务break down到足够小的话，用小时数完全没有问题。用故事点数反而会使Team觉得复杂。
-
拿赶路类比, 故事点数是距离(X千米), 小时数是在使用特定载具的情况下的所需时间(Y小时). 同样是1千米的路, 汽车和走路当然时间不同. 一个团队里, 新手老手解决同一个问题的时间也是不一样的. 一个条目取出来, 我们说他是1天能干完的, 必须是在确定谁来做的前提下.
即需要对问题复杂性本身的大致估算, 与实现者无关, 即故事点数.
也需要进一步参考团队的实现能力, 来估算和真实世界的对应关系. -
开发人员很容易将工作对应到小时，而不是多少个点。虽然期望通过点来保证大家的统一理解，同时也能支持任何一个Story可以由任何人去做，但在实际中大部分项目Story的开发者都是相对固定的，所以估计小时数对开发者更适应。
-
相当同意你的说法。我个人觉得根据“短板效应”，使用团队平均完成速度来预算还是比较公平的。因此两者没有什么冲突的地方。我的理解是下列公式：
人时×团队平均速度=故事点数。
因此如果团队平均速度是一个定量，一个sprint完成的故事点数和完成这个sprint所需人时就是线性关系了。所以我反而不同意“在故事点数和工作小时之间没有线性的对应关系。”这个说法 -
拿赶路类比, 故事点数是距离(X千米), 小时数是在使用特定载具的情况下的所需时间(Y小时). 同样是1千米的路, 汽车和走路当然时间不同. 一个团队里, 新手老手解决同一个问题的时间也是不一样的. 一个条目取出来, 我们说他是1天能干完的, 必须是在确定谁来做的前提下.
即需要对问题复杂性本身的大致估算, 与实现者无关, 即故事点数.
也需要进一步参考团队的实现能力, 来估算和真实世界的对应关系.
这个貌似和我感觉上很符合，非常不错的解释
7 条回复
关注此讨论 回复