2021-11-14 18:56 浏览量:455
敏捷开发
K公司为某银行敏捷开发的功能并不复杂的XX核心系统,在历经多次延期之后终于投产。回顾3月初的一则新闻:因 IT 项目失败,M公司向其保险公司客户DirectLine赔偿三千六百万英镑,之前该公司指控M公司搞砸了一个影响深远的基于敏捷方法的保险平台IT项目。比较这两个敏捷项目,前者是交易系统,最后投产了(如果发生在英国,K公司是否可能面临诉讼?),后者是数据平台,已成为一个数据平台项目失败的经典案例。M公司还搞砸了另一家保险公司Co-Op的敏捷项目。
他们做错了什么?
他们都破坏了敏捷宣言的第一原则:首要任务是通过尽早并持续交付有价值的软件来满足客户的需求。这一点是事实,无可争议。
他们为此辩解:甲方发出了不必要的、变更范围的变更请求。从传统软件工程管理的角度看,IT方某些理由貌似很充分:甲方客户负责需求,乙方公司负责按需求实施,但是对于一个号称敏捷的项目,这样的理由显得苍白无力。
即他们破坏了敏捷宣言的第二原则:即使在开发后期,也欢迎不断变化的需求。敏捷过程利用变更来获得竞争优势。所谓的敏捷开发,主要应对的场景是业务需求不明确,或者技术需要通过快速原型与业务沟通来确认对需求的理解。主要起因是传统的瀑布式SDLC开发流程,必须有明确的需求,从需求、设计、 开发、测试,每一阶段都要进行严格的评审,每一阶段工作的完成是下一阶段工作开始的前提。一些软件类系统项目,特别是创新性或者急于上市抢占市场的项目,很难在需求阶段分析和挖掘出所有需求,所以对于敏捷开发,需求的不确定性以及变更应该是很正常的场景。
敏捷开发的前提是不降低质量,提升交付效率的同时,不影响交付质量。敏捷开发要求有很好的原型、高素质的参与者以及高效的团队管理。
敏捷宣言强调对流程的要求,要求开发人员对其工作流程拥有完全的权限,不能容忍团队之外的任何人(包括业务用户和管理人员)的任何干扰。实际上许多大型组织没有孤立的系统,不可能提供这样的真空项目环境,需要与内部、外部其他系统交互,这些交互接口应该遵循约定的标准,不需要程序员主动自我创新。
团队内业务人员和开发人员每一天都必须相互合作,所有任务和交付成果必须是共同拥有和共同开发的,每个参与人都积极主动,互相信任。业务人员和开发人员之间如何沟通需求?程序员之间交互协作的接口是什么?对于一个处理业务数据的系统来说,这个接口应该就是数据接口标准,所有协作的开发人员,对于数据的结构、关系及所允许的操作,必须有一致的理解,这是他们之间的信任基础。
以频繁交付为主要目标,不重视文档工作,往往只有少量文档,甚至没有文档,数据的元数据藏在程序中。软件应该还包括其文档,没有元数据的敏捷开发给数据治理与数据平台建设制造了大量障碍。没有元数据,下游不可能快速实现整合的模型,没有敏捷的手段或方法来给混乱的数据建模。
麻烦制造者
某些所谓的敏捷开发,IT与业务之间没有很好的沟通工具,没有透明的信任基础,很多时候是不断试错,不断推翻重建的过程。这些敏捷项目有很多相似之处:
向一些业务系统IT人员调研数据模型,绝大部分不知道什么是数据模型,或认为只有数据仓库才需要数据模型。他们不知道关系数据模型的作用,第3范式是设计关系数据库的要求,并不是数据仓库的独特主张。因此,他们生产源源不断的问题数据,他们成了麻烦制造者。
敏捷方法并不是只有Scrum或XP,敏捷是指能够快速推进,及早持续交付。传统软件工程强调软件的重用以提升质量与开发效率,数据与数据模型也可以重用。数据与业务,相对于流程、程序,有更多的确定性与稳定性。数据模型是对业务与数据的知识积累,无论流程怎么优化或再造,业务内涵很难发生颠覆性改变。互联网只是一个渠道,在互联网上经营存贷款业务,改变不了业务本质。
数据不是流程的副产品,数据建模比流程建模更重要或者至少同等重要。当一个敏捷项目必须抛弃重来的时候,至少还有数据模型可以重用。有些银行核心系统已经经历过多次升级换代,应该总结提升形成一套符合本行特色的核心交易数据逻辑模型,作为未来升级换代的快速原型。
一些所谓的敏捷开发方法反对或回避模型设计,认为设计模型延误了开发时间,是敏捷开发的主要瓶颈,主张直接从需求到直接建物理表,进入编程开发阶段,从而产生了大量的需要治理的数据问题。不需要数据模型、跳过模型设计的敏捷开发,是不了解数据模型的作用与价值,是对数据库设计的曲解与无知偏见。开发者通过数据模型达成对业务与数据的共同理解,是敏捷开发合作、共享与信任的基础。
数据平台敏捷开发方法
传统数据仓库开发备受责难的一点是建设周期长,可能会失去业务机会,他们甚至建议不再需要关系数据库管理系统和基于它们的数据仓库。这是个伪问题——越过数据治理的敏捷开发。
根据《哈佛商业评论》,平均而言,创建的数据记录中有47%具有严重影响工作的错误。根据ForresterResearch研究报告,数据探索和集成步骤花费了DW / BI工作的50%至80%。集成驱动了80%以上的价值。数据分析项目80%的时间花费在准备数据上,而非创造价值。
对于数据驱动的业务数据集成项目,Scrum或任何其他功能驱动的软件开发方法都不是正确的方法。所有流行的开发独立的交易系统的敏捷软件开发方法,都专注于尽可能快地编写和交付高质量软件,从未为以数据为中心的业务集成解决方案而设计,无需过多考虑或关注数据,例如数据剖析、数据标准化、数据建模、数据集成设计、解决数据争议等等,所有这些数据管理活动都需要从企业角度出发,并且工作量很大,开发前端BI应用程序只是数据平台开发中最后几步,Scrum和XP都没有考虑到这些工作的复杂性和相互依赖。
数据平台不是软件开发Project,而是业务数据持续整合的Programs。这样的商业智能计划应该是持续的,随着业务需求的变化变得越来越复杂。
Inmon推荐Larissa Moss螺旋式方法开发数据仓库,并已证明了价值。螺旋式方法非常适合不知道自己想要什么的用户。商业智能功能通常以探索方式开发,业务人员最终将在看到他们想要的东西时才知道他们想要什么,一旦他们得到了想要的需求,他们就会提出更多的需求。
螺旋方法的目标是建立可重用资产的清单,帮助组织摆脱废件与返工的死亡螺旋,将重点放在可重用组件上。包含3条平行路径:数据管理路径、数据交付路径与元数据管理路径,那些所谓的快捷交付,常常忽略了数据管理与元数据管理。
为了使螺旋式开发方法获得成功,Inmon推荐采用一种企业数据处理方法—“七流方法”,即企业参考模型、企业知识协调、信息工厂开发、数据剖析与映射、数据清洗、基础设施管理、总体数据质量管理共七个高级活动流,如下图。
成熟的行业数据模型给螺旋式开发提供了很好的参考原型。可以根据数据的重要性按主题或按数据源或按主数据、交易数据的不同来组织迭代,不需要等数据仓库所有主题设计完之后设计应用。
敏捷开发的不对数据建模的交易系统,不断产生数据问题,他们是麻烦制造者。
敏捷开发的不对数据治理的数据平台,不可能交付高价值数据。
来源:DAMA数据管理
作者:山水模子