《开源之迷》是一本由适兕著作，人民邮电出版社出版的376图书，本书定价：平装，页数：2022-2-10，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。

　　 《开源之迷》读后感(一)：很好的开源运作科普书籍

　　看完了《开源之谜》，这本书是很好的开源运作科普书籍。通过本书，我们可以深入浅出地了解开源生态。前两章介绍的是开源的概况，即如何产生、如何运作。后面几章介绍开源的标志性事件和开源的特征，以及开源生态的发展，开源项目与开源领军人物的突起。后面讲了开源的商业思维和开源经济效益，再往后面从基础设施的角度系统介绍了开源生态的发展趋势。最后一章认为在开源领域本土与国际上流行的开源社区比，人财物等投入还是不足，还有较大的发展空间。道路是曲折的，前途是光明的。与开源生态携手，一起向未来！

　　 《开源之迷》读后感(二)：一位真正意义上的布道师

　　建盛（适兕），是一位真正意义上的布道师。

　　一般意义上的布道师，是一种职业。而对于建盛来说，则是一种志业。甚至可以说，是一种无法推却的使命感，“迫使”他辞去工作，成为一名全职的开源布道师。我们这些同样身为开源爱好者的朋友，对于建盛的选择与执着，也是深感佩服。

　　作为一个布道师，建盛也一直在磨炼自己的布道技巧。从写文章，到写书。从研究社区，到自己来运营开源之道社区。其实我们一直能够感受到他的变化。他在不断进步，在不断试错，也在不断尝新。这次抢鲜读到《开源之迷》，我充满了惊喜的感觉。说实话，建盛以前的文章，是比较晦涩的。但是这次读到的这本书，轻松、愉快、引人入胜，以导游带领大家参观的形式，一步一步的展开开源世界的画卷。这样的形式，非常令人激赏！

　　再次祝贺《开源之迷》出版。

　　 《开源之迷》读后感(三)：给开源新手/外行人聊开源的有力工具

　　这本书当中介绍了不少开源的历史。

　　作为一个开源开发者，这些信息对我来说，增量不多，但换个角度来看，如我一般的开源开发者又有几何？

　　倒是这本书的文笔朴实，大量的时间和核心精髓的总结，可以让不那么熟悉开源的人认真的了解一下开源的全景图。对于每一个想要参与开源的人来说，都是一本好书。

　　而对于我们这些开源的老人来说，更多是能够为我们提供查漏补缺的机会，和与身边的朋友在另外一种方式中再次见面的机会。

　　如果你对开源感兴趣，这本书值得一读；如果你希望参与到开源之中，那么这本书提供的建议值得你参考；如果你希望以此创业，以此为生， 这本书提供的参考案例，值得你学习。

　　如何找到开源爱好者？

　　对于投资人来说，什么样的开源项目是好的项目？

　　 《开源之迷》读后感(四)：对开源世界的布道及导读

　　过年期间看完了这本书，颇有感慨。仿佛回到了大一，那时对于计算机世界的认知仅停留在word的阶段。然后有了一门课：计算机导读。大一看导读，其实是带有不屑，觉得浅。现在回头看，还是缺乏大局观、急功近利。看导读能够：

　　1. 了解全局，了解不同子领域间的关联关系

　　2. 找到自己“可能”喜欢并擅长的领域

　　3. 了解自己不擅长的领域并给予对应的敬畏之心

　　上述无论哪个都很难，第一个是了解整体架构，第二个是知道自己可以做出什么真正有价值的贡献，第三个是可以站在前人肩膀上、也避免了半桶水晃荡。

　　《开源之谜》就是这样一本导读，比较全面的介绍了开源全貌，介绍了涉及到的计算机科学、软件工程、社会学、经济学、管理学、政治学等。建盛老师创办的读书会我断断续续有参与，也一直和不同人有讨论：开源的精髓到底是什么。越讨论越心虚，因为越讨论就越发现，开源远远超出了编程的范畴。试问，又有多少人能够懂社会学、经济学、管理学、政治学，别说有经验，认真读了相关名著的又有多少？这些问题在《开源之谜》里没有给出解答，从建盛规划来看，会在后两部涉及，后两部的挑战可想而知。

　　《开源之谜》在结构上立的不错，内容非常详实，撑起了近400页的内容，体现了建盛雄厚的知识积累。小瑕疵是目录标题还可以打磨的对称点（最近有点强迫症），另外后几章稍微不够正交、显得突兀。

　　开源里面有太多的书籍，喜欢分享“道”，喜欢沉迷“道”，喜欢只讨论顶层设计的理论而不讨论具体实现的细节。这些很重要，但比例太多了，最后想了解开源的人还是云里雾里。这些是“talking”，不能说cheap与否，但最终还得“show me the code”，实干为王。

　　在开源领域的相关书籍中，这本书属于实干系列的书籍，推荐5颗星。

　　 《开源之迷》读后感(五)：业界同行推荐语

我是一个大二的学生，学的专业是软件工程。再读林锐的这本《软件工程思想》之前，我学习了C和C++的一些编程知识，但是我却一直很迷惑于一个问题：到底软件工程是什么，有什么用，我毕业之后是做些什么工作。直到今天我学习了现代软件工程，并在老师的直到下阅读了这本《软件工程思想》，让我有种眼前豁然开朗的感觉，对软件工程有了一定的认识，也让我对软件工程的一些具体的工作等有了一定的认识。 本文来自读后感吧
《软件工程思想》我想之所以命名为思想，是因为在这本书中虽然并没有该我们提供可以学习的一些具体的知识，但却用作者特有的带点幽默感的语言给了我们一个软件工程的基本框架，让我对软件工程的各个方面有了个清晰的认识，这对我以后的学习和工作都很有用。 本文来自读后感吧
软件工程主要讲的是软件开发的道理，我读这本书是能充分的感受到作者在学习过程中的那种成功和失败的经验，这本书中写的作者的一些新的和体会都是值得我们去学习和感悟的。一般我在阅读相类似这样的书的时候，都有一种晕晕沉沉的感觉，总是看了前面的一小部分，极少有看完的，担当我在读林锐的《软件工程思想》时，我居然一个人就这么窝在寝室里花了一天的时间看完，当时我自己都有一种恍然的感觉，没想过自己可以看完，当时老师说的时候就在想怎么可能看完，但事实证明我是错的。我不仅看了，对其中林锐所说的一些话还很有感触，读这本书就好像我在吃我特别喜欢的

程序是指按特定的功能和性能要求而设计的能够执行的指令序列；
数据是指程序能正常操纵、处理的信息及其数据结构；
文档是指与程序设计开发、维护和使用有关的图文材料。
软件危机：
（1） 软件生产不能满足日益增长的软件需求，软件生产率远低于硬件生产率和计算机应用的增长率，社会出现了软件供不应求的局面 。更为严重的是，软件生产效率随软件生产规模的增加和软件复杂性的提高而急剧下降。
（2） 软件生产率随软件规模与复杂性提高而下降，智力密集型行业的人力成本不断增加 ，这些都导致软件成本在计算机系统成本构成中的比例急剧上升。
（3） 软件开发的进度与成本失控 。人们很难估计软件开发的成本与进度，通常情况是预算成倍突破，项目计划一再延期。软件开发单位为了赶进度、节约成本，往往只有降低软件质量。软件开发陷入成本居高不下、质量无保证、用户不满意、开发单位信誉降低的怪圈中。
（4） 软件系统实现的功能与实际需求不符 。软件开发人员对用户需求缺乏深入的理解，往往急于编写程序，闭门造车，最后完成的软件与用户需求相距太远。
（5） 软件难以维护 。程序中的错误很难改正，要想使软件适应新的运行环境几乎不可能，软件在使用过程中不能增加用户需要的新功能，大量的软件开发人员在重复开发基本类似的软件。
（6） 软件文档配置没有受到足够的重视 。软件文档包括开发过程各阶段的说明书、数据词典、程序清单、软件使用手册、维护手册、软件测试报告和测试用例等。这些软件文档的不规范、不健全是造成软件开发的进度、成本不可控制和软件的维护、管理困难的重要原因。

从狭义上说，软件工程的目标是生产出满足预算、按期交付、用户满意的无缺陷的软件，进而当用户需求改变时，所生产的软件必须易于修改。从广义上说，软件工程的目标就是提高软件的质量与生产率，最终实现软件的工业化生产。
一般软件生存周期包括问题的定义、软件开发、软件测试、软件使用与维护等几个阶段。

软件错误是指在软件生存期内的不希望出现或不可接受的人为错误，软件错误导致软件缺陷的产生。
软件缺陷是存在于软件（文档、数据、程序）之中的不希望出现或不可接受的偏差，软件缺陷导致软件在运行于某一特定条件时出现软件故障，这时软件缺陷被激活。
软件故障是指软件在运行过程中产生的不希望出现或不可接受的内部状态，对软件故障若无适当措施（容错）加以及时处理，就会使软件失效。
软件失效是指软件在运行时产生的不希望出现或不可接受的外部行为结果。

软件质量是与软件产品满足明确或隐含需求的能力有关的特征和特性的总和。
其含义有以下4个方面：

软件测试定义：使用人工或自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清楚预期结果与实际结果之间的差别。
软件测试的原则：
尽早测试；全面测试；全过程测试；独立的、迭代的测试；Pareto原则：测试发现的错误中80%很可能起源于20%的模块中；对测试出的错误结果一定要有一个确认的过程；制订严格的测试计划；完全测试是不可能的，测试需要终止；妥善保存一切测试过程文档；注意回归测试的关联性。

（1）功能测试。功能测试主要针对产品需求说明书对软件进行测试，验证软件功能是否符合需求，包括对原定功能的检验以及测试软件是否有冗余功能、遗漏功能。
（2）健壮性测试。健壮性测试侧重于对程序容错能力的测试，主要是验证程序在各种异常情况下是否能正确运行，包括数据边界测试、非法数据测试、异常中断测试等。
（3）接口测试。接口测试是对各个模块进行系统联调的测试，包括程序内接口测试和程序外接口测试。在接口测试中，测试人员在单元测试阶段进行一部分工作，大部分工作是在集成测试阶段完成的。
（4）性能测试。性能测试主要测试系统的性能是否满足用户要求，即在特定的运行条件下验证系统的能力状况。性能测试主要是通过自动化的测试工具模拟正常、峰值以及异常负载状况，对系统的各项性能指标进行测试，测试中得到的负荷和响应时间等数据可以被用于验证软件系统是否能够达到用户提出的性能指标。
（5）强度测试。强度测试是一种性能测试，强度测试总是迫使系统在异常的资源配置下运行。强度测试的目的是找出因资源不足或资源争用而导致的错误。
（6）压力测试。压力测试是一种性能测试，主要是在超负荷环境中，检验程序是否能够正常运行。压力测试的目的是检测系统在资源超负荷的情况下的表现，是通过极限测试方法，发现系统在极限或恶劣环境中的自我保护能力。压力测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，压力测试还要评估软件的性能特征，例如响应时间、事务处理速率和其他与时间相关的性能特征。
（7）用户界面测试。用户界面测试主要对系统的界面进行测试，测试用户界面是否友好、软件是否方便易用、系统设计是否合理、界面位置是否正确等问题。
（8）安全测试。安全测试主要测试系统防止非法侵入的能力，例如测试系统在没有授权的内部或者外部用户对系统进行攻击或者恶意破坏时如何运行，是否能够保证数据的安全。
（9）可靠性测试。可靠性测试是指为了保证和验证软件的可靠性水平是否满足用户的要求而进行的测试，即确定软件是否满足软件规格说明书中规定的可靠性指标。软件可靠性测试的目的是给出可靠性的定量估计值，通过对软件可靠性测试中观测到的失效数据进行分析，可以评估当前软件可靠性的水平，验证软件可靠性是否达到要求。软件可靠性测试是一项高投入的测试工作，通常需要进行大量的测试。
（10）安装/反安装测试。安装测试主要检验软件是否可以正确安装，安装文件的各项设置是否有效，安装后是否影响整个计算机系统；反安装测试是逆过程，测试软件是否被删除干净，删除后软件是否影响整个计算机系统等。（11）文档测试。文档测试主要检查内部/外部文档的清晰性和准确性，对外部文档而言，测试工作主要针对用户的文档，以需求说明、用户手册、安装手册等为主，检验文档是否和实际应用存在差别，而且还必须考虑文档是否简单明了，相关的技术术语是否解释清楚等问题。
（12）恢复测试。恢复测试主要测试当出现系统崩溃、硬件错误或其他灾难性问题时系统的表现情况，以及系统从故障中恢复的能力。
（13）兼容性测试。兼容性测试主要测试软件产品在不同的平台、不同的工具软件或相同工具软件的不同版本下的兼容性，其目的是测试系统与其他软件、硬件兼容的能力。
（14）负载测试。负载测试是通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征。例如，响应时间、事务处理速率和其他与时间相关的方面。

制订测试计划、设计测试、测试准备、测试环境的建立、执行测试、评估测试和总结测试。

移动应用开发技术
《移动应用开发技术》，是机械工业出版社2021年出版的图书，作者是工信部通信行业职业技能鉴定指导中心，中国移动互联网基地。[1]
书名
移动应用开发技术
作者
工信部通信行业职业技能鉴定指导中心，中国移动互联网基地
ISBN
9787111366638
页数
287
出版社
机械工业出版社
旧书九成新 移动应用开发技术【全新未拆封】--EA2009140
包邮
￥26.00
￥43.00
古物潮玩 智能小程序
去购买
旧书九成新 移动应用开发技术【全新】--EI2044474
包邮
￥31.00
￥43.00
古物潮玩 智能小程序
去购买
旧书九成新 移动应用开发技术【全新未拆封】--EA2021673
包邮
￥18.00
￥43.00
古物潮玩 智能小程序
去购买
快速
导航
目录
内容简介
全书一共19章：第1章和第2章详细介绍了移动增值业务的发展与应用商场的模式，以及各种主流的开发平台技术；第3～16章全面而系统地讲解了Android应用开发所必备的知识，包含Android的系统特性及架构、Android应用开发环境的搭建方法、UI设计、数据存储、SQLite数据库、内容提供器、广播与服务、网络编程、手机功能开发、多媒体开发、2D游戏开发、State和MVC框架的使用等一系列知识点，大部分知识点都配有精心设计的小案例，便于读者理解和动手实践；第17章以迭代的方式讲解了一个完整的游戏案例；第18章讲解了中国移动的跨平台统一开发环境的搭建以及项目开发方法；第19章详细列出了NobleLeader终端应用开发常用的各种类。
本书既适合想从事移动应用开发的技术人员自学，又适合作为移动应用开发的培训教材。
目录
编审委员会
前　言
第1章　移动增值业务发展与应用商场模式介绍
第2章　移动开发平台技术
第3章　Android 系统架构
第4章　Android 应用开发环境搭建
第5章　Android 应用程序基础
第6章　基本UI设计
第7章　高级UI设计
第8章　Android数据存储
第9章　数据库SQLite
第10章　内容提供器ContentProvider
第11章　广播与服务
第12章　网络编程
第13章　手机功能开发

一直以来，我对度量骨子里有一种抵触，因为很多时候，指标容易被拿来衡量团队绩效。而作为考核的KPI，容易成为团队改进指挥棒，带有很大片面性和欺骗性；另一方面，如果没有度量，有无法客观的评价组织改进的效果，这是一种矛盾。不想因为自己心智模型导致目光的短浅，跳出盒子去了解原本的度量，这是我都这本书《精益软件度量——实践者的观察与思考》的初衷。本次阅读本书的前四章。

按照IEEE的定义，“软件工程是将系统化、规则，以及可控的体系方法，应用于软件设计、开发、操作和维护；换言之，即工程理念在软件中的贯彻。”

Roger Martin在他的著作《The Design of Business: Why Design Thinking is the Next Competitive Advantage》把知识的演进用一个知识漏斗（Knowledge Funnel）生动形象地描述了出来。这个漏斗总是从一个问题开始，需要经过谜题（Mystery）、启发（Heuristic）和算法（Algorithm）3个阶段[注释]，如图1-1所示。

Roger在书中提出了两种思考问题的方式：分析性思维和启发性思维[注释]。分析性思维的驱动力是标准化，消除个体的判断所带来的偏见和差异，而启发性思维的驱动力是发现和创新。这两种思路在具体实现上体现出的区别在于，分析性思维倾向于可靠性，而启发性思维倾向于有效性。

度量本身似乎就是一个分析性思维的产物，但这并不妨碍我们回归问题本身，同时利用分析性和启发性思维，判断到底哪些要素跟“成功”更相关，并尝试用一个度量体系来帮助我们在动荡的环境中捕捉和把控这些要素。

在理念上，我们希望把度量的重心从“控制”转向“改进”。虽然控制和改进都是对系统采取的干预性措施，“控制”给人造成的心理暗示是围绕着静态目标而行动；而“改进”则将动态的目标植入人们的思维模式。

度量体系的实现分成3个不同的层次——理念、设计、应用。

1、度量是在一个特定组织上下文中形成的一系列共识。

2、度量是将经验模型向量化模型进行匹配的尝试。

量化模型就是通常所指的硬数据、硬指标。量化模型比较有两种类型：

•跟自己比较：持续改进，持续超越自己，就需要比较自己发生的变化。

•横向比较：这对于拥有大量开发人员、团队和产品的大型组织来说，是非常有吸引力的。在组织内部进行团队和团队之间的比较，是不少公司激励大家提升绩效的手段。另外，如果能跟业界的数据比较，也可以知道自己在行业中的位置如何。

3. 度量是包含人、流程、组织和工具的一个动态系统。

如果把软件开发组织看做一个动态的系统，度量实际是作为反馈机制来对这个系统产生作用的。

1. 度量不是软件开发固有的活动。

作为一个组织来讲，应该积极地评估当前的度量活动的成本，分析是否真正为达成业务目标发挥着价值，从而确保运行度量体系的投入产出是在一个合理的水平。

2. 度量应该避免跟绩效直接相关。

把一套标准的度量与个人、团队绩效强相关，很可能导致各种奇怪的博弈行为，中长期的负面作用经常会大于短时间指标提升带来的好处

3. 度量不是免费的。

目标和指标的选择就显得特别重要，试图实施一个大而全的度量体系，通常弊大于利。

度量体系是引导团队达成业务目标的一整套策略，如图2-1所示，包含了业务目标、决策场景和指标体系3个阶段。

软件产品的开发分成几个大的阶段：业务策略、项目定义、项目执行、维护支持。

业务对开发组织的期望大致分为几类：价值、效率、质量和能力，其中效率又包括对市场的响应速度和单位规模开发组织的交付速率。

对于功能性需求，开发组织能够在开发前，将低价值内容从高价值特性上剥离下来，从而提升投资回报（ROI）。

对于非功能性需求，很多情况下，开发组织提出的方案都会影响投入在短期和长期时间轴上的分配，因此，能够使技术方案跟业务模式相吻合，就有可能在相当程度上提升交付的价值。

管道的长度代表了端到端的软件开发活动，包含了从用户需求的产生到该需求以产品的形态为用户产生价值的整个过程。管道的长度和交付对象在管道里流动的速度，决定了组织对市场的响应速度，也就是交付周期。

如果把管道直径比作组织的规模，效率的一个目标是提升管道的吞吐率，也就是交付管道直径不变的情况下，提高单位时间内通过管道的工作单元的数量。对应到软件开发组织，就是单位规模的组织在单位时间内所能交付的软件规模，我们简称其为交付速率。

软件开发本身的特点，使得在传统制造业中大放异彩的规模效应，并没有在软件开发中产生明显的效果。业界分析的结果指出，规模能够对软件开发效率带来2个正面效应。

（1）在以提高生产效率为目的的工具和基础设施上的投入可以被更广泛的共享。

（2）产品和项目管理的成本不会直接随着项目规模的增大而增加，可以想象，一个项目经理或一个产品经理，可以应对从十来号人到上百人团队的管理工作。

负面效应：

（1） 沟通成本：如Brooks在《人月神话》中说的[注释]，开发规模大了之后，团队成员之间、团队和团队之间的沟通路径是几何级数增长的。

（2）人员投入程度：软件开发是一个需要紧密协作的活动。大团队增加了人员间个性冲突的概率，会造成团队内不良的化学反应，降低团队效率。此外，大团队还降低了大多数个体的参与感。

（3）系统复杂度：产生大规模团队的一个原因是系统本身的规模，而根据Conway’s Law[注释]，软件设计的架构，实际上反映了开发组织的结构与沟通架构。随着组织结构的扩展和复杂化，模块间接口数量也会随着模块数量的增加呈几何级数增长的。这意味着系统复杂度的增长，而且更加难以评估引入变更的影响，这也意味着系统维护、演进成本的增加。

质量是指广义上的质量，包括产品设计、用户体验、功能完善等。质量是个约束性的属性，对于一个特定的产品来说，其质量要求通常是相对稳定的。质量保障是通过系统化的一系列活动，提供足够的证据说明软件产品是适合使用的（fI Tfor use）。

个人、团队、组织的能力是对上述3个因素有直接影响的要素。Peter M .Senge在《第五项修炼》中指出，一个组织唯一可持续的竞争优势是比对手更快的学习能力。这种学习不仅发生在课堂里，更重要的是从客户、市场、团队学习，从成功和失败学习。

软件度量信息的使用者分成3个主要角色——管理层、项目管理、工程师。

管理层关注：

•公司的战略定位——产品和服务的交付对战略目标的支撑。

•战略目标的达成——产品和服务的商业绩效，组织的交付效率。

•组织所处的竞争环境——自身和竞争对手商业模型，对市场变化和机会的响应速度。

•客户满意度，等等。

大多数的度量都跟项目管理相关，但是项目管理也分不同的层面。首先需要在组织层面考虑各个目标的权衡，诸如交付、创新和能力提升；然后需要考虑本项目在产品或产品线组合中的位置、产品各个版本之间的关系，还要顾及项目目标和相关人员个人诉求之间的关系。

工程师不仅仅是第一手度量信息的生产者，当管理层和项目管理人员根据信息采取行动时，工程师都常常是执行者或是最终受到主要影响的人。

合适的软件开发实践一定会受到产品本身和开发组织特点的影响，正如 Barry Boehm 和 Richard Turner 在“Balancing Agility and Discipline: A Guide for the Perplexed”里提到，5个方面的因素[注释]会在很大程度上影响开发的组织模型和流程模型。

1. 问题定义

清晰地定义问题是设定目标、制定计划的前提。如果把项目分成问题域和方案域，不少组织和个人都会不自觉地混淆问题域和方案域。

2. 交付目标

交付目标应该有可度量的开始点和截止点，也就是有清晰的边界。这个边界可能会在交付过程中，根据最新的信息而调整。但在任何特定的时候，项目的所有干系人对边界都应该有一个清楚的共识。

3. 提升目标

一个组织要分析相关行业和竞争对手的数据，对自身交付竞争力做出评估，有策略地制定提升目标。研发竞争力的提升必须要以项目为载体，在实践当中部署实施。

4. 资源配置

一个大型的开发组织一般都有多个产品、多个版本在同时进行当中。这就涉及到在不同发布目标之间的权衡，决定资源，特别是优质资源的分配。资源的投入经常是多个项目、多个产品之间博弈的结果。项目管理人员需要根据项目的目的和里程碑来规划项目，在规划的时候需要覆盖进度、质量、资源和风险各个方面。

5. 进度目标

项目的关键路径信息可以帮助项目管理人员识别交付过程中的里程碑。里程碑提供了一个常规机制来跟踪项目的进展是否跟预期相符。这些里程碑给团队之外更广泛的项目干系人一个必要的机会，一起分析最新的项目和环境信息，调整后续的时间点、投入、工作范围和目标，或做出其他必要的决策和干预。

6. 质量目标和手段

不同类型的产品有不同的质量目标。在这个项目里，开发人员将负责单元测试完成，测试人员将会跟业务分析人员一起定义每个用户估算的验收条件，并设计功能和集成测试用例。功能和集成测试用例的自动化则根据工作量的平衡，由开发人员和测试共同完成。

7. 资源的规划

项目管理人员就需要用真凭实据，对照过往的历史数据和项目相关信息，提出资源的要求。对于个人来讲，项目的参与人员需要了解团队计划，评估个人对于交付目标的承诺，并且识别成长的机会。

项目干预通常主要出自以下两个方面的原因。

•环境变化——市场上的客户需求或是竞争对手的行动出现了变化，原来决策所基于的事实或假设出现了变化，因此需要对本组织的开发做出调整。

•内部变化——本项目的进度、质量，周边其他项目的进展跟预期不符，如果需要达成原来的目标就需要采取额外行动，否则就可能需要调整目标。

对于项目管理来说，为管理层提供确实的数据，支持管理层决策是至关重要的。这里度量数据的典型用途包括以下几方面。

（1）设定管理层对进度和质量的期望。

（2）获取更多资源，以较低的风险达成项目目标或是管理层的期望。

（3）提高项目透明度，取得包括管理层在内的各方干系人的信任，以取得决策的权威。

（4）预测项目状态，争取管理层做出对项目有利的干预。

（5）识别项目执行当中的瓶颈，做出相应调整，或是说服调动其他有资源、有权利的人做出调整。

（6）识别项目执行过程中的浪费，积极采取措施消除浪费。

管理层在这个阶段更关心客户的满意度，这里满意度主要体现在以下两个方面。

•需求的价值命中率——做出来的东西是否真是市场和客户最需要的东西，是否为公司创造了最大的价值。

•客户满意度——这个维度更加复杂一些，不仅包含了前一个需求价值命中率的因素，还包含了用户体验、线上的缺陷率，以及支持维护的响应速度和质量。

项目管理人员需要在维护阶段管理客户和市场对维护响应的期望，因此需要知道以下内容。

（1）问题的优先级——哪些问题会造成较大的影响，必须先解决。

（2）响应速度——支持团队对客户的响应周期，包括：邮件、电话确认问题，定位、解决问题，回复客户的周期。

（3）响应质量——提出解决办法是否真的解决了问题？打补丁的时候是否引入了新的问题？

（4）维护成本——每个类型问题和请求的处理工作量。

如果借助戴明环（PDCA循环——P计划、D执行、C检查、A行动）分析这个过程，就会发现度量数据的使用主要集中在支持计划和检查两个环节的决策。

计划-根据己知的数据，设定合理的目标，预测未来可能发生的情况，制定可行的计划。

检查：我们借助度量数据，识别现实与预期的差异、面临的问题、改进的空间。

一个指标体系通常包括下列内容。

•指标的维度。

•每个维度里可选的具体指标。

•指标的优先级评估。

•指标的数据采集、分析和使用方法。

每一个指标都不是独立存在的数据，都必然跟一系列上下文信息相关，具体体现为类似下面所列的属性。

在裁剪指标体系的时候，也应该在目标优先级的引导下，如图4-3所示，权衡有效性、可靠性和成本，设计和选择要使用的度量指标。

•有效性：指标数据在多大程度上能真实地为达成目标服务。

•可靠性：数据收集以及分析结果的一致性和可靠性。

•成本：度量数据的收集和分析成本。

以工作量的估算数据为例，在使用Delphi专家估算法的时候，参与者会将很多可以量化、不可以量化的上下文信息都纳入到估算的考虑当中，因此有可能得到更有效的数据。

从前面的过程中可以看到，度量体系的设计本身蕴含了很多人为的主观判断和取舍，面临着不少的局限性，所以肯定不能满足所有人的诉求。

对业务目标有帮助，能起到引导作用才是我们实施度量体系的价值所在。

度量体系中的指标不是一成不变的，所谓“流水不腐，户枢不蠹，动也”。

企业内部和外部环境的变化不可避免，我们设计体系时所期望满足的目标和优先级也可能发生变化，因而需要随之增加、减少或是修改当前的指标。

当增加一个指标的时候，一定要记住重新审视一下己有的指标，看看是否有可以减去的，否则指标体系将会越来越沉重，体系的投资回报逐渐降低。

1. 度量数据应该解决数据生产者的问题。

2. 各级组织有自己的期望和目标并需要上下双向沟通。

今天参加了《研发教练大会》，收获和体会很大，对着自己的心智模型有了改变。有客观的数据，去直面团队变化，应该是团队转型的第一步。