- ShineScrum
- 2016-08-31
- 来源:
Scrum-暴露功能障碍的强光
所有组织都受到功能障碍的困扰,这里的功能障碍指阻碍组织实现他们全部潜能的障碍或障碍物。敏捷流程(如Scrum)的好处之一就是它帮助暴露这些功能障碍。
虽然发现和解决功能障碍最终对每个组织最有利,但是一些组织对此没有兴趣。事实上,当一道强光照射在他们的问题上时,一些组织变得相当不舒服。事实上,他们是如此不舒服,以至于更乐意调整Scrum(那道光),而不是直面他们的问题。
那些抵制冲动,不去掩盖他们的功能障碍,反而选择勇敢面对Scrum揭示严酷事实的组织,往往会经历更多的成功。
让我给你们举一个例子。在我的培训课上,我常常会说下面的话:
程序员和测试员应在同一Scrum团队。他们的目标应该是,在每个冲刺结束时,产出已知缺陷为零的功能。
在一次课堂上,我刚传达这个忠告,一位女士就举手说:“那个忠告在我们这儿行不通。”
我问为什么,她回答说:“嗯,我是QA经理,所有的QA工作人员都向我报告。你刚才说,我应该把我部门的所有人都放在Scrum团队中,而且他们应该帮助团队确保生产零缺陷。”
我说:“是的,就是这样。我知道这是一个很有挑战的目标,一开始你可能无法实现,但为什么不把它作为你的长期目标?”
她回答说:“不,这行不通,因为我们会基于我们的测试员找到缺陷的个数来补偿他们。如果在冲刺结束时,他们没有已知的缺陷,他们的薪酬实际上会减少。”
我等着看她接下来会说什么,因为她如何应对她意识到的这个问题,将在极大程度上提示该公司是否能够成功运用敏捷。
她可能会说,“你能明白为什么我无法把我的QA指派到跨职能的Scrum团队中。我只是不得不用不同的方式来做事情。”
如果她这样说,就等同于她说,当Scrum这道强光暴露了一个障碍,我们不是解决这个面临的障碍,而是调整Scrum(例如,不构建跨职能团队),这样障碍就不存在了。换句话说,我们没有兴趣处理这个棘手的问题;取而代之,我们将继续推进一个可以说是疯狂的政策:根据他们所发现的缺陷个数来补偿他们。
(说到这个,难道这样的政策不会导致串通吗? 假设我是开发者,你是测试者。有什么能够防止我说:“嘿,我会在这里面放些缺陷,然后告诉你它们在哪里,你“找到”它们,我再把它们弄出去。然后我们一起分奖金!”但我跑题了。)
但是她完全没有那么说。相反,她说,“既然我们显然需要跨职能团队,好像我需要和工程副总裁以及人力资源总监谈谈怎样改变我的QA成员补偿政策。”