精益敏捷转型听起来很容易，但做起来很难，很多组织在数字化转型的过程的早期，一到两个团队作为试点团队进行敏捷转型，都能获得不错的转型效果。随着转型的持续推进，涉及到越来越多的团队转型，这时就会暴露出早期没有发现的一些问题。我们经常说量变引起质变，如何保证组织转型过程中，大团队从传统的瀑布式开发转变到精益敏捷模式的开发呢？今天我们不谈理论，不谈框架（SAFe，LeSS），我想从一个实操的方面来剖析一些我们实际遇到的困难和一些应对策略。
我们从以下4个方面来分析：
- 产品规划
- 多开发团队的协同
- 集成与测试
- 上线交付
我们知道在传统瀑布模式下会产生如下的一些问题
- 产品规划：规划流程长耗时，反馈慢，交接成本高，用户价值被工作交付物替代， 战略目标和价值息被衰减。
- 多开发团队的协同：研发流程长，问题到测试才会被发现，相互依赖严重，联调成本高，项目管理成本高。
- 集成与测试：集成耗时长，集成质量不好，修复问题繁琐，全流程测试缺失
- 上线交付：上线时间长， 上线后不稳定，上线失败。
造成这些问题的主要原因：
- 角色划分工作范围（内心：我只做这个）
- 部门墙重（内心：不是我的目标）
- KPI导向（内心：我只考虑完成我的指标）
- 角色技能单一（内心：我只会做这个）
- 任务依据技术分类拆分（UI，后台服务…)
- 节奏对不齐（我没时间联调）
- 系统关联依赖多（你先上API，我在上UI）
- 沟通不畅（内心：不要说出全部事实）
这些方面只是软件开发中很多问题的一个缩影，现在来让我们看看精益敏捷如何在这些方面帮助团队更好的完成工作。
首先我们一起看一下，一个敏捷团队如何在上面的几个方面提供更好的工作模式？
让我们来看看大致的过程：
- 产品规划有PO(产品拥有者）来负责规划，PO会在需求澄清会议上给团队（开发，测试，UX）讲解要实现的功能，
- 团队负责需求的开发，测试，交付。开发每日多次提交代码构建软件产品，进行持续集成和部署
- 测试同学前移到需求分析过程，参与需求讨论并输出测试用例，每天一旦发现缺陷，立刻快速修复，重新测试验收
- 在迭代最后，由团队给PO进行迭代演示，PO验收用户故事同时给出反馈结果。
- 团队一起对开发流程，协作回顾，找出浪费的地方，进行改进
这看起来还不错，团队解决了上面说的的那几个问题，
- 提高了交付价值的能力，由PO全生命周期负责产品。
- 减少了协同管理成本，团队具有独立交付能力
- 缩短了交付周期，减少了各种浪费（精益-7个原则：消除浪费).
- 提高了质量，频繁进行构建和自动化测试，更早发现Issue.
这样的团队符合精益敏捷的小团队运作，是比较理想的一种状态。但真实情况比这复杂很多，一个产品可能有很多这样独立自主的跨职能团队组成。这么多独立的跨职能的小团队，他们按上述过程完成自己的工作，是否就能实现产品的整体目标？答案是否定的，
首先我们建议在多团队下，请按照下图的架构来组建团队和团队与团队之间的关系。
优势在于：
- 跨职能独立的团队，减少团队之间依赖等待的浪费
- 产品领域按业务垂直拆分，可以交付完成的客户价值
- 由领域PO，领域DM负责整体业务和整体开发计划，各团队目标对齐，减少摩擦
- 领域内角色横向的虚拟组，建立起了连接，增强了整体协同能力
- 对于更大规模的业务，横跨多个业务领域，可以快速横向扩展
各个团队交付用户价值和产品整体战略规划对齐
当多个团队负责一个产品的时候，这个功能有那个团队负责，谁考虑整体产品价值等，都需要面对解决。首先从组织战略规划层面上明确商业愿景，通常我们使用EDGE中的精益价值树（LVT）来梳理愿景， LVT始于组织的最高层，一层一层传递，再反向传递成果。
其次当产品战略和目标清晰后，承接举措的就是一到多个跨职能团队。这些跨职能的团队根据自身的能力来和这些独立的小块工作对齐。 每一份工作都代表了相对对立的用户价值。 这些用户价值组合在一起整体实现了产品价值。
多团队的开发协同
- 多个团队服务一个产品时，迭代的节奏要对齐，同时启动迭代，同时结束迭代，好处在于多团队是按照同样的时间周期开发，容易对齐各个团队规划。在交流沟通时，大家是基于一个时间周期概念在讨论。
- 多个团队服务于多个产品时，这种情况就比较复杂。建议梳理团队工作，尽量支持一个产品领域，这时需要重新考虑各个团队承接的产品。
- 一个团队对应多个产品线，例如：基础架构团队，他们提供基础架构支持多个产品。这种情况下，有两种建议，
第一种拆分团队，把基础架构工作分散在各个团队中，这时团队依赖基础架构团队的情况就减少了。但同时也带来了另一个问题，就是基础架构没有统一规划标准，解决这个问题可以在各个对立团队中，建立横向的虚拟的架构守护组。
第二种建议，如果组织无法拆分基础架构团队，那基础架构团队就要把自己的工作当成产品来管理，就是说这个团队有着自己的架构规划和研发节奏。团队需要有相关产品PO，根据组织战略和各个产品特点来规划基础架构或基础服务。定期发布最新的服务能力。这类似微服务团队或现在比较热的中台研发团队。
在开发阶段，团队里的各个角色都可以组建成横向的虚拟小组。这和Scrum of Scrum有着异曲同工的左右。 为什么要组建这些横向的虚拟小组呢？ 因为单个独立的团队好比群山中的一角，团队只能看到自己，对于整体无法知道，现在在团队层面上，各个团队的角色横向建立小组，就是让每个团队信息共享给其他团队，使单个团队具备了上帝视角。可以看到一个产品的全貌，从而更好的完成自己的部分。
集成与测试
在多团队下，持续集成的技术就显得更为重要了。 团队对自动化建设需要持续投入，包括（代码仓库，自动化编译和构建，自动化测试，自动化部署等）关于持续集成技术有很多书和资料，这里就不在详细介绍。 但我们想表达的，团队需要投入一定资源在自动化程度的提高上面。一开始投入大于收益，但随着持续的建设，慢慢收益会大于投入。这里就需要一些策略，每一个迭代新增的故事都要有自动化测试跟上，对于已有的功能，构建主线流程测试，同时还构建了基本的冒烟测试。同时还需要培训测试人员如何写自动化代码。这些都需要领导的支持和组织的远见。
上线交付
多团队下的上线一直就是一个挑战。主要是每个团队只完美的完成自己的部分，对于依赖的部分由于信息沟通问题导致接口无法对齐或接口缺失，或全流程功能无法打通。
这里的建议就是：
- 在测试层面，各个团队的测试组成的横向虚拟小组来解决全流程测试案例的设计和执行。
- 在需求分析设计层面，由PO组成的团队负责整体功能的规划和拆分。
- 开发层面利用持续集成的技术，每天进行产品构建部署。缩短集成周期，减少代码冲突，提前自动发现程序接口问题。
当我们建立了持续集成流水线以后，我们要求每天数次的代码提交到主干版本，通过所有测试后自动部署到测试环境。 这样大大加快了功能集成。当我们要进行发布时，我们只需要在某个时间节点进行代码冻结，然后立刻生产新的发布分支，进行编译构建发布版本。这一过程在数小时之内就可以完成。
总结
以上是我们在大团队转型时遇到的实际问题，给出的建议大家可以参考，但切记不要复制，你可以从这些经验上找到自己组织的转型之路，因为转型需要文化、认知的转变，这些是无法复制的。你需要像煲一锅靓汤一样，高级食材已准备好，需要耐心，小火慢炖，让这些食材的精华逐渐融入进你的组织。
**更多精彩洞见，请关注微信公众号：ThoughtWorks洞见
**
