敏捷建模在业务需求开发中的应用探索

在商业银行信息系统建设过程中，传统的做法大多采用瀑布模型，从项目立项、制定计划、需求调研、需求分析到软件设计、项目实施等，自上而下、环环相扣。瀑布模型为信息系统项目建设提供了按阶段划分的里程碑节点，从原始的“边做边改"模式中脱离出来，使得松散无序的信息系统建设活动变得有序可控。但同时也大大拉长了项目建设周期，在资源、工期紧张的情况下，尤其是在当前金融市场不断创新的新环境下，业务需求不断增加、不断变化，原有的信息系统建设模式将变得难以为继。敏捷建模方法的应用正是弥补了当前信息系统建设效率不高的短板，通过定义一系列的核心原则，大大提升了信息系统建设的效率。本文从金融市场业务领域出发，探索敏捷建模方法在金融市场业务领域需求开发过程中的应用。

一、新形势下的金融市场业务领域需求开发

　　1.金融市场新兴业务的发展及创新环境的特点

　　随着我国金融体制改革的不断深化，金融市场业务国际化的步伐不断加快，金融脱媒、利率市场化、互联网金融等体制变革和业务创新层出不穷。同时，云计算、大数据等新兴技术的出现亦如催化剂般加剧了市场变革。商业银行，尤其是在金融市场业务领域，其生存和发展环境正发生着翻天覆地的变化。

　　由于业务创新多，业务人员出于抢占市场份额、提高运营效率、控制成本等方面的需要，常常希望在提出业务需求之后的一两个月内即能获得稳定可靠的信息系统支持，有时候业务开展的具体规则还不清楚，便提出了业务需求开发或改造的申请，从而造成了信息系统建设要么工期紧张、要么资源浪费的情况。因而，如何在新形势下通过方法论的改进以提高效率成为了目前信息系统建设工作中值得探讨的课题。

　　2．敏捷建模与新形势下的金融市场业务领域需求开发实践尝试

　　在商业银行信息系统建设过程中，传统的做法大多采用瀑布模型。众所周知，瀑布模型的核心思想是采用结构化的分析和设计方法，为信息系统建设提供了按阶段划分的里程碑节点，将信息系统建设过程划分成项目立项、计划制定、需求分析、软件设计、项目实施等固定阶段，自上而下地顺序执行。

　　瀑布模型的应用使得松散无序的信息系统建设活动从原始的“边做边改"模式中脱离出来，变得有序可控。阶段化的切分将问题逐级化简，大大提高了项目建设的效率，同时，当前一阶段完成后，只需要关注后续阶段，也在一定程度上降低了项目建设的成本。然而，瀑布模型严格的里程碑定义和顺序执行也导骛了如下问题：

　　(1)瀑布模型的各个里程碑阶段的划分完全固定，每个里程碑节点都要求详尽的文档和评审，工作量很大。

　　(2)瀑布模型依赖较多的强制完成日期和里程碑来跟踪各个项目阶段，在工期与资源紧张的情况下往往导致低质量的交付。

　　(3)瀑布模型是线性的，用户只有等到整个过程的末期才能见到开发成果，而一旦发生变更，则需要重头再来，从而增加了开发风险。

　　通常情况下，由于质量和风险控制的要求，瀑布模型在商业银行信息系统建设过程中的应用是切实有效的。然而，由于瀑布模型不适应用户的需求频繁变化的情况，在如今金融市场不断创新、业务需求不断变化的环境下，尤其是在资源、工期紧张的情况下，瀑布模型便显得捉襟见肘，很难满足要求。正是基于新形势下金融市场业务创新多、变化快的特点，敏捷建模方法应运而生，其目标是以一种有序高效的态度来进行系统建模。

二、敏捷建模的核心原则

　　敏捷建模的主要思想是要使项目利益相关者的投资最大化，运用合适的工具来记录开发工作的情形，尽可能创建简单的模型，且当有清晰的目的及业务需求时才建立模型或文档。其核心原则包括轻装前进、主张简单、目标明确、拥抱变化、快速反馈、增量建模等。

　　（1）轻装前进：当按照软件工程的理论选择多种工具和方法(比如业务需求卡片、统一建模语言、原型工具等)来进行需求开发时，一旦有变化发生，如新需求的提出、业务规则的变更、流程的优化等，就必须考虑变化对所有这些模型产生的影响并采取相应的措施。很明显，采用的工具越少，实现同样的改变要花费的功夫就越少，灵活性就越强。

　　(2)主张简单：在需求不断变更的环境下，不要对信息系统进行过分构建。即对于暂时并不需要的额外功能，不要在模型中增加它，日后需求有变更时，再来重构这个系统，尽可能地保持模型的简单。这样，在业务需求开发阶段，可以大大节省浪费在不必要的细节讨论和相关模型开发上所投入的时间和精力。

　　(3)目标明确：对于所建立的模型，例如文档、用例等，人们常常担心它们不够详细，或者担心它们不够妥当或在不久之后会发生变化。这往往与建模的目标不明确有关。因而，首先要确定建模的目的以及模型的受众，然后确保模型足够正确和详细。一旦实现了目标，就可以结束当前的工作，把精力转移到其他的工作上去。

　　(4)拥抱变化：软件工程领域有旬名言叫“世界唯一不变的就是变化"，需求时刻在变，人们对于需求的理解也时刻在变，项目组成员也可能不断变化，甚至项目利益相关者的观点也可能变化。因此需求开发必须能够接纳变化并反映这种现实。

　　(5)快速反馈：从开始行动到获得反馈，二者之间的时间越长，开发效率就越低，项目产生风险的可能性就越高。按照敏捷建模的要求，有必要和其他所有项目利益相关者一同进行开发。这样，需求开发人员的想法可以立刻获得反馈，减少确认和反复修改的时间。

　　(6)增量建模：不用在一开始就准备好一切，也不用在模型中包容所有的细节，只要有足够的细节就够了。没有必要试图在一开始就建立一个囊括一切的模型，只要开发一个核心的模型，或者是概要模型，然后采用递增的思想逐步改进模型。

三、敏捷建模在兴业银行金融市场业务领域需求开发中的应用

　　敏捷建模在软件公司、互联网企业等软件开发专业领域已有广泛的应用，并结合传统的瀑布模型、螺旋模型或Scrum、XP等敏捷过程进行了深入的探讨。而在商业银行信息系统建设中，由于对质量和风险控制的要求，敏捷方法的应用还不是很多。本文选取金融市场业务领域的业务需求开发阶段来介绍敏捷建模的应用探索。

　　根据敏捷建模的目标明确原则，在着手进行业务需求开发之前便定义清晰的交付物模板。这主要包括最终交付的业务需求说明书的文档结构，每个章节所需描述的内容(比如业务规则、操作流程、输入输出信息等)及所涉及使用的描述语言和工具。通常情况下的业务需求点模板示例如图1所示。

　　根据敏捷建模的轻装前行原则，并不对所有业务需求点创建完备的视图模型，尽管UML建模语言提供了如状态机图、活动图、顺序图和合作图等视图加以描述；仅在业务流程较为复杂时，选取泳道图对业务处理流程进行描述以帮助理解。在此，以常见的购物支付流程为例作泳道图(如图2所示)。

  　 (2)对参与业务需求开发的人员进行培训(培训计划见表1)。通过专题讲解的方式，向业务需求说明书的编写人员说明模板的每一个组成部分和编写规范、语言要求等；以实例演示编写的方式阐述业务需求点颗粒度的划分、业务规则与操作流程的描述、输入输出的描述形式等；当涉及使用图表工具时，对常用的画图工具(如Visio、Jude等UML建模工具)进行介绍，并以实际业务需求点进行示例演示。这样可以确保目标明确并且在业务需求编写过程中不会产生多余的文档或其他在业务需求开发阶段所不涉及的技术模型。

　　(3)在业务需求开发过程中，组织开发小组成员集中办公，确保重要成员的全程稳定参与。这样，根据敏捷建模的快速反馈原则，一方面在开发过程中，需求开发人员可与业务人员持续保持现场沟通，交付结果可以得到最终用户代表的快速确认，且在遇到问题时可充分地进行讨论并得到解决，因而提高了交付质量；另一方面，当涉及多方最终用户利益并产生冲突时，可以快速寻求业务负责人的决策，从而降低开发过程中的沟通成本，提高开发效率。

　　(4)敏捷建模的一大特点是采用增量建模的原则，因而，可把业务需求开发过程划分成多次快速迭代过程，每次迭代大约一周时间。在首次迭代过程中，对存量文档进行研读和整理，提取可以复用的文档材料，对已经明确的业务需求点补充编写文档，统稿后形成第一版交付文档(即业务需求说明书)。

　　如图3所示，在后续的迭代过程中，首先比对上次迭代过程所产生的文档与目标文档(在目标明确原则的应用中已产生目标文档大纲)间的差距，即查找未编写完成和尚存有疑问的业务需求文档节点，并在该次迭代中进行相应需求节点的增量开发，产生新版本的交付文档，并在小组内部发布。

　　每次迭代过程结束后，进行统稿并组织小组讨论，重点对增量部分进行确认，对未编写完成和尚存有疑问的业务需求文档节点进行列表跟踪，并进行下一次迭代过程。根据目前的经验，一般规模的项目大约进行3～5次迭代过程(大约3～5周)即可完成整个业务需求开发。

　　在业务需求开发的任何阶段都接受业务需求的变更，这与敏捷建模的拥抱变化原则相符。当业务需求发生变更时，如果尚处于当前迭代周期内，且所需变更的业务需求文档未完成编写，则按照新的业务需求进行整合后编写业务需求文档；如果当前处于迭代后的讨论确认周期内，或者处于当前迭代周期中但业务需求开发及相应的业务需求文档编写已完成，则将该业务需求变更进行记录，纳入下一版本的迭代开发。总体业务需求变更流程如图4所示。

　　通过敏捷建模方法的应用，笔者对金融市场业务领域两个信息系统业务需求开发过程进行对比：其中，完全按照传统线性流程实施的项目从成立业务需求调研小组到最终业务需求说明书通过交付评审的时间为49个工作日，而同一业务类型且项目规模相近的信息系统业务需求开发过程，采用敏捷建模耗时仅为31个工作日。简单地从过程耗时来看，敏捷建模使得业务需求开发过程的耗时缩短了30％。因而，在具体实践过程中，可以确切地体会到敏捷建模所带来的开发效率的提升。

　　此外，通过后期的总结与沟通，项目参与人员均表示按照敏捷建模的方法开展业务需求开发工作有章可循、心中有数。这些项目参与人员、开发人员的良好体验，虽然不能量化到具体的成本节省比率等数字指标，但不得不承认，其对开发过程的顺利推进、交付质量的提升都有很大的帮助。

　　敏捷建模在商业银行信息系统建设中的应用还不多，本文在大部分原则的应用上还只是粗浅的尝试，尤其是主张简单原则，仍然受制于评审要求的束缚而不得不生产大量与里程碑节点相对应的过程文档。在后续的工作中，或许可以尝试在更大范围的信息系统建设周期中应用敏捷建模方法，对现行的信息系统建设过程加以改进，进一步提高工作效率。

(文章来源：《中国金融电脑》杂志)

扫码即可手机
阅读转发此文