BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

敏捷实践效果量化分析

| 作者 Ben Linders 关注 27 他的粉丝 ,译者 郑柯 关注 3 他的粉丝 发布于 2014年9月24日. 估计阅读时间: 16 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

利用 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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT