20131007 detail

20131007

我记得我曾经有两次写博客提及过度量这个词：
一篇是2010年的博文：http://www.sssa2000.com/?p=33。
另一篇是2012年的博文：http://www.sssa2000.com/?p=748。
当时的我基本上是把可度量和可测试画上了等号。

随着自己慢慢开始关注管理，对可度量这个词的含义有了更多的认识。例如：当需要回答某些问题的时候，我发现过去的眼光太局限：

-  团队生产的产品质量有多高？
-	团队的效率够高吗？
-	团队的能力有多强？
-	团队能力往哪个方向提高？

作为一名软件开发工程师，我认为我学到的最重要的一课是：**搞清楚问题领域和解决领域**。也就是说要解决一个问题的时候，首先搞清楚问题是什么，搞清楚问题的上下文。

当我们谈到度量时，我们关心的其实并不是度量本身。度量本身没有价值。如果按照道法术器的层次划分，度量应该是介于“术”和“器”之间的。那么在之上的“道”、“法”究竟是什么呢？当然是理念和价值观。

#理念和价值观
这么空洞的标题，实际上换成直白的说法就是“为什么要度量、度量能干嘛” ？

度量是一种行为，这种行为是软件过程的一部分。如果把软件过程视为一个黑盒，那么软件过程把输入的需求、约束、业务规则通过一套流程、人、工具把输入转化为了软件产品。

软件开发中的理念在哪里得到体现？答案是软件开发方法。例如瀑布开发方法、RUP、XP、Scrum、精益……当然这些方法都各有各的局限性。

那么一个组织采用某种开发方法，也就表示了该组织认同这种方法的理念和价值观。如果一个组织如果采用RUP的开发方法，那么这个组织一定是认同开发过程中“规范”的重要性。所以从书的标题：《精益软件度量》中就能看出，这本书谈论的是精益开发方法下的度量行为。那么精益的理念是什么？

```
以越来越少的投入创造出尽可能多的价值；同时也越来越接近用户，提供他们确实要的东西。
```

可以用作者在书中给出的文字概括：
```
精益的一个核心理念是持续改进。
```

也就是说精益开发中的度量的目的是为了持续改进，改进什么？

 - 生产过程整体优化 
 - 改进技术 
 - 理顺各种流程 
 - 杜绝超量生产 
 - 消除无效劳动与浪费 
 - 充分有效的利用各种资源 
 - 降低成本 
 - 改善质量

以上这些是精益生产中提及的，直接套用到精益软件开发中也毫无违和感。我想即使不知道精益生产、精益软件开发，持续改进这个思想应该是任何开发方法都赞同的。

摘抄一段书中的原文：
```
所以，在度量的理念上，我们希望把度量的重心从“控制”转向“改进”。在这样的理念的指导下，度量体系的作用是：提供信息来帮助我们知道现在在哪里，距离目标到底多远，我们是否在向目标前进，进展如何？
```

那么接下来的问题是：

- 持续改进，改进的方向是什么？需要度量哪些指标？
- 谁在什么时候会用度量数据干什么事情？

#谁
度量数据的使用者有三类人：

- 公司管理层
- 项目管理层
- 工程师

书中把一个项目的生命周期简化为四个阶段，在每个阶段以上三类人使用度量的数据做了以下事情：
 
 tu
 
 
当然，时间维度上来看这个图还是太宏观。我们的软件开发是迭代进行的，一般来说，每次迭代都有“计划”和“检查”，显而易见的，这两个行为也正是使用度量数据最多的地方。

#度量什么
这个主题是这本书的主要内容。度量什么也就是等同于：什么能够促使达到持续改进的目标。作者给出了他的看法，不难看出这些是符合精益生产的核心思想的。

tu
 

##价值
这里作者提出了精益软件开发中对价值的观点：

 1. 应该尽可能识别软件中高价值的特性，优先实现。
 2. 应该尽快的提交，得到用户的反馈，迅速改进。


对于如何度量价值，作者简单的给出了方法：

 1. 在发布前估算价值，方法是：“通过估算在产品各个阶段的投入以及产出，以贴现现金流DCF的方式来计算产品生命周期或是路线图中产生的净现值NPV”。
 2. 在发布后验证价值。

对于这部分内容，我没有共鸣。某些产品可能能估算价值，某些产品很难估算价值，如果是作为底层库之类的产品更加无法估算。

##效率
我认为这里作者讲的效率针对的是“团队效率”。作者分两个部分谈了“团队效率”：团队响应速度和团队产能。

为什么要效率要分为两个部分来谈？我是这么认为的：书中谈响应速度实际针对的是由于各种原因导致等待、负载不均衡现象；而谈产能针对的是真正的生产力。

响应速度应该分几个不同的层次关注（也就是响应速度的度量具体方法）：

- 版本发布：从立项到发布的时间
- 特性发布：在特性层面上，从需求定义到集成测试、验收测试、回归测试完成的时间。基本代表了一个开发组织响应市场需求的最快速度.
- 用户故事平均周期：从用户故事被纳入迭代计划，经过分析，开发测试等环节，到被验收的时间。这是一个最小的端到端的工作单元在一个团队中流转的时间
- 缺陷生命周期：代表团队对测试、运维的响应速度。

书中给出的提高团队响应速度的方法主要是关注流程：

1. 关注流程中的半成品。
2. 关注流程中成为瓶颈的人。
3. 关注流程中成为瓶颈的事务。
 

通过精益开发中的看板、以及价值流图（VSM）可以比较容易发现问题所在。

产能的概念：```单位规模的组织，在单位时间内，所能够交付的软件规模```。
度量产能需要度量两个值：

1. 一个迭代周期团队完成的故事点数。故事点数是通过估算得来的。
2. 一个迭代周期内代码合入的频率和构建频率。这代表了产能的稳定性和可靠程度。

我想，度量第一个值是很容易想到的。但是对于第二个值我在读之前确实没想到。当然我觉得这个值也可以归类到“质量”中度量。

书中给出的改进产能方面的建议，除了提供个人能力和优化整体系统结构（流程、人员组织）外特别花了大笔墨提及了减少浪费，这也是精益思想中的重要内容。书中总结的浪费的情况有：

- 重复手工劳动
- 重复手工测试
- 准备数据和环境
- 规模、复杂度导致的无直接价值的活动
- 定制版本
- 生命周期太长的软件
- 距离导致的浪费
- 层级导致的浪费
- 不良技术实践导致的浪费。例如狗血bug、理解烂代码
- 文档导致的浪费
- 度量本身导致的浪费
- 任务切换或中断

##质量
书中讲质量分为了内部质量和外部质量。这个提法我第一次接触。

外部质量指的是：
```
软件符合用户客户的需要和期望，也就是对其使用场景、使用目的的符合程度。此外还包括软件在特定硬件、os、浏览器等环境上运行相关的性质。
```

内部质量指的是：
```
软件的静态性质。衡量的是在代码、设计层面软件是否符合非功能的需求，比如可靠性、可维护性、可移植性。
```

关注内部质量的原因我想无需多言。关于内部质量的度量方式书中给了一个公式，不过我觉得难以实施，意义不大。但是我认同书中提到的：使用静态代码检查工具来度量内部质量，至少做到每次提交代码后，已有的内部质量不会比提交前变得更差。

书中给出的技术债的表现形式，我认为很有意义：

1. 没有重构的代码（有坏味的代码）
2. 缺乏自动测试保护的代码。
3. 未达目标的架构和设计决策（就是指代码能工作，但是还有未搞清楚的问题）
4. 未能更新的依赖（就是指，某些第三方依赖库的升级问题）

外部质量书中主要提到的两点是：满意度和Bug。作为一个产品而已必须关注用户满意度的问题，这点我很赞同。书中提及满意度需要关注的两种情况：

1. 有清晰行为状态变化的。例如用户流失这样的。可以通过调查收集满意度。
2. 可能有潜在变化的。可以使用一些有技巧的问卷，或者通过程序内部的日志记录用户的行为，做分析。

关于bug我想我认为比较重要的是:需要特别关注“回归测试产生的Bug”。即：新增了一个功能B，提交代码后发现功能A出现了bug。这类bug对用户来说伤害巨大，很容易让用户对开发团队丧失信心。

##能力
在这一部分中，书中给出的最有价值的内容我认为是：

- 如何度量个人的能力
- 如何建立学习型组织

个人能力方面，刻意练习才是在任何领域取得世界级水平的关键，刻意练习包括：

1. 为提升而特意设计
2. 持续得到结果的反馈
3. 不断重复
4. 对精神上专注有很高的要求

那么应该刻意练习什么（以下就是度量个人能力的指标）？

1. 技术能力：解决问题，并完成任务的能力
- 知识面
- 对卓越的追求

2. 首创能力：产生想法，并实现的能力。这跟主动、创新相关
- 自主启动，前瞻性
- 坚持
3. 社交能力：与其他人协作的过程中运用并发挥其技术能力的能力。比如协作、沟通、主动、辅导、领导力

那么团队能力如何度量呢？书中只提到了：
```
“团队的能力主要是被效率、质量等目标所牵引”。
```

不过书中提到了一个理想的团队的描述：
```
“组建有端到端交付能力的全功能团队，培养覆盖多项领域能力的多面手，是减少开发瓶颈、提升交付效率和质量的关键。”
```

那么为了达到理想的全功能团队，一个必不可少的特征就是：团队是一个学习型组织。学习型组织的特征是：

1.	招来的人有很强的学习主动性和习惯。
2.	组织的环境具有鼓励和推动所有成员持续学习和提升的氛围甚至是压力。

书中给出了度量学习型组织的七个维度，其实也就是如何做

1. 组织创造持续学习的机会
 - 培训
 - 非正式读书会
 - 更有挑战的工作机会
2. 促进探寻和对话活动
 - 组织需要创造安全的氛围，鼓励对新方式的探寻
3. 鼓励协作和团队学习
 - 团队中有共享的目标。
 - 个人的学习活动和成果对其他成员要有价值，对团队目标要有贡献。
 - 团队成员之间要充分讨论交流在学习过程中遇到的问题。
 - 学习的过程也是一个反馈的过程，成员之间应该及时就方式、投入、目标、问题等提供直接的、建设性的反馈和意见。
 - 团队成员之间就学习的进展和价值表达赞赏和感谢
4. 使人们能够寻求共同的愿景
-		要让团队成员认为团队的事情是自己的事情
-		设定团队共同的愿景，其目的是寻求学习的意义
	
5. 连接组织与其所处的环境
-		在组织内部建立起全局观的思维理念
-		通过联系组织与其内部、外部的活动，建立起活跃的知识流，信息流。
6. 建立捕获和共享学习的系统
-		一方面，在持续变化的商业环境中，组织需要面对众多难题。
-		另一方面，员工对学习、自我提升有期望。
7. 为持续学习提供战略层面的领导力量
-		有高层领导直接对学习型组织的建设目标负责
-		领导以身作则，其行为有正面影响

#后记
当然这本书还有很多其他内容，例如如何构建度量体系，构建度量体系的时候需要注意哪些事情等等。不过我认为对我而言价值不大。

我认为这本书最秒之处是，从宏观到围观的把度量这件事情、以及和度量有关的人、事、物都说清楚了。告诉你思考的方式，然后也无需多言了。

遗憾的地方也不是没有，例如关于价值的部分，在书中虽有提及我认为意犹未尽，并且在书中后面实战部分也没有提及价值度量如何实战。

十一假期在电脑面前作者基本没干别的，把这本书翻来覆去看了几遍，做笔记、思考、整理、到今天总结成文。算是对这几天自己的交待吧。