农行软件开发中心二部从2017年底开始启动敏捷转型，以春天工程为试点项目组，探索出了一套适合传统银行的敏捷开发模式。
作为这个团队的外部敏捷教练，我有幸参与了这个团队转型的全过程，目睹了一个传统软件开发团队从对敏捷一无所知到可以自我组织，自我改进的过程。看板站会作为敏捷团队转型的重要切入点，在这个团队的转型过程中起到了非常重要的作用。以下是这个团队自己录制的一段推广视频，作为进行敏捷转型的团队来说，有非常好的借鉴意义。
（感谢农行二部制作和分享这段视频）
从我个人的感受来说，这个团队的转型主要经历了3个阶段：
1. 以看板站会作为暴露问题手段，用Scrum模式为团队建立持续改进基础
这个阶段主要关注团队工作的可视化，并通过严格的每日站会制度帮助团队建立起持续改进的基础。这块看板集成了需求分析，原型设计，故事拆分前期过程以及3个产品组的进度看板为一体，形成了春天工程这一跨团队项目组合管理的可视化板。团队在转型初期非常严格的执行了“削足适履”的原则，通过Scrum的4个活动建立起了团队自己的流程和改进机制，特别是对回顾会议的足够重视，让团队快速的进入了持续改进状态，找到了自己的节奏。
2. 改变测试模式，引入 Git Pull Request + CI/CD 工作流，加速开发和测试迭代速度
虽然这个项目作为敏捷试点，但仍然需要在农行现有的项目管理流程中，特别是投产之前必须经过测试中心的测试。测试中心在前期仍然按照传统的方式参与，在大版本投产前才会为项目组投入测试资源执行测试。在项目第一次投产前这并没有构成太大的问题，在后续的开发过程中，项目组希望能够为业务提供更加频繁的交付获取反馈，开始考虑测试中心派驻人员进行持续测试的模式。
这一人员构成的改变促使团队开始考虑引入更加迅速的部署模式，因此启用了TFS中的Pull Request，并衔接TFS构建实现CI/CD流程，为团队提供更为迅速，可靠，可跟踪的环境获取能力。这些TFS功能的启用为团队开始按照用户故事组织开发和测试过程提供了工程支撑。
3. 打通持续交付全链路
当团队开始使用 Git Pull Request + CI/CD 的方式以后，发现从代码分支到环境的跟踪能力给予了团队非常有效的代码质量把控方式，并开始自主的改进看板，将看板上的故事/任务卡片和Git分支(Pull Request)建立联系，实际上已经形成了从需求到部署的持续交付全链路跟踪能力。
因为以上团队自主实现的物理看板到TFS持续发布流水线的跟踪，团队也开始考虑如何能够启用TFS的工作项/电子看板，以便可以对持续交付过程进行更加直接有效的跟踪。
以上这个过程经历了大致6个月的时间，我们可以看到一个逐渐成熟的团队。这个转变过程是一个非常典型的从团队工作模式为起点，借助工程手段支撑，在适当的时间点引入工具解决痛点问题，工程手段的引入同时又进一步促进了团队工作模式的演化；这样一个管理和工具互相推动的模式。在这个过程中，二部的部门领导给予了团队非常坚定的支持，允许团队犯错并在错误中总结和改进，农行软开项目办也为这个团队给予非常到位的支持，比如在前期排出专业的Scrum Master给予指导，全程由专人跟踪团队动向，引入外部教练；当然最重要的还是这个团队本身的开放务实的态度和努力。
在这个过程中，我给予了这个团队一些传统银行IT很难接受的建议，比如：抛弃执行多年的成熟配置管理流程，切换到分布式的配置管理工具Git，使用基于Pull Request的模式，甚至将代码库进行拆分等等。让我非常欣慰的是，这个团队针对这些建议非常重视，前期对这些新做法的具体细节反复验证，推导，启用后接受工具所带来的改变并努力适应。
希望这个团队能够继续成长，探索出更多更好的敏捷实践。
相关文章
请关注微信公众号 【devopshub】，获取更多关于DevOps研发运维一体化的信息
[…] 来自农行软开的看板站会秘籍和敏捷转型经验 […]
Comments are closed.