来QCon北京,现场感受“纯血鸿蒙”的魅力!席位有限,抓紧报名 了解详情
写点什么

敏捷实践效果量化分析

  • 2014-09-23
  • 本文字数:5177 字

    阅读完需:约 17 分钟

利用 Rally 软件公司的敏捷应用生命周期管理(ALM) 平台软件收集的数据,Rally 软件公司和卡内基·梅隆大学软件工程学院(SEI) 正在研究敏捷软件开发实践的影响效果。该研究的报告在这里可以看到。

InfoQ:你们为什么要量化研究敏捷的影响?

Larry:首先让我作为研究者回答这个问题。关于敏捷实践的出色效果,我们现在得到的很多信息,都是轶事形式,或者适用范围有限。因为 Rally 交付的是多租户的 SaaS 产品,所以我们有独特优势,可以进行这样全面的研究。我们可以访问 13,000 个不具名团队的数据,他们都使用敏捷实践,而且覆盖众多领域和背景,也就是说,我们可以达成统计显著性、通用性,以及对权衡过程的量化,这都是现有文献缺乏的。

现在,让我换个角度,作为希望交付更好、更快、更低成本的软件的人。大部分组织认为:如果没有大量具体证据,很难同意组织做出大规模转变,比如没有数据可以整合到公司的业务模型中,可以用于证明转变的成本和对公司运营底线的潜在伤害。该研究和我们正在进行的其他研究一起,就是要解决这些问题。

Jim: 还没有人进行过敏捷方法和实践的学术研究。尽管很多案例和调查数据指出,使用敏捷可以带来改善;我们希望更进一步地指出:哪些实践和实践组合、在哪些上下文中效果最佳。

InfoQ:为什么 Rally 和 SEI 要合作进行该研究?

Larry: 我曾经在卡内基·梅隆大学(SEI 所在地)从事研究者工作,当时 Watts Humphrey(时任 SEI 院士)首先提出,应该将量化思考重新引入到敏捷开发的世界中,虽然他们之前将度量方法视为妖魔鬼怪,退避三舍。在 2009 年的敏捷大会上,我就此想法做了一个演讲,然后得到三个工作邀请。我选择为 Rally 工作,因为他们是行业领导者,而数据又来自多租户的 SaaS 软件栈,十分诱惑我这样的研究者。我们最终得到了一个度量框架:软件开发效能指数(SDPI),其基本结构与 SEI 长久以来研究得出的多种度量框架有很多相同之处。所以,自然而然,我们就在一起工作了。Rally 能够接触数据。SEI 能够接触软件工程度量领域中世界上最好的思想领导者。

Jim: 当时, Larry 联系我们,讨论一起进行度量方面的研究,我们马上认识到:这是一个很好的机会,可以用经验主义的方式,验证、强化敏捷对于提升效率的某些说法。Rally 对这个研究提供的合作很值得称赞。总是有各种障碍阻止组织分享数据,所以我们非常欢迎这个来自 Rally 的机会。

InfoQ:你们使用了哪些数据供研究使用?又是如何分析的?

Larry: Rally 软件可以用来管理敏捷开发项目。我们可以查看 Rally 中的历史数据,得出效能指标(performance metrics),比如一个中等大小的工作项需要多久才能从“开发中”过渡到“可接受”状态。我们可以得到多种效能指标,涵盖工作效率、可预测性、质量和响应程度。而且,我们可以得出行为指标(behavior metrics),比如有多少个工作项同时处于“开发中”状态,或者看看专为一个团队工作的人完成了多少工作,以及同时为多个团队服务的人完成了多少工作。

Jim: Rally 收集软件开发的原始数据,我们也希望得到多种属性的数据,用于评估实践。为了完成全面分析,我们需要得到组织研发的背景资料,以匹配实际数据。虽然我们得到许可,可以收集一些团队的数据,包括使用了哪些实践、应用类型等等,但对本次研究,还是有些需要的数据不能及时到位。目前我们还在收集这些信息,希望能为将来的研究所用。

我们的确遇到一些数据问题:最大的问题是客户群的变动幅度。对于几乎所有的实际开发数据来说,这样的变动幅度很难建立严格的统计模型,难以分析不同变量之间的关系。也就是说,如果 n 是个很大的数字,一切都能体现出统计显著性,但是难以提供有效的可预测性,因为偏态分布太严重,方差太大。虽然我们使用了多种数据变换方法,以解决这些问题,如果没有对应的属性数据对全体样本分类,我们还是无法取得太多进展。

Rally 的工具设计得很灵活,可以整合到多种工作流中,而不是强制用户让他们的工作流程符合工具的设计。这种灵活性对于我们这样的研究来说,是很好的差异来源,因为可以限制我们针对产生数据的工作流做出的假设。因此,数据中的差异水平曾经是个问题,因为如果没有对于实践模式(即工作流设计)的信息,我们就无法做出合理推论,推导出哪些团队模式对应数据中的效能模式。

InfoQ:你们在报告中使用了“软件开发效能指数(SDPI)”度量框架,提供对工作效率、可预测性、质量和响应程度的深入分析。为什么这些指标如此重要,需要加以度量?

Larry: 构成一个完整、平衡的测量体系,需要 7 个维度,这只是其中 4 个。目前我们在加入客户 / 项目干系人满意度和员工参与程度。以后我们还打算加入我称之为“构建正确之物(build-the-right-thing)” 的指标。你可以在今年出版的“Impact of Agile Quantified - A De-Mystery Thriller”中看到。

InfoQ:研究中得出一个结论:当人们只为一个团队工作时,团队的工作效率就会提升。能否详细解释一下?

Jim: 当我们研究工作效率、质量或是可预测性时,我们看到相对稳定团队的中位数和平均数数据都有提升。但是这种差异被数据的变异多样性遮蔽了,因为数据产生于多种不同的工作流模式。

Larry: 一个团队,它的工作几乎 100% 都是由专属于它的人完成;另一个团队,只有 50% 的工作由专属于它的人完成;前者的工作效率是后者的两倍。

使用敏捷之前,人们认为团队中应该配备有特定技能的人,这些特定技能需要得到最大化利用,因此这些人会身兼多个项目。然而,由于任务切换和责任等原因,每个人身上背的项目多一个,他的效率就会呈现指数级降低。参与两个项目,只能发挥 80%,参与三个项目,只能发挥 60%……以此类推。推进到敏捷的做法,团队只需要响应不断变更的需求(这是敏捷的定义),他们不需要“拥有”全部技能。同时,让一个人只属于一个团队,团队就会迅速走上快车道。即使你的“专家”只能在一半时间发挥他们的特张,把他们只放在一个团队里面还是效果更好。

InfoQ:与之相关的结论就是,不稳定的团队会降低效率?组织应该怎么做,才能预防必须要改变团队构成?

Larry: 我们发现:一般来说,稳定的团队效率要高 60%,可预测性高 40%,响应程度高 60%。

使用敏捷之前,人们的想法是:项目结束时,要将团队拆散;新项目开始,再组建新团队。可是团队要融合在一起并达到最佳效率,这需要时间。同时,因为开始和结束项目从来不会同时发生,几乎可以肯定:在项目开始和结束时,总会有些人不是一直呆在这个团队,而这都是团队效能最关键的时刻。

所以,首要之事,就是让已经达到最高效率、而且凝聚力强的团队接手新项目,而不是为每个项目构建新团队,从而还要再经历一次“初起炉灶—暴风骤雨—照本宣科—大放光彩(forming, storming, norming, performing )”的循环。然而,不是所有的稳定性问题都源于公司决策。员工离职了,你必须要找人替换。对于这个问题,遵循传统的 HR 思考很重要:让现有员工开心,要比寻找新员工更好。

Jim:我们发现:不只是敏捷,各种软件开发环境中都有切分团队的事情。各种组织都在想尽办法,发现、招募、留住各种专业人才,过去十年也有不少值得注意的软件开发成功案例。敏捷作为一种思想,可以视为解决低效软件开发的一种方法,其目的就是要为团队授权,让有才能的人充分发挥。所以,任何与这种团队核心理念相龃龉的事情,我认为都背离了敏捷原则。

InfoQ:有些团队使用故事点数估算,有些使用任务小时数,有的两种都用。同时使用两种方法,能够为团队带来哪些好处?

Larry: 数据显示,一般来说,使用两种方法的团队,在发布版本缺陷密度上的表现有 40% 的提升。原因在于,将工作拆分为任务并加以估算,这种行为可以让人更深入思考设计和需要的功能。团队内部对工作会有更多讨论,大家得以分享彼此的理解。这种更多思考和共享的理解,可以预防缺陷流入产品。

同时要指出:我们的研究也得出结论,如果考虑工作效率、响应程度和可预测性,没有进行任务分解和基于小时的估算的团队,整体表现更好。不过,这也可能是因为成熟团队才会采取这种方式,而最终结果源于团队的成熟。

InfoQ:你们的研究也调查了减少在制品(WIP)的效果。在制品更少,能够带来质量显著提升,比如产品中的缺陷更少。能否详细说明?

Jim: 如果将在制品数目进行统计上的标准化,我们会发现,在制品的变化相当于质量指标。但我同时也对工作类型的比率变化感兴趣,不管是用故事还是缺陷。比率的变化,可能是更有效的团队度量指标。发现有意义而且有作用的方式,将数据加以统计上的标准化,这是本次研究的工作方向之一,而且会持续下去。举个例子,你愿意用何种方式计算软件产品的“规模”……类似的讨论没有止境。

Larry: 在制品对软件质量竟有如此重大影响,我们当时也很惊讶。我们当初以为:对响应程度会有很大影响,可能会影响一些效率和质量;但是我们看到:通过控制在制品,能够对发布产品缺陷密度有更大影响。原因可能在于:干扰更少,任务切换更少,而且能够将精力集中在少数几件事情上,这能带来质量的改善。不过,还有一种理论。竭力控制在制品的团队,在工作过程中,当工作受到阻塞,或者某个队列清空之后,没有其他工作可做,他们可以得到一些喘息时间。在这个喘息时间中,人们会更多思考已完成的工作,并用这些时间来确保产品的更高质量。

InfoQ:基于你们的研究结果,你们推荐哪些实践?是不是有哪些敏捷实践是你们不建议使用的?为什么?

Larry: 第一阶段的研究针对 5 种行为,但我们目前正在研究超过 55 种变量,包括行为、态度、实践、上下文。结果发现:我们关注的某些上下文变量,得到很多人推荐,而这些变量都与具体上下文密切相关。我想说:没有最佳实践,只有适合某个上下文的好实践。【译注:关于最佳实践,推荐 InfoQ 中文站的一篇老文章 http://www.infoq.com/cn/articles/better-best-practices ">《更好的最佳实践》。】

话是那么所,还是有些实践在很多情况下表现优秀。降低你的在制品。保持团队稳定。让大家只为一个团队工作,确保团队是一个“完整团队”,具备交付产品应有的全部技能。有些实践只在某些环境下才能发挥效果,或者只能带来某一个方面的好处,比如可以提升质量,那就有可能导致工作效率方面的妥协。我们现在还没有准备正式对外发布,不过有几个极限编程(XP)方面的工程实践属于这个类别。当然,仅仅从表面上实施一个实践无法达到预期效果。你必须要认真实施,才能享受带来的好处,或是去掉它的负面影响。

对于我不鼓励的实践,很多与文化和人的因素相关。如果你按照传统方式推动度量体系,就很可能伤害敏捷转换的进程,进入度量的“黑暗面”。我已经把某些内容写成了《敏捷度量七宗罪》一文。第一宗罪,就是试图使用度量指标直接驱动行为。正确的做法,是将其用于自我改善和提升的反馈机制。

Jim: 我同意 Larry 的说法,在制品和稳定性很重要,但我们还需要分析不同实践之间互相组合之后的效能。一般来说,在某些关系上,比如相同全部时间的处理能力和缺陷密度上,我们的确看到中位数和平均数在向期望的方向提升,但还是要说,样本差异太大了。考虑到敏捷是一个原则和价值体系,团队和组织可以选择自己构建软件的方式,而度量指标的使用假定了不同实践之间可以互相比较,由此得来的知识可能不太容易直接应用。

InfoQ:对于量化研发实践,未来还会有更多研究吗?

Jim:我们当然会继续研究敏捷实践效果,我们会去比对产品和质量数据与研发上下文的关系。目前,我们正在准备一个提案,研究这些问题。但在所有软件开发的数据背后,有一个同样的问题:在不同应用、系统和组织中,如何让这样的数据具有可比性?将焦点放在敏捷上,能够让我们获得更多更好的理解,理解如何更好地判断软件产品。

Larry:正如我上面说到的,我们现在正在研究 55 个另外的变量。其中某些即将公开发表,包括:不同上下文中的理想迭代长度,哪些地区有表现最佳的软件开发团队,不同上下文中测试人员与开发人员之比,等等等等。我会在六月的 RallyON 大会上分享这些内容,还有五月的 Lean Kanban 大会、六月的敏捷澳洲大会,以及七月的敏捷 2014 大会。

关于受访者

Larry Maccherone是 Rally Software 的分析和研究总监。 在加入 Rally Software 之前,Larry 在卡内基·梅隆大学的软件工程研究院工作了七年,致力于软件工程度量的研究,专精于向敏捷领域重新引入量化理念。他现在带领 Rally 的一支团队,使用大数据技术,取得有趣的结论和敏捷效能指标,并为客户做出更好的决策提供产品。

Jim McCurley是 SEI 软件工程研究院中软件工程度量和分析计划(Software Engineering Measurement & Analysis,SEMA)技术组的资深成员。他在 SEI 长达 17 年,专精数据分析、统计建模、经验研究方法。最近几年,他与多个美国国防部部门一起工作,参与到大规模系统的采购之中。

查看英文原文: Quantifying the Impact of Agile Software Development Practices

2014-09-23 18:192398
用户头像

发布了 479 篇内容, 共 152.0 次阅读, 收获喜欢 47 次。

关注

评论

发布
暂无评论
发现更多内容

想要简单上云?云耀云服务器L实例是你首选

YG科技

SpringBoot3之Web编程

Java 架构 springboot SpringBoot3

【我和openGauss的故事】openGauss 5.0.0企业版两节点CM高可用实践

daydayup

OpenGauss与NVM

daydayup

PoseiSwap 开启“Poseidon”池,治理体系或将全面开启

鳄鱼视界

浅谈贷款的还款金额组成

萌大统领

贷款 还款

云耀云服务器L实例:简单上云,智能不卡顿,性能遥遥领先

平平无奇爱好科技

上云没那么难,华为云云耀云服务器L实例助力中小企业和开发者开启上云第一步

平平无奇爱好科技

【我和openGauss的故事】SpringBoot连接openGauss项目实战

daydayup

PoseiSwap 开启“Poseidon”池,治理体系或将全面开启

威廉META

LangChain系列-01 是什么

无人之路

ChatGPT #LangChain

Qt搭建RTSP服务器

攻城狮Wayne

数字化转型与架构-规划篇|PRD也适用SMART原则?

数字随行

数字化转型

【我和openGauss的故事】openGauss容灾集群搭建过程代码学习记录

daydayup

三步建站,两倍性能!云耀云服务器L实例开启简单上云第一步!

平平无奇爱好科技

PoseiSwap 开启“Poseidon”池,治理体系或将全面开启

股市老人

Programming abstractions in C阅读笔记:p84-p87

codists

PoseiSwap 开启“Poseidon”池,治理体系或将全面开启

EOSdreamer111

技术赋能,在鸿蒙生态下华为互动媒体内容飞轮加速

最新动态

华为云耀云服务器L实例:简单上云,智能不卡顿,让你的业务飞起来!

YG科技

云计算时代,华为云云耀云服务器L实例为何受到企业和开发者青睐

YG科技

简单上云第一步——华为云云耀云服务器L实例

YG科技

BenchmarkSQL 5.0 压测 openGauss 5.0.0 案例分享

daydayup

【我与openGauss的故事系列】openGauss 5.0.0全密态数据库应用小试

daydayup

Go 变量

小万哥

Go 程序员 云原生 后端 开发

简单上云第一步,华为云云耀云服务器L实例助力中小企业与开发者轻松应对多种场景

YG科技

上云简单又不简单,华为云云耀云服务器L实例的用户体验究竟如何?

平平无奇爱好科技

javascript对象基础

timerring

JavaScript

【我和openGauss的故事】在vm中安装openEuler及使用yum安装openGauss

daydayup

【我和openGauss的故事】openEuler20.03上编译安装opengauss-5.0.0

daydayup

【我和openGauss的故事】openGauss集群故障节点替换操作

daydayup

敏捷实践效果量化分析_文化 & 方法_Ben Linders_InfoQ精选文章