上篇提到，我们引入精益Kanban方法来“拉动”项目前进，把整个研发交付过程透明化，并加速需求卡片的流转。
本篇继续讲述平安创新银行产品引入全面敏捷实践的故事最终篇 part 4。
指路牌：敏捷项目管理
在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年，获评“中国最佳直销银行”大奖。（本资讯于2016-08-02首次发布）
