经过在这篇文章中，我将潜入软件开发中最动荡不安的话题之一。测量开发人员的生产力通常被视为傻瓜的差事，但越来越多的开发团队开始看到它的价值。然而，在超越概念到为开发人员生产力设置特定度量时，难以实现。
为了妥善衡量软件开发团队的生产力及其在特定项目的进度，它必须远离工业时代管理流程并带领一支与现代实践的团队。有效的软件开发团队是包容性，多样化的，开放，以改变和学习。理想是一个积极主动的团队，可以识别进步，并知道它在其所在的情况下，在分享项目完成和努力的期望方面。这是管理，团队领导和团队成员的联合原因。除了允许更好措施软件开发生产力，这种方法实际上增加了生产力，帮助创建获得所需的快乐最终用户，以及他们甚至不知道他们所需要的有用事物。
衡量成功
在前进之前，重要的是定义一些关键概念。当我谈论的时候测量某事，意图是建立一个或多个已知的指标，其随着时间的推移表示一个或多个已知的动作。然后，该测量可以显示可用于做出决定的时间随时间的趋势。请注意，测量并不总是与事件的系统视图一致。因此，比跟踪一组指标更重要的是理解谁，什么时候，何处以及如何取得实际发生的成功。
成功在此上下文中，识别完成工作直接导致用户或客户交互的特定结果的工作。这种交互可以是特定特征的减少或增加的使用，它可以更流体地使用提供给用户的数据或接口，或者可以简单地增加对软件的满意度，从而增加了软件的销售或采用的软件。成功意味着在软件的客户或用户中创建期望的行为变化。
当每个人都同意并重点关注成功的特定理解时，我在个人和团队中取得了最大的成功。首先，必须具体由客户或最终用户确定成功。其次，识别指标不得覆盖实际，系统的理解，对团队如何建造软件。指标可以并将被召开，所以他们可能会讲述一个误导性的故事，除非人们追踪他们建立产品的团队的全身性质。
团队的系统性
所以,如何做一个了解团队的系统性？系统性质，系统， 和系统思考提供一些洞察力：
工作流程:这些包括团队合作的系统，例如源控制，框架和库，票证和其他此类系统。工作流还可以包括某人生活方式的物理工作条件，通勤和相关的外部努力以及外部工作影响，以及与保持健康和集中的相关概念，以便有效地工作。
社会：这些系统在人们之间基本上不言而喻的社会契约，包括团队中的专业感和其他抽象概念。它涵盖了这种动态，因为团队是否是包容性或排他性，多样化，并根据社交互动改变。
过程：过程系统决定了如何完成工作流程。这些并不是那么多包装，如票务系统，而是会议，工作时间和相关机制的想法，这些机制用来建立员工如何了解他们的工作日。
所有这些系统和其他系统都与之相互关联系统思考。当用系统思维的思想来理解一个团队时，还有几个想法可以帮助将团队定义为一个系统:
- 该团队由部分组成。这包括具有不同特征，能力和态度的个人解决问题，工作流程，社会和流程实践。团队的其他部分可以成为团队本身。
- 团队的所有成员都与某种方式直接或间接相关。
- 团队有其运作的界限。
- 与成功的定义一样，这些边界最好是由团队建立的软件的最终用户或客户定义。
- 一支球队可以是颞性的;它可能会增加或丢失自己的部分。这可能是进程的变化，团队成员的添加或丢失，或者只是临时软件项目的开头或结尾。
- 一个团队可能在物理上位于一个共享的中央办公室，也可能位于不同的位置，或者两者的混合。
- 团队是一项自治系统，必须能够通过内部决策履行其使命。
- 团队的进程由输入组成，转换为发出输出。
只有当所有这些元素都被正确理解时，才能观察者开始确定如何测量开发人员的生产力随时间。甚至那么测量也不是静态的。每个测量必须是基于团队的使命，努力，不断变化的任务和新理解的流体。从无效的工作流程系统采取的指标可能会随着时间的推移提供不准确的趋势，并且应该被删除。领导力必须保持警惕，因为它们变得古老的指标，不准确或过时。
在开始时测量
现在我们已经建立了一些背景，让我们来看看一些现实世界的想法来衡量实际的软件开发团队的生产力，专门团队产品努力和产品交付。
每个星期球队都应该确定某种类型的开球。它可能是一个会议;它可能是坐下来开始一份工作清单。它可能是一个体系结构或系统计划会议。这可能只是步行到当地的咖啡店，让每个人的大脑在团队环境中工作。它只需要是一个包容性的活动，团队可以讨论和详细介绍下周的工作。
这也是从本周意图导出生产力测量的点。如果团队打算构建功能A和B和部分研究功能C，那么这是本周的基本指标。如果管理，领导力和发展团队本身是诚实和现实的，那么对本周可以实现的内容的启动将变得越来越准确。
一个关键因素是管理层如何围绕团队的每周目标行事。管理层必须创造一个团队问责和包容的环境，否则每周估计的准确性将不断波动，领导层将无法得到一个清晰的画面。不要过分地给他们压力，让他们承担超出他们实际能完成的任务，否则他们就会变得压力过大，最终反而会做得更少。
累计测量的下一个机会来自结尾一周中的。应该留出一段时间，类似于每周启动，回忆并观察到本周末实际完成的团队。达到所有预期目标的地方？什么障碍提出了？这是一个重复的障碍吗？本周有没有必要的压力或中断？是否发生了任何其他计划异常的异常值？这些异常值之前出现了吗？他们应该在每周开始会议期间应经常考虑的事情列表中添加到什么？
有一个更大的问题应该在每周回顾期间解决：什么是完毕在这种情况下意味着什么？具体来说，团队是如何定义的完毕与终端用户或客户如何定义?如果它们不一样，该如何填补这个缺口?得到一个共同的定义完毕与对共同的理解同样重要测量和成功。
笔记：工作周作为测量时间框架是有道理的，并且在开球和回顾之间有一个周末对团队的流程是破坏的。
最后，所有这些方法都是基于积极主动的vs.反应产品发展的过程。这意味着团队控制着通向成功的道路。反应式流程——管理的工业革命时代的不幸遗留物——将软件团队视为只负责他们个人工作的工厂工人，与大局没有联系。反应性过程使生产力测量怀疑游戏化或其他腐败，所以管理层经常得到一个不准确的团队进展的画面。