本文讲述了2014年研发管理部敏捷教练团队在平安一个创新银行产品项目中，指导引入全面敏捷实践、帮助产品在3个月内快速发布MVP的故事。本项目曾在《IT经理世界》（2014年11月刊）被作为封面报道。
“平安银行大厦14职场，一排排完全开放的办公桌，贴满了写有需求目录便签纸的墙面，以及每天早上八点半站成一圈紧张讨论的站立式会议，一切都让这个团队与众不同。
5月26日，这里迎来了一位特殊的客人-C行长，C行视察了直通银行项目团队敏捷实施情况，对敏捷及精益思想给予了高度的肯定”
——摘自平安银行通讯稿
困难重重
时光回到2014年4月份。我们接到一项教练指导邀请，平安银行正在启动一款创新银行产品的建设，在国内银行同业内，已经有2家银行发布了同类产品，我们需要与时间赛跑，尽快推出并且做得更好。
我们进场时，发现存在重重困难：
1 业务已聘请某咨询公司规划了革新方案，但咨询公司只管战略规划，如何落地大家心里都没有底
2 IT技术方案存在不确定性，对于如何实现这一创新业务模式，技术实现方案还不能敲定
3 IT人力内外部比例悬殊，当时逐步到位开发团队有30人，但其中28个是外包人力！只有2个内部人力……1个作为PM管理项目，1个作为SA分析需求
4 不论是IT还是业务，都涉及多方关联，其中多数系统关联都需要跨专业公司的对接合作
5 IT与业务之间为传统协作模式，习惯于相互制约、界定责任。业务很不高兴经常听到IT人员说“这个无法实现”，而IT人员要求业务完全细化需求文档，于是业务集中人力“拼命”写文档，业务自己都承认，文档细节都是“拍脑袋”出来的、未来不一定是这样
6 上线时间已向高层承诺，作为一个全新的业务模式及产品，只有3个月的建设时间，时间非常紧张，压力很大
与业务的第一次亲密接触
当时的情况，除了由研发管理部派遣的项目经理，不管是IT方还是业务方的人员，对敏捷开发都没有概念。IT内部的还好办，知识的传递和技能的培养可以直接安排，但如果希望全面导入敏捷变革、用一种崭新的合作方式来工作，与业务方（平安银行和平安科技是2家专业公司）的沟通就显得非常重要。
我们安排了与业务、IT方关键人员的第一次圆桌沟通，主要的沟通策略如下：
• 关注业务的问题和感受，再收敛引导双方都觉得现状必须改变
i 强调双方的相互理解，例如
ii IT要理解业务，需求的细化是永无止境的过分细化没有意义；
iii 业务也要理解IT，对于知识工作的工作量评估存在评估，IT可以逐步给出“信心指数”越来越强的估计和计划，但也要理解这不是绝对的承诺
• 对于需求渐进明细、开发及早启动的做法，符合业务期望，但阐明对业务造成的影响和变化，例如：
I 业务需要对需求进行优先排序，明细范围可协商
II 业务人力需要有持续的投入
• 以提升需求梳理效率作为切入点，明确的引导以下沟通方向：
I 揭示现行做法的风险
II 回到大家共同的目标
III 探讨怎么做才能尽快推进项目
沟通的结果挺理想。我们并没有主动提出要引入“敏捷开发”，沟通到后面，反而是业务方主动提出来：
“看来这样搞不下去，要不我们试试现在外面流行的敏捷开发模式？”
OK，那就卷袖子开干！
发动机：快速启动工作坊
我们立马准备场地、道具，圈定并把项目各方的关键人员及干系人集合起来，组织及引导了一个为期5天的项目快速启动工作坊。
这5天的日程，基本可以分为3个阶段：
Day 1：
引导团队成员及相关干系人快速沟通确认项目目标及概要方案，所有人达成一致理解，凝聚共识
Day 2-3：
运用“用户故事地图”方法，梳理与验证整体项目需求，分“需求模块 主题故事－故事”三层来归纳组织；识别需求实现上的技术风险，分析清楚产品内外部的依赖关系，也用可视化的方式呈现出来
Day 4-5：
我们进行需求估算，基于需求价值进行优先排序，并形成“迭代计划墙”。
每个迭代都聚焦于一个清晰的业务目标，每个迭代安排的具体需求，优先服务于这个聚焦的业务目标；而对于其他的优化类需求的实现时间，则视开发进度“可协商”，这一点在向业务“大PO”演示沟通版本计划时，也得到了业务PO的认可。
这5天的工作坊，效果非常好，像“发动机”一样，从一开始就驱动了整个项目的成功运作。至少体现在3个方面：
1 通过各角色人员的全程参与互动、所有信息的透明及共享，IT和业务之间建立了非常好的相互信任关系，以目标、价值为导向，协作默契。
2 通过在项目启动阶段引入敏捷的理念、工作方式和多种有效实践，为团队应用敏捷开发模式来实施软件开发和测试，从思想上、技能上都奠定了基础
3 对项目目标（时间紧，必须快速推进）的达成起到了直接的帮助，1周的工作坊完成后，团队安排一个简短的迭代0进行需求开发“穿刺”，然后即推进到有节奏的迭代开发过程。
拉动力：精益看板方法
加强IT团队内部、IT与业务互信的另一个非常有力的“拉动力”，是精益看板方法在项目中的运用。在快速启动之后，我们引导了以下看板实践：
1 通过纵向泳道划分，来可视化端到端的研发全流程
2 通过在关键环节设置“拉动规则”（即这个环节的Definition of Done），来强化质量控制
3 通过横向泳道划分，来约束WIP（在制品数量），加速需求任务的流动
4 通过人员照片数量限量（2张），来限制每个人并行开展工作的数量
5 通过“选择”队列，来可视化开发同学可以优先拉动的故事卡片，并明确服务时效的“承诺点”
看板方法的运用，起到2个显著的效果：
1 把整个研发交付过程透明化管理，促进银行业务人员、PM、SA、开发、测试各角色之间的协作效率提升，并建立及巩固了业务对IT的信任
2 加速了需求卡片的流转，根据当时的看板数据统计，85%的需求可以在需求提出后45天之内发布上线，这对一个银行类的系统，已经算是挺快的交付速率
指路牌：敏捷项目管理
在3个月的敏捷项目管理实战中，我们边实践、边思考，通过项目管理方法上的“改进实验”，改变了很多以往传统项目管理中一些低效的做法，逐步总结出敏捷项目管理的“十大原则”。这些原则像“指路牌”一样，指引着我们朝着正确的方向轻步疾行。
我们遵循以下10点原则来管理这个项目。
1、构建特性团队，统一目标。传统上，平安科技的“IT团队”和平安各专业公司的“业务团队”是契约服务关系，业务更关注于业务目标的达成，而IT更关注于项目SOW承诺的履行。在IT内部，也存在不同的职能团队，有着各自的局部工作目标。我们组成虚拟的“特性团队”，强化共同目标和愿景。
2、轻量需求沟通，缩短链条。传统上，典型的沟通链条从“用户->业务人员->业务领导->业务BA->IT SA->IT开发团队”，很长，各个环节之间主要靠文档来串行传递信息，信息经常失真。我们把所有项目关键角色人员拉到同一个地点，引入Kanban方法完全透明工作流程、进展和阻碍，缩短沟通链条，引导团队引入用户故事等轻量的需求沟通方法来提高沟通效率。
3、坚守进度质量，协商范围。传统fixed scope的项目形态，往往在客户压力下，time、cost也是被钉死的，结果往往先满足短期交付，而牺牲质量（尤其是隐性的“内部质量”）。我们和业务充分的进行沟通，说服业务认同这样的处理方式：我们一起确保给老板承诺的上线时间不动摇，确保高价值的亮点功能发布，其他的需求细节可以协商。
4、营造信任环境，透明管理。传统的协作形态，业务对IT交付过程的参与度很低，IT也不希望把自己的真实状况“给业务看光”，结果是业务很难以对IT建立信任，指责和质疑增多，IT出于自我保护，进一步降低透明性以便有谈判资本，恶性循环。我们在项目中实践透明化管理，让真实的信息充分共享，致力于营造一个相互信任的环境。
5、缩短需求周期，全局优化。传统上IT有“需求交付失效”的服务承诺，但计算起点是从需求进入IT需求分析甚至是分析完毕之后才开始算，与提需求的用户的实际感受脱节（在需求沟通链条中，前面的环节可能也消耗了很多时间）。我们倡导从全局的视角来度量和优化，改善“端到端”的需求周期，真正提升业务用户的满意度。
6、专注效率提升，降低批量。之前有不少团队尝试引入“迭代开发”的外型，实际上还是一颗瀑布开发的内心，迭代内“分析－设计－开发－测试”串行流转”，迭代中存在很多等待，过程效率不高。我们通过约束WIP（在制品）数量，降低并行工作的任务批量，开发人员每次只专注于1个卡片大开发，也提升了效率。
7、拥抱需求变化，延迟承诺。传统的项目管理，基于一个非常明确的项目范围，在一开始就承诺批量交付，通常会要求提前冻结需求，并严格控制需求变更，在市场及需求变化很快的互联网背景下，就缺乏灵活响应业务的能力。我们延迟commitment points，在承诺点之前，业务可以有很大的需求变化的灵活性；一旦进入承诺点，我们会最快速的完成需求开发和交付。
8、价值风险驱动，版本火车。传统上，项目交付周期较长，业务不太关心不同需求之间的优先级，经常要求全部实现、一个不落、中间还不停的塞需求，就像挤公车一样，拼了命都要挤上去，因为下一班公车什么时候到、谁都心里没底。我们引导“版本火车”到版本管理方式，像地铁一样，每隔5分钟一班，价值高的、商业风险高的内容，先上车，其他的内容就等下班呗，几分钟后就到了。
9、测试工作前置，内建质量。传统上，在IT内部，也存在职能部门之间的“高墙”，开发同学想着后面有测试兜底，代码写好了不管质量怎么样先扔到墙那边去，测试同学则前期看不见墙这边的东西、突然被砸中。我们倡导“全民质量观”，在流程上以用户故事为开发、测试协作和流转的单位，在每个用户故事流转的早期，就由业务、开发、测试一起来分析并达成一致理解，彻底把墙推倒。
10、加速反馈闭环，验证假设。传统上，很多团队习惯于只完成“交付”本身，对于做的东西是否有价值、是否能支持商业目标，没有太多关注。我们给业务和IT做了“Lean Startup （精益创业）”方法培训，在一些创新性的需求上，先用比较小的实现代价先做尝试，快速验证，加速反馈闭环。
轻舟已过万重山
在团队的共同努力下，
2014年7月，该创新银行产品MVP版本发布内测。
2014年8月，正式推出市场。
2015年底，用户量突破500万。
2015年，获评“中国最佳直销银行”大奖。
（全篇完）
网友评论