文章

可持续的节奏：相信你的团队

/分类： /编辑：

无止境的商业需求，特性需求，市场压力，总是有更多的工作要完成。有时候，你会感觉无止境的sprint就像你觉得你每次快到终点的时候，总有人告诉你还有一圈。你鼓足了劲继续前行，但是当你转过最后一个弯道准备冲线的时候，你听见场外有人在喊“还有一圈，还有一圈”，然后你试图再次给自己鼓劲但是你已经筋疲力尽。你一直在想你会有机会休息的，但是你从来没有等到那一天。一个接一个的sprint就像一圈又一圈的赛跑，你永远都看不到终点。你需要调整你的呼吸，需要补充水分，你已经慢慢开始体力透支，直到最后精疲力竭。
Read more →

在混合型的开发和受限于服务品质协议的bug修正团队中使用敏捷

/分类： /编辑：

如今在大多数的软件开发组织中，没有专门的维护工程（SE）团队来关注已发布产品的维护和支持。工程（研发）团队除了完成产品的功能开发外，要花费同样的时间来完成维护任务。然而，支持服务品质协议（SLAs）的维护支付的客户通常都很严格，所以比起研发，维护工程经常有更高的优先权。然后遵循scrum的工程团队由于维护工程问题的大量涌入以及对于迅速解决问题的需求，他们无法成功地递交承诺的功能。在功能开发和修改bug中挣扎反作用于团队士气和工作积极度。
以下基于scrum的选择是由小组成员提出建议来克服在这些情况下发生的问题的。 Read more →

敏捷绩效评估

/分类： /编辑：

每年我们都痴迷于为团队成员评级。回顾软件开发领域，好像已经有近50年历史，有一些我们可以肯定的是：软件是由团队来创建的，而不是个人的。此外，每个人都需要积极主动的合作来生产有质量的软件，这意味着团队中的每个人来承担集体所有制，并且相互帮助。因为他的主旨并不是成为一名英雄，而是创建一个超高质量和可预测的最终产品。 Read more →

支持特性团队

/分类： /编辑：

当我最初给某个位于加州的游戏工作室做咨询的时候，它的团队是按照存在于他们开发的游戏中的具体的内容和对象来组织的。对于每个角色有一个单独的团队，比如包括武器团队、车辆团队等。这带来了一些问题，比如武器太弱以至于不能够杀死怪物，颜色太暗以至于不能显示秘密通道和障碍，这样的问题，即使是那些最耐心的玩家也会感到沮丧。

在更传统的企业应用项目上，当团队结构是几乎按照应用程序分层来划分的时候，我们看到了同样的问题。举例说明，一个典型的项目早期阶段的错误，它将有4个团队：一个富客户端团队，一个Web客户端团队，一个中间层团队，以及一个数据库团队。创建一个这样的组件团队会带来各种问题，它们包括 Read more →

对速率重新取样来模拟项目

/分类： /编辑：

我通常只会在我使用过一个技巧若干年并发现这个技巧确实在几个不同情形下都适用后才会将这个技巧告诉大家。而今天，在本文中我要介绍的正式这样一种技巧。这是一种统计学的方法，叫做“重新取样”，我一直喜欢用这种方法来对未来的速率进行预测。

重新取样是基于我们相信我们在未来观察到的数据会和以前观察到的数据相似的原理的。在下面我们要观察的例子中，我们假定一个团队在将来的速率应该和过去的速率是相近的。我们可以把重新取样想象成将所有我们收集过的老数据全部都放到一个袋子里面。如果我们过去的速率是18，17，18，19，22和20，然后相信我们把这些数字都分别写在纸条上，然后放入袋子中。需要留意的是，在这个袋子中将会有两个上面写着18的纸条，因为我们有两次的速率都是18。

接下来要预测未来的速率了，我们要做的就是从袋子中拿出一张纸条。第一张被抽出的纸条上面的数字就是我们预测第一个sprint的速率。然后我们要预测第二个sprint的速率，我们要做的就是再从袋子里抽出一张纸条而已，但是在这之前，我们必须要将第一次抽出的纸条先放回到袋子中。这种方法叫做“resampling with replacement”。因为团队在任何给定的sprint都有可能再次达到以前的任意一个速率。

假设我们要预测一个团队在未来十个sprint能够完成的任务量。我们就会重新取样十次。每次我们都从袋子里抽出一张纸条，然后放回去，直到抽完十次。最后我们把十次抽到的数字加起来，于是我们就得到了这个团队在接下来十个sprint有可能完成的工作量。

当然，我们完全有可能十次都抽中数值最大的22，也有可能都抽到17。但是，实际上这两种情况出现的概率极低，最多每几千或者几百次才出现一次，所以基本上可以忽略不计。

由于我们不可能手工来做几千次的取样，这个时候我们就需要电脑来帮助我们了。这样我们就可以从大量的数据中看到实际的结果了。假设我们要启动一个10个sprint的项目。如果我们能够知道以下这些东西将会对我们有很大帮助：

  •  10个sprint能够完成的工作量的平均值是多少？
  •      团队完成200个故事点数的工作量需要的时间是多少？

其实要回答这些问题，使用重新取样和模拟的方法是最直接的了。接下来让我们来看看怎么做吧。你可以根据这个速率重新取样电子表格（http://blog.mountaingoatsoftware.com/wp-content/uploads/ResamplingVelocity.xls）来进行。在下图中，B3单元格到B28单元格显示的是历史速率。

scrumcn1320381250

由于我们的项目需要10个sprint，单元格D3到E12显示的是sprint 1到10重新采样后的速率。

agilescrumcn1320381274

重新采样速率实际上就是从单元格B3到B28中随机抽取速率而已。这样的任务可以使用下面这条公式来完成：
=SMALL($B$3:$B$28,INT(COUNT($B$3:$B$28)*RAND())+1)
这个公式首先产生一个1到26之间的随机数，然后用SMALL方法从列表中选出一项。（SMALL方法是从一个列表中选中最小的一项，在这个例子中我们也可以使用LARGE，目的只是为了要从B3到B28中随机抽取一个速率而已。）

因为我们对E3到E12使用了RAN()函数，所以每次你在表格中改变任何单元格的时候，E3到E12中的数值都会变化一次。这个正是我们想要的结果。

E3到E12模拟了10个sprint的速率。然而，我们想要的是模拟100次，200次甚至是1000次项目的数据（每次都是10个sprint）。要达到这样的目的，我们必须做一些额外的工作，因为我们将要使用大家在Excel中不大熟悉的Data Table。在我们的表格中，Data Table的范围是G3到H202，下图显示的是其中一部分。

scrumcnagile

G列显示的是sprint的序号，H列显示的是10个sprint速率的总和，也就是说每个单元格就代表了这个例子中一次项目。从途中可以看出，第一次项目10个sprint总共可以完成的故事点数是230点。在下一行中，团队得到了高得多的速率264。在数据表格中，我重复了这样的操作200次，当然你也可以根据自己的情况来增加或者减少。

本文结尾有建立Data Table的概述。想要详细介绍请参阅Excel帮助文档。

现在我们有200个次项目的数据了，于是我们就可以回答之前提出的问题了。“这个团队在10个sprint中一个可以完成多少工作量呢?”单元格E17和E18显示出200次模拟项目的可以完成的平均工作量，以及其标准差。

scrumcn1320381462

在这个例子中，重新取样的平均值是240点，标准差是12。于是我们可以推测团队可以完成大概240个故事点数的工作量。我们都知道有95%的可能性团队能完成2个标准差范围内的任务，也就是说95%的可能团队可以完成216到264个故事点数的任务。

如果我的老板需要我保证的话，我会说：“我可以保证完成216个故事点数。”当然，从技术角度分析，我知道数学方法并不能支持我的承诺，因为还有2.5%的可能我们会只能完成少于216个点数的任务。尽管如此，包括我参加过的很多很好的团队在内，人们总是希望能够多做一点，而不是只承诺216个点数，于是，我们还是决定210点以防止那2.5%的概率发生。

另一个通过这种模拟项目可以解决的问题是，当你的老板对你说：“我们要在接下来10个sprint以内完成250个故事点数的工作。”你可以通过重新采样的方法来看看完成这么多的工作有多大可能，也可以知道有多大可能性可以超过老板，客户和用户的预期。下图中的表格正是显示了这个自动完成的功能。

scrumcnagile1320381491

在L20单元格中输入期望的数值，表格会自动计算在模拟中达到或者超过这个数值的次数填入L21中，然后把得出的机率填入L22单元格中。在这个例子中，如果老板想要在10个sprint中完成250个点数的工作，我们可以回复说“我们会尽力，但是历史数据表明我们只有20%的机会完成这么多的工作。”

希望这种重新取样的技巧能对你有所帮助。使用这种技巧还可以完成很多估算。我会在以后的文章中做介绍。

你可以在http://blog.mountaingoatsoftware.com/wp-content/uploads/ResamplingVelocity.xls下载上面这些例子。

如何创建Data Table

要创建Data Table，首先要在H2（也就是你想要显示模拟结果的单元格）填入你需要用来计算每次模拟结果的方程。在这里，由于我想要知道10个sprint的速率总和，于是我输入：=SUM($E$3:$E$12)

接下来，在G列中填入数字1到200。然后假设你要做200次模拟，选中G2到G202单元格。现在我们开始创建Data Table。在我手上的Excel – Mac 2011中，选中Data->What If->Data Tables。然后你会看到一个弹出对话框询问需要的取值范围。然后用鼠标选中G2单元格。关闭对话框，你就会看到200行的模拟数据了。

作者:Mike Cohn

原文地址：http://blog.mountaingoatsoftware.com/simulating-a-project-by-resampling-velocity

根据待办列表中的一项估计整个列表

/分类： /编辑：

在本文中我想讨论一下最近经常被提及，几乎每个月都要被问到的一个问题。这个问题就是我们如何能够在没有可参考的历史数据的情况下，估算完成整个产品待办列表中所有项目所需要的时间。

我的建议是，在没有能够试行第一个Sprint之前，不要轻易给出答案。但是，我们总是要应对各种特殊情况的。在我们无法试行一个Sprint的情况下，可以举行一到多次的承诺驱动的(commitment-driven)的Sprint计划会议，然后根据这些数据来预计可能的速率。

当然，有的人总是喜欢使用小时，而不是速率，他们希望能够估计出完成产品待办列表所需的小时数，从而估算出整个项目周期（然而通过速率反而能够更直接的估算项目周期）。但是，既然这是一个普遍问题，我就希望能够解决它。

下面是经过我简化和提炼的实际问题：

我们没有历史的速率数据。我们有一个包含300个用户故事的产品待办列表。所有的用户故事都已经完成估算了，大多数都在3到13个故事点数左右。下面的方法合理吗？
1. 随机选择40个用户故事。
2. 把这些用户故事都分割成任务，然后对人物进行估算。
3. 然后可以得出每个用户故事的平均小时数。

例如，假设我们随机选择了40个用户故事，总共有150个用户故事点数，然后通过估算，完成这40个用户故事总共需要600小时。那么我们就可以得出每个用户故事点数大概是4个小时了吗？

嗯，是的，但是这种方法有下面两个问题：

1. 千万要记住故事点数和小时数并不是对等的关系，不能相互转换。我们不能够像上面的例子那样说1个故事点数就等于4小时。1个故事点数大约等于4个小时加上标准差，假设是45分钟。这就是说，在68%的情况下，1个故事点数等于3个小时15分钟到4个小时45分钟，在98%的情况下，1个故事点数等于2个半小时到5个半小时，也就是2个标准差。
2. 以上的方法假设1个故事点数的用户故事和13个点的用户故事是按照相对估算的。也就是说，如果1个故事点数为1的用户故事如果需要4个小时，那么一个13点的用户故事就需要13X4=52个小时。由于各种原因，这种推断并不成立。根据我收集的很多团队的数据表明，正如我们所预期的一样，团队并不是完美的。

那么我们怎么样才可以解决这些问题呢？第一个简单的解决方案就是，我们计算出每种大小的用户故事所需要的平均小时数，而不是把所有大小的用户故事合起来一起计算。例如，在上面的例子里40个用户故事总共是150个故事点数和600小时，然后得出每个点数等于4小时的结论。但是，如果我们把所有故事点数为1的用户故事来做计算，我们有可能会发现1个故事点数等于3.2个小时。同样的道理，我们可能发现2个故事点数的用户故事可能是1个故事点数等于4.3个小时，而用3个故事点数计算的时候，1个故事点数等于4.1个小时。

然后，我们就可以将平均小时数和对应的用户故事个数相乘得出每种大小的用户故事所需要的总时间。如下表所示：

 

 故事点数  每个用户故事对应小时数   用户故事个数   总时间
 1   3.2   5   16.0
 2  8.6  8  68.8
 3   12.3   7  86.1

我们首先要注意的是，在上表中的第二列是每个用户故事对应的小时数而不是每个故事点数对应的小时数。一个故事点数为2的用户故事每个故事点数等于4.3小时，所以一个这种大小的用户故事总共需要8.6小时。

 

这个表格告诉我们，故事点数为1的用户故事一共有5个，每个需要3.2小时。最后把最后一列的总时间相加就是170.9个小时。

在这里需要注意的是，这种方法会包含所有在分割任务和估算时间中的缺点。由于通常团队会无法一次过确认所有任务，所以这种方法只能估算出能够在会议上找出的任务所需要的总时间。因此，这种估算方法将需要后续的调整工作。我将会在后续的文章中讨论对这种简单方法的改进方案。

作者:Mike Cohn

原文地址：http://blog.mountaingoatsoftware.com/estimating-a-full-backlog-based-on-a-sample

从估计绝对时间转换到相对估计

/分类： /编辑：

恭喜你终于说服团队使用相对估计的用户故事点数来估算工作量，这真的是一个非常大的进步，现在你准备好进入到你们的第一次估算扑克游戏了吗？你该怎么开始呢？哪个是1个点的故事？哪个又是3个点的呢？13个点的呢？这个游戏对你和你的团队来说都是一个全新的开始。

我曾经见过一个简单的设定初始值的方法就是先从你的产品待办列表中找出一个大家同意作为1个点的用户故事。然后，你就可以再挑选一个大概是这个用户故事2倍左右工作量的故事作为2个点的用户故事，接着就是两倍于2个点的用户故事的工作量的作为5个点的用户故事，以此类推。这样做没什么问题，但是你要清晰地意识到你的团队对这个流程还是非常陌生的，同时你又希望尽量地减少歧义和主观性。然而，任何估算本来就是主观的，因此，我在这里推荐一个更加切合实际的方法来帮助团队更好地进行估算。

一个不一样的方法

我们并不能因为我们采用了新的估算方法就把以前的估算方法看作成噩梦然后迅速忘掉。在以前的某些时候，这些方法是可行的。用例、问题、bug、功能特性——无论你管它们叫什么，团队都能够完成，而且团队也有对这些东西的工作量有一定的认识。我的方法是，我们仍然采用老式估算方法的一部份来建立起和新的用户故事点数的对应关系。下面是我的方法的流程：
1） 建立一个用户故事点数和实际时间对应的表格（为了保持表格简洁我把20，40和100点去掉了）。如下图所示：
scrumcn1314947985
当然，你可以根据自己的需要对时间部份进行修改。值得注意的是，随着点数的增加，在时间部分的上限和下限变得更加重要（例如不能是线性的）。这是因为越大的用户故事，包含的不确定性就越多。
2） 以团队为基础，回顾一下（可以回顾文档或者仅凭记忆）以往类似功能特性所需要的时间。需要留意的是，这里所指的时间必须包括了能够把用户故事标记成完成的所有任务的时间，例如开发、评审、设计测试、执行测试、部署等等。
3） 根据我们得到的时间，我们就使用第一步中的表格把第二步中的功能特性作为对应大小的用户故事的参考。例如，以前的XYZ特性现在成为了8个故事点数的用户故事的参考。
4） 然后我们重复这些步骤，直到我们为每个用户故事点数卡片都找到了相应的作为参考的特性为止。

有一点值得注意的是，一旦完成了这个过程以后，一定要把故事点数和时间的对应表格去掉，而使用刚刚找出来的作为参考的特性。这样，我们就可以开始把新的用户故事和作为参考的特性进行比较来进行我们的扑克游戏了。有些人会想，要么我们就继续用上面的对照表格来继续估算吧？但是，这并不是我们想要的。假如我们真的这么做的话，其实我们就是在进行套上了用户故事点数外衣的老式估算而已，而最后我们发现我们这么做纯粹是浪费时间。如果有人问起老式的估算时间方法，你就可以假装失忆然后告诉他你已经忘了，现在你唯一记得的就是要用用户故事之间进行比较，而不是直接去估算时间。唯一的例外就是团队有新成员加入的时候，而他又不熟悉估算扑克的流程，这个时候可以让他先使用故事点数和时间对应的表格进行训练一到两次。

还没结束呢

如果你按照上面的方法进行，我相信你们一定能够很容易地完成第一次估算扑克游戏，然后你们的一个Sprint马上就要开始了。但是，这还没完，仍然有一些东西需要进行调整。

在Scrum中，通常你会每天跟踪完成剩余的任务所需要的总时间（通常这会在燃尽图中反映出来）。但是，我还希望能够统计出完成的用户故事所需要的实际时间，这样，我们就可以比较实际所花的时间和之前按照1）中表格估算的差距。（嗯，也许我应该早就把那个表格给丢掉了，但实际上我总是在我的桌面上放着一份拷贝）

如果用户故事进行得很顺利，但最后发现其实这个应该是一个13个点数的用户故事，而不是8个，那么我们就应该做一些调整，把这个用户故事作为13个点数的故事的参考，这样下一次我们就能够更好地进行估算。我这么做就是为了能够让我们的估算的根基能够更牢固一些。

我会跟我的团队说明我记录实际完成的时间并不是要用于绩效考评。团队需要知道我们这么做的原因是出于“检视和应用”的考虑来改进估算而不是想要进行微观管理。

现在你已经知道要怎么做了。如果你觉得这个方法有用，或者你有更好的办法的话请告诉我。

 

作者:Ilan Goldstein
原文地址：http://www.scrumalliance.org/articles/368-transitioning-from-timebased-to-relative-estimation

Scrum-ban

/分类： /编辑：

Scrum-ban是一个Scrum和Kanban的开发模型。Scrum-ban尤其适合于那些维护的项目或者经常会有用户故事变更或程序错误的项目和系统。在这些项目中，Scrum模型中规定时间的sprint显然就不能够满足项目的需求了，但是Scrum中的每日站会和其他一些工程实践还是可能根据团队的情况加以运用。可视化的工作进度和对未完成的并行用户故事和任务的限制都是Kanban的法宝，通过这两样法宝，能够指引团队以最少的时间完成用户故事和修复程序错误以及保证团队每个成员都能持续地投入到工作中。

为了能够清楚地展示工作的每个阶段，在同一个地方工作的团队通常会使用便签纸或者一块大的白板。而分布式团队通常会使用工具软件，如Assembla，ScrumWorks或者安装上GreenHopper的JIRA来帮助团队更好地了解各个用户故事、缺陷和任务所处的状态。

最简单的办法就是把任务或者用户故事划分成以下三类：
 候选
 进行中
 已完成

如果有需要的话，团队可能添加更多的状态，例如，“已定义”，“完成设计”，“完成测试”或者“已交付”等等。划分更细的状态能够帮助团队在遇到瓶颈又不能改变并行任务的最大限制的时候更有效地解决问题。同时，更具体的任务状态划分也能够使团队成员更专注在特定的工作环节上。

对于最大并行未完成工作的数量并没有一个通用的值，每个团队需要根据自身的情况来设定。如果这个值设得太小，有可能会导致很多团队成员有太多的时间在空闲状态；如果这个值设得太大，那么就有可能会在同一时间出现大量的未完成的工作，从而导致每个任务完成的时间大幅上升。这里给出的建议是，每个团队成员同一时间不能进行超过两个任务，另一方面在同一时间所有团队成员不能都有两个任务。

Scrum和Kanban最大的不同就是，Scrum把工作划分成固定长度的周期——sprint中，而Kanban则以持续工作的方式进行。从表示任务状态的表格来看，Scrum会在每个spirnt把表格清空，而Kanban则一直沿用同一个表格。从团队组成来看，Scrum强调的是跨职能团队，团队成员需要是多面手，而Kanban则更强调专职团队。

由于Scrum-ban是新的开发模型，因此并没有太多的参考资料。就目前来看，Kanban至少已经被Microsoft和Corbis采用了。

对非功能性需求的估算

/分类： /编辑：

几个星期前，我曾经答应某人在博客上发表关于估算非功能性需求的独特挑战的文章。

首先，我们应该知道所谓非功能性需求是指对整个系统状态的一种需求，而不是系统的某个特定功能。非功能性需求通常包括性能，准确性，可维护性，互通性以及便携性等等。

（在这里顺带说一句，如果你对如何用用户故事的形式表达非功能性需求的话可以看这里：http://blog.mountaingoatsoftware.com/non-functional-requirements-as-user-stories。）

估算非功能性需求的挑战是它包含两项成本。第一个是初始维护成本。第二个是持续维护成本。

让我们来看看下面这个例子来说明这两个成本。假设一个团队正在开发一个新产品，而且对该产品有性能方面的需求。在第一个Sprint中，团队可能会考虑到性能的问题，但是由于还没有足够的代码，他们并没有办法去做性能测试。在几个Sprint以后，比如说Sprint 5，团队觉得已经有足够的代码，并且决定从这个Sprint开始做性能测试。

还记得我们提到过的初始维护成本吗？在这个例子中，就是指团队在Sprint 5开始做的性能测试的工作。虽然，性能测试比不会比大多数的其他用户故事多花很多时间。于是，团队在估算的时候给性能测试预留了几个用户故事点数或者理想人日。

接下来，我继续看这个例子。假设团队真的在Sprint 5中进行了性能测试，并且根据测试的结果进行了调优。在第六个Sprint的时候，团队还需要继续增加新功能，这就是刚刚提到的第二个成本—持续维护成本。一旦团队在项目开始中开始关注非功能性的需求（就像例子中的团队在Sprint 5中做的那样），他们就必须在项目中接下来的日子里一直维护下去。我把这项成本看作是一种税。性能测试（或者说持续维护非功能性需求）给团队带来了额外的负担（也就是税）。而且这种负担或者说税必须一直的持续下去。

有些时候，团队和Product Owner会确定每个Sprint都需要承担这种税。在这个例子中，就意味着每次他们要添加一个功能，他们都必须要给新功能甚至是整个系统做性能测试。有时候，团队和PO可能会同意每隔几个Sprint才承担一次。毕竟，有时候团队会说新加入的功能并不会给系统的性能带来什么影响，而且我们并不会在这个Sprint后发布。我们可以把每个月的进行性能测试想象成销售税或在VAT。把每隔几个月进行一次测试的想象成季度税，例如在美国的独立承包商所付的税。

我们到底应该如何估算非功能性需求呢？答案很简单，把上面提到的两项成本分开估算。像估算其他用户故事或者待办事列表项目一样估算初始维护成本。团队和Product Owner需要一起估计什么时候开始进行测试，因为在第五个Sprint开始做性能测试和在第二十开始做是不同的。然后，团队和Product Owner要协商持续维护的频率，是每个Sprint都要做还是每N个Sprint做一次？然后团队可以估算需要的工作量，然后分配相应的时间。比如说，团队和Product Owner决定每4个Sprint做一次性能测试，团队估算出每4个Sprint大概需要6个用户故事点来做性能测试。也就是说，大约每个Sprint要1.5个故事点。如果团队的速率是30的话，1.5个故事点可以看作成是5%的税。当然，对于第一次团队的估算可能不大准确。不过值得庆幸的是，团队在几个Sprint之后可以清楚的知道他们在性能测试上具体花了多少时间，然后根据统计来修改他们对持续维护成本的估算。

原文地址：http://blog.mountaingoatsoftware.com/estimating-non-functional-requirements

 

作者:Mike Cohn