*1、背景
传统金融企业，系统交付一直用瀑布模式。2016年，因为敏捷开发很火，我主导发起了敏捷转型项目，经过与部门各方沟通，确定了试点项目。
2、参与方
需求管理、系统开发、测试管理
3、问题
项目开展以后，咨询顾问进场先进行了基础知识培训，大多数人对Scrum表示有一定程度的理解，但是认证考试的结果不甚理想，通过率不过50%。
试点项目开始时在团队角色确定上遇到问题，大家对team成员没有意见，但是对PO和SM有不同观点，具体的争论如下：
1）SM由PM还是系统资深开发主管担任？
2）PO是由系统负责人还是需求负责人担任？
最后为了让项目顺利推进，在原来的开发团队中选出了PO和SM，需求团队继续写需求文档给测试人员使用，大家一起写用户故事。
接下来又遇到问题。在瀑布开发模式下测试团队总是最后一个出现，之前参加会议也是基本不说话，最多要个需求分析文档，评估工期。而敏捷开发模式里面要求测试前期参与，与原有的工作习惯有很大的变化，测试一直未完全进入冲刺，因此前面几个冲刺实质还是瀑布模式。
然后，冲刺的交付不遵守MVP原则，往往需要几个冲刺才能完成一个独立可交付模块，测试等待完整功能的测试代码前无事可做。
还有需求变更频繁，业务方随意调整需求优先级，导致冲刺里面很多任务中途搁置，造成很大的投入浪费。
4、项目成果
大家对敏捷有了深入的了解，但是限于既有的管理模式，很多好的机制和方法不能有效运作，需要管理层在组织机制上的支持。
由于部分试点团队是全功能团队，因此落地效果较好，交付效率和质量都有提升。所有团队能使用熟练使用看板方法，规划会、每日站会、回顾会已经形成工作习惯。
5、回顾分析
1）管理层的信心和支持至关重要，新模式导入会有一段时期的不适，需要各个层面理解和支持；
2）Scrum的理念和基础知识培训很有必要，避免一些人一知半解的情况下随意发挥，导致纠偏困难；
3）很多明显是正确的道理和方向，往往因为各种原因无法遵从或落实，需要极大的耐心和很长的时间来说服，阻力可能会超出想象，终归是利益或意愿方面的问题，可能短期无解。
6、总结
传统企业推行敏捷是一项系统工程，组织机制、管理制度、绩效指标、团队利益、个人意愿等等，都有可能对敏捷落地有负面影响，知易行难。
