背景

我们公司的研发队伍有200人左右，1年多之前，我以总操盘手的身份，推动全部IT团队开展敏捷实践。所有敏捷团队都在以Scrum框架开展实践，利用 Jira 展开对 Story、Task 的敏捷管理。有的已经连续进行了20多个 Sprint 周期，开始主动重构自己的系统，大家都玩的很嗨。在这个过程当中，也有某些同事在转型中碰到了问题，甚至质疑我的方向。但最终我用结果证明了转型的正确性，同时在研发团队内推动形成了良好的敏捷气氛。

敏捷的四个范畴

关于敏捷，我的观点是，敏捷的含义很广泛，但可以被分为以下四个范畴，这是四个独立话题，有人说是不同级别的敏捷，我旗帜鲜明的表示不认可，我认为基本上没有关联，并不是包含的关系。我们遇到的敏捷问题，都可以归结到其中一个范围，思索和寻找答案也请在这个范围内找，否则疑惑会越来越多。

首先是组织的敏捷，现在是VUCA时代，面对互联网的冲击，各种传统行业的转折点在不经意间就会来临，应对不好就可能死掉。老板们已经认识到这一点，他们想建立更好的体制来应对。有一本书是专门讲这个的，《赋能TeamofTeams》跟IT并没有必然联系，投入大成本开展组织敏捷实践的，往往是传统跨国企业，比如麦当劳。

然后是适合敏捷的项目任务，在项目管理范畴里面，没有最好只有最合适，看任务本身适合什么。中国的互联网行业的特点，诞生了大量适合敏捷模型的项目，特别是从0到1的阶段，但无论你是否知道敏捷，你都会不由自主这么去做，因为他是符合人的正常认知的。但仍有大量的项目任务，并不适合敏捷模型。

再说个人和团队利用敏捷来提高自己。敏捷是一种心态，一种做事哲理。你可以利用敏捷来提高自己，跟你做什么并没有关系。Scrum的三个支柱什么？透明，检视，调整。你有没有仔细思索过这三个词？敏捷使人进步，你要记得敏捷对你的好，你要感恩提供机会给你敏捷实践的人。

最后说跨团队协同。在平台型多团队研发体系中，有各种问题，立场不同，目标理解不一致，沟通GAP，责任不清晰，问题很多。不管是DEVOPS还是SAFe框架，还是什么，都是为了解决问题的。怎么样形成良性循环，我的评估标准仍然是，是否有助于透明，增加共识和减少沟通成本。是否有利于发现问题？是否有利于改善和调整。

跨团队协同的难点

那么我们是怎么进行跨团队协同的呢？

首先说下我们所面临的难点和困境。我们做的是To B业务，研发者天然不是用户，业务不是生活场景，开发人员不明白业务场景和业务需求。掏钱使用平台的都是中小微物流企业的企业主，都是李云龙一样的草莽英雄，他们只想着性价比，能不能通过平台挣钱，他们虽然会为平台付费，但从来不是平台的使用者。使用者都是他的员工，因为老板的命令而不得不使用，因此从最终使用者那里永远得不到正面反馈。

我们的需求来自独立的业务部门，他们仅熟悉业务语境，而研发团队只懂系统语境，存在巨大的沟通代沟。产品经理则处在一个夹心的位置，稍有不慎，就变成了两端的抱怨对象，被吐槽成“无附加价值的传话筒”，两头不讨好，他们的自我价值感很低。

而我们的平台系统，处在业务核心建设的中后期，一方面要继续建设，前期积攒的问题又在爆发，架构不合理，系统耦合性高，随便增加点功能，所有系统模块都要跟着动，所有研发团队都要参与，因此项目规模很难缩小。

系统耦合性大，你中有我我中有你，责任不清，跨团队协同非常麻烦，同时架构的优化改造又很难找到抓手。找到原因，设计解决方案那么我们要如何去解决这些纠缠不清的问题呢？

找到原因，设计解决方案

基于对我们实际情况的思索，我们找到了问题的根因。

从两个维度来分析，从业务维度，业务项目关注的的业务的价值，关注的是承载价值的业务流程，也就是由价值块组成的业务闭环。这个价值块是业务语境，跟系统实际无关。他们不关注系统是怎么实现的，只关注上线时间。

再从研发团队维度，他们不对价值块负责，只对系统模块负责，期望按照自己的敏捷节奏做事。

在价值传递的过程中，由于价值块和系统模块之间的不统一，产品经理在把价值块落地到平台系统上的时候，会遇到很多难题。架构设计上扯皮，每个研发团队的理解，会产生很多不认同。在落地的时候就会非常艰难。

找到了问题的根源，也就有了解决方案，那就是从最开始，就要把价值块和团队绑定起来，明确好责任方。根据系统和模块的现实情况，团队是改造不了的，除非废掉平台，推倒重来。那么能改的，就是对于价值块的定义。

那我们是怎么设计的呢？

我们在 Jira 上定义了”项目 — Epic — Story — 子任务”的四层级结构。

首先明确所有研发团队的性质。承担业务功能研发的，承担底层及相对独立模块的，比如成员体系，支付体系，还有前端团队。为项目分类，大业务项目立项通过后由管理员建立，技术优化类项目有研发团队自己建立。那么Epic，就明确定义为之前所说的价值块。明确由某个研发团队牵头负责，属于某个唯一项目，在业务流程图和计划中体现，这个是最关键的点，下一页我会重点说明。

然后Story属于某个唯一系统，同时属于某个唯一Epic，不跨团队，由各Scrum团队自行管理。SubTASK又属于一个唯一的Story，由一个人负责。

既然是价值块，不可能仅涉及一个团队，但是又由一个团队负责。怎么办呢，需要其他团队完成的部分，以Story的形式，指给其他团队。但是由Epic责任方承担跨团队沟通责任，作为依赖项进行明确的管理。这样，就界定了责任。从一开始避免扯皮。

这其中，最关键的点，就是拆分Epic！

对于业务团队来说，Epic是沟通业务场景的最小颗粒元素，组成业务流程图。Epic及业务流程图是是沟通业务方案的终点，但同时是技术团队沟通系统方案的起点。Epic的内容从一开始就要得到业务团队和研发团队的认同，务必要实现语境的统一，这样就形成了所有人理解一致的基础，避免了在价值传递过程中的转译。

在拆分Epic的时候，要考虑系统的现实情况，确保要以某个团队为主，让这个团队承担责任。而这个Epic中，需要其他团队完成的，由该团队的PO与其他团队PO协调一致，指给其他团队，刚才说了，有负责Epic的团队，承担跨团队沟通的责任。

这实际上，对各团队都提出了高的要求，不提高要求怎么能进步呢？同时要求各团队要向对方走进一步，不靠近怎么实现透明呢？

对于产品团队来说，进行业务模块拆分时，要充分考虑系统现状，这对产品经理的业务场景抽象能力和工作习惯提出了一些更高要求。

对于业务团队，Epic不仅仅是业务语言，不仅仅是价值块，还包含了系统因素，他需要多了解一些业务和系统的结合。

对于研发团队来讲，从一开始，就知道了可能要负责某个Epic，他必须提前进入项目，了解业务，参与Epic的梳理。

这种高要求，同时会促使团队的进步，这种大家共同促成的语境统一，降低了沟通难度，提高了合作水平。

项目实践中的经验分享

在具体工作中，我们除了各个团队的看板以外，还设立了项目看板，每周更新一次。由三个部分组成，业务流程图，项目迭代看板，各团队依赖项看板。

首先我们把业务流程图画在墙上，当然不是所有模块都需要研发，很多是利用现有模块的，大家可以看到，上面的的每一张贴纸，都是一个 Epic，代表了任务。我们可以完成一个 Epic，就把这张纸撕掉扔掉，流程图仍然在上面。这是业务流程图。

再看项目迭代看板，每一行是一个团队，每一张贴纸，代表了他负责的 Epic。这样就是这个项目的整体进度。思路清晰的不得了。

再看依赖项看板，这是其中一个团队的。把这个项目迭代中的所有依赖项都写出来了，主要是要对方提供接口。每一行是一个团队的。每一张都是指给别人的 Story。在每周的项目站会上，大家以统一的基准过进度，确认问题。所有的问题，都可以定位到某一个 Epic，很容易确定问题范围。极大的降低了沟通复杂度。看着业务流程图和迭代看板，研发小伙伴很容易知道在做哪一个模块，在业务链条上处在什么位置。

同时各个团队有自己的 SM 和 PO，又明白了在跨团队沟通时的主从地位，在依赖项看板前沟通问题，就不用扯皮了，责任一目了然，进展一目了然。

在实际实践过程中，效果非常好。详细的内容，我们整理在 Confluence 上，包括项目情况，业务流程图，包括依赖项。

还有产品+研发团队的回顾会，大家会讨论Epic的划分是否合理，会讨论发现了哪些可以系统优化的点。这样，我们实际上走在持续改善的道路上。

除了之前介绍到的理解一致外，增加了透明，降低了沟通难度，明确了任务的标准，是 Epic 还是 Story，还明确了责任，跨团队沟通中，谁是责任方，我们还能够从任务分配和 Jira 数据统计中，发现我们系统的问题。

对于业务研发团队来说，如果任务都是业务 Epic，而缺少系统优化的自建 Epic，则说明团队业务研发负荷过重，从而忽视了系统自身的优化，这样容易积累技术债务，积累风险，贻害未来。你们可能在生产 BUG。需要加以平衡干预。

对于基础研发来说，他们的主要工作是系统能力的沉淀，和业务项目的支援，比如一些对外提供接口的 Story 任务。如果他们承担了独立的业务 Epic，或者业务项目的 Story 过多，则说明基础系统需要继续解耦，或者架构不合理，你做了哪里，就说明哪里有问题。

  对于小前端团队来说，不应该承担业务逻辑，如果出现了独立的 Epic，或者业务逻辑 Story，那么做了哪里，哪里就有问题。需要将逻辑还给业务编排层及以后，逐步实现真正的前后端分离。

我们说，好的需求是涌现出来的，系统优化的点，也是不断涌现出来的。通过这个流程，我们就能够实现能够落地系统方面的持续改善。适时的改善，有业务价值的改善，不是自嗨的改善。

工具为辅，思想认知为主

讲到这里，大家发现我并没有讲到太多的 Jira 和 Confluence 这些工具的使用方法。

对于工具，我的观点是：工具可以做为技术的辅助，但更重要的是使用者的思想认识；我们既要尊重现实情况，又要尊重团队各角色的需求，也要保持一定的专业度和立场，才能达成能够落地的协同，最终形成合力共同迈向目标。无论是 Jira 还是 Confluence 都是很灵活的工具，本身提供了很通用的管理要素，我们可以根据实际的需求把这些要素进行组合，把适合自身的管理和协同思想融入进去，不断实现良性循环，不断提高交付能力。