"应当仔细地观察,为的是理解;应当努力地理解,为的是行动."
--罗曼 . 罗兰(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 的分层次定义,团队达成共识,并不断演进.
来源: http://www.jianshu.com/p/f7a8ae705c70