农行敏捷开发模式创新及应用实践

相对于传统软件工程，敏捷开发阵营发展出多种方法论，定义了多种开发模式，如XP、FDD、TDD、Scrum、Crystal Clear、lconix等。虽然敏捷开发模式多种多样，但均严格遵循敏捷的核心价值，即沟通、简单、反馈、勇气，遵循敏捷的核心原则，即持续交付、高效沟通、拥抱变化、客户合作、精益求精、简洁优雅、团队内省。2008年起我行引入敏捷开发，在开发中心领导的主持下，分析了业界已有的各种敏捷开发模式，并与ThouqhtWorks公司进行了多次交流，经反复研究和不断尝试，在多个项目应用实践的基础上最终形成了我行独特的敏捷开发模式。根据研究成果，重新定义了敏捷开发模式，确定了新的开发过程模型。

1．开发过程定义

        我们选用迭代开发过程作为过程模型，主要目标为降低需求风险、减少系统开发风险、规避系统设计风险、提高计划可靠性、从整体上加快开发进度并降低开发成本。每一次的迭代过程，都包括项目开发的全过程（计划、需求、分析设计、实施、部署、测试、评估）。根据具体项目的不同，我们定义迭代周期为1周～1个月，超过1个月项目就将面临失控的风险。每一个迭代周期结束时进行项目评估，一方面决定是否继续迭代，下一迭代周期需实现哪些需求和功能，另一方面评估系统是否基于这个迭代周期结束后的版本发布上线，在生产系统上部署新版本，启用新功能。

2．开发团队组建

        我行采用轻量型开发团队，规模不允许超过10人，以降低沟通和交流的成本。在团队角色分工上仅设立1名专职项目经理，其他人员既是需求分析、系统设计人员，也是开发人员、测试人员，不再严格区分个人角色，而是根据实际工作情况随时调整。同样也不设立技术经理角色，而是采用设计和代码全员共享的模式，使所有人了解系统结构、要做什么、如何做。该团队可发挥每位队员的最大潜能，使每个人都能做出更好、更聪明的决定，从而适应不断产生的变化。

        对于团队成员技能要求方面，团队成员要求必须是中、高级以上具有丰富经验的技术人员。这种人员配置极大顺畅了沟通，也使头脑风暴更为有效。这样的团队组成能更好地应对挑战性项目，工作效率大幅提升，队员工作激情倍增。

3．日常管理

        在管理方法上我行选择简单高效的方式，通过项目门户、站立例会、缺陷直通、人员结对等方式，简化管理工作，提高工作效率，降低管理成本。

        对于会议，我行原则上除每日例会和评估会议外不召开其他会议。例会在每日下班前召集，所有人站立在白板附近，每人用1分钟时间回顾本日工作，并提出问题。将问题在白板上形成列表，评价每项是否的确成为问题，由谁解决，并不具体讨论如何解决，因此会议很少超过15分钟。问题的解决由负责人找相关人员通过沟通、交流找到解决办法。

        基于WIKI开设独立的项目门户，我行每天上班前由项目经理发布项目进展、工作安排，队员通过抢任务的方式领取当日的执行工作。每位队员必须认领当日工作，采取先到先得规则，队员积极性很高并乐在其中。

        对于缺陷，不再按照传统的划分方式分级，而是统一要求半日内解决。每个缺陷由测试人员直接与对应的开发人员沟通，对存在争议的问题由项目经理仲裁。由于敏捷模式为小迭代开发，每个迭代周期实现的功能数量有限、功能明确，因此很少有争议，也很少因缺陷修改导致开发和测试的进度延迟。

        对于开发技能、业务知识，我行采用结对方式。我行使用的结对模式相对敏捷提倡的结对模式，更宽泛也更灵活，按需安排，技术和技术、技术和业务人员均可在需要时临时结对，每次结对均针对特定需要。需要得到满足，则此次结对结束。

4．文档书写

        对书写文档我们有自己的要求，仅限于软件需求规格说明书、系统设计说明书、操作手册这3种。

        对于需求规格说明书，我们反对按照特定文档模板编制“八股文”，要求对每个功能点用最简单的语言说清用途。例如用“系统切换会计日期时刻，不允许发起联机业务”来描述系统状态控制的功能说明。

        系统设计说明书也不是传统意义的架构设计、概要设计、详细设计说明书。说明书仅描述系统总体逻辑结构、业务模型、各模块接口和常量定义。对于其他设计内容，因为队员都是专家，自然会用代码体现，不需要耗费在写文档上。

        操作手册最终要面对用户，因此需要书写详细，使最终用户通过看操作手册迅速了解系统、功用、问题解决，绝不允许简化。

5．需求研制

        挑战性的项目必然有挑战性的做法，各种敏捷开发模式都提倡以User Story的方式确定需求和开发内容，我行借鉴了这种方法，且又向前推进了一步。

        在需求研制方面，在项目意向阶段派出开发团队成员，进行技术预研、需求研究、业界分析，由技术人员和业务人员一起对项目范围、需求开展讨论和研究。项目早期介入的优势在于从一开始业务和技术人员形成了自己的专有词汇和共同概念，使后期沟通交流更为顺畅。

        有了前一个阶段的铺垫，在开发阶段对需求的优先级就不存在争议，仅就每个迭代周期要实现哪些功能进行讨论，并制订该迭代周期的工作计划，每天的工作安排，并非传统意义的User Story，而是仅发布一个系统功能——前期全员参与了需求验证，不需要再详细描述每个功能如何实现。

6．领域驱动设计、模型驱动开发

        系统的根本复杂之处不在于技术，而在于业务领域本身。在分析设计时，如不能通过模型将承载的业务领域模型和概念清晰地表达出来，仅凭先进的技术和平台架构，很难保证项目建设成功。因此一个系统设计的成败关键，根本上是领域建模的好坏。技术人员通过领域建模，能够掌握业务需求，理解业务模型，将系统实现为真正满足用户需要的软件。

        我行通过模型来驱动开发，工程中的所有工作都通过业务领域模型理解，让工程师们忽略无关细节，将主要精力放在系统的最重要部分。业务领域模型不仅仅是技术专用，也用来与业务人员交流，通过模型展示和讲解，确定模型是否满足业务功能和发展需要，通过模型建立一个业务与技术无歧义的沟通平台。

（文章来源：金融电子化）
 

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