成功不是终点, 失败不是毁灭: 重要的是继续前进的勇气-温斯顿·丘吉尔"
我最近在Scrum从业者论坛上注意到了很多讨论, 这些讨论是关于如何确定一个Scrum Master是否高效-人们如何衡量他或她的成功? Scrum Master(SM), Product Owner(PO)，开发人员, 教练, 顾问和全面管理工作的经理们的回答各有不同, 从"无法实现" 到捕捉团队输出和各种工件生成的详细指标.
尽管这些答案对于个别的机构, 情况和观点来说可能是正确的, 但是我相信有一个普遍准确的答案, 也是唯一真正重要的答案, 尽管很简单, 这个答案是用敏捷的最基本的准则来衡量的: 项目交付产品价值到了什么程度? 客户对这个结果满意吗? 有人可能会问" Scrum团队是自管理的团队而且并不是为SM工作, 那为什么该准则是对SM效率的衡量呢?" 我将在本文中尝试解开该谜团.
虽然价值和客户满意度是最终目标，但某些机构可能会发现将绩效进行拆解以识别出价值交付的确切领域是必要并且有帮助的. 对于一些机构, 请阅读整篇文章, 但是要小心谨慎, 因为对某些指标进行细化跟踪可能会导致不必要的工作, 这是违背敏捷原则的. 对于完全转型为敏捷思维的机构, 只要测量冲刺目标交付的指标(在下一节中介绍)以及衡量最终目标成功的指标(在上一节中介绍)就足以确定SM是否有效.
指标 - 冲刺目标交付
信息图提问团队是否达成了他们的冲刺目标. 团队用来管理冲刺待办事项(即用户故事)的工具和流程将确定捕捉和报告此问题的确切方式. 尽管每个团队都会选择他们自己的工具和流程, 但我采取一个我多次用于其他很多团队的一个通用流程: 故事点估算[提供协商冲刺目标的基础的流程], 并参考官方Scrum指南中的基本原则.
这为什么是一个SM指标?
PO和DEV分担阐明并理解每个用户故事目标的责任, 而SM负责确保进行对话并一直持续到足够清晰, 可以估算并开始工作(SM角色). 当达到这种清晰时, DEV在确定了使用故事点流程进行交付所需的步骤和工作量之后, 估算每个故事的大小. 然后, PO和DEV协商将在冲刺目标中包含多少个故事. 每个用户故事的故事点总合决定了目标中包含的故事点.
当团队首次开始一起工作或开发新产品时, 很难进行估算, 而且在初期的几次冲刺中, 很少能达到百分之百的正确. 期望是估算能越来越好, 最终非常正确.
SM在提高正确性中起到很重要的作用. 作为对DEV的服务的一部分, 他们负责"帮助开发团队创建高价值产品". 作为对PO服务的一部分, 他们负责"确保在Scrum团队上的每一个人都尽可能的了解目标, 范围和产品领域". 作为对机构的服务的一部分, 他们负责"进行能够提升Scrum团队生产力的更改". 所有这些在指南中明确指出的责任直接影响团队的成功并且强调了SM作为实现这些目标的角色.
如何衡量并报告
如何使团队有能力优化冲刺目标的交付不在本文的涉及范围中. 它是造成掌握Scrum的困难的原因之一.
所有团队成员作为个人和团体都要对交付负有责任. 这意味着要成功, 必须有效的管理约束, 依赖和障碍, 验收标准必须要明确, 所有人都要接受Done的定义. 如果团队始终未能实现目标, SM就必须站出来向整个团队(包括他们自己)提出问题并找到解决方法. 这就是为什么一个优秀的SM是有价值的-能够在不"当老板"的情况下做到这一点, 并且谦逊的提供服务并非易事.
如何衡量并报告实现冲刺目标的成功是所选工具的功能. 在上面我的故事点估算示例中, 以最简单的形式, 可以在电子表格中跟踪为每个用户故事协商出来的故事点，表格中有很多行, 最后一行提供一个总和，表示冲刺目标. 然后可以制作图表来显示"燃尽"(剩余的工作量 VS. 总工作量)或"燃耗"(完成的工作量 VS. 总工作量). 这些图表可以由Jira, Version One, 或Rally等工具根据团队的输入自动生成. 我的总前提是SM与团队作为一个整体一样有效, 因此对于燃尽, 燃耗或者其他认同的指标的衡量都直接反映在SM身上.
指标 － 持续提升
点击此处查看完整信息图, 阐明了有助于交付价值和客户满意度的Scrum组件.
持续提升是Scrum的基础. SM在他/她为PO，DEV和机构提供的服务中负有重要的责任来确保其实现. 通过日常工作, 审查, 回顾和积压列表精炼这些仪式和活动来完成.
注意: 对于以下某些指标进行细化跟踪可能会导致不必要的工作, 是违背敏捷原则的. 应该是还没有完全转化为敏捷思维的机构要求这些指标, 但应谨慎使用.
- 团队估算的准确性提升了吗？
这一点可以在回顾中进行评估. 团队将检查并讨论估算出的工作量和实际工作量的对比, 来了解获得的是应该加强的好结果还是应该缓解的坏结果. 通过对回顾会中的行动计划进行讨论和跟踪的结果, 能得出对于团队估算效率的衡量. 如果有明显的提升, 则SM成功; 如果经常一个又一个冲刺之后仍有同样的Issue还在待办中而没有任何提升, 则SM有不足.
- 团队互动增加了吗？
可以通过观察和团队反馈来进行评估. 尽管此指标比其他指标更主观, 但它同样有效, 并且是团队潜在成功的指示. 作为协调员, 教练, 以及领导者, SM在这个领域负有重要责任.
- 团队提升速度了吗？
速度是生产率的量度. 经验证, 努力应用Scrum能够提升团队的产出. 在估算变得正确并且形成了一个节奏之后就可以测量速度，通过确定在每个冲刺中交付了多少个故事点, 再跟前一个冲刺进行比较. 如果每次迭代的输出都能稳定增长, 则SM成功; 在有的时候, 速度会达到停滞, 说明保持那个点时的节奏就可以成为一个准绳.
- 流程更加高效了吗？
随着团队迈向Bruce Tuckman著名的团队发展理论中的"执行"阶段, 他们的仪式和惯例变得更加高效. 尽管很难衡量, 但可以尝试采用观察和团队反馈来量化。 同样，指南中描述的关于SM角色的职责会对团队的结果产生影响，并且可以归因于他们的有效性。
- 是否有效管理了障碍?
消除障碍是SM的另一主要职责。 可以通过评估障碍日志中记录的结果来衡量有效性。 有关此的详细信息，请参阅我关于障碍管理的文章.
- 有真正的认识到问题吗？
- 解决问题的计划有效吗？
作为协调员, 教练和领导者，SM在这个领域负有重要责任。 这些问题在SM的日常工作中得到解决，并在回顾中进行检查。 在我的关于回顾仪式中SM的角色的文章中, 我讲到的工具和流程能为衡量提供建议.
- 客户对于结果满意吗?
我将在本文的最后一部分（指标-交付价值）中提供用于测量这一项的设备.
指标 - 信任
点击此处查看完整信息图, 阐明了有助于交付价值和客户满意度的Scrum组件.
信任是团队绩效最重要的方面之一。 彼此信任的团队成员可以取得惊人的成绩。 Scrum以能增进信任的价值观为基础。 SM通过建立信任关系，提供指导和谦逊的仆人式领导力来帮助团队达到此目标。 我的有关建立高绩效团队的文章将有助于深入了解如何建立信任。
这是最难衡量的. 观察往往是主观的，但如果有人想要将其作为有意义的指标，则应用科学方法将有助于提供一些客观性并使它能够在一定程度上进行量化。 一种衡量方法是定期观察团队并始终如一地应用信任指标, 并记录这些观察结果，然后在每个点进行比较。
一个Google搜索就能得到大量关于衡量信任的资源. 其中一些看起来不错, 但我只是阅读了摘要，并不能保证其有效性.
- 衡量团队中的信任
- 建立信任和团队效能
- 信任指示
最近，我还看到了这篇Medium上的帖子，该帖子提供了大量信任指示：John Cutler写的在高效团队中工作的25条提示
指标 － 交付价值
点击此处查看完整信息图, 阐明了有助于交付价值和客户满意度的Scrum组件.
该指标实际上是SM执行工作情况的最佳指标。 所有团队成员都有此责任，并对客户负责。 PO，SM和DEV的角色概述了各自为实现此目标而执行的特定活动。 听起来很苛刻，但现实是，无论SM履行其职责的程度如何，如果最终目标未能实现，他们也没有好的绩效。
有许多方法可以衡量这一点。 如果希望获得良好的基准，则应在团队开始改进产品之前执行这些方法，然后在每个增量版本中执行。
- 询问客户是否满意
PO可以对用户进行调查以了解他们对该产品的满意程度。 有一些非常具体的问题来量化他们的满意度会很有帮助。 该方法可能是低技术含量的，由PO在面对面讨论中为小范围用户群记录答案，也可以用诸如Survey Monkey这样的工具针对较大的用户群生成更复杂的编译报告。
- 收集并评估使用量统计
使用量的增加通常表示满意度更高. 这些统计数据通常很容易收集，因为许多应用程序都具有内置的机制来测量此数据。 尽管增加使用量并不能保证实现了更高的价值和满意度，但这是一个有力的指示，尤其是在仔细权衡了所有因素的情况下。
- 评估技术支持电话
通过评估技术支持电话查看问题区域是否正在减少，可以收集到另一个指示。 许多机构擅长跟踪技术支持问题。有很多因素需要考虑, 但在本文中我不会深入讨论. 一种经过深思熟虑的策略将收集大量有用的用户满意度指标。 同样，也可以对技术支持人员民意调查.
- 分析由产品产生的财务
由于一个应用程序可能由很多种方式来使用，因此这是一个非常广泛的类别。 如果使用该应用程序能执行操作而得到收益流，则这些收入的增加可以很好地指示该应用程序带来的增值。
- 分析应用自身的销售
如果该应用程序就是需要花钱购买的, 那么一个很大的价值指示就是其销售情况, 尤其是与竞争对手相比。
- 用户评论及打分
如果该应用程序和/或用户群是将要接受客户审查，则可以将它们作为基准，汇总并评估。 移动应用程序以其收集客户反馈的能力而闻名。
总结
在本文中, 我提出了一些想法和建议来设计指标, 衡量SM的绩效. 其中很多可以在团队已经用于开发的工具和流程中进行捕捉, 报告和分析.
无论您是对自我评估感兴趣的SM，PO还是为人力资源目的评估SM绩效的经理，还是对团队成员水平感到好奇的其他干系人，我强烈建议您选择使用已经由团队工具和流程生成的指标。 这是因为它们最有道理，并且不需要额外的工作，如果一个人接受Scrum的价值观，其中的许多工作都是不必要的。
真正有价值的是能够增值并满足客户需求的实用软件。 团队的成功就是SM的成功-两者缺一不可.
閱讀更多 星知數據 的文章
