程序员度量

章节摘录

第一部分概念该部分涵盖关于度量、模式分析、数据采集和数据元素的常见概念。第1章概述让我们不要太确信，我们没有错过一些重要的东西。——比尔•詹姆斯（棒球统计学家和作者），摘自“Underestimating the Fog”这是一本关于程序员、软件开发团队的度量和模式的书。本书的一些想法源于我在多年前开始的对软件开发团队构成的思考：无论好坏，所有细微贡献以及无名英雄的辛勤汗水都是项目成功的关键组成部分。近二十年里，我一直在负责设计师、程序员和测试团队的组建与管理工作。这些年，我意识到一个软件开发团队就像一支球队一样，需要有各种角色的球员和不同的技能的专业人员才能成功。我同样认识到成功和失败的模式未必像我之前所设想的那样简单。我见过一个简单的模式，或许你也看到过：我曾经所在的每个成功的软件开发团队中，总是至少有一位同事无怨无悔地去做一些琐事，比如创建安装程序，改善编译脚本，或者修改一些其他人的错误来帮助团队实现产品功能。如果团队里没人去做这些琐碎的事情，那些项目就总是无法完成，或者至少是做得不够好。另一种模式是：我见过很多经验丰富的软件开发团队，其中一般都有一到两位程序员在充当明确的技术领导和关键人物，虽然他们未必拥有与之对应的头衔。这些关键的程序员不仅解决问题，而且他们对其他人产生了强大的影响力，比如其他的程序员技能飞速发展，越来越接近技术领导者的水平。其最终结果就是，一到两个牛人提高了整个团队的水平。这里还有我在曾经亲身参与的一个长期项目中观察到的一个模式，这种模式尤其常在处在创业阶段的小团队中发现：当项目进展到80%的时候，项目团队往往就“撞墙”了。像马拉松运动员跑到20英里标志点一样，项目团队经过几个月的努力奋斗，每一个人都身心俱疲。有时候当团队遇到困难时，我们就停滞下来，并且无法重获生机。这样项目剩下的20%工作量似乎永远也完不成，最后，我们基本上都是跌跌撞撞地走向终点。但有时某些团队可以穿越那堵墙，重新恢复生机，再次调整好步伐。在任何情况下，能够重获生机源于团队中一些人的优秀品格，他们能够减轻团队的工作负担，营造轻松的工作氛围，鼓舞团队士气，并让每一个人都感觉良好。感谢团队中那些爱开玩笑的伙计，他们让团队中的每一个人重新找回（多数是）积极的心态，准备冲刺到终点。一旦我们看到这些，成功的模式似乎是显而易见的，但要看到它们，我们必须学会相应的方法。当我开始思考这个问题的时候，我就在琢磨我们是否可以建立一套指标，以便给我们一个明确、客观的方法来识别、分析并讨论软件开发团队的成败以及全方位地看待程序员的技能和贡献。这并非只是一种评判绩效的方法，而是一种有助于我们更好地理解和获得成功的关键因素，并且它指明了从哪里和如何提高。我在自己的团队中进行了一些尝试，并取得了优异成果。令人鼓舞的是，这些方法对其他人也同样适用。本书是我对这些想法和实践进行分析的一次尝试。在这一方面，很少有关于软件开发团队度量的材料——无论是书面的或其他方式的。我们有关于面试、技能测试、项目估算、项目管理以及团队管理的大量书籍，还有关于敏捷和其他更有效提高开发流程的方法学之类的书。但是，我们从未有过讨论或探寻一种量化分析方法，该方法通过理解个体程序员的技能和工作来提高软件开发团队的效率。目前绝大多数软件开发团队所使用的度量，一般是项目估算或项目管理过程中的一个简单的计数集合。我们使用bug数量、任务数、时间增量（时/天/周）以及敏捷团队中的故事点数（story point）和速率（velocity）来度量。项目估计中也有些更复杂的系统和工具，如使用千行代码量（KLOC）和功能点之类的数据进行规模度量。但我们常用的度量标准没有提供足够的深度来回答我们所面对的很多关键问题，例如：我们的软件开发团队可以变得多么优秀？什么样的团队成员才能有助于团队的成功？哪种能力的提高有助于团队取得更大的成功？如果我们不能很好地回答这些看似简单实则深刻的问题，或者缺乏一种清晰的方式来讨论和思考这些问题的答案，那么作为个人和团队成员，我们并未竭尽所能去取得成功。当然，我们必须从根本上探究成功究竟是什么，以及如何衡量软件开发团队的成功，而不是想当然地认为这些可以得到充分解决，而事实上这些问题还存在。在接下来的内容中，我将尝试建议一些全新的、与众不同的方式，来帮助我们更好地理解这些问题以及得到可能的答案。我是个体育迷，因此在本书的很多地方，我选择用体育来作类比。然而，这并不意味着为了理解本书中的这些概念，你需要喜欢或者懂得体育运动。像所有的类比法一样，其目的只是帮助我们更好地领会及更容易记住一些概念。就个人而言，我认为采用体育类比来探讨软件开发团队是恰当且饶有乐趣的。我把软件开发团队想象成一支球队。通常，软件产品是通过团队而不是单个人开发出来的，尽管有单个程序员独自完成工作的例子，但此时那位程序员一个人扮演了一个团队里的各种角色。我们知道，在体育比赛中，成功的球队需要球员之间能够互补，而不需要也不应该要求每个人具备同样的技能。球队里除了需要擅长跑动、传接球的球员，也同样需要擅长防守和抢断的球员。不是所有的人都擅长做同一件事。事实上，所有球员都拥有相同优势的一支球队，不管这个优势有多强，大多数时候都比不上拥有不同的优势互补技能的球员的球队。因此，只有球队中的每一个球员都做好自己的本职工作，球队才能取得成功。通过使用统计分析来度量程序员的初步想法来自于体育活动中有组织的量化分析法。计算机和软件已经带来了职业球队队员统计数据分析的巨大变化，以及帮助他们确定队员的哪些技能可以最直接地帮助球队获胜。比尔•詹姆斯和其他的记录分析家已经建立了一个围绕棒球运动员进行统计分析的学科，称为“赛博计量学”译注1。通过作者Michael Levis的书《Moneyball》、《The Blind Side》和他在《纽约时代杂志》以及其他出版物上的文章，这些新的方法已普及到球队的管理中。将这些新方法应用到球队管理中的先驱在数据分析领域都接受过较多的训练，比如Daryl Morey（NBA休斯顿火箭队总经理）在美国西北大学主修的是计算机科学，Paul DePodesta（MLB纽约大都会队副董事长，前洛杉矶道奇队总经理）在哈佛大学主修的是经济学。这个应用于体育中的新方法，相对于占大多数的、基于主观和直觉判断的人才评估和球队建设的方法，经常被看做一种应变和迁移。多数球队现在都属于很大的企业，拥有大量的资金。在这个新时代里，球队的管理者花费更多的时间来收集和分析度量数据，用更合理和可预测的方式来帮助打造获胜的球队（就像《Moneyball》描述的，用更有效的成本效益和盈利的方式）。度量并不是要代替个人的直觉和创造力，而是帮助我们增进了解。这个新方法中所遵循的关键步骤包括：发现测量获胜球队和失败球队差异的方法。发现测量单个球员对球队贡献大小的方法。确定那些决定球队胜负的关键球员的特征。发现体育中有意义的度量指标和公式的过程不是一成不变的，而是一个持续演进的过程。很容易理解，许多重要而细微的技能难于测量和分析，比如防守型球员能发现带球球员的本能，或者在压力下进行比赛的能力。例如，比尔•詹姆斯在关于棒球的连载文章和年鉴中所介绍的新的度量指标和思路，一些被人采纳和使用，一些被改进了，也有一些用处不大，逐渐消失了。和公开的演进相同，度量指标也在悄悄地演进。体育运动是一个竞争性领域，因此球队实际采用的统计数据和公式是保守的机密。很多分析师在公开撰文的同时，也为单个球队充当私人顾问的工作。Theo Epstein（MLB红袜队总经理）以及Billy Beane（MLB奥克兰运动家队总经理）可能会彼此分享一些信息，他们也都可从大社区中众所周知的度量指标中获益，但最后他们都在试图战胜对方，因此，属于他们方法中的某些元素，他们组织之外的人是无法知道的。有别于大体育联盟的竞争压力，我们的软件开发领域不那么公开化，大多数程序员也不在公众的视线范围内。我们没有或者从来就不会有粉丝关注我们的统计数据，或者把我们的海报贴在他们家墙上（有点儿可怕的想法）。颇具讽刺的是，我们所在的这个领域，在许多方面使体育（以及其他行业）的深层的统计分析成为可能，但我们自身并没有拥抱或者完善地考虑量化分析在我们软件开发领域中潜在的益处。像其他工作者一样，我们可能很自然地怀疑是否可以找到一个好的度量指标，是否存在一个真实有效的例子，并且也可能担心这些统计数据会被管理者错误地运用到绩效考核中等。然而，本书的前提是，在我们的领域中，有多种技能和结果是可以真正地测量的。从那里我们能够针对我们自己和团队获得有意义及有用的见解。这些数字不是非黑即白，并且依靠个别的几个数字无法说明全部。知道Derek Jeter的平均安打率（batting average）或者Tim Duncan的投篮命中率，只能告诉你他们作为一个高效的球员或者队友的一个很小的部分，但当我们看到多个统计，我们就可以识别个体和团队的模式，有时我们的发现甚至是意外的而且富有启发性的。让我举例告诉你一个我曾管理了多年的软件开发团队的故事。注意：关于本书中的一些故事的说明：这些故事来自我之前的工作经历，但在很多案例中，这些故事做了简化或概述，以传达要点。为了保护个人隐私，我将不使用姓名，包括我本人。这个示例发生在一个风险投资创业公司，这个团队有6位程序员和3位测试人员（本书重点关注程序员，因此在这个例子中，我将着重描述他们）。我们前两年的经历中有三个关键阶段：1.0发布版的最初开发工作，大概花了9个月的时间；1.0版本发行之后，我们花了6个月的时间支持第一个客户和开发1.1版本；接下来又花了大概9个月的时间来开发2.0发布版。这个团队拥有3位资深程序员，每个人都拥有超过10年的开发经验和优秀的领域知识，还有3位初级程序员，拥有很好的教育背景及大约两年的商业软件开发经验。在这两年中，所有的资深程序员依然留在团队中，但其中两位初级程序员在完成第一年的工作之后就离开了这个团队，之后我们又招聘了两位新的程序员。我们的执行委员会和投资者认为我们最初的1.0版本取得了巨大的成功。我们在一个关键的行业展览中赢得了大奖，并且收到了许多正面的产品评价。许多中间商对我们感兴趣，客户评估的数量两倍于我们的预期，以至于我们的销售人员忙得不可开交。该预制（on-premise）的软件解决方案运行在客户的环境中。译注2在产品发行后的第一个季度，收入也同样好于预期。这有足够的理由使得我们的软件开发团队感觉良好，每一个人都在夸奖我们。但是，我们的1.0版本真的成功吗？我们花了一些时间才意识到这个问题，通过探查当时的数据，应该能够发现一些严重的问题。关键而糟糕的事实是：当我们成功地获得了知名度，强化了客户兴趣的时候，每个试用的客户平均要来7个电话寻求客户支持。尽管每个客户事实上都收到了安装程序和安装帮助。这7个电话使得需要平均3整天与客户一起工作来调查问题，而且结果证明每个客户平均在产品中发现了从前不知道的3个新bug。花在支持客户试用（包括辅助支持的时间和修改重大产品问题）的程序员时间是以周为单位来计算的，而不是以小时或者天为单位的。那些看似积极的收益也在误导着团队。由于几单大的生意，我们超出了早期的收入计划，但是我们从评估者到真实客户的整体转换率及转换所花的时间远不能满足达成一个成功业务的要求。这种情况至少部分是因为从支持工作量和发现bug的数量上反映出的可用性和质量问题。换句话说，虽然局外人可能认为我们的初始发布版取得了巨大成功，但是事实上它充其量不过是部分成功。图1-1里的数据揭示了新用户与bug和支持问题相比是多么微不足道。还有另外一个大问题。随着时间的流逝，团队里的一些程序员遇到了麻烦。花在刺激的新功能上的时间越来越少，花在乏味的问题调查和bug修改上的时间越来越多，加上初创阶段紧张的支持工作，成员间和团队内开始显露出裂痕。个性差异被放大，某些程序员慢慢地开始彼此回避，甚至在工作场所大喊大叫也常有发生。

前言

前言是否存在一种合理的方法来衡量程序员的技能与贡献，并且也同样适用于团队所有的人？是否可以通过度量来帮助个人提高程序员的自我意识，以及促进团队工作、出谋划策和目标设定？能否通过详尽的数据帮助你做出更好的聘用决策，或者更公平地进行绩效考核，从而让你的软件开发团队变得更成功？无论你是程序员、团队负责人，还是项目经理，如果你对这些主题中的任何一个感兴趣，或者你对如何采用不同工作方式将度量应用到软件开发团队中感兴趣，那么本书很适合你。本书的思路和过去在软件开发中使用度量的方式有很大不同。本书中提出的概念和技术，旨在帮助你从不同的角度思考构建软件开发团队以及开始你们的新旅程——在软件开发过程中采用更新、更好的度量方法。作为软件开发团队的经理，我本人亲身实践了这些方法。本书中所提出的技术已帮助一些身处麻烦中的团队走出困境，并且帮助一些本来已经不错的团队锦上添花。固然，本书提出的度量方法并非成功的唯一途径，但它对我来说极具价值，我相信对你也会同样有效。也许你会通过使用软件的人数、交付版本的效率或者软件中错误的数量来衡量软件的成功。通过使用度量方法可否将这种成功提高5%、10%或者15%？自己测试一下这些想法就知道了。虽然本书描述的方法相当有效，但即使仅仅有5%的改善，也意味着很大的价值。如果度量可以简单地帮助开发者在一个团队里变得更自觉，并继而成长为更好的团队成员，那么这有多大的价值？最起码，我相信潜在的收益足以抵得上你收集和使用书中描述的各种度量指标所花费的时间和精力。即使最终你决定不再收集这些度量，但是我相信通过阅读本书，你仍然能够从中学到很多有用的概念并应用到你的团队中。本书结构本书按阅读的顺序分为三部分，虽然在以后将度量方法应用到实践时，可能其中某些章节对你而言更有价值。第一部分对程序员度量背后的思想进行详细介绍，并介绍了多种关于可以从度量获得的分析和那些可用于测量程序员和软件开发团队的数据。第二部分可以作为各种度量方式的参考指南。每种度量方法都包含一些例子和注释。第三部分介绍将度量引入团队并将它们用于开发流程中的一些技术，以及使用度量来构建和改善软件开发团队的方法。第一部分由以下章节组成。第1章详细解释了本书的构思、动机和目标。第2章讨论了度量、程序员度量以及团队协作和团队绩效分析背后的基本概念。第3章讨论有用数据的组成，怎样获取它，以及在程序员度量方法中使用的详细数据元素。第二部分由以下章节组成。第4章覆盖各种关于程序员技能和贡献的度量方法。第5章包括对软件的各种正面、负面用户反馈的度量方法。第6章包含度量程序员为团队带来价值的方法。第三部分由以下章节组成。第7章给出一个多步骤的方案，用于检验和把度量引入一个组织中，并提供了在开发过程和绩效评审中使用度量的方法。第8章描述怎样使用度量来确定团队的需要，以及如何把它们应用于个人计划、招聘以及培养现有团队成员。最后给出了关于度量价值的结论，如何处理那些很难量化的关键度量，以及如何在未来改善和扩展度量方法。致谢本书中的观点受到了Michael Lewis关于赛博计量学以及运动统计分析的启发，这些分析指引我了解了Bill James的著作。这些观点体现了作者知识渊博、见多识广和幽默风趣的特点。尽管他们没有理由来读这本书，但我还是要首先感谢他们。我还要感谢曾经在过去的许多年中一起工作过的卓越的程序员以及管理者。我非常幸运，很难想象从单一的职业生涯中我能学到如此多的东西。特别要感谢Vocalocity公司的CEO Wain Kellum以及整个团队，他们在我写作本书的过程中给予了我支持。感谢Andy Oram，O扲eilly的编辑，他在整个过程中给予我帮助，使得这本书在各方面都更上一层楼。与你共事非常愉快，谢谢你，Andy。同样也感谢O扲eilly的编辑Mike Hendrickson，是他最早支持和鼓舞了我的想法。同样感谢整个O扲eilly媒体制作团队。我要感谢Google的Brian Jackson、Taleo的Nagaraj Nadendla、Zuora的Ben Wu给予的反馈和评审。他们自身都是卓越的领导者和管理者。谢谢他们。感谢父亲，他培养了我对运动和统计的爱好。感谢母亲，她用爱鼓舞我写作本书。最重要的是感谢我的妻子Barbara。她在写作本书期间大力支持我，不仅仅是用她出色的编辑技巧校对本书，发现缺陷并提出一些改进意见——虽然她是一名律师，并不会写一行代码（可能会）。谢谢她，亲爱的！同样感谢我两个漂亮的女儿，Naomi和Vivian，她们使得我的每一天都是特殊的。感谢她们！

内容概要

JonathancAlexander拥有超过25年的软件开发经验.a他现在是Vocalocity公司的工程副总裁.aVocalocity公司是基于云技术的商用通信服务商中的佼佼者.a在加入Vocalocity之前,1他曾经在多个公司建设和管理软件团队,1包括vmSight、Epiphany和Radnet.a他毕业于加州大学洛杉矶分校计算机科学系,1其职业生涯的早期曾经为著名作家MichaelcCrichton（迈克尔·克莱顿）编写软件.a

书籍目录

《程序员度量:改善软件团队的分析学》

前言
1

第一部分 概念

第1章 概述
7

第2章 测量程序员的工作
15

度量的目的
15

案例分享：局部地揭露魔力三角
21

模式、异常点和离群点
23

理解度量的限制
28

案例分享：意料之外的成功因素
29

有价值的数据
30

案例分享：度量和怀疑论者
37

第3章 合适的数据
39

度量可以帮助回答哪些问题
39

案例分享：赛季的最有价值球员
45

度量数据
46

案例分享：双队记
61

第二部分 度量

第4章 技能度量
67

输入数据
67

.进攻度量
68

防守度量
79

精度度量
85

技能度量计分板
91

如何度量各种程序员类型
94

第5章 响应度量
97

输入数据
97

获胜度量
98

输场度量
105

动量度量
112

响应度量记分卡
122

基于项目类型的观察
124

第6章 价值度量
128

输入数据
128

贡献度量
129

评价度量
138

价值度量记分卡
146

关于团队在不同阶段的一些观察
147

第三部分 过程

第7章 使用度量
153

着手开始
153

案例分享：7%规则
161

在开发过程中使用度量
163

案例分享：转机
170

在绩效评估时使用度量
174

进一步采用度量
179

案例分享：相同与不同
183

第8章 打造软件团队
189

目标和描述信息
189

角色
198

案例分享：两次通宵
206

人事
208

案例分享：没有完美团队这回事
214

第9章 结论
216

附录 本书中的度量方法汇总
221

编辑推荐

《O'Reilly精品图书系列•程序员度量:改善软件团队的分析学》提供了一套行之有效的方法——程序员度量，这种方法不仅能通过衡量程序员的技能水平及其在团队中的贡献来提升他的综合能力，而且还能使团队变得更高效和更有凝聚力，让软件团队的成功变得可以衡量。

作者简介

你该如何改善你的软件开发团队？这本精炼的书籍介绍了程序员度量，这样一种清晰客观的方式来确定、分析和讨论软件工程师的成败——不作为绩效考虑的一部分，但是可以帮助团队变成更有凝聚力的生产单元。

富有经验的团队建设者Jonathan Alexander解释了程序员度量是如何帮助团队准确地理解在项目过程中发生的事情，让每一位程序员可以关注于特定的改善。Alexander呈现了各种简单而又复杂的程序员度量，向你传授如何建立你的团队。

-- 学习如何通过程序员度量改变长期以来的假设，并且改善团队动态。

-- 获得将程序员度集成到现有流程的建议。

-- 提出正确的问题来确定你需要收集的数据类型。

-- 使用度量来测量一段之间之后程序员个体的技能和团队效率。

-- 确定每个程序员对团队所作的贡献。

-- 分析对软件及其特性的响应，并且验证程序员正朝着团队和组织目标而努力。

-- 建设更好的团队，通过使用程序员度量来进行人员调整和补充。

---

 程序员度量下载 精选章节试读

---