Scrum是否适用于金融电信行业？-InfoQ

【编者按】许多人认为像 Scrum 这样的轻量级框架只适用于互联网这样“小而快”的行业，而在电信金融这样“大而笨重”的行业中，并不适用。为此，InfoQ 中文站特地邀请了行业内的一些实践者和咨询师，来分享他们自己的体会和看法。

参与这次虚拟座谈会的嘉宾包括：

徐毅：上海惠普资深敏捷顾问，曾任诺基亚西门子网络全球敏捷及精益转型部门顾问。

朱薇：交通银行软件开发中心项目经理，Scrum 推动者。

吴穹：独立敏捷咨询师，曾多次服务于电信金融保险行业。

肖鹏：ThoughtWorks 咨询师，曾服务于大型电信公司。

InfoQ：很多人认为金融电信业不适合搞敏捷，以你的自身经验来说，你觉得适合吗？

徐毅：我觉得合适。金融电信业相对目前蓬勃发展的互联网行业而言，采用的技术相对落后，多采用重型软件开发方法，产品开发所涉及的人员为数众多，这恰恰需要敏捷来解除束缚释放出潜藏的巨大生产力。

我来自电信业（前雇主），我们所服务的是世界各地的电信运营商，由于他们所面临的商业环境发生变化，客户需求不断升级以及变得多样化，面临着 3C 融合带来的压力，这一切都需要我们能提高产品交付速度，快速响应客户需求，同时保持产品的高质量。而这些恰恰是正确地、切实地进行敏捷转型后所能够带来的好处。。。。

我不知道我还应该如何回答这个问题，这让我非常的纠结，敏捷就是开发软件的更好方法，还有什么不适合的吗。其实非常简单地问一句“你们想要改进你们的软件开发吗？”只要答案是肯定的，那就要去做，没有什么适合不适合之说。

当然，可能有的时候有的情况下有一段时间有一些需求会很固定，没有什么变动，即使在这种情况下，敏捷所提倡的跨职能特性团队也能够增强不同职能工程师之间的交流和合作，从而产出质量更高的产品；也许团队的互相合作已经很好了，那么完善单元测试的覆盖率，使用测试驱动开发等一些开发方式，都可以提高代码的质量，降低产品后期维护的难度和开销；或者搭建出一套持续集成系统也不错啊，可以获得实时的反馈，知道产品的质量状况，需求完成的进度等等各种信息。

朱薇：我觉得是否适合敏捷开发与行业没有太大关系，而主要与项目的类型有关。以下两种是我觉得不适合敏捷开发，或者说敏捷带来的好处没有那么明显的项目。

有外部依赖的系统。比如分析型的报表系统，经常需要依赖上游系统的完成。除非将上游系统的项目也纳入到 Scrum 中，并且商量好同步开发的进度，而且上游系统的开发进度不能有延迟。否则下游系统的实现常常受制于上游，很难实现敏捷。

对于功能实现范围及上线时间没有太多谈判可能的。比如用于上报监管机构数据的系统，这种项目范围基本是相当固定的，对于每个模块没有很分明的优先级，对于上线时间的要求也是整体性的。此类项目不能实现 Scrum 一些特定的好处，比如在额定时间内实现有更大商业价值的功能，或者分模块分批上线，让用户更早体验到更多新功能以便抢占市场。

金融业有很多项目是不落在以上区间的，这种项目相对就会适合敏捷开发模式。

吴穹：我对敏捷的定义是这样的：（软件行业的）敏捷就是以切合软件开发本质特征为导向、以减少浪费为手段、以加速交付业务价值并快速获取反馈为目的来对软件发布流程进行逐步优化。

根据这个定义，可以看到金融业、电信也都需要大规模的软件开发，因此，它们同样需要敏捷这是毋庸置疑的，而且，越大规模的团队，其实浪费越多，实施敏捷的效果会越明显。

许多人往往将敏捷狭隘地理解为“裸奔”，快速交付，牺牲质量，因此，我们才常常听到这样的问题。

肖鹏：对于电信业来说，我觉得不存在适合不适合的问题，而是具体到每个企业自己要不要做的问题。为什么这么说呢？国内最大的电信设备制造商和运营商都已经行动起来了，而且取得了比较明显的成果。从全球范围来看情况也差不多。

我确实接触过很多人对于敏捷的适用范围持怀疑态度。他们的担心在于，从运营的角度来说拥抱变化之后技术成本不可控；从交付的角度来说交付周期不可控。但是市场竞争和变化越来越激烈，导致运营和交付团队不得不面对更大的压力——快速响应市场成为业务发展的硬性要求。

敏捷方法从诞生起就致力于解决频繁变化所以引入的成本和风险。我们确实看到除了电信设备制造商、软件集成商和电信运营商之外，其他的较为传统的行业，比如电力业、保险业等也在积极地尝试敏捷转型。所以，我们认为行业和领域并不是敏捷是否合适的决定因素。只要是市场和业务对于软件变化和交付有强烈需求的行业和领域，敏捷的价值就能够最大化地得以体现。

InfoQ: 金融电信也需要为敏捷实施做哪些改变吗？

徐毅：敏捷的背后其实是一种文化，也即是敏捷宣言中所描述的价值观以及原则。这意味着如果企业的文化和敏捷所隐含的文化差别较大的话，会需要付出比较大的努力才能产生很好的联动效应，使敏捷的各种实践结合起来发挥最大的效果。当然，不改变文化也能够使用一些敏捷的实践并从中获益，但会很快地遇到瓶颈。

改变会来自于各个方面，有形的例如办公室布局的重新设置（墙壁、桌椅、白板等），无形的例如管理者甚至基层工作者思考及解决问题的思路；和管理相关的可能包括，角色（请注意不是“职位”）的设置和职责的分布，例如 Scrum 所提出的三种角色，例如取消项目经理这个职位；团队层面的，可能包括如何写代码、做测试，可能是每天干活的顺序和方法会改变，可能是提问题的方式方法甚至问题本身的改变，以及团队间合作的方式；各种各样。

朱薇：首先要得到管理层面的支持。Scrum 的顺利开展有三方面因素是依赖于中高级管理层观念的改变以及相应政策和资源的支持。

人员支持。首先尽量保证所有的项目成员是全职在一个项目中，尤其是针对开发人员而言。其次，安排的技术人员需要拥有相应技术较为熟练的开发技能。再者，项目组成员以稳定为佳。最后，管理层要做到尽量少地直接打扰 Scrum 组的项目人员。以上问题在我们试点项目中尤其突出。回顾会议中，几个项目不约而同反应，有些项目组成员同时做 A 项目的开发和 B 项目的项目管理，开发 A 项目过程中频频被 B 项目的电话打断思路，有时候又会被经理叫去处理额外的 C 问题，导致开发计划经常被打乱，不同事务间切换所用时间变长，效率降低。另外也有人员反应，在进入 Sprint 开发前，对需要使用的技术不是很熟悉，造成边开发边摸索的情况，往往造成开发所需时间不可控，最终导致 Sprint 失败。

软件资源支持。如让项目人员坐在同一个区域，提供所有项目相关人员统一的交流工具，提供自动化测试及集成工具等。“工欲善其事，必先利其器”，比如自动化测试工具可以大大降低人力测试的成本，对提高软件开发效率是相当有用的。

相关政策的支持。很多公司在开发项目的时候使用的是 CMMI 的流程规范，每个阶段过程都有规定的文档产出物，之后还有阶段评审。这个思想和 Scrum 开发中“只写必要的文档”的思想在某种程度上不是很一致。所以，需要管理层在试点过程中，放松一部分的限制，以便在实践中得出，什么活动和文档是必须的、适合公司实际情况的，又有哪些是优先级较低，可以缩减或者以能以另外一种更简便的方式代替的。

其次需要项目实施人员观念的转变，积极地参与。

工作态度的转变。Scrum 强调人员的积极性，提倡由项目人员自行认领每天要做的工作。这就要求项目人员摒除惰性，以主人翁的态度来面对每天的工作。信任是互相的，希望管理层放权，自己就要拿出可以自我管理的态度来证明。

提高自身工作技能。在进入 Sprint 开发前，自身的技术还不熟练，会大大影响开发效率，加大 Sprint 失败的可能性。所以，对于需要使用新技术的项目，项目人员本身不能等到开始开发后才开始学习技能，而是在项目开始前就做准备，有一定程度的累积。

遵守项目的 Scrum 规定。每个项目在 Scrum 开始前，都需要制定一份适合本公司及本项目的 Scrum 规定，这个是保证 Scrum 顺利开展的规章，需要得到每个成员的重视。

总体而言，Scrum 更适合自上而下的推动，这样推进的速度和成功率都会更大。

吴穹：每个团队的情况有所不同，但是，总体而言，都要加速反馈，加快价值的交付速度。但是，具体到每个团队，阻碍他们快速交付价值的障碍会有所不同，因此，要因团队而变。另外，金融电信业的质量成本比互联网行业要高很多（想象一下，如果一个电信公司需要为 10000 台 W-CDMA 设备升级软件来修复一个严重缺陷是什么样的成本）。这样高的质量成本使得团队倾向于做大量的质量保证活动，这些活动里面有一些是有效地，有一些是可以改进的，而有一些则可能是浪费，如何恰当的、高效地进行这些质量活动，往往是金融电信业敏捷的关键。

肖鹏：最主要的是思想的变化。敏捷开发的核心思想是面向交付，虽然所有的开发方法都可以说是以交付为目的的，但是只有敏捷方法要求以交付条件驱动开发过程（TDD），只有敏捷方法强调尽早地交付可运行的软件。转变这个思想，关键是主动分析开发活动中哪些是对交付有益的，哪些是浪费。
另外就是工作方式的变化，比如各部门之间的协作和沟通会更加频繁，对于效率的要求也相应提高。工作方式的变化是直接影响每个人的。在有些组织内，这些变化的难度特别大，因为很多人都不愿意尝试新的工作方式。
其他方面的变化主要集中在敏捷的具体实践上面，这里就不展开说了。

InfoQ：那敏捷是否真正给你们带来了好处？（仅针对企业内部实践者，不包含外部咨询师的回答）

徐毅：当然。我不敢代表前公司的所有员工，但是从我所了解到的信息，敏捷带来的变化是利大于弊。最为人所知的那个大部门转型更接近于休克疗法，转型过程中有一段阵痛期，但是我从质量经理处了解到的信息是后来的发布各方面数据都在提升，例如发布到市场的时间间隔，版本交付后客户提交的 bug 数，自动化覆盖率，内部版本发布的速度等等。

个人的角度，我更欣慰的是看到很多人真正的了解了敏捷，并加入到推动的行列中来。而这些人从一开始是持怀疑或观望态度的，他们来自于软件开发的各个阶段、角色，想要改善研发的状况，他们对敏捷接受或欢迎的程度各不相同，但在漫长的岁月过去之后，他们却留了下来，愿意继续坚持使用敏捷的方法和实践。而人才，正是软件开发的关键所在。

朱薇：我们发现 Scrum 给我们带来的好处有以下几点：1. 每日站会是一个值得提倡的内容，它加强了项目组成员间的交流，每个人都更容易知道每天其他人在做什么，进度如何，遇到了什么困难。对自己的工作也有一个激励作用，而 10 分钟的会议也不会占用太多开发时间。2. 白板的展示，加强了大家团队的观念。白板是以项目为单位展现在其他人眼中的，有助于项目人员把自己完全融入团队，提高主人翁意识。3. 用户反映，能够更早地看到系统原型，有助于帮助他们及时发现系统与当初设想的需求不符合的地方，也有助于他们发现自己所提需求不合理的地方，他们十分赞同这种实现方式。

【编者小结】也许如互联网这样的行业本性更“敏捷”一些，所以能更快地开始实践 Scrum，也能更快地看到它所带来的好处。而像电信金融这样本性“笨重”的行业，会需要更大的努力去接受新思维、采取新实践，因此也需要更长的时间才能见到 Scrum 所带来的好处。但正如嘉宾们说所，只要你有意愿改进软件开发方法，那就去做吧！持续改进与行业本身无关！

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。