文章

巧妙使用“故事点”进行敏捷估计

/分类： /编辑：

克强在“敏捷中国”讨论组中引发对敏捷的估计的讨论（“Scrum sprint plan中规模估算的做法调查”，“关于story point的单位”）。我想分享一下我自己对敏捷估计方法的理解以及对于“故事点”的认识。

在敏捷开发中，团队通过两种方法对迭代做计划。

Read more →

应该为bug修复的故事安排故事点吗

/分类： /编辑：

在把一个产品从传统方法向敏捷方法的迁移过程中，团队通常带着一大堆bug前行。这通常是缺泛持续的高质量要求的自然结果。导入敏捷后不用多久，很多团队（及他们的产品负责人）会决定激进去清除这些Bug的backlog。 通常的做这件事的方法都是在每个Sprint中计划修复掉X个bug，或者是每个Sprint中计划花Y小时用在修复bug上。有时团队会为这样的活动写一个用户故事如“作为一个用户，我希望至少有15个bug被修复”或者“作为一个用户，我希望你这个Sprint中花大约50个小时去修复bug，使得应用系统逐渐的变得质量更高”。即使团队并没有明确的写一个这样的用户故事，他们也通常会在他们的任务板中加这么一行，以便于bug修复的工作是可见并且可以跟踪的。 Read more →

基于用户故事的计划及跟踪(三)

/分类： /编辑：

（这只是开发不能如期完成时的解决方法之一，这种方法应该是在客户比较有诚意合作的前提下使用。）
用户故事        故事点

卖饮料        4
取消购买        2
输入管理密码                                                        1
补充饮料        3
取出钱箱里的钱        1
安全警报        2
总计        13

然后他还要挑出总和至少为0.5个故事点的故事。
Read more →

故事点数是用于相对估计而不是排序

/分类： /编辑：

设我在计划买辆新车。于是我列出了一个车型清单。下面的列表按照优先级排序：

布加迪威龙超级跑车
帕加尼 Zonda Clinque Roadster
兰博基尼 Reventon
麦克拉伦F1
Koenigsegg CCX
保时捷卡雷拉GT
阿什顿马丁 Vanquish
丰田 Prius
丰田凯美瑞
塔塔 Nano
但是不幸的是，我认为我承受不了最高优先级的车型的昂贵售价。那么让我来给每辆车分配点数吧。我将会从优先级最低的车开始，给它1点，然后给下一辆车2点。按照点数分配，重新排列列表：
Read more →

看看团队的故事点数如何从1到8保持一致

/分类： /编辑：

最近关于如何利用用户故事的相对大小进行估算的话题，已经在很多评论以及这个博客的留言中多次出现过了，那么我们就这个话题来讨论一下吧。下面的图表显示了一个公司的相关数据：
scrumcn1319134105

每一列的数据和每一对柱状图都显示了来自下方表格中对应的用户故事点数的数据。第一组数据是关于1个故事点数的用户故事的，第二组是关于2个故事点数的用户故事，如此类推。在第一组数据中我们发现，这家公司中完成一个1个故事点数的用户故事所需要的时间的中位数是21个小时。最短所需时间是6小时而最长所需时间是36小时，在上图中分别用绿色和蓝色表示，而中位数则由红色曲线表示。

让我们来看看2个故事点数的用户故事。从图中我们可以看到，中位数是52个小时，最短和最长的时间分别是31和73个小时。如果我们假设1个故事点数的用户故事的估算是准确的，那么我们应该预期2个故事点数的用户故事所需时间的中位数应该是42个小时而不是52小时。反过来推断，那么1个故事点数的用户故事所需时间的中位数应该是26个小时。在绝大多数情况下，估计都不是完美的。无论是从哪边开始推断都有所偏差，因为2个用户故事的中位数并不是正好是两倍的关系。

但是我再看看3个故事点数的用户故事。根据推算，对应的中位数应该是1个故事点数用户故事的3倍，也就是说应该是63小时，从图中可以看出实际是64，已经非常接近。

同理，5个和8个故事点数的用户故事的中位数应该分别是105小时和166小时，而他们的实际值是100小时和111小时。但是，等等，我们必须要对这两种用户故事进行一些调整。如果你使用的是我推荐的方法的话，你就会将这些数字看成是一个个水桶。8个故事点数实际上对应的是从6到8的用户故事。所以，如果你认为一个用户故事是6个故事点数的话，你不能把它放到5个点数的那一项里面，而是要放到8个点数的一项。

这就意味着，5个故事点数的用户故事实际上是对应4个和5个点数的用户故事。如果我们假设这两个大小的用户故事的数量是相等的，那么实际的平均故事点数应该是4.5。于是4.5×21=94.5个小时，在实际值101小时的5%的误差以内，还算不错。

由于图表中8个故事点数对应的是6,7,8三种大小的用户故事，我们可以推断平均故事点数是7。于是，中位数应该是7×21=147小时。然而，实际值却是111小时。所以，这个团队在进行8个故事点数的用户故事的时候肯定会比计划中有所偏差。

（在这里我想说点题外话。与其简单地推断21个小时就是1个故事点数所对应的时间，然后在后续的计算中使用，使用Excel进行线性回顾分析会是更好的办法。你可以观察复判定系数r-squared来检验得出的值是否合理。在这里我并不想深入探讨这些数学问题。但是我相信，这些数据一直到8个故事点数都会比较准确。）

我鼓励你在你的公司收集类似的数据，但是你必须小心。因为你要收集的是每个用户故事的实际时间，所以很有可能你的团队会比平常感觉到更多的需要在估计时间内完成的压力。然后，他们也许就会给自己预留更加充裕的时间。要是这样的情况发生的话，最终将影响到数据的准确性，违背了收集数据的初衷。所以，让团队看看类似上面的图表，然后向他们说明这是为了帮助他们。举个例子，上面图表中的团队可能会意识到他们也许将本来应该是5个故事点数的用户故事误当作8个故事点数了。（从数据上来分析，也许他们的估算是对的，只不过是当中包含了比较多的6个故事点数的用户故事而已。）

很多团队会发现他们对故事点数从1到8的用户故事的估算还是比较准确的，就像上面图表中的团队一样。使用这种方法一段时间以后，加上一些练习和校正，几乎任何团队都可以对13个故事点数及以下的用户故事进行较为准确的估算。至于超过了13个故事点数的用户故事，使用这种方法的时候必须非常小心，或者只能够用来回答一些比较粗略的问题，如：“这个项目的周期大概是几个月还是要一年？”

如果你收集了你的团队的相关数据，并且愿意和我分享的话，我将会十分感激。你可以把数据通过邮件方式发送到mike@mountaingoatsoftware.com。我一直在做这些数据的研究工作，因此如果我能够有更多数据会更好。

作者:Mike Cohn

原文地址：http://blog.mountaingoatsoftware.com/seeing-how-well-a-teams-story-points-align-from-one-to-eight

 

Scrum还是Kanban？这不是问题

/分类： /编辑：

几天前，我就Matthias的关于Scrum强制团队只能在sprint结束之后才能发布，而Kanban则更灵活的帖子发表了看法。

我想知道Scrum和Kanban的不同，我很疑惑为什么有人抱怨Scrum把规则定得太死，不够灵活等等。于是，我参加了David Anderson的Kanban中级课程。

结果，David的课程让我大开眼界。David表示Kanban并不是去改变什么东西，而只是将工作流程可视化和将隐藏的政策公开讨论而已。Kanban通过加入并行任务的限制，使得公司需要进行的改变慢慢地涌现出来。David说Kanban和Scrum的不同就在于，Kanban所引起的改变是自发的，Scrum引起的改变是被动的。革新由于革命。

首先，我要承认的是我真的非常喜欢精益的思想。我对David能够把这种思想融入到软件开发中感到十分敬佩。有趣的是，和我一起上课的人里面有人把我认出来了，而且他们觉得很奇怪，我明明是Scrum的支持者，为什么我会出现在这里呢？

从1994年起，我就开始相信学习精益理论非常有用。当我在2002年知道Scrum以后，我就确信Scrum能够处理精益理论解决的问题。我认为David这种优雅地将精益思想引入到软件开发世界中来的方法是朝着正确的方向迈出了坚实的一大步。

但是，在这课堂中十分困扰我的是居然没有人提及一些在我讲授的课程里经常提及的问题，例如：
 如果大家愿意创建任务版怎么办？
 如果团队成员之间不想合作怎么办？
 如果大家不想坐在一起怎么办？
 如果管理层反对这样的工作方式怎么办？
 我该怎么样创建一个发布计划？
 我该如何计算出项目成本？

我见过有些人没有成功连续完成3个Sprint，经常找不到Product Owner，或者团队经常被打扰的问题无法解决。然后，这些人就说Scrum没有办法解决这些问题，Kanban才是更好的解决方案。恕我不客气地说一句，就在Kanban倒在无数无法解决的问题前的时候，Scrum的支持者们已经给这些问题提供了解决方案。

今天，Scrum的实践者们已经懂得了如何：
 管理大型项目
 解决大型团队的问题
 解决团队之间的依赖关系
 使用Scrum构建大型架构的框架
 在项目开始之前计算项目成本
 快速有效地进行估算
 还有很多很多
在David的一本书中解释的著名的“泳道”模式，是为了管理大型企业的模式。这个模式是我2004年在德国WEB.DE的时候为4个Scrum团队发明的。直到今天，我还在用这种模式来管理180人的团队。从2005年起，我在我的所有课程中都会解释这种模式。

但是，无论是Scrum，还是Kanban，还是ASD，还是Crystal都无法解决下面的这个问题：人们害怕改变，尽管他们已经看到问题所在。很多人，包括Scrum Master，都需要一个领路人来让他们变得更好。

使用Kanban，Crystal或者ASD的人都必须说服他们的团队或者管理层他们建议的方法是真正能够带来改进的。Ken Schwaber总是说：“行动才是最好的证明。”我必须承认的是，我也不大明白，David能够让人相信使用他推荐的方法，而不是单纯他们自己本身的能力能够解决问题。

我认为David就是一个天才，一个天生的领导者。我承认以他提倡的方式开展一个新项目会比使用Scrum看起来更加简单。Kanban可能在某些环境中更加有效，当然我们也可以在实施Scrum的时候使用Kanban中的某些方法。

其实，Scrum，Kanban，Crystal和ASD在核心上是非常类似的：找出障碍和问题的来源，然后有针对性的行动。

我的建议是按照你认为能够符合你当前情况的方式进行。你可以先使用Kanban然后在其中应用一些Scrum的内容，或者先使用Scrum然后在其中应用一些Kanban的内容。例如，为任务定义Service Levels是解决分组工作的很好的办法，或者让循环周期可见度更高。这些都是对Scrum很有用的补充。

我所关心的是，我们想要改变我们公司成员的工作方式。我们想要给他们授权，我们想要让他们高兴和给他们最好的，因为他们热爱他们所做的事情。

然而，更常见的是，在很多Scrum团队中，有的人默默离开，有的人行为根本不像成年人，有的人只愿意被动地接受别人指派的任务。正是这些人，通常会在我的课程里面问类似“我们真的有必要分割任务吗？如果我们不能完成所有用户故事怎么办？如果一个用户故事本应该是8个故事点而被估成5个点怎么办？”的问题。

我认识很多Scrum实施顾问经常会把他们的客户引导这些问题上面来，因为他们只懂得回答这些问题，或者更不幸的是，他们害怕使他们的客户面对更加麻烦的流程问题。这些顾问败坏了Scrum的名声，因为他们不敢向他们的客户提出一些有可能让他们感到不自在的问题。于是，为了保住他们的客户，他们选择了沉默。

当然，有时候我们会损失一些客户。因为客户对我们呈现出来的真相感到恐惧。我们并不迷信Scrum，我们只是做我们认为对的事。我们是很务实的！我们坚持真相和让事情更透明。那是因为Scrum虽然简单，但是却很难用好。

作者:Boris Gloger

原文地址：http://www.agileweboperations.com/scrum-or-kanban-it-does-not-matter

巧妙使用“故事点”进行敏捷估算

/分类： /编辑：

克强在“敏捷中国”讨论组中引发对敏捷的估算的讨论（“Scrum sprint plan中规模估算的做法调查”，“关于story point的单位”）。我想分享一下我自己对敏捷估算方法的理解以及对于“故事点”的认识。

在敏捷开发中，团队通过两种方法对迭代做计划。
  • 基于承诺”Commitment”。做法很简单：
    • Product Owner从Product Backlog中取下一个用户故事（按照优先级），对这个用户故事进行解释，
    • 团队对用户故事进行讨论，明确需要解决的问题，
    • 整个团队确定是否能够在下一个迭代周期中完成这个故事，
      • 如果团队没有信心完成该故事，计划会议结束，或者把这个用户故事进一步划分成更小的用户故事重复第一步。
      • 如果团队有信心完成该任务，重复第一步。
  • 基于速率”Velocity”
    • 确定Product Backlog中用户故事的规模（用“故事点”）
    • 确定团队迭代的开发速度（“昨天的天气”）
    • 从Product Backlog中取出相应量的用户故事。
基于速率的估算中，需要确定一个“故事点”，也就是确定一个速度的单位。而在敏捷计划与估算计中，这个“故事点”是没有单位的。为什么？首先来看一下传统的规模估算的方法（标准日、代码行数）的问题。
  • 绝对估算 vs. 相对估算
    传统的方式是通过计算出一个绝对值（有单位，比如多少人天，多少代码行）。然后，做出计划。很大的问题是，人天生不擅长做绝对估算，人们更擅长做相对估算，更容易在相对估算值上达成共识。举一个简单例子，估算从上海市人民广场到徐家汇的距离，如果使用公里或者米等绝对单位，多个估算者很难达成共识，往往陷入没有必要的讨论和争吵。而如果用相对距离，比如从人民广场到徐家汇的距离相当于两倍的从人民广场到火车站的距离，人们就很容易、很快达成共识。因此对一个需求点来说，关注于相对大小也更容易使整个团队在估算值上达成共识。
  • 关注规模（而不是将不同维度的概念混淆）
    比较合理的估算方法是，首先估算整个规模，然后有一定的历史数据，知道速度，从而可以做出计划，推算出时间。比如我们看书，一共三百页，一天看十页，很容易就算出是三十天。如果使用理想日（时间维度），其实就是把这个过程搞反了，从时间维度反过来推算规模。同时使用“故事点”可以综合考虑一些其他因素包括复杂度、不确定性等，基于故事点的规模估算是在综合考虑各种因素之后的综合估算。而用代码行数很难对复杂度、不确定性等作出估算
  • 忽略个人能力的不同
    不同人的理想日和代码行数估算是不同的，是根据每个人的能力和认识的不同而不同的。但是使用关注“相对大小”的“故事点”就可以解决这个问题。同样举距离的例子，每个人的能力是不同的（有人步行、有人跑步、有人公车、有人地铁、有人开法拉利），但是所有人得出的相对规模值还是一样的。因此使用相对规模估算就可以不需要考虑这种个人能力因素。
  • 不可相加
    传统估算方式的一个很大的问题是，估算不能相加。每个人的理想日是不一样的，这样成员甲的估算（理想日）就不能和成员乙的估算（理想日）相加。基于这种相加结果的计划肯定是不准确的。在敏捷开发中，需要整个团队一起对任务进行估算，因此需要一个能够达成团队共识的标准 – 也就是“故事点”。
因此，为什么“故事点”没有单位？
  • 首先，故事点是一个相对量，相对值是没有单位的；小学乘法：被乘数 × 倍数 = 积。故事点估算值就是这个倍数。
  • 其次每个团队的单位“故事点”是不同的，很难也不需要统一。
最后，其实敏捷的计划估算与传统的计划估算很大的不同是对计划的态度。在敏捷开发中，计划估算只是一个对未来的预测，因为是一个预测，所以总是有不确定性。敏捷开发计划承认这种不确定性，因此对计划估算的态度应该是不断根据新的发现，对计划进行不断的调整，但是不需要过于关注预测的准确性（我们的工作是为客户开发有用的软件，而不是提供可靠的计划。如果公司以预测的准确性来衡量员工的绩效，那其实大家也该考虑换一个地方了，这又是一种局部优化）。

关于作者：

爱迪德高级软件经理，InfoQ中文站特约编辑。他是亚洲第一位也是目前唯一一位认证Scrum教练(Certified Scrum Coach)，Daniel具有多年的敏捷项目（Scrum & XP）实践经验以及丰富的带队经验。

Daniel于2006年1月创建了Irdeto上海研发团队，并将Scrum和XP成功引入了团队。目前该团队主要负责数百万美金级别的大型付费媒体计费及客户关系管理系统的开发及维护，四年中成功发布产品的两个新版本。系统现在在美洲、欧洲以及亚洲的许多国家运行。

Daniel一直致力于将海外的敏捷思想、理论及方法以及实践介绍到国内，帮助国内的软件团队高效并有趣地工作，真正为客户创造价值。作为敏捷社区的活跃分子，Daniel通过博客、InfoQ以及讨论组等宣传敏捷。Daniel经常受邀到各个会议中针对敏捷话题进行演讲，他是敏捷中国2009的讲师，并受邀QCon北京2010以及在CSDN举办的软件开发2.0大会2009等中作关于敏捷的演讲。

Dianel的blog： http://www.cnblogs.com/tengzy/

故事点是工作量，而非复杂度

/分类： /编辑：

是工作量，而不是复杂度
有个客户问我，“我的团队什么时候才能完成这个项目？”我已经被问过千百次类似的敏捷项目管理问题了。
但却从来没人问过我，“开发这个项目我的团队要费多少工作量去进行思考？”
客户，老板，顾客以及干系人只会关心一个产品要耗时多久，却不会去理会要交付该产品我们得多么殚精竭虑地思考，除非这些必要性的思考会带来时间或成本风险。 Read more →

故事点和小时数如何对应？

/分类： /编辑：

我经常被问到故事点和小时数的关系。提问者经常期待我像这样回答

“一个故事点=8.3小时”。好吧，事实并非如此(尤其是我用了8.3这个数字)。来，让我们看看敏捷故事点和小时数之间的真正关系吧。

假设因为某些原因你跟踪了一个团队一段时间，来查看他们开发的每个1个故事点的用户故事。如果你把相关数据做成图的话大概会是这个样子： Read more →