从去年下半年开始，我行全面敏捷转型，本人谈谈自己敏捷转型的感受，目前本人负责数据中台部落风险控制小队，风险控制小队目前行员3名，外部资源41人，分为三个小组，涉及行内13个系统，7个关键业务系统，成员多，管理成本非常高，转型前期业务需求不明确， 交付时间经常变更，经常紧急插队需求，导致研发工作完全无序进行。经常业务抱怨。开始转型后，我们严格按照第一步进行需求分级，P1,P2,P3,P4的业务级别去响应业务的需求，强化需求澄清，强化需求设计评审，确认完成后，在开始动工。进入敏捷后，严格按看板，站会，开始任务拆分，研发。
每日站立会议大家认领任务。包括业务任务、开发设计、开发编码、前端设计开发、测试等都是一个个任务，统一管理起来。强调的是一个团体，如果有同事请假，其他同事可以顶上完成任务。站立会议总结昨天的任务是否有问题，对于当前的任务有什么建议，控制在15分钟内，有效会议。这里不会像以前业务或者项目经理追着大家屁股要结果，而是团队驱动，每天大家做的事情都反映在墙上，谁出现了什么状况，大家都会帮他想办法，保证整个项目能够成功。每一个任务完成，由项目执行者把任务从进行中贴到完成区域。再从未分配区域认领新任务贴到进行中的区域
软件开发过程。认领任务后，怎么保证大家开发有质量的代码？团队有丰富经验的工程师，不需要太多指导，直接可以参与项目的开发。而学习型工程师，需要指导帮助才能一步步做用例、系统分析。不建议认领太多开发任务，他负责开发团队的系统架构设计审核，没有审核通过的设计不能开发，并指导大家分析和设计系统。大家都知道，系统思路有了，剩下就是技术实现的过程，只要技能掌握熟练实现基本难度不大。大家可能会问，敏捷开发不是强调软件开发的产品是软件，而不是文档吗？我们这里也不是像传统开发软件一样为了文档而文档，只是让大家把自己的设计思路写下来，只有经过自己仔细设计后才能把思路清晰的写下来。大家写的时候也不需要长篇大论，这样的文档是不欢迎的。
互帮结对编程，之前这个编程模式被无数人吐槽过，其实也不可能让每一个项目全程都是两个人互帮结对编程。这个不现实也浪费资源。我们的互帮结对是在大家开发一个难点模块时，会给结对的人增加一项任务去配合其他开发一起完成这个任务。其实我们在开发时，很多时候都会结对，比如指导新同事、讨论设计模块，而之前这些都没有算在我们的开发工作量里。
项目演示和总结会议。在项目结束后，让所有参与项目的成员都参加，分让大家感受到收获的果实, 大家充分沟通，表达自己的看法，头脑风暴，沟通所能体现出的则是一种近似于激情式的开发方式，我们可能往往一个团队只有在一起吃饭时候才会将想要说的想法暴露出来，原因就是平时在工作中沟通太少了。对于技术的交流、进度的沟通都会被无意思的阻隔掉，这样往往当生产过程进入尾声时候，才会将各种问题保留出来，现在的敏捷则尽可能能的将沟通也放在了日程的前端，我们不得不每天都开会、谈心，不断的将需求、测试案例、开发风险从我们每个人的各个角度爆发出来，将最后风险爆发的可能性降至最低总结会议主要对于过程中大家遇到的问题和经验分享，并为下一个需求做准备。
将近一年的敏捷实践，为我们研发带领了很多新的理念和想法，并且一步步在落地，后续我们将持续敏捷，推动我行敏捷转型，更好的支持我行业务前台发展。
网友评论