小瀑布如何向敏捷转型？
关于敏捷和小瀑布的疑惑
一些正在实践敏捷（如：Scrum）的伙伴，常常会这样的疑惑：如果利用敏捷思维方式来拆分产品，将交付物拆分成更细粒度，以每周或者每两周的方式迭代，每个迭代也交付一些些可用的产品，那么这样是不是就是敏捷了？
又或者说：这样虽然知道很可能是小瀑布，但和敏捷貌似也没什么差别了。
诚然，在交付压力和团队都正常的情况下，从每个迭代以及最终交付的结果来说，小瀑布和敏捷我个人认为并没有什么区别。真正最大的差异来自于交付压力或者团队出现变化时候，小瀑布团队和敏捷团队表现出巨大而明显的不同。
试着观察两种沙发
我们先从两种不同的沙发来试着观察和体会。
伙伴们看到上图是一张懒人沙发，图片右下角是沙发的填充物。众多相同的球形颗粒填充在沙发内，支撑了整个沙发外来的压力，满足「坐」的需求。
而这是另外一种使用弹簧的沙发，通过弹簧、线绳和海绵垫，各司其职共同来支撑承受外力，完成「坐」的需求。
两种沙发有什么不同？沙发完好并且承受正常外力情况下，两种类型的沙发都能提供良好的舒适度。但出现变化时的情况就完全不同了。
情况一：撤掉 30%支撑物
在这种情况下，懒人沙发舒适度可能降低，但依然可以提供「坐」的能力，内部每一个颗粒间承受的压力将变大。而使用弹簧工艺的沙发有极大的可能性已经不能「坐」了。
情况二：承受超出范围的外力
在这种情况下，两种类型的沙发虽然都不能正常的提供「坐」的能力，也会受到致命损害。但是在受损临界点上的表现则也不同。
弹簧工艺的沙发在临界点上一定是承受力最低的零部件首先断裂或故障，导致沙发不能「坐」。而懒人沙发在不能「坐」时内部颗粒一定会同时不同程度受损。
小瀑布和敏捷
小瀑布和敏捷最大的差异是「团队」，在团队成员出现变化或超出能力范围时会出现类似「弹簧沙发」和「懒人沙发」的表现。
试想，在实施小瀑布的团队里，依然讲究明确的分工、流程化作业，一旦去掉某种职能（例如：QA），这个团队将无法正常交付产品。
而真正意义上的敏捷团队则不同：交付能力会受损，但依然可以交付。这是因为敏捷团队讲究：
• 跨职能，同时团队成员应该具备第二、第三技能；
• 职责模糊，例如：RD 和 QA 之前并没有明确的界限；
• 自组织，出现变化时将自适应、补位而不是等待调配。
从小瀑布到敏捷，我们该做什么？
多数身处小瀑布的团队，对敏捷的基础知识已经有了较全面的掌握，同时也有相当的实践经验。在这个过程中，多数团队也能够获得一些收益，例如：迭代时间变短了，交付能力提升了等等。
下一步，可能就需要做一些更深入的转变，让团队更加「敏捷」。
转变一：从单一部门到跨部门
开始实践敏捷（例如 Scrum）时，常常从一个小部门内部开始转变，而这个部门常常是研发部门。那么此时，研发部门就应该将敏捷的理念和成功实践向公司其他部门推广，帮助如产品部门、业务市场部门、售后服务部门更多地了解：
• 研发部门在做什么？
• 研发部门为什么这么做？
• 研发部门从开始到现在获得了哪些收益？
• 如果 XX 部门和研发部门一起实践，会带来哪些更大的收益？
而在跨部门沟通的时候，不应该仅仅局限于「敏捷开发」，例如精益创业、精益数据分析、增长黑客等和市场、产品和业务相关的话题更容易引起共鸣。
跨部门协作中，可以用到的工具方法包括：
• Impact Mapping（影响地图）；
• User Story Mapping（用户故事地图）。
转变二：从单一职能到跨职能
有时候，在实践敏捷的初期，只有开发工程师参与实践。那么在这个阶段，要尽早引入产品经理、项目经理和测试工程师。
在很多有一定规模的软件或互联网企业，产品、开发、测试很多时候分属于 3 个平行部门，而项目管理部门（常常被称为 PMO）又是另外一个部门。那么在这个阶段，就要找出适合的协作方式，尽可能让角色间的协作更接近于敏捷开发常常宣称的「跨职能团队」。不同团队有不同 KPI，所以这样的协作从来都不容易。此时的 Scrum Master（如果有的话）或者研发部门的负责人就要找到一个更好的协作方式，让不同职能团队之间的协作能够共同面向更高一级的目标。
可能的一些方式包括：
• 尝试跨部门合作制定 KPI；
• 针对某个项目，一起尝试建立虚拟团队，为虚拟团队制定针对整个团队的目标；
转变三：从流程改造到技能先升级
在这个阶段，要将对团队流程改进的关注逐步转移到对团队专业技能提升的关注上。通过一些集体活动，让团队加深对软件设计、设计模式、单元测试的理解。这些集体活动可以是：
• Mob Programming – 多人共用一台电脑进行代码练习或软件设计讨论；
• Pair Programming – 两人共用一台电脑写码，互相学习，促进生成第二技能；
• KATA – 个人或者集体练习，提高代码能力，训练 TDD 等。
同时，在团队层面，开始尝试持续集成、继续交付等实践。结合个人能力的提升，最终提升整个团队的交付能力和稳定性。
总结
如果把敏捷的全部收益看做是一棵苹果树的话，树上每个苹果就是我们实施敏捷后获得的一个收益。那么，当我们的团队已经熟练的做到小瀑布时，就相当于把这个苹果树上低垂的苹果都采摘完了。从小瀑布向敏捷转变的过程，是很多团队敏捷转型的必经阶段。我们只有不断地把敏捷实践推向更广、更深的范围，才能进一步享受到苹果树上更大更甜美的果实。
作者：高尔迈，福州迈向创新信息咨询有限公司创始人，福建省信息技术人才协会创办人。致力于福建地区推广 Scrum 和 XP 的敏捷实践。前百度91高级研发经理，从无到有三年打造一支高度自主的 Scrum 团队。QCon 分享嘉宾、Agile Tour 组织者。
