《精益软件度量》之度量对象模型

封面

“应当仔细地观察，为的是理解；应当努力地理解，为的是行动。” 

                                                ——罗曼·罗兰（1866—1944）

在讨论具体的度量指标之前，需要先定义和描述被度量的对象。一个开发组织中被度量的对象主要包含两个部分：交付流程、交付对象。另一个系统性的要素是交付对象在流程里各个阶段的度量边界。

1. 交付流程模型

精益里面一个重要的流程模型是看板系统。一个看板系统的容量大小是被事先定义的，这个容量是用系统所正在处理的卡片总数代表。一个系统的卡片数量其实也代表了这个系统所允许的半成品（WIP）的最大数量。

精益系统应该是个拉动（Pull）型的系统，卡片的作用其实是一个信号机制。

多团队协同看板

看板系统希望达成的效果如下：

（1）通过数量有限的卡片，避免在整个生产系统中出现过载的情况，从而保障需求和团队交付速率之间的平衡。

（2）通过可视化的方式，迅速发现任何环节出现瓶颈，以便及时干预。

这个过程中，每个人在同一个时间应该只工作在一个卡片上。

从度量的角度来讲，我们要研究的就是这个精益系统的以下内容：

•交付价值。

•周转速度——响应周期。

•运转效率——交付速率。

•可靠性——质量。

•系统能力—个人和组织。

2. 交付对象模型

估算容易受锚定偏见/基准点偏见（anchoring bias）影响。

锚定偏见是心理上的一种经验性的或是启示性的作用，会对人们的评估结果造成影响。

在软件的工作量评估当中产生的结果就是，不管一个功能实际的大小如何，人们通常在估算的时候，倾向使结果靠近前面己经估算的功能的大小量级上。那么估算一组大小相差极大的功能，其结果就很容易受到这种偏见的影响。比如我们刚刚估算一个大约3000行代码的功能，后面马上要估算的一个功能比起前面一个小很多，我们通常倾向于至少估个800行或是至少500行，不会太情愿放个200行的数字。

敏捷开发提倡以端到端的方式划分交付的对象，期望每个划分出来的交付对象必须能够为软件的用户（不管用户是一个自然人还是另一个存在交互关系的系统）提供直接的价值，为此还提出了划分用户故事的INVEST原则。

Extreme Programming（极限编程）的实践者大多使用用户故事（User Story）描述客户需求。关注的是“谁”，“要做什么”，“为什么”。

Scrum定义的Product Backlog是一个按优先级排序的需求列表，但却没有定义backlog里的需求是在什么样的粒度上，以什么形式描述，因此实践者一般都从其他流派借来了需求的发现、分析和描述方法。

在《Agile Software Requirements》一书中，Dean Leffingwell尝试着梳理敏捷理念下的需求管理体系，使其能够适应不同规模、类型的开发场景。其中一个重要的做法是把软件开发组织处理的工作单元分成了4个层面：投资主题（Investment themes）-Epic-特性-用户故事。

3. 度量的边界——DoD（Definition of Done）

根据Dhaval Panchal在Scrum联盟发表的一篇文章上的说法，DoD（Definition of Done）是软件生产所需活动的一个检查列表。这些活动可能包括：需求澄清、功能设计、编码、单元测试、功能测试、联调、集成测试，还有一些我们暂时在这里没有考虑的活动，在生命周期中靠前的有需求的发现、体验的设计，往后靠还有部署、线上反馈等相关的活动.

DoD引导开发行为

举例，电信设备供应商的软件团队采纳敏捷实践的时候，推荐的DOD：

•以单元测试作为用户故事级别的DoD；

•以功能测试作为迭代级别的DoD；

•其他质量保障活动，只能暂时在发布级别做。

对于DoD的定义并不是一成不变的。因为随着团队技能的扩展，更有效的工具和框架的引入，测试、构建基础设施的完善，提前完成更多质量保障活动的投资收益平衡点是在移动的。

拓展DoD在不同层面的范围

团队应该对DoD的定义达成共识，并将其明确地记录下来，严格执行。随着团队交付能力的提升，DoD应该逐渐演进。在这个演进过程中，度量体系起到的作用是牵引团队。

（1）拓展DoD的范围：提高用户故事、迭代的验证级别。

（2）提高流程和质量可靠性：减少联调、系统测试周期的不确定性对交付时间点的影响。

（3）降低缺陷的修复成本：提前发现和去除潜在问题和缺陷。

小结

本次阅读《精益软件度量——实践者的观察与思考》的第五章，主要讲述了交付流程、交付对象和度量的边界。提及了评估中的锚定偏见/基准点偏见现象，值得注意。另外强调DOD的分层次定义，团队达成共识，并不断演进。