程序员度量

出版者:机械工业出版社

作者:Jonathan Alexander

页数:236

译者:张燎原

出版时间:2013-3

价格:59.00元

isbn号码:9787111401407

具体描述

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

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

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

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

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

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

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

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

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

作者简介

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
· · · · · · (收起)

用户评价

这本书的装帧设计很有品味，封面那种深邃的蓝配上简洁的几何线条，一下子就抓住了我的眼球。我本来还担心内容会过于枯燥，毕竟“度量”这个词听起来就挺硬核的，但翻开后发现排版非常舒服，留白恰到好处，阅读起来一点也不费力。更让我惊喜的是，作者在开篇就用一个生动的小故事引出了度量在软件开发中的重要性，一下子把我拉进了情境。我记得那个例子是关于一个早期团队如何因为没有科学的度量标准而陷入无休止的争论，画面感十足。作者的文笔流畅自然，没有那种高高在上的说教感，反而像一位经验丰富的前辈在耳边娓娓道来。很多技术书籍堆砌公式和术语，让人望而却步，但这本书的叙述方式却充满了启发性，它不只是告诉你“怎么做”，更让你思考“为什么要做”。那种引导思考的节奏感，让我觉得这不是一本工具书，而是一本能提升我职业认知的进阶读物。我特别喜欢作者在章节过渡时使用的那些富有哲理的小引语，它们就像是路标，指引着我继续探索接下来的内容。

我不得不说，这本书在内容深度上达到了一个令人尊敬的高度。它没有满足于泛泛而谈，而是深入剖析了几个核心指标背后的复杂性。比如，关于代码复杂度度量的那一章，作者没有直接抛出 McCabe 环复杂度公式，而是先探讨了为什么传统的行数统计法是如此的具有欺骗性。他通过一系列实际项目中的反例，论证了度量工具的局限性，并提出了如何结合人工评审和自动化分析的综合视角。这种批判性思维的培养，对我触动很大。以前我总觉得度量就是为了评判，但这本书让我明白，度量更重要的意义在于发现问题、持续改进，它是一种“诊断工具”，而不是“惩罚机制”。我记得有一个论述提到，过早或过度地引入度量指标，可能会导致团队为了“刷数据”而偏离业务目标，这种对人性的洞察，让这本书的价值超越了单纯的技术层面。读完之后，我立刻回去审视了我们团队现有的几个KPI，发现其中一个指标似乎正在产生负面的行为导向，这真是一次及时的警醒。

这本书的语言风格充满了强烈的个人色彩，读起来像是在听一位身经百战的老兵分享他的“战场经验”，而不是在啃一本刻板的教科书。作者的叙事中偶尔会穿插一些幽默的比喻，让原本抽象的理论变得鲜活起来。比如，他把“技术债”比喻成一个不断累积的“隐形购物车”，每次不规范的提交都会往里面多加一件昂贵的商品，而最终的清算会异常痛苦。这种形象化的表达方式，极大地增强了知识的留存率。而且，这本书的结构设计也很有趣，它不是严格地按照时间线或者技术栈来组织的，而是围绕着几个核心的“度量哲学”来展开的，这使得我可以根据自己的疑惑点，随时跳跃到相应的章节进行深入阅读，查阅和回顾的效率非常高。我个人最喜欢的是它对“失败案例”的坦诚分析，作者没有美化任何一个项目，而是毫不留情地解剖了那些因为度量缺失或误用而导致的项目崩溃，这种坦诚让我对作者产生了极大的信任感。

对于我这个已经工作了几年，感觉自己达到了一个技术瓶颈期的开发者来说，这本书提供了一个全新的“观察世界”的透镜。它成功地将我从日常的“写代码”事务中抽离出来，让我开始用一种更宏观、更系统性的方式去审视自己的工作产出。它不仅仅是教会我如何计算那些指标，更重要的是，它培养了一种“度量驱动的思维惯性”。例如，在接触一个新需求时，我不再是立刻动手编码，而是会下意识地思考：“如果我们成功了，我们如何证明它成功了？我们应该记录哪些数据点来指导下一阶段的优化？”这种前置思考的习惯，极大地提升了我决策的质量。书中对不同成熟度团队的度量工具选择给出了非常细致的建议，从初创期的敏捷看板到成熟企业的DevOps流水线监控，每一步的推荐都基于对实际工程场景的深刻理解，这使得即使是小型团队，也能找到适合自己的起点，而不是盲目追求行业标杆的复杂工具链。这本书真正做到了“授人以渔”，它给了我一套思考的框架，而非一套固定的答案。

这本书的视角非常独特，它似乎并不把“程序员”视为孤立的个体，而是将其置于一个更宏大的工程体系中去考量。我尤其欣赏作者在讨论“效率”与“质量”的平衡时所采用的辩证手法。很多业界讨论常常把两者对立起来，认为提升一方必然牺牲另一方，但作者通过引入“流程吞吐量”和“缺陷密度衰减曲线”等概念，巧妙地展示了在特定阶段，这两者其实是相互促进的。我感觉作者对软件工程的理解是极为全面的，他不仅懂技术实现，更懂组织管理和跨部门协作的微妙之处。例如，书中关于如何向非技术管理者清晰地传达技术度量成果的那一部分，对我这个经常需要向上汇报的技术人员来说，简直是及时雨。作者提供了一套非常实用的沟通框架，强调将技术指标转化为业务影响，比如“减少的维护时间意味着能提前上线X个功能点”，这种转化能力，是区分普通工程师和资深架构师的重要标志。

参考棒球运动的度量，在软件项目中应用。分析有点少。简单的类比应用，缺乏深入思考。

度量对于帮助我们定义持续改进的流程、长期维持高水准的绩效来说，是非常有帮助的。 对于团队来讲，不论是一支运动团队或者一支软件开发团队，度量可以在许多领域帮助创造机会。机会的数值基本上和团队的人数成正比。就像本书已经讨论的，度量可以在招聘、程序员和团队考评、目标设定和进度分析方面为团队提供帮助。如你在运动项目上看到的，度量所提供的自我认识也极具价值。周期性评测度量的程序员也能收到类似的效果。 迭代改进是我们这个领域的本质。度量可以被程序员和软件团队使用在检测-调整-检测循环中。同样，我们可以迭代地改进度量本身或者我们使用它们的方式。当我们把度量纳入开发流程的时候，我们将学到更多关于团队的，同时也关于度量及其使用的知识。

把棒球运动的度量方式应用到软件开发领域，有些收获。但是不懂棒球，读起来还是无趣了点。

将球队的数据度量与软件开发中的工作量度量进行类比，从不同角度审视软件度量的作用和方法。

参考棒球运动的度量，在软件项目中应用。分析有点少。简单的类比应用，缺乏深入思考。