衡量开发者不是暴政
测量开发人员是公司最热门的趋势之一，为什么它如此重要，什么应该和不应该被测量？
作者
CORE -
21年8月6 日 -DevOps Zone -观点
喜欢 (1)
评论
保存
Tweet
3.12K浏览次数
加入DZone社区，获得完整的会员体验。
告知某人你想 "测量 "他们，并不是一个开始对话的好方法。软件开发人员，像所有人一样，往往会对密切衡量他们的表现感到不快。但衡量开发人员是全球公司最热门的趋势之一。那么，衡量人是一种暴政吗？
人们很快就会注意到，数字并不能说明全部问题，并可能对他们的生产力应该以某种方式被量化的说法产生抵触。当团队之间的关系变得紧张时，这种抵触情绪会变得更加根深蒂固。
许多领导者--如Netflix的Kathryn Koehler--认为我们应该绝对避免对个人和团队进行堆积式排名。毕竟，团队中人的因素--沟通、协调、领导力--都会影响到团队或流程的速度或感知的生产力，那么你怎么能量化呢？
值得庆幸的是，现在有很多工具可以使数据驱动的方法用于开发过程。通过正确的方法，这些工具可以用来提高任何个人或团队的绩效。除了绩效之外，如果应用得当，这些工具还可以在领导层和员工之间带来更和谐的一致。
但首先，我们为什么要测量？
为什么要测量呢？
重要的是要记住，衡量只是一种工具--它既可以用来做好事，也可以用来做坏事。一个有效的领导团队了解这个基本事实。衡量标准最酷的地方在于，它们提供了可能在其他方面难以获得的洞察力。员工们应该注意到，好的领导层会使用指标来为他们的决策提供信息，而不是仅仅驱动他们。
作为一条基本规则，很难改善没有测量的东西。
_我从一个非常基本的观察开始，我相信如果你不去衡量它，你就不能确定你在改善什么，对吗？我的意思是，想想在不称体重的情况下试图减肥。卢卡-罗西，_来自发展中断播客，4:31
衡量创造了一个基础--基准--可以在此基础上建立。一旦这个基础建立起来，组织就可以开始设定目标。如果你能设定目标，你就能召集一个团队；如果你能召集一个团队，你就能实现你的产品目标。当你对你的过程采取量化的方法时，这一切都变得更容易。成功源于测量所提供的基础元素。
最后，测量存在一个心理上的好处：即人们隐约明白，被测量的指标是重要的。毕竟，没有人会测量他们不关心的东西。领导层认定的可衡量的东西自然会告诉员工，领导层认为哪些指标是重要的。决定测量某样东西的行为本身就传达了你的意图。反过来说，也是如此：人们倾向于相信没有被衡量的东西是不重要的。
所有这些都意味着领导层应该谨慎地确定哪些指标是重要的，因为它们定义了你的组织和它的行为。
什么应该被衡量？
首先，一个组织必须决定哪些指标是有价值的，以及它们是否是可操作的。在这里，精简的方法是最好的。决定什么对你来说是重要的，什么是不重要的，然后自信地朝着这个方向前进。
那么，对一个工程团队来说，哪些指标是有价值的？
有许多有效的衡量标准，包括以下内容 速度, 分支覆盖率，以及 周期时间但我们在LinearB关心的最有趣的指标之一是Pull Request。事实上，这也是我们的事情。
拉动请求有两个主要目标：第一是在你发布代码之前提高代码的质量，而第二是在团队之间分享关于代码库的知识。
拉动请求是很好的，因为它让你的团队能够控制进入git的内容；它让人们评论事情以某种方式完成的原因；它可以作为关于某块代码的永久文档，在以后的工作中可能会很有用。
如果我们在LinearB推荐一个可以开始测量的指标，那就是Pull Request Size。衡量 PR 大小 -- 并使用该衡量标准来鼓励更小的 Pull Request -- 将有助于大幅降低周期时间。它将鼓励围绕代码审查的各种良好行为，并将证明衡量标准可以对业务成果产生积极影响。
一旦你确定了追踪成功的最佳指标，你将需要去确保它们的持久性。在这里，最好是保持一种精简的方法，避免大量的时间或金钱的前期投资。
如何使衡量标准坚持下去
_作为一个领导者，作为一个管理者，你应该让人们感到你的关心。这一点是无可替代的。-_Luca Rossi,Dev Interrupted Podcast at 21:10
我们都曾在一家公司工作过，在那里决定了一项变革，人们看到这项变革时很兴奋，然后，在几个月后，每个人都忘记了它。衡量标准也不例外。一旦一个公司决定与一个指标保持一致，它就必须做出努力，使之持久。
通常最好从小处着手。在开始的时候，最好是保持一种精简的方法，避免大量的时间或金钱的前期投资。考虑到小的可操作的变化，有两种方法来处理度量衡的采用。
- 在一个自上而下的方法中，你要在早期与你的高级开发人员交谈。给他们提供战略意见，帮助他们找出在你的开发团队中实施度量衡的最佳方法。然后，工程领导可以解释指标如何融入公司的战略方向，并向员工清楚地传达这一信息。获得员工的认同是很重要的，因为他们才是创造价值的人，并进一步发现什么可以和应该被衡量。如果做得正确，自上而下的方法会让管理者说："哇，我一直想测量这个。现在我可以了。"
- 在自下而上的方法中，关键是要让你的团队明白你想实现的目标。为他们提供建立价值的主动权，这样他们就能理解为什么以及如何对他们进行衡量。例如，大多数开发人员都能体会到糟糕的拉动请求体验--一个花费太长的请求，或者一个审查不力的请求，在生产过程中导致问题。人们明白，一个好的代码审查应该既快又准确。因此，通过从一个已经被理解的指标开始，你将获得团队的支持。如果做得正确，自下而上的方法会让员工说："哇，我们没有想到可以测量这个，而且它实际上是有价值的"。
你如何在长期内调整变化的方法取决于你。在一个理想的世界里，自上而下和自下而上的方法都会被同时利用。
最重要的是，你的员工应该知道，你关心并重视他们的反馈。
底线
为了实现未来的目标，一个开发团队应该知道它的起点。衡量标准提供了这个基准。它们是一个基础，可以在此基础上建立未来的成功和业务协调。
此外，在工程中，就像在生活中一样，如果连续跟踪数月或数年，微小的改进是惊人的。这些进步会增强团队的信心和协作。
因为有了持续的改进，人们就会觉得他们是在一个团队中工作，而且_是作为一个团队_在工作。当事情进展顺利，大家一起进步时，就会形成纽带。
当然，如果你想了解更多关于LinearB的指标，或者想知道我们的客户已经知道了什么，你可以预订LinearB的免费演示。
我在上面附上了Luca Rossi的几句话。对于那些热衷于工程的人来说，他有一个很棒的博客。你可以在这里查看：https://refactoring.fm/
如果你还没有听说， Dev Interrupted将与Dzone合作，在9月30日举办 INTERACT： 一个互动的、社区驱动的、数字化的会议--由工程领导人举办，为工程领导人服务。1天时间，10位发言人，100多位工程师和工程领导人，全部免费。
<立即注册
主题。
衡量标准、 衡量标准监控、 速度、 拉动请求、 周期时间、 领导过程、 管理与监控、 员工参与、员工反馈、 员工投资
经Nick Hodges授权发表于DZone。点击这里查看原文。
DZone贡献者所表达的观点属于他们自己。
DZone上的热门文章
评论
