“发布流水线进行得如何?”这是当今常见的首席技术官和工程经理之间的对话。然而，这两位技术领导者是否能找到一个共同的语言来回答这个问题，这就是我们将要讨论的内容。
工程经理们普遍面临的困难是如何量化工程工作的“真实”指标。大多数情况下，这是由于工程经理与高层管理层在优先事项上的差异引起的;而其他时候，则是关于对“什么”需要进行衡量的意见分歧——是产品、流程还是两者都要。
理解、认可甚至跟踪工程绩效是一项复杂的任务，特别是当公司的技术发展速度非常快时。这种情况在现实场景中是疯狂和不可持续的。这就是为什么多样化的度量指标变得至关重要的原因。在本文中，让我们看看每个工程经理应该关注的顶级软件指标，以及它们为什么真正重要。
从工程经理的角度看软件指标跟踪软件指标对整体工程绩效有着复合效应。这就是为什么如今的工程经理们正在寻找稳定的指标来支持他们的交付流程，并努力创建优质产品的原因。
传统上，软件开发被视为一个机械过程。即使是瀑布式方法也证明了昔日软件开发生命周期的线性特性。然而，随着技术变得更加专业化，开发方法也必须转向质量指标，而不仅仅是过于强调速度和过时的交付。
软件经济已经充斥着太多的工程指标。那么如何找到符合您要求的指标呢？
通常，工程经理使用三个方面的方法——开发者福祉、SDLC健康状况和最终产品的结合，从庞大的软件草堆中找到类似针一样的指标。使用产品、流程和人员指标的整体混合可以真正提高工程团队的可操作性。
流程指标以下是工程经理不容忽视的三个最佳流程指标的列表。
1.周期时间
周期时间无需新介绍。这些指标已经是Google的DORA指标的一部分，它们不断提醒团队重视发布质量和速度。
周期时间是团队交付速度的指标，它跟踪从首次提交到最终部署所需的时间。对于工程经理来说，高周期时间应该是一个警示信号，因为它是健康SDLC的最基本指标。
此外，正确跟踪周期时间时，该指标还可以提供大量数据和其他流程指标。当周期时间较长时，工程经理有机会打破传统的流程隔阂，转向高效的工作流程。
如果开发者的工作负荷过高导致周期时间飙升，工程经理可以将工作委派给其他人，甚至将非核心任务从开发者的工作列表中降低优先级。
开发周期时间
在另一种情况下，开发人员已经优化了他们的编码和接手时间，但部署时间却高于团队的基准值，导致周期时间膨胀。这可能是由于测试速度慢、构建不稳定或等待时间过长。工程经理可以进行反复迭代，直到完全合理化周期时间。将周期时间数据与PR大小、平均行代码数和编码时间配对，可以帮助团队负责人减少根深蒂固的开发瓶颈。
2.开发吞吐量
在工程流水线中，吞吐量是速度和数量之间的桥梁。通常，吞吐量是根据在一段时间内发布的功能或完成的任务数量来衡量的。大多数团队汇总“工单”，以确定一个月/季度的最终团队吞吐量，并将其与基准进行比较，以确定工程效率。
然而，吞吐量远不止完成问题的数量。试图仅通过问题解读吞吐量，就像在没有与消费者交流的情况下开发产品一样，简而言之，完全失败。
吞吐量成为重要的工程指标，因为它帮助工程经理识别团队中的工作类型比例。该指标根据功能、错误和任务对团队合作进行筛选。通过了解吞吐量趋势，团队可以有效地规划下一轮迭代，甚至消除任何未计划的工作。
然而，只有在了解工作复杂性和资源限制后，工程经理才应将吞吐量作为团队指标进行基准测试。否则，过于片面地跟踪吞吐量可能会对团队产生反作用。
3.PR大小
这个指标是一个非传统的指标，通常被低估其对代码质量的价值。开发人员出于习惯会创建大型拉取请求。这样更容易，也不需要太多时间。此外，编写较小的PR需要额外的纪律，大多数开发人员都愿意以任何代价换取它。
较小的PR大小是你开发过程中真正的卫生指标。PR大小越小，你要处理的错误就越少。此外，较小的拉取请求限制在200-300行代码之内，比通常的1000行代码更容易审查，也更易读。
工程经理应继续关注PR大小，以培养纪律的文化，提高代码可读性，并减少团队中的合作隔阂。
4.冲刺速度
成功的冲刺计划是实际工作完成的三分之一。它让团队形成全局视角，设定项目里程碑，并为团队与可用资源进行协作创造空间。实现冲刺目标的下一步是通过最佳冲刺速度。
冲刺速度是团队在每个冲刺中完成任务的比率，而不会牺牲质量。较高的冲刺速度可能意味着较高的交付速度，甚至缩短上市时间，对于工程经理来说，这是一项重要的指标。然而，冲刺速度也分散在各种变量之间，并应包括问题分布(错误 vs 新功能 vs 史诗)、故事点数和计划准确性，以便真正了解冲刺的健康状况。
幸福指标上面列出的大多数指标在可衡量性上都是切实的，可以轻松测量，并遵循一连串客观数字。然而，当涉及主观指标，如开发者生产力或团队满意度时，工程经理通常缺乏记录过程来测量甚至定义这些指标的能力。
尽管愿意为开发者的生活做更多贡献，但工程经理在实现士气指标方面仍然存在困难。随着时间的推移和工作负担的增加，这些关键的试金石测试在交付和吞吐量的讨论之间消失了。福祉指标是脆弱的指标，如果采取行动，可以为整体开发者体验提供指数级价值。
5. 研发时间 研发时间和片段化时间
制作者时间指标跟踪开发者进行“深度工作”的时间。开发人员一天中的大部分时间都花在参加站立会议、讨论冲刺工作、开会和运维保养上。制作者时间确保开发者至少有120分钟的连续、不被中断的工作时间，以便他们可以再次专注于核心任务。通过制作者时间，工程经理可以详细了解开发者典型的工作日是如何度过的，开发者花了多少时间没有切换上下文。完美的情况是每天70%的制作者时间。通过指标数据，管理者甚至可以确保下一个冲刺中的可持续工作分配。
6.工作时间分布
者时间有助于管理者确保核心开发任务有固定的时间段。然而，说起来容易做起来难。即使在核心任务中，开发者也会花费很多时间被阻塞或做无效的工作。等待跨时区的代码审查、全天候开灯和高强度的事故警报可能导致过度工作的开发者。
通过工作时间分布指标，工程经理可以轻松追踪开发者的工作时间与官方规定的工作时间之间的关系。如果工作时间分布超过正常限制，管理者可以重新安排开发人员的工作时间或限制外部干扰，使开发者能够回到高效的工作状态。
利用软件指标实现工程成功现在我们清楚了工程团队应该追踪的指标，工程经理更容易回答：“发布流水线进行得如何?”
当这些工程指标与数据结合在一起时，有助于促进团队的持续改进。将这些指标共同考虑，更或多或少地相当于找到软件开发生命周期中的缺失环节——困扰团队许久的阻碍或妨碍团队工作流程的无效工作。
具备足够的背景信息，工程经理可以将这些技术指标转化为通用的业务语言，使所有层级的领导都参与到工程流程中。
当项目经理配备了一个工程管理平台时，从指标中提取可行动的见解变得轻而易举。工程管理平台可以帮助工程经理实现开发过程的整体情况：提高生产力、增强工程效果和持续协作。
