Scrum敏捷项目管理

逃逸速度

遵循著名的口头禅“你可以’尽你所能’t衡量”,Scrum团队通常具有一组衡量其活动的指标。速度,即团队在单个冲刺中完成的工作量,可能是最著名的敏捷指标之一。诺顿医生(Doc Norton)写了一本有趣的书,讲述了速度的负面影响以及对于敏捷团队而言可能是一个好的指标。

根据他的经验,Doc Norton在开始他的书时就对速度度量的缺陷进行了长时间的讨论。在此基础上,他接着解释了度量标准的一般问题,并提出了替代方法(提前期,团队快乐度等),以监控敏捷团队的发展。我最喜欢的部分是试图从客户角度检查问题的部分。这本书易于阅读,将概念与with中的故事相结合。

我会自然地向Scrum团队的每个成员推荐这本书,但是它应该为每个软件开发项目经理或执行人员提供有趣的想法。

参考: 逃逸速度–敏捷团队的更好指标,诺顿博士, //leanpub.com/escapevelocity

逃逸速度- Better Metrics for Agile Teams

行情

速度是一个较差的指标,其提供的价值远远小于永久性滥用所引起的焦虑。

在敏捷软件开发中,速度是团队为客户交付价值的速度。价值是可量化的,因此我们可以说它具有规模。从概念到实现的遍历指示了方向。一个完成许多任务但没有为客户带来任何价值的团队的速度应该为零。我之所以说“应该”,是因为我看到很多团队根据除了给客户带来价值以外的标准来衡量速度。有些人认为开发完成后就完成了一个故事。其他人则稍微“成熟”一些,并在准备投入生产时将故事视为完成故事。请注意,这实际上不是生产中。这需要几个星期–带有手动测试要求和变更控制程序的内容以及如何让操作团队排队……有些团队认为故事一旦真正投入生产就已经完成。但是,即使那样,也会为客户带来价值。如果您没有将故事算作是在客户实际使用并喜欢它之前怎么办?如果速度是我们向客户交付价值的速度,那么速度的真实衡量标准是否包括价值交付的验证?

领导者(和团队)试图以多种方式实现速度提升。您可以想象,大多数对团队都有意想不到的副作用,并且没有任何实质性改善可为客户带来价值的实际流程/交付。在这里,我们探讨了鼓励团队提高速度的几种方法。不幸的是,无论意图多么好,使用此类技术仍然会产生负面影响。

如果您必须估算(可能不需要估算),那么我建议您使用参考故事。确定整个团队可以接受的故事是1分。确定整个团队可以接受的第二个观点是5分。在估算时,请牢记这些故事,并尝试估算所有与之相关的故事。然后,在估计会话结束时,将故事与参考模型进行比较。这些要点仍然感觉正确吗?将故事与先前迭代中的随机选择进行比较?这些要点仍然感觉正确吗?如果不是,请根据需要调整新的估算值。

与我合作的大多数团队都扮演三个不同的角色。 BA,开发人员和质量检查人员。与我合作的大多数团队都有三个不同的工作阶段:收集需求,构建,验证。即使在敏捷团队中,也存在这些分离。在此过程中有明确的界限和明确的职责分工。但是,这种隔离是速度不稳定的原因之一。您知道多少个“敏捷”团队的BA组比开发人员的质量领先于QA的开发人员,这使我们有3个迭代周期,并且各组之间的反馈循环明显滞后?收紧环线。让人们不仅紧密合作,而且紧密合作。让开发人员和质量检查人员参与需求的形成。将质量检查推到最前面,然后进行自动化,自动化和自动化。不要让手动测试成为瓶颈。在完善需求之前就开始开发。并且不要等到最后全面测试所有内容。