2016, 深圳, Ken Fang
前言：
精益敏捷开发以轻量级的文档与团队协作, 提高开发的效率。另一方面, 许多人对于精益敏捷开发在轻量级的文档下, 如何保证开发的质量存在著许多的质疑与困惑。
本文将从 “度量” 的角度, 运用一轻量级度量的方式, 确保团队在精益敏捷开发的过程中, 可同时确保效率与质量。
本文:
此轻量级的度量方式主要的目的是希望: 通过度量驱动团队去做该做的事; 包括：测试用例先行, 逐步提升效率, 同时兼顾效率与产品质量。
1) 测试用例先行 (流程指标)
精益敏捷开发, 期望以表格式的测试用例, 使开发人员可清楚的明白到底要开发什么? 避免开发人员在不完全理解 User Story 的需求或是 User Story 需求不明确的情况下, 进行无谓的开发, 形成不必要的浪费。
所以, 必需经由度量 “开发前测试用例覆盖率”, 以驱动团队需先有测试用例再进行开发。
开发前测试用例覆盖率＝开发前已有测试用例的 User Story总数 / User Story总数
另一方面, 为避免测试用例的设计会形成版本开发的瓶颈, 所以, 必需经由度量 “测试用例设计平均人天”, 以驱动团队提升设计测试用例的效率。
测试用例设计平均人天＝测试用例设计总人天 / 测试用例总数
2) 逐步提升效率 (效率指标)
精益敏捷开发, 团队的效率并不能仅从 User Story 开发的速度来衡量。因为, 仅提升 User Story 开发的速度, 并无法保证版本的整体开发效率的提升。 为何?
当团队的 Sprint Backlog 中代办事项 (User Stories) 的工作量, 远远超出团队所能负荷的工作量时, 则即使 User Story 的开发速度提高了, 但, 也会因各 Sprint 的工作量过重, 而使团队在各 Sprint 中, 能完成所有 User Stories 开发与测试的时间, 依旧会过长, 因而, 导致版本的整体效率无法提升。
精益敏捷开发是以 “平均等待时间 (平均处理周期)” 来衡量开发的效率, 且同时衡量:
1) Sprint Backlog 的 User Story 数 (工作量)
2) User Story 开发, 测试的速度
平均等待时间＝ Sprint Backlog 的 User Story数目 / 每周平均可完成 User Story 的数目 (完成是指开发, 测试完成)
举例： Sprint Backlog 的 User Story 数目: 30
某团队每周平均可完成开发, 测试的 User Stories 数目: 15
平均等待时间: 30/15 ＝ 2 周
所以, “平均等待时间” 便会驱动项目经理要逐步提升效率时; 降低平均等待时间; 除了需提升团队的开发, 测试效率外, 更重要的是, Sprint Backlog 中代办事项 (User Stories) 的工作量 (数目) 需合理化。
3) 同时兼顾效率与产品质量 (质量指标)
精益敏捷开发的质量指标, 主要是以 “缺陷” 驱动团队的开发质量与测试效率。
I. 开发质量:
i. 平均多长时间可修复一个新的缺陷：驱动开发人员不可只开发新需求的 User Stories, 而忽视或不处理缺陷的 User Stories。
ii. 缺陷重新被激活总数目: 缺陷重新被激活指的是开发人员将一缺陷标记为 "已解决", 但实际上并未解决根本, 真正的问题。 缺陷重新被激活总数目, 可驱动开发人员真正针对造成缺陷的根因去解决问题。
II. 测试效率:
i. 平均多长时间可发现一个新的缺陷：驱动测试人员提升自动化测试与手工测试的效率。唯有测试效率提升了, 产品质量方能获得保证。
结论:
精益敏捷开发的度量指标主要目的是希望, 项目经理不要再追求浮而不实的表象数据, 而能真正经由轻量级的度量指标, 做好 “数据管理”, 驱动团队去做真正该做的事。
