敏捷现状调查报告

IT 开发团队如何管理向敏捷方法的过渡

“敏捷现状调查”旨在收集有关企业如何实际实现敏捷技术的信息,其调查对象来自世界各地,共 168 人,他们分别工作在各种不同的商业领域,其中包括政府机构。这些调查对象分享了有关他们如何受益于敏捷方法以及他们仍面临的挑战的详细信息。本文分享从调查中得出的一些总体数据,探讨重要的收益和面临的挑战。

Paul Gorans, 加速解决方案交付实践负责人,GBS 应用服务, IBM

作者照片Paul Gorans 是 IBM Global Business Services 的 Accelerated Solution Delivery Practice 全球领导者。他和他的团队为 “规范敏捷” 提供支持,还与其他 IBM 小组合作将敏捷实践集成到服务和产品实现活动中,并向 IBM Global Business Services 专业人员提供敏捷培训。Paul 拥有 20 多年的 IT 从业经验,他领导实施过多个敏捷项目,分解过敏捷程序,执行过敏捷评估和转型活动。在过去 10 年,他亲自为超过 400 个敏捷客户端机会和活动提供咨询,扩展 IBM 全球敏捷功能,并参与撰写敏捷开发图书和 Forrester 调查。



2012 年 4 月 12 日

关于本调查

小型公司通常在实现敏捷开发上没有太多困难。这不是一项太难的任务。大部分遇到问题的团队都是在更大型的组织级别中。这正是我们花了几年时间尝试帮助客户解决的问题:您如何计划?如何管理您的利益相关者和高层支持者?您如何与敏捷开发团队所依赖的其他团队合作,确保成功交付最终的产品?

当我们与客户交谈时,我们的意图是通过分享我们活动中实用、成熟的经验和实践来帮助人们,他们可应用这些经验和实践来解决其组织的转型问题。我们发现,大部分敏捷团队都在大型组织中,他们需要扩展一个敏捷项目,但面临着文化层面上的挑战。

我们开展敏捷现状调查,是因为我们希望询问敏捷从业者,“您在实际中使用敏捷方法做什么?” 我们还想了解他们在使用敏捷时获得的收益类型(包括他们的组织所实现的收益)以及他们采用敏捷的过程中经历过(或目前正在经历)哪些阻碍。我们将调查范围限制到实际拥有敏捷经验的调查对象。

我们的调查对象包括来自不同领域和不同组织的各种人群。许多人来自非常小的敏捷团队,但也有一些调查对象来自非常大的团队。例如,16% 的人来自拥有 21 个或更多成员的团队,其中很大比例的人来自拥有 100 多名成员的团队。这些信息类似于在传统软件开发组织中找到的统计数据。

有趣的是,受调查者中只有 26% 位于同一个位置,也就是说,大部分人都以某种方式分散在不同地方。1/3 的受调查者表示需要空中旅行才能将整个团队集中在一起。这些细节很重要,因为敏捷社区可能会强调位于相同位置的重要性。但是从总体数据看,我们看到了大量分散的团队组织。

此调查的完整细节,包括源数据和我们询问的原始问题,可在 www.ambysoft.com/surveys/ 上找到。


在实践中使用敏捷方法

我们的调查表明,人们正在监管形势和复杂技术形势下成功地使用敏捷,比如需要遵守标准和政府规定的项目。

受调查者表明敏捷范围大小不一;但是,更大的团队必须修改所应用的一些实践。甚至通用实践(比如举行每日动员会议)也必须进行调整,以反映真实现状。团队需要采用真正规范、完整的生命周期方法,尤其是在解决跨组织实践时,比如 DevOps。

这些结果支持着这样一种想法,敏捷项目应该受企业支配并在企业级实施。项目经理应该与企业架构师合作,遵循现有数据源的常用编码约定。一种成熟的敏捷实现方法会反映您自己所在组织的类型。


敏捷收益

我们调查分析了全部收益。4/5 的调查对象表明,由于他们使用了敏捷技术,他们的交付成果的总体质量得到了改进。同样有 4/5 的人表明最终改善了生产力,提高实用性。2/3 的人表明他们提高了 ROI 并改善了交付速度。而且,所有这些都是与利益相关者紧密合作、迭代式和增量式工作的直接结果,这意味着开发团队构建了利益相关者真正想要的东西,而不是他们指定的东西。

有趣的是,1/3 的受调查者表明,与系统一起提供的文档得到了改进,一半的人表明,他们得到了相同质量水平的文档和系统。大约 80% 的人报告,拥有和以前使用方法得到的同样好或比之前更好质量的文档。您会问,这里的重点是什么?简单来讲,文档是敏捷社区批判了多年的一个东西,但事实上,敏捷文档实践似乎能够提供可靠的结果。

当然,如果无法帮助企业自身变得更加敏捷,全世界的所有技术敏捷性都毫无意义。我们的调查表明,超过 90% 的调查对象表明他们对变化(包括商业环境和业务需求中的变化)做出反映的能力得到了改进。

结果指向了这样一种趋势:软件开发实践的质量与企业的质量一致。频繁的利益相关者互动和紧密的团队协作可能是所有其他敏捷技术的核心。我们相信,如果团队更多地关注规划敏捷、布局利益相关者支持和促进这些收益的实现,利益相关者的满意度将显著提高。可能需要更多的培训,或许通过进一步熟悉在天平的较高一端添加的规范需求来实现,而不是在 Scrum 或 XP 方法中提供的基本培训。


敏捷不仅是基本培训

我们多年来一直在通过注重实效的敏捷、精益且快速的开发方法为客户提供帮助,但在最近两年,我们已将我们规范且可扩展的实践标准化为一种端到端方法,并帮助客户实现它。规范敏捷交付 (Disciplined Agile Delivery, DAD) 是一个流程框架,反映了组织在采用敏捷方法和尝试高效地应用敏捷方法时遇到的现状。DAD 支持比纯敏捷方法更加可靠的工作方法。

因此,我们真正想要问的一个问题是,双向 Certified ScrumMaster (CSM) 课程是否是他们取得成功惟一所需的东西。不到 4% 的受调查者给出肯定的答案,所以我们得出的结论是:它是一个合理的开端,但培训不应该止于此处。

基本的敏捷培训无疑必不可少,但它仅是您的成功必备要素中的冰山一角。当从一个成熟的、具有 DevOps 问题、需要改善的治理、企业级开发环境和企业架构的组织的全盘进行考虑时,您在开始采用可不断扩展来满足这些挑战的敏捷方法时会发现,您需要一个更加成熟、更加规范的方法。


我们也注意到了挑战

有时,好意的精英敏捷顾问会尝试通过他们的敏捷转型来帮助较大型的组织,但他们并不总是具备能力来解决正在发生转变的一些事情。我们的调查证实了这一观点,团队在尝试实现敏捷实践时会面临一些常见的阻碍。这些挑战包括衡量成功、IT 的财务治理与敏捷战略之间的脱节,以及与非敏捷团队合作。

衡量成功

过去 10 年来,IT 组织已与业务分离开,更多地关注成本削减,而不是为业务提供支持。但没有合理地协调业务和 IT,敏捷实践确实没有什么效益。当敏捷拥护者取得了能带来企业支持的进展时,实践本身就会开始提供这种端到端可视性,这意味着责任性,哪怕是在大型组织中也一样。拥有更好的衡量方法和可视性,团队会找到更多共同点来与他们的高管和支持者合作,有望再次将业务和 IT 联合起来。

敏捷实践提供了一种机制来实现此目的。尽管许多人仅从项目级别来考虑它,但您确实有必要考虑组织级别并部署更高级的衡量指标。

财务与敏捷的脱节

几乎有一半受调查者表明,他们的 IT 财务治理方法(项目)与敏捷战略脱节。许多团队反映,他们仍被迫在验收项目时提供详细或准确的评估,老实说,甚至对于传统项目而言这就是一种非常糟糕的实践,更别说敏捷项目。这是公司需要克服的一个严重问题。一般而言,我们仍然会看到业务需求与高效的 IT 治理之间存在很大的脱节。提前索取详细的规范和详细或准确的评估,不是克服这一挑战的办法。

在 IBM,我们开发出了一个名为 DIS Financial 交付的产品来帮助填补这一空白。DIS Financial 交付是一种流程框架,它反映了组织在采用敏捷和尝试高效应用敏捷方法时所面临的现状。

非敏捷团队

几乎 2/3 的调查对象表明,他们的敏捷团队受到了阻碍,因为他们所依赖的其他团队没有采用敏捷方式工作。例如,数据管理小组或质量保证小组采用了一种传统方法,减缓了这些流程并使一些任务变得更加困难。事实上,非敏捷团队为增加了大型组织面临的风险,而不仅仅是敏捷团队的成功所面临的风险,因为非敏捷实践会降低团队和个人的生产力。哪些最终参与多个团队的人,同时是因为他们拥有多个项目中都需要的某些专门技能,这实际上会成为开发团队的瓶颈。这些问题将可能随着时间逐渐消失,但一些组织仍将挣扎一段时间。


最后的思考:IBM 和其他大型敏捷采用成就

IBM 代表着世界上最大型的敏捷采用成就之一。我们不仅在自己的开发团队拥有敏捷方法(我们现在已编写了多部图书并参与过多项敏捷采用案例分析),我们还帮助数百家组织转型到敏捷方法。这是我们的关注重点。我们帮助组织理解敏捷战略和如何高效地采用它们。

我们在 IBM 的许多团队的工作规模相当大,而且开发团队的很大部分人现在都在以敏捷方式工作。IBM Rational Team Concert 是一个由全球分布式敏捷团队为敏捷开发人员构建的一款产品。我们正在主动帮助客户理解 agility@scale。我们的 Rational 和 Global Business Services 敏捷产品为大规模敏捷开发提供了基础。

如果您有机会,请访问 Agile Transformation 专区和 Jazz.net,了解我们正在做的一些真正有趣的事情。对于正在尽力实现规范且大规模的敏捷项目的客户,请联系您的 IBM 代表,我们可以探讨您的具体挑战并定制一项适合您需求的服务活动。


结束语

从敏捷现状调查中我们了解到,相当高比例的调查对象正受益于更高质量的交付成果、更高的实用性、改进的文档、更高的生产力和更高的 ROI。挑战包括确定如何衡量成功,敏捷和财务之间的脱节,以及非敏捷团队所创造的瓶颈。对于那些寻求帮助来解决其难题的人,我们建议求助于 IBM,因为我们已在非常大的规模上采用了敏捷,已帮助过许多其他大型组织迁移到敏捷开发方法。

参考资料

学习

获得产品和技术

  • 获取免费的 Rational 软件工具包系列,了解最新的 IBM Rational 软件开发工具技术文档和资源。
  • 下载更多免费的 IBM Rational 试用版软件,了解 IBM Rational 软件的最新特性。
  • 获取更多 IBM 试用版软件,并熟练掌握来自 DB2®、Lotus®、Tivoli®,以及 WebSphere® 的开发工具和中间件产品,用这些试用版软件开发您的下一个项目。这些试用版软件可以免费直接从 developerWorks 下载。

讨论

  • 加入 developerWorks 中文社区,developerWorks 社区是一个面向全球 IT 专业人员,可以提供博客、书签、wiki、群组、联系、共享和协作等社区功能的专业社交网络社区。
  • 访问 developerWorks 社区上的 敏捷开发小组,在那里您将有机会与更多的开发人员一起交流敏捷开发最佳实践。
  • 加入 IBM 软件下载与技术交流群组,参与在线交流。

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=810092
ArticleTitle=敏捷现状调查报告
publish-date=04122012