• A-CSM 国际Scrum联盟认证 ScrumMaster
  • 敏捷思维 领导力 企业培训 国际Scrum联盟认证
  • 敏捷开发课程
  • CSM A-CSM Scrum敏捷实践
  • 敏捷领导力认证培训  CAL认证培训 CST CSP
  • A-CSM 国际Scrum联盟认证 ScrumMaster
  • Scrum硬件敏捷产品开发 国际Scrum联盟认证
  • 30天软件开发 敏捷规模化实践 Scrum精髓 敏捷文化
  • CSM CSP CAL CSPO CSD CST CEC CTC
  • 认证csm cspo cst
  • Scrum敏捷培训 Scrum敏捷企业内训
  • Scrum敏捷软件开发管理 企业内训 Scrum转型
  • Scrum框架
伪造敏捷指标或造假敏捷

TL; DR:

伪造敏捷指标——令人大开眼界的练习

设想您是一名SM,而您的团队经理深信敏捷转型成功的最好指标是敏捷团队的开发速度不断提高。如果团队未能取得该指标,那么要不团队有问题,要不由于您是SM,您有问题,要对团队的表现负责。 (显然,在这种情况下,保持透明,不伪造敏捷指标,看上去将不被重视)。

通过造假敏捷的简单练习,了解有关如何指导这类经理并帮助他们战胜对工业历史的偏爱。


造假敏捷——简单练习

建立在古德哈特法则之上,关于伪造敏捷指标的造假敏捷练习引人注目且直截了当。

古德哈特定律指出,一个度量指标一旦成为目标(例如绩效评估),就不再是有用的度量指标,因为参与者知道如何玩弄系统。

对于一个熟练的、有经验的团队来说,“速率”度量开发速度(一个开发团队在冲刺或迭代期间交付的故事点或项目的数量)可能有益于团队规划。然而,如果管理层为了绩效报告而将其用于缺乏经验的团队中,则会导致相反的结果。一旦压力上升,大多数开发团队就会尝试通过发挥创新性来减轻压力。经常观察到的估值膨胀就是团队处理问题的一种方法,伪造敏捷指标更微妙。

然而,根据我的经验,有一种指导方法可以带来成果:造假敏捷练习,并正面处理不愿多谈的那些假装看不见的伪造敏捷指标。通常,我和SM们一起做这个练习,这样他们就知道该关注什么,或者和需要了解如何进行敏捷转型信息的经理一起做。这个练习大约需要15到20分钟,是1-2-4-所有微观结构的理想的解构法。

基本上,它围绕着一个简单问题的典型场景:

“您的经理相信,如果一个团队报告他们的开发速度随着时间的推移不断增加,那么敏捷转型就进展顺利。您的任务是找出让团队在不增加实际工作量的情况下报告可以加快速度的方法。


为SM伪造敏捷指标

SM负责组织内的敏捷实践,因此,当团队成员尝试与敏捷博弈,需要学习如何识别反模式,因此给它起了不好的名字。认识到这些模式有助于发现SM先前的指导和教学中的缺点。

敏捷团队可能没有完全理解敏捷的价值观(比如我们相信通过不欺骗,对他人保持开放和尊重)。相反,他们一开始假装成为敏捷团队,这指向了问题的一个更关键的方面。无论行为的根本原因是什么,SM都必须能够发现模式识别这些套路。


为经理造假敏捷

对于经理而言,伪造敏捷指标的练习是通过试图站在他们的立场来看待汇报的一次同理心方式的历程。对于仍然接受工业范式文化的组织来说,这是特别有用的练习。在这里,管理信念至高无上,规定工人需要被监督并被指导做什么和怎么做,否则他们就会把组织撕成碎片。在这类组织中,人们通常还认为,“敏捷”可以如“六西格码”,像过去的其他管理风格一样,通过自上而下的决策来推广。

有趣的是,以我的经验来看,不管参与者是否有技术背景,他们都很擅长通过伪造敏捷指标来玩弄“系统报告”。因此,在练习之后对有用的敏捷指标进行有意义的讨论是一项非常简单的任务。(请注意,练习的目的不是剥夺所有所有指标的管理权。它将确定那些既为组织又为团队服务的指标)。


伪造敏捷指标——SM培训班的示例

这是PSM培训班和研讨会参与者提出的一些典型建议,如何在不做出更多工作的情况下汇报出一个增长的速率:接受“大部分”完成的产品待办事项,并创建新的任务放在以后完成它们。接受“bug”项,并创建新的产品待办事项来修复问题给bug或者Spikes增加点数(Spikes是一种预研类的用户故事)把其它团队的票‘工单’也纳入到自己的任务板上打开然后关闭假票添加敏捷活动票更改点/参考故事的基本值将用户描述的估计值乘以2,在估计值中使用更高的数字通过在实现之后增加它们的复杂性来重新评估故事为项目的每个子任务添加故事点另外添加故事点到史诗级缓慢而稳定地做,以显示稳定的增长;任何时候都不要过度交付在溢出的情况下,收集部分的故事点,并为新冲刺创建一个新的用户故事将任务自动化,并且假装它们仍是手工完成的将一个问题分解成几个小问题,这些小问题的总体估计值更高。


通过造假敏捷来伪造敏捷指标——结论

克服熟悉的报告模式对管理层来说是困难的。然而,敏捷转型需要的正是这种废弃喜爱的习惯并适应变化的过程。为了让过渡更容易,您可以从一个简单的练习开始,教经理们如何在任何基于开发速度的敏捷团队中玩弄博弈报告系统——解放您的思想,其他的就会随之而来。


——译者:褚慧  

原文地址:https://age-of-product.com/faking-agile-metrics/amp/