《精益软件度量——实践者的观察与思考》—第1章1.1节精益软件开发的度量体系...-CSDN博客

本节书摘来自异步社区《精益软件度量——实践者的观察与思考》一书中的第1章1.1节精益软件开发的度量体系，作者张松，更多章节内容可以访问云栖社区“异步社区”公众号查看。

第1章　度量谜题
精益软件度量——实践者的观察与思考
“我们所能拥有的最美好的经历是感受到神秘，它是触发所有真正艺术和科学起源的基本情感。”

艾尔伯特·爱因斯坦（1879—1955）

按照IEEE的定义，“软件工程是将系统化、规则，以及可控的体系方法，应用于软件设计、开发、操作和维护；换言之，即工程理念在软件中的贯彻。”1看上去很美，不是吗？当我们看到一个又一个软件开发组织，特别是大型的组织，特别是拥有辉煌历史的组织，把过程可控作为主要的管理目标时，一次又一次地惊讶于人们是如此容易被误导，而我自己在开发管理的日常工作中，软件工程那些条条框框所带来的虚假的安全感，也曾使我一次又一次地迷失于其中。反思之后，我现在不得不重新审视软件开发的目标和软件工程方法的目的。

可控应该只是我们在软件开发管理中期望优化的属性之一，而不是全部。退一步讲，奥运会的口号或许比IEEE的定义更好地诠释了我们的目标——“更快，更高，更强”，还有一句俗话——“多、快、好、省”，我感觉也比IEEE的那句话更全面。但是为什么人们的注意力都放在了可控性上呢？虽然可控的生产过程可以帮助管理人员更有针对性地优化和改进。不过在向“多、快、好、省”的方向前进的过程中，管理层和项目管理人员的避险本能，在相当程度上扭曲了我们的注意力，有意无意地遗失了原始的目标。

风险源于不确定性。然而软件之所以“软”，就是由其生命周期中所面对的变化和不确定所决定的；从另一个角度讲，不确定性又是与创新如影随行。跟其他行业相比，软件领域的创新之活跃也不能不说与此密切相关，反过来说，那些非常确定、稳定的东西或许就不应该用软件来实现，既然要开发软件，就要正视其固有的变化性，利用其变化性取得优势。

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

01cd4afd7bd10ceca65081ec6db770fa5c390d45

Roger Martin认为，复杂问题的解决总是从谜题阶段开始。探索一个神秘的问题，可能会有无限种可能的方式。以我们的交通工具为例，人类一直在孜孜以求地获取更快更好的交通工具。那么如果说“更好的交通工具”是一个谜题，经过了几千年的摸索，在工业革命之前，交通工具这个谜题曾经已经被降解成一系列的启发式的问题。其中的两个可能是：更好的马车和更好的帆船。相对于谜题，启发式问题是将探索的领域缩小到一个更加可控、可管理的大小。当有了这两个启发式的问题之后，人们就倾向于不再去考虑“更好的交通工具”这么一个没边儿的问题，目标就变成了“如何制作更精致的马车，让马车更轻便、更结实”，“如何制作更大的帆船和有效的风帆，让帆船载货量更大，速度更快”。问题的解决聚焦在了产品的升级和演进，这两个问题又被进一步降解成了一系列的算法化问题。算法化的问题指的是已经有固定的公式、模式来解决的问题。对于马车和帆船的例子来讲，马车和帆船的制作就是一个算法化的问题，经过训练的工匠能够依据固定的流程和工艺，顺利地重复制作多个产品。

不过世界并没有就此止步。到了工业革命之后，伴随着技术约束的突破，“更好的马车”和“更好的帆船”，这两个启发性的问题已经不再合理。我们需要重新回到“更好的交通工具”这个命题，将其降解成了另外一系列问题，“更好的汽车”、“更好的轮船”、“更好的飞机”……而那些醉心于旧的启发性和算法性问题的人们或是行业，逐渐被时代所淘汰。我们可以看到，随着时间的变化、场景的转换（陆地、海洋，还有天空、太空）、科技的突破，我们要解决的基本谜题可能会降解出不同的启发式问题。

回到软件开发这个谜题上来，Gerald M. Weinberg在他的《质量·软件·管理—系统思路》中写到“虽然人类的大脑或多或少存在些许的差别，然而都有一定的限制；随着程序规模的不断增加，软件的复杂度也将至少以平方的速度增加。”3Weinberg称其为自然软件动力学。Weinberg认为“软件工程学的历史过程，也就是人类试图通过建立简化方法，降低随着问题规模的扩大而提高的问题复杂度，从而不断对规模/复杂度动力提出挑战的历史过程。如果没有这种追求，也就不需要软件工程专业了。”

软件开发这个谜题，就像其他复杂而又会随着时间和场景不断转移重心的谜题一样，我们似乎也有无数种的方式来做到一定程度的简化，在某种程度上或是在某个方面上解决了这个问题。IEEE对软件工程的定义，“系统化、规则，并且可控”就是对这个谜题在一个维度（可控性）上简化而得出的一个启发式问题。

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

IEEE的这个定义，因为并不直接关注更好地开发软件本身，明显带着可靠性的倾向，对于有效性则显得缺乏应有的关注。我猜测这应该是1965年到1985年软件危机的产物。那个时代，计算机行业刚刚摆脱萌芽期，硬件能力大幅提升，人们开始在各种领域尝试用计算机软件来解决愈来愈复杂的问题。大型软件项目纷纷出现，可又纷纷失败，软件开发就像怪兽，失去了控制，主要的表现是大幅地超时和超预算，又或是软件的质量极不靠谱。为了解决这个谜题，可靠性似乎是理所当然的，也是最迫切的切入点。

度量体系给人的直观感受就是可以提高开发过程和开发结果的可靠性，但可靠和成功，这两者真的是等价的吗？度量本身似乎就是一个分析性思维的产物，但这并不妨碍我们回归问题本身，同时利用分析性和启发性思维，判断到底哪些要素跟“成功”更相关，并尝试用一个度量体系来帮助我们在动荡的环境中捕捉和把控这些要素。

1The Institute of Electrical and Electronics Ehgineers, 1990。
2 Martin, 2009
3杰拉尔德·温伯格, 2004, 页 169
4Martin, 2009
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。

1.1　精益软件开发的度量体系
精益软件度量——实践者的观察与思考
度量本身不是目的，是手段。我问过很多人，你们这儿度量信息是在什么地方用呀？我经常听到的是，“现在不是都要用数字说话嘛，咱得搞点儿量化管理”，“这玩意儿（数字）就是给上面看看，没啥用”，“没这些数字，我怎么知道下面的人干得咋样？”我们发现：

在很多情况下，数据的生产者不是数据的使用者；

数据的生产者没什么动力去分辨信息的价值，也不关心信息准确与否；

数据的生产者关心的是数据是否会对自己带来惩罚或是收益，而不是数据跟软件开发的关系；

在很多管理者的认识当中，度量的主要目的，是确保事情在掌控之中，为的是获得可靠性和安全感；

相对于“更高效的开发软件”这样模糊的目标而言，很多一线人员对度量指标的使用其实更加一个简单、清晰、朴实——一旦开发出了问题，一个自我保护的理由就是“我已经满足了度量的要求了呀？”

软件项目中可能出现各种各样的冲突，权衡并把握住进度、质量和人员能力提升等各种不同目标，总是要消耗掉项目管理人员很多的脑细胞。可是不管多么努力，做出的决定仍然不是得罪了这个，就是让那一个不爽。度量体系中的指标通常是那些复杂、模糊的目标经过分解和简化的结果。一套度量体系被实施之后，很多人都有一种光明初现的感觉，好像做决定变得有章可循，容易多了。出于趋利避害的考虑，人们经常会把目光聚焦在片面满足相对明确的指标上，回避了对综合的项目目标和复杂上下文的思考和权衡。

为了规避指标替代目标的陷阱，我们希望在设计和运营度量体系的时候，将各类相关人员都融入到一个共同的理念之下。

精益的一个核心理念是持续改进，丰田澳大利亚技术中心（Toyota Technical Center – Australia）对持续改进的诠释是：“我们从来不认为当前的成功是我们最终的成就。我们从来不会满足于当前所处的位置，而是会一直竭尽全力，寻求最佳的思路持续改善我们的工作：我们热衷于创造更好的替代方案，质疑已有的成果，寻求新的成功定义”1。挺复杂的一句话，咱老祖宗在3000多年前，只用了9个字就把这事儿说清楚了。商汤王，也就是商朝的开国君主，在他自己的洗澡盆儿上刻了一行字以自勉：“苟日新，日日新，又日新”2，就是提醒自己：弃旧图新是每天都要干的事儿。

如图1-2所示，在理念上，我们希望把度量的重心从“控制”转向“改进”。虽然控制和改进都是对系统采取的干预性措施，“控制”给人造成的心理暗示是围绕着静态目标而行动；而“改进”则将动态的目标植入人们的思维模式。这有助于我们在识别软件开发的成功路径时，由可靠性转向一个更广泛的视角。

在这样的理念指导下，度量体系的作用就是提供信息来帮我们知道现在哪里，距离目标到底有多远，我们是否在向目标前进，进展的程度如何。因此简单地说，度量是通过对目标位置、相对位置、移动方向的描述，帮助组织达成其业务目标。