精益敏捷开发: 轻量级度量

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.  平均多长时间可发现一个新的缺陷:驱动测试人员提升自动化测试与手工测试的效率。唯有测试效率提升了, 产品质量方能获得保证。

结论:

  精益敏捷开发的度量指标主要目的是希望, 项目经理不要再追求浮而不实的表象数据, 而能真正经由轻量级的度量指标, 做好 “数据管理”, 驱动团队去做真正该做的事。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏大数据挖掘DT机器学习

大数据架构和模式(三)——理解大数据解决方案的架构层

作者:Divakar Mysore等 来源:DeveloperWorks 摘要:大数据解决方案的逻辑层可以帮助定义和分类各个必要的组件,大数据解决方案需要使用...

3624
来自专栏IT大咖说

为什么大数据需要敏捷思维?

内容来源:2018 年 09 月 08 日,宜信大数据技术专家卢山巍在“2018开源数据库论坛暨首届MariaDB中国用户者大会”进行《敏捷大数据实践与开源赋能...

2282
来自专栏云计算D1net

超融合设备如何影响私有云部署

超融合设备为构建云计算基础设施提供了低风险的选择。这些预集成系统包括商业化的服务器和多个驱动器,以及允许在计算集群上共享这些驱动器的必要软件。 对于硬件专业知识...

44012
来自专栏about云

企业生产环境为什么选择使用Cloudera Manager

看到About云中很多成员,特别是初级入门Hadoop成员,当然也包括已经工作的成员,经常会遇到Cloudera的问题。About云邀请了鸟叔,一线资深大数据工...

2023
来自专栏腾讯移动品质中心TMQ的专栏

腾讯TMQ在线沙龙|腾讯手机管家iOS测试实战

腾讯手机管家iOS测试实战 活动时间:2016年11月10日 QQ群视频交流 活动介绍:TMQ在线沙龙第十二期分享 本次分享的主题是老司机给大家分享腾讯手机管家...

2785
来自专栏携程技术中心

干货 | 携程机票无线测试技术与效能提升

作者简介 罗昭君,携程机票无线高级测试经理,负责机票移动端功能测试、自动化测试、平台开发等。从事开发、测试工作近12年,先后在阿里巴巴、携程任职。 一、敏捷下移...

3105
来自专栏DevOps时代的专栏

手把手教您构建自己的 DevOps 流水线

持续交付是一组能够帮助软件开发团队极大的提高其软件交付的速度和质量的模式和最佳实践组成。

2141
来自专栏程序猿DD

请不要在“微服务”的狂热中迷失自我!

2017年是“微服务”疯狂的一年,如同股灾前的狂欢,各种不同行业的技术团队都在宣讲着自己微服务实践的道路。然而大家是否有反思过自己真的在玩“微服务”吗?您真的在...

4345
来自专栏技术墨客

multi-tenant solution(多租户方案)说明

今天在研究vertx-Metrics时碰到了一个multi-tenant solution的概念,特此整理记录相关资料。

2742
来自专栏DevOps时代的专栏

顾宇:成功的微服务的技术特征及其反思

在上一篇文章里,我们介绍了如何定义一个微服务改造的成功,并介绍了落地成功的微服务组织结构有哪些特征。这篇文章我们来介绍一下成功的微服务的技术特征以及我们在微服务...

1122

扫码关注云+社区

领取腾讯云代金券