敏捷开发 是 传奇 or 神话 ?

Posted 2021-04-25 CIO之家

1

敏捷能否解决传统行业适应互联网IT开发敏捷性问题

起源于上世纪九十年代的“敏捷开发”之所以近年来高调江湖行走，是因为“互联网IT”带来的对以传统商业和金融业为代表的很多传统行业的颠覆式冲击。Gartner公司在2015年十大战略技术趋势特别提到的“互联网IT”，在未来三年内它可能颠覆现有企业的业务模式、末端用户的使用习惯和企业IT的基础设施。同时指出：以移动互联网、搜索智能、社交网络和多渠道为核心技术、以客户体验为主导、以全球虚拟化市场为平台的跨界创新数字电商模式(digital commerce)正进一步驱动全球消费化趋势的快速发展。数字电商模式对传统企业的营销理念、组织文化和决策策略产生颠覆性挑战。而数字电商的核心架构便是“互联网IT”。

“互联网IT”是互联网公司把互联网思维、技术架构和云服务输送到企业，使传统企业的IT基础、敏捷性和技术能力得到远程重塑，也就形成了 “互联网规模IT”或“互联网IT”。 “互联网IT”也可称为“企业互联网化”。Gartner2014年预测在未来三年内它可能颠覆现有企业的业务模式、末端用户的使用习惯和企业IT的基础设施，到2017年将成为架构方法的一种，全球50％的企业将使用这种模式，较2013年的不到将10％有较大的增长。

互联网IT旨在建设可扩展（包括内外部可扩展）、低成本、稳定高效的技术架构，其特征包括：

• 拥有成千上万台机器的计算能力

• 只需少数工程师就可以运维大量机器

• 应用可以承载非常高的用户访问量

• 即使有些机器出现故障，应用仍然工作正常

• 应用每天可以升级部署应用好几次

• 刚刚够用的流程和扁平化管理

• 快速向用户交付产品

• 支持开源代码及软件

• 密切合作、高效沟通的组织架构

“互联网IT”是一种在企业内部IT设施上运行的我国球级别计算模式，在多个层次上重新考虑各种定位的关系，具有大型云服务提供商的功能。像Facebook这样的Web-Scale实例，从来就没有“完成”的时候，而是以“敏捷开发”的方式一直处在过程之中。“敏捷开发”意味着更多的迭代，更早更频繁地发布产品更新。强调的是先把东西做出来，而不是像过去那样过于忧虑产品是否完美。它的出现不仅促使开发人员更加快速接近客户需求，让开发者开始更多关注如何加快开发周期，写出更容易实现的代码、更好的用户体验，而不是更多所谓酷炫的功能上。

“敏捷开发方法”与“项目开发方法”的区别在于，项目有独立的产品服务开发目标和开发时间起点终点；而“敏捷开发方法”是在一个既定的短时间内将本应由一个项目组开发的独立产品服务开发任务切分成若干个有关系或没关系的开发任务，并行或迭代开发，这里姑且将大项目或拆分成几个迭代的小项目统称之成为项目级。

成功的敏捷开发非常依赖高水平的CTO协调，或者各大小项目组均有IT开发的“江湖高手”,沟通协调成本其实很高。由于单个项目组可能缺乏对项目目标的整体判断、理解不清迭代间的依赖或调用关系、各迭代系统之间接口标准不清晰等“盲人摸象”的问题，“敏捷开发方法”在促成产品服务快速面市同时带来了很多副产品——缺乏企业级流程、产品和数据标准的竖井式系统，不但有可能使企业家追求超级客户体验的初衷背道而驰，而且后续整合竖井衍生的IT开发成本并不亚于非敏捷开发，其后续质量修复和数据整合分析的麻烦不是一个大数据就可解决的,这就引出新的问题，如何同步提升敏捷开发的质量和效率？

2

“双模IT”能否提升传统行业企业IT开发质量效率？

如今，互联网公司正在尝试为企业提供公共设施云平台，包括移动安全、移动支付、移动社交商务、移动智能搜索、移动地图导航和移动电商平台等。传统企业确实渴望拥有和互联网公司一样的IT能力去进行业务创新，同时提高IT运营效率、降低费用。

Gartner公司指出，企业如想井然有序地实现数字化敏捷性，可同步推行“双模IT” （Bimodal IT)，即目标为可靠性的模式1和目标为敏捷性的模式2并行（见下图）：

企业IT部门可借此采用两种不同的方式来满足企业需求——一个专注于敏捷性和灵活性，另一个以效率、可预测性和循序渐进法为中心。“迭代式增量开发”（IID）有两种形式。最初的IID方法可被视为压缩的瀑布，通常历时8周。这种“高规格IID”适用于模式1——例如，原来的统一软件开发过程（RUP）。第二种IID形式——“IID精简版”或“低规格IID”——涉及到更多同时完成的工作，降低的文件需求和较少的流程形式。它更适合模式2——例如，针对敏捷软件开发的OpenUP和微软解决方案框架（MSF）。

模式1和模式2大体上分别对应“传统IT”（Traditional IT ）和“互联网IT”（Web-scale IT），实行这种“双模IT”对于传统企业在高度互联世界注入敏捷基因，在保持业务稳健性的同时提高数字化悟性，确实是一种可选方案。未来很可能会有更多的企业以亚马逊、谷歌、Facebook等互联网科技巨头的方式去思考、行动和打造应用程序和基础设施，随之而来的更是传统企业的商务模式发生巨变。

若以为仅仅依靠“互联网IT”及“敏捷开发”就能包治创新开发滞后的病状那就有失天真了；尤其是将传统金融与生态金融割裂对立起来的论断可能有失偏颇，对于系统安全性、稳定性要求比较高的传统企业，不可能像互联网企业那样依赖大规模试错，盲目采用缺乏企业级业务架构管控和组件化、标准化支撑的敏捷开发后果，可能做不到提前释放风险，导致风险遗传到上线，就像吃完低质量迭代出的“香蕉”后马上踩上自创的副产品“香蕉皮”（Banana skins，在风险管理领域常以此形容过程失控的操作风险陷阱），产生难以承受的企业声誉损失和后续更昂贵的IT整合成本。

好在Gartner公司给出了配套的防患药方，随着双模IT走向成熟，其成功将从依赖IT转型驱动转化为依赖业务转型驱动，从战术性走到战略性，这个阶段被称为“企业双模”。实现双模IT意味着企业拥有与之相匹配的能力和行为方式，适应互联网基因进化方式的成熟度由低到高，实施过“精益六西格玛管理”或“业务基因组图谱驱动开发”的企业更容易提升到业务驱动，从单个项目敏捷开发走向企业级整合的敏捷性开发，所以应称为“企业级双模”更为贴切。“双模IT”能成为更好的连续统一体，这两种模式才可在企业级业务基因组图谱这同一个旋律下共舞 。但要解决的问题是，在多项目并行或迭代敏捷开发的过程中，避免因为业务部门之间、业务部门与IT部门之间因为缺乏高效协同机制，导致“拉抽屉”式的项目决策拖延不决，导致“谎报军情”（增加缺乏风险优先级评估的过度协调成本）或“贻误军机”（耽误系统面世的市场响应低效率）。

3

“DevOps”能否提升传统企业敏捷性IT开发中的协作效率？

“互联网IT”和“传统IT”不仅在技术上有差异，而且在文化上也有差异。“互联网IT”能够实现持续部署和交付，不单是靠自动化工具，更重要的是依靠流程、组织、文化上面的变革。很多时候，思维方式、文化方面的改变比技术上更重要。同时它也开始影响运维人员更加以客户为中心，这也是出现DevOps的主要原因。开发与运营之间的高效协作配合(DevOps)是实现“互联网IT”配套能力之一：

• DevOps（英文Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

• DevOps的核心观点，鉴于开发人员与运维人员的关注点可能处于对立状态（即开发人员更加关注新技术、新体验，而运维人员更加关注安全、稳定），DevOps鼓励开发部门和运维部门在各自领域工作中尽早通力合作。在DevOps环境中，开发人员和系统管理员会构建一些关系、流程和工具，从而更好的与客户互动，最终提供更好的服务。它更多体现了一种思考方式以及企业文化的建设。

• DevOps保障了敏捷高效：与传统开发方法那种大规模的、不频繁的发布（通常以“季度”或“年”为单位）相比，敏捷方法大大提升了发布频率（通常以“天”或“周”为单位）减少变更范围与传统的瀑布式开发模型相比，采用敏捷或迭代式开发意味着更频繁的发布、每次发布包含的变化更少。

• 新的应用程序和架构方法可以将企业引向营运设计之路。也就是说，IT部门要从一开始就重视如何提高性能和弹性，继而开始重新思考他们的业务支持。将新的软件架构与DevOps风格结合可望成为催化剂，以提高IT部门适应变化的能力。据Gartner公司预测，全球企业CIO的25％至2020年将参与过企业网络规模IT计划，而在2013年只有不到5%的CIO是这样。

事实上，尽管IT敏捷开发模式已经面世多年，然而相当多的“传统企业”和“互联网企业”所使用的敏捷开发方法和DevOps成熟度仍然处于初级阶段，对于敏捷开发是否适合于各种项目类型并不十分清晰。无论是一个大型转型企业项目群内各个项目组的横向协同，还是某一项目的后续纵向修改，由于缺乏“企业级流程、产品和数据标准”，使得开发与运营之间的协作配合(DevOps)难以高效，甚至有的项目因未能在开发过程中及时缓释系统协同风险或修正客户体验缺陷，而将风险和缺陷遗传到运维阶段，导致运维操作风险或用户抱怨投诉。“敏捷开发”不可能像“星际穿越”电影中那样神奇地穿越时空包治不适应“互联网IT”的百病，缺乏整体架构设计的“敏捷开发”仍可能仅仅是“敏捷神话”。事实上，一些领“敏捷开发”潮流的新兴互联网公司，在从单个产品线走向事业群（BG）、乃至整合跨界信息服务平台的时候，也在抱怨遇到“迭代开发”难以处理的数据和流程整合瓶颈，难以快速响应客户综合信息分析和服务的需要。

Gartner公司所强调的“互联网IT”环境下“敏捷开发”和DevOps无疑是发展前景广阔，但同时也需注意到，一些运筹“互联网IT”成熟度较高的企业和银行系统开发和运维成功实践表明，在企业级业务架构和技术架构对接管理的基础上，采用企业级业务基因组图谱驱动的企业级敏捷开发及其DevOps，较之竖井模式的敏捷开发及其DevOps，能够创造出更高质量、更高效率、更可持续的快速创新和精益运维效应。譬如一些商业银行借助“业务流程组件化管理”（Component Business Model，CBM）技术，搭建起业务流程创新和IT应用架构实现之间的桥梁，大幅度提高了组合产品的研发、分销、交易和管理效率；借助“面向服务的企业架构”（SOA）技术，创建面向服务、支持创新为导向的、灵活的IT基础架构，使“业务流程、应用架构与基础架构”之间密切协同，实现可迅速组建和配置企业级的、可扩展的业务系统，并实现组件在不同渠道的共享使用，例如涉及客户和员工的数据，不必自己单搞一套竖井，可直接从管理客户或员工信息的组件拿数据和流程，技术接口统一，数据共享，在提高支持产品和服务创新效率的同时大幅度降低业务和IT运维成本。

4

如何可持续地提升传统企业IT开发的敏捷性？

事实上“互联网IT”的灵魂在于以比传统IT更高的投入产出效率支持业务的个性、灵活性、差异性，而业务的这些需要应该是建立在一个最基础的共享业务平台之上，面向市场的不同垂直业务线之间的共性的、优势的东西，如果用横向的系统沉淀到共享平台上，它就形成整个企业生态系统最关键的基础。沉淀的基础流程和基础数据，应像肥沃的土壤能使更多的物种自由生长，这才是符合“高度互联世界”（Hyper-connected World）和“物联网”（IoT, Internet of Things）时代特征的IT生态系统。

仅仅是披上“互联网IT”外衣的信息工程模式敏捷开发往往表面光鲜，大多是从单个项目、单个迭代短期看能够快速灵活，在长期看、整体看难以可持续、可重用发展；而企业工程模式下的“敏捷开发”更能适应“互联网IT”的基本导向，其开发成本和运维成本较之信息工程模式下IT开发（无论是否采用敏捷开发方法）均可大大减少。与此同时，对于业务需求分析人员和IT开发人员的共同客户——使用系统的业务人员而言，则一方面更快速地落实新产品服务面世，实时的获取信息查询分析支持，另一方面，也更容易基于业务基因组图谱界定系统运维及相关流程制度的牵头、协作责任；对于使用系统界面的外部客户，也将更容易获得个性化产品定制和前中后台无缝衔接超级流程用户体验。

传统的“敏捷开发方法”只适合短流程的小应用开发，而不适合大型企业级新建或转型项目群建设。滥用敏捷开发方法是一件非常危险的事，敏捷开发方法不等于敏捷性，提升敏捷性的方法有很多，要甄别项目特性使用。切实重视“高度互联世界”里“快鱼吃慢鱼”式企业基因组图谱及基因重组能力建设的虚拟化企业，才能以更低的成本和更高的效率适应“高度互联世界”的“生态圈金融”跨界价值链整合和市场竞争。

5

提升企业级开发敏捷性的关键“使能者”是谁？

很多互联网企业在“互联网IT”时代运用敏捷开发实现了系统快速上线，快速抢占市场份额。但其中不乏成熟度不高或缺乏业务协同能力的敏捷开发仅逞一时之勇，如果缺乏整体架构管控能力，尽管容易实现某些场景开发迅速上线，却有可能导致端到端客户服务流程缺陷或后续整合成本高昂的后遗症，难以可持续发展。企业如想井然有序地实现数字化敏捷性并不简单，实际上很多互联网企业使用的项目级敏捷开发等于“古董级”，需要进化了。

如果一个企业建立了业务基因图谱及其驱动IT开发的能力，那就意味着这是一个适应互联网IT的虚拟化企业，更容易在全球虚拟化市场中叱咤风云，业务基因组图谱、业务架构师、IT架构师及其配套的IT实施工艺是助力“企业级敏捷性IT开发”的“使能者”。“使能者”中有个关键角色是业务架构师，其作用表现在运用业务基因组图谱迅速解析和评估业务需求可行性，确定项目群内各项目目标、边界及其衔接关系，并与IT架构师对接合作，运用架构原则、标准和工具及时校准同步迭代实施的IT开发项目群接口质量，引导开发人员充分运用企业级业务基因组图谱中的CPC、结构化业务规则表等可重用元素，进行灵活配置开发，大幅度提升开发速度和降低开发成本。

企业级敏捷性IT开发与项目级敏捷开发的区别是，业务架构师能更及时做出企业级、跨组件或跨项目的业务架构决策，大幅度减少了项目级敏捷开发受制于跨部门协商的“折返跑”成本，并随时衔接业务人员确认迭代设计成果的可用性；而项目级的敏捷开发事实上往往是IT人员孤军奋战，项目群的IT人员每天晚上加班开会沟通，往往会依赖大规模试错。企业级敏捷性IT开发非常适合于承担金融安全社会责任的商业银行（当然并不限于商业银行），因商业银行的IT开发质量管控必须确保项目迭代开发过程中及时识别、评估并提前释放风险，避免风险遗传到上线。实时智能银行系统是“战略-业务-信息技术”一体化的企业级工程，采用的是新的思想和方法，这套思想和方法不单单是系统建设方法，也是银行转型的方法，实时智能的系统设计要体现业务基因驱动开发的转型宗旨。

面对“互联网IT”所带来的挑战和机遇，一些国家的传统企业和银行已经开始实践基础设施、企业文化和技术架构互联网化。无论从互联网架构、电商平台、移动平台甚至客户渠道等，诸多互联网公司与传统企业积极合作，并成功组建战略联盟直接颠覆市场游戏规则，在跨界“媒介”融合的价值链“场景”上，灵活运用“客户、产品、渠道、服务”组合创造出基于定位市场的超级客户“体验”，以灵活的方式支持个性化、智能化的“杀手级”应用（Killers app），提高客户粘性。

总之，无论对是否主动或被动被划入传统行业的商业银行而言，还是对新兴互联网金融企业而言，都似应避免机械地将“客户、产品、渠道、服务”界定为“传统金融”，并将之与以“场景、媒介和体验”为代表的“生态金融”人为对立起来。所以，似应客观辨识披上“IT互联网”外衣的“敏捷神话”，小心踩上“神似”敏捷的“香蕉皮”，才能创建高度互联世界靠口碑传播的“杀手级”应用和超级客户体验“传奇”。

（本文摘自中国金融出版社发行的《实时智能银行》一书，作者系中国建设银行股份有限公司产品创新与管理部副总经理）

延伸阅读

• 
  

• 
  

• 
  

昨日热文

• 
  

• 
  

• 
  

 Tip:输入关键字 大数据 可以获得更多内容

CIO之家-CIO的知识库

点击下方“阅读原文”每天都有精彩新发现