似乎 Scrum 和敏捷测试/断言在今年变得流行起来。例如,诺基亚测试 Scrum。我认为进行这样的测试根本不是一个好主意。你怎么看?
3 回答
一方面,越来越多的人声称他们是敏捷的,所以这样的测试可以让我们整理出“我们在做 XP,我们不评论我们的代码”这一行。
但是我们如何才能确保人们会以正确的方式理解这个问题,而不是回答“嗯,我们有迭代。我们经常不得不稍微扩展它们来满足我们的承诺,但我们确实有四个星期的迭代。” ?
另一方面,您提供的链接很有趣,因为它不是初始版本,它得到了 Jeff Sutherland 的支持。
关键是:你不能用八个问题来概括一个开发方法。因此,恕我直言,如果在正确理解问题的情况下回答,则单独的测试很有趣。这对想要改进的团队很有帮助。对于通过此测试收集的结果,我不会说同样的话。
这篇 infoQ 文章以更好的方式说明了这一点:简单的清单可以提供有用的快速评估。他们不会告诉你这些做法是否真的产生了效果。
我很快就参加了测试,发现这些问题对于任何声称正在做 Scrum 的人来说都是很好的问题。我还会问一些问题,例如:
- 你有一个自动化的构建过程吗?
- 它多久运行一次?
- 当构建中断时会发生什么?
OTOH,像这样的测试作为自我评估很有用,但我不会根据测试“评价”一个团队。
我看到诺基亚测试可用于快速概览。
为了进一步调查,我建议使用Henrik Kniberg 编写的更详细的 Scrum Checklist,它有助于教练和Scrum Master 快速发现敏捷团队在大多数领域的差距。即使有 70 个问题,团队成员也会回答是/否。我们能够在 20 分钟内完成这项调查。特别是如果你在几个月后重复它,你可能会对你的团队的回答感到惊讶。
如果您需要对敏捷实现进行深入分析,我建议使用由Mike Cohn创建的 C*比较敏捷*y 评估。它有助于您的公司与行业的相对比较。我们在对适应过程质量有直接影响的企业组织中使用它。多亏了这家企业公司的适应过程要好得多
在此处查看有关 Scrum 清单和比较敏捷性的更多信息。