在敏捷2016大会上,Johanna Rothman敏捷项目管理的度量指标发表了演讲。她首先确认了项目团队当前在结果度量方面所面临的问题:
  1. 度量什么?
  2. 什么可以被我们度量?
  3. 什么指标有用?
  Johanna解释说,管理层看到的是全局,而团队看到的是自己团队的状况。项目全部都要看。她介绍了敏捷团队如何使用指标帮助团队实现自组织和自管理;不过,那些数据对管理层而言没有意义。
  Johanna还解释说,你可能得根据项目情况改变并选择合适的指标。
  她还提到,如今的度量指标不断变化,这是有历史原因的,是无法保证团队可以连续不断地交付价值。为此,经常要求使用预测性度量指标,而不是经验性度量指标。
  接下来,Johanna列举了真正关心的内容,如客户赢取率、客户保持率、营收增长率、客户体验和接触点。对于SaaS公司而言,客户体验非常关键,因为如果无法提供良好的客户体验,则企业客户可以选择其他的提供商。
  她举例说明了指标的转换模式,下面是其中的一部分,比较了预测性指标和经验性指标:

  Johanna还比较详细地描述了需要重点度量的方面。
  度量学习:学习有法度量吗?总是寻求获得小段代码的反馈,并且问问自己,“我们还需要进一步学习吗?”我们通过学习获得动力。
  度量趋势:我们造成的缺陷多过修复的缺陷吗?缺陷比以前多了吗?关键是随着时间推移的趋势数据。快照无法提供足够的信息。
  度量已完成的特性:项目始于长篇故事/主题,听上去像特性,但实际上模糊不清,无法确定交付什么。不要把这些作为特性。从为客户提供价值的角度出发,度量更具体的特性。
  度量产品待办事项列表燃尽图:部分地回答“我们处于什么阶段?”,展示特性范围何时扩大了以及特性的整体进展。数一下每个特性集的故事数量,并用它作为度量数据。
  度量你需要增加什么以及需要减少什么:减少WIP、减少多任务。增加可以工作的软件,这是用户关心的;增加发布的用户满意度。
  度量成本:运转率营收(美元),团队每月的成本是多少,我们愿意为我们每月取得的成果支付这些成本吗?(从客户的角度看发布的成果和有价值的软件。)
  度量发布:发布频率——从构建到发布需要多长时间?将构建时间缩短到几个小时!我们的构建时间是延长了,还是缩短了?不应该延长吧?周转时间——一项特性从准备到发布需要多长时间?
  度量产品指标:创建场景或性能场景。人们需要登入、传输文件、支付,等等。这些任务的性能属性如何?性能、可靠性……。产品性能指标:这些可以是发布标准的作用。自上次发布至今,我们有改善吗?
  度量质量指标:客户反馈和满意度。
  你多久一次从客户那里获得反馈?障碍报告——有人会有障碍。决策需要多长时间?项目之外的事情影响了我们完成工作的能力吗?
  后,她列举了自己看过的常见的度量陷阱:
  ◆ 永远不要度量个体或团队的生产力;
  ◆ 永远不要比较相邻的人;
  ◆ 永远不要比较团队。
  特邀编辑Angela Wick是一名敏捷教练兼培训师。同时,她还是BA-Squared,LLC的创始人兼首席执行官。那是一家培训和咨询公司,帮助组织实现需求实践的现代化。她帮助传统、敏捷及混合团队发展所需的技能,构建正确的解决方案,为组织提供预期的价值。