• ShineScrum
  • 2016-08-31
  • 来源:

Scrum-暴露功能障碍的强光

所有组织都受到功能障碍的困扰,这里的功能障碍指阻碍组织实现他们全部潜能的障碍或障碍物。敏捷流程(如Scrum)的好处之一就是它帮助暴露这些功能障碍。

虽然发现和解决功能障碍最终对每个组织最有利,但是一些组织对此没有兴趣。事实上,当一道强光照射在他们的问题上时,一些组织变得相当不舒服。事实上,他们是如此不舒服,以至于更乐意调整Scrum(那道光),而不是直面他们的问题。

那些抵制冲动,不去掩盖他们的功能障碍,反而选择勇敢面对Scrum揭示严酷事实的组织,往往会经历更多的成功。

让我给你们举一个例子。在我的培训课上,我常常会说下面的话:

程序员和测试员应在同一Scrum团队。他们的目标应该是,在每个冲刺结束时,产出已知缺陷为零的功能。

在一次课堂上,我刚传达这个忠告,一位女士就举手说:“那个忠告在我们这儿行不通。”

我问为什么,她回答说:“嗯,我是QA经理,所有的QA工作人员都向我报告。你刚才说,我应该把我部门的所有人都放在Scrum团队中,而且他们应该帮助团队确保生产零缺陷。”

我说:“是的,就是这样。我知道这是一个很有挑战的目标,一开始你可能无法实现,但为什么不把它作为你的长期目标?”

她回答说:“不,这行不通,因为我们会基于我们的测试员找到缺陷的个数来补偿他们。如果在冲刺结束时,他们没有已知的缺陷,他们的薪酬实际上会减少。”

我等着看她接下来会说什么,因为她如何应对她意识到的这个问题,将在极大程度上提示该公司是否能够成功运用敏捷。
她可能会说,“你能明白为什么我无法把我的QA指派到跨职能的Scrum团队中。我只是不得不用不同的方式来做事情。”

如果她这样说,就等同于她说,当Scrum这道强光暴露了一个障碍,我们不是解决这个面临的障碍,而是调整Scrum(例如,不构建跨职能团队),这样障碍就不存在了。换句话说,我们没有兴趣处理这个棘手的问题;取而代之,我们将继续推进一个可以说是疯狂的政策:根据他们所发现的缺陷个数来补偿他们。

(说到这个,难道这样的政策不会导致串通吗? 假设我是开发者,你是测试者。有什么能够防止我说:“嘿,我会在这里面放些缺陷,然后告诉你它们在哪里,你“找到”它们,我再把它们弄出去。然后我们一起分奖金!”但我跑题了。)

但是她完全没有那么说。相反,她说,“既然我们显然需要跨职能团队,好像我需要和工程副总裁以及人力资源总监谈谈怎样改变我的QA成员补偿政策。”

我宽慰地松了口气:她的确有兴趣来处理真正的障碍!

注意,在这个例子中,Scrum不是障碍的原因-根据测试员发现的缺陷个数进行补偿,这样一个糟糕的政策明明白白地摆在那儿。并且,Scrum不提供指导如何消除障碍本身。但Scrum的确持续的如一道强光,在这种情况下把障碍暴露给跨职能团队(可以说是良好的编码实践)。在Scrum的强光照射的地方,你的公司选择做什么,将最终决定你在多大程度上取得成功。

阅读英文原文:
http://innolution.com/blog/scrum-the-bright-light-that-exposes-dysfunction


本文由ShineScrum翻译,王子君审核