如何度量敏捷开发团队

​目前，我所见到绝大多数软件开发团队所使用的度量，一般是项目估算或项目管理过程中的一个简单的计数集合。



比如使用bug数量、任务数、时间增量（时/天/周）以及敏捷团队中的故事点数（story point）和速率（velocity）来度量。项目估计中也有些更复杂的系统和工具，如使用千行代码量（KLOC）和功能点之类的数据进行规模度量。





请你这里停下来回答我，你所用的这些常用的度量标准能不能提供足够的深度来回答以下关键问题：



·我们的软件开发团队可以变得多么优秀？



·什么样的团队成员才能有助于团队的成功？



·哪种能力的提高有助于团队取得更大的成功？



如果不能很好地回答这些看似简单实则深刻的问题，或者缺乏一种清晰的方式来讨论和思考这些问题的答案，那么作为个人和团队成员，我们并未竭尽所能去取得成功。



好的度量能将在一场漫长而充满不确定性的比赛变成一场中间有许多"终点线"的比赛。





那在这种情况下，如何有效的识别、分析软件开发团队的成败以及全方位的看待程序员的技能和贡献？



我今天不是来跟你列举好的度量维度有哪些，这也并非是一种评判绩效的方法。它应该作为一种有助于我们更好地理解和获得成功的关键点，并且指明了哪里和从何提高。



度量的目的



首先不管你做任何形式的度量，请先停下来，问自己一个问题："你度量的目的是为了什么？" 在我看来，有效的度量应该出于以下四种目的：



1.帮助你跟踪和理解发生了什么。

统计、或者度量，是过去发生的事情的详细档案。



2.帮助人们沟通发生的事情。



3.关注那些需要改善的事情。



度量记录了你所能和所完成的事情，并且给出了一个关于你的期望水平和实际水平的比较。



在关注改善的事情上，我们需要区分"异常点"和"离群点"。



"异常点"一般是指那些不可解释或不可再现的异常发生事件;"离散点"则表现得是违背常理的时间，并且可能在线，甚至伴随一些"可预知"的模式。我们需要发现的离散点"而不是"异常点"。





4.寻找可复制的成功因子。

常言"人算不如天算"，用在度量里或许是对的。一旦我们定义了成功，就可以分析软件开发团队去的始终如一的成功模式。



度量不是为了评级。只有作为每个程序员当前的工作技能、强项、弱项的反映，度量才真正有效。



如何评估度量的好坏



坏的度量通过没用的或者实际不相关的细节浪费你的时间，分散你的注意力，使你不能有更深刻的理解。



好的度量像探照灯，拨开迷雾，将灯光照耀在真正紧要的事情上。好的度量可以直接关联到产出成就。



宏观来看，你可以通过如下这些问题来评估一个度量本身的好坏：



·这个度量是否相对易于描述和理解？



·这个度量是否展示了我还不知道的一些事情？



·这个度量是否清楚地涉及了我关心的目标？



微观来说，好的度量可以帮助回答一下问题：



· 成员在核心职责方面做的怎么样？



代码写的怎么样？



设计做的如何？



对自己的代码测试的如何？



·成员在核心职责之外的贡献如何？



能覆盖多少领域？



足够主动么？



创新么？



处理压力的能力如何？



应对困难的能力如何？



·成员和他人的互动如何？



是都展示了领导力？



是否激励了队友？



如何知道他人？



理解和遵循方向的情况如何？



协助他人多少？



·团队是成功还是失败？



用户对每次发版的响应是什么？



同竞品相比，软件做的如何？



发版质量趋势是什么？



如何选择数据



选择度量的指标也是个试错的过程。产品的不同成长阶段，团队的不同阶段，我们都需要时时反思我们的指标是否适用。 不管在什么时刻，我们选择指标数据遵循标准如下：



·最容易获得的



·最容易让程序员理解的数据





慎用的指标



千行代码量（KLOC）

我们常常认为用代码行数（KLOC代表1000行代码）来测量程序员的效率是非常有用的一种方法，并且也有不少实例认为KLOC在估计技术和降低项目估计失误的工具方面是有用的，特别是对一些大型项目而言。



但一般而言，我认为KLOC更像是活动而不是代码的度量指标。我很难将这个度量指标关联到明确的团队目标上，例如客户接受度、满意度或者产品质量。



KLOC的另一个问题是，对不同的编程语言来说，它们没有一个统一的标准。比如，写1000行Java代码所花的时间和能力与写1000行JavaScript、XML、PHP或者Ruby代码是完全不同的（虽然理论上可以有这样的一个方法来进行跨语言的KLOC标准化）。



最后，我认为程序员很难认为这个度量指标与其工作业绩或者成败有什么关系。从而，也就很难有效地使用KLOC作为一种手段就技能与贡献进行讨论。



开发阶段的bug数量





Bug数量肯定是评定代码质量的一种度量。但是根据我的经验，在开发阶段的bug不同于发布后产品的bug，由于存在太多的可变性，因此很难使得开发中的bug数量成为一个很有用的度量。



开发过程中发现的bug的多寡会随着测试人员的数量、测试的深度和代码在开发中的成熟度而波动。



如果我们在开发周期早期就开始对一块复杂的代码进行彻底地测试，会发现许多bug，但是这并不能告诉我们什么。



也许会有人认为确实存在这样一些bug，如果bug是在程序员认为功能已经实现且完成单元测试的情况下发现的，它们可以成为有用的度量。



但是我发现，在实践中，这项指标不太一致，也很难下结论。最后，我认为我们仅需保持关于任务的复杂度和完成这些任务所花的时间的度量，它已经包含了充分修改开发bug的时间，否则代码就无法发布。如果程序员制造了许多bug，其结果就是完成任务的时间更长。对于同样复杂的工作，花费时间更少的程序员一般更井然有序且产生的bug数目也较少。



产品收入

产品收入（毛收入或净收入）是商业规划和产品规划中的一个关键部分。我们建造什么产品，新增哪些特性，哪些问题值得花时间去修改，都依赖于财务分析的结果。





在大多数情形下，软件开发的预算与产品收入有直接的关系。事情本该如此。然而，如果把产品收入作为软件开发流程中的度量，去衡量程序员和团队的成功与相关贡献，我认为这是有问题的。首先，很多软件根本就没有收入（开源项目和内部项目就是两个很好的例子）。



即使存在收入，这也不总是与软件和软件开发团队的工作直接相关。它们广泛地依赖于折扣、不同销售人员的能力和更多的因素（包括国家或全球经济）等。



另一个重要的问题是，将金钱作为度量，很容易转移注意力和带来误导。人们会变得更关注金钱，而不是度量的目标和意义。



我个人的感觉是，产品收入的意识和理解收入预测如何驱动产品计划的决策对软件开发团队来说是有用的。但是，作为软件开发团队工作进度的度量，我更愿意测量特性的交付、试用用户到客户的转换率、产品bug数量，并且对用户数和使用量保持关注。



总之，探索新的数据类型并尝试使用它们不会带来损失。我们应该乐于试验新想法。也可以相信，其中非常有用的、合理的那些数据会显现出来，而剩余的部分可以舍弃。



小结



度量自身不是一个解决方案。度量也不是全部，但是它可以帮助一支软件开发团队和程序员个体改进。



如果我们已经决心要改进，并且愿意付出辛劳的工作，度量是帮助我们选择一条达到目标的路径的极其有用的工具。