转载

大规模敏捷导入工具实践

看到金鱼哥2月18日发的一篇文章《规模化团队敏控创变之路》，介绍了通过分析问题根源，优化协作模式，最终在JIRA工具上实现了高效协同管理，使JIRA从一个被500人+规模的团队广泛吐槽的工具，成功转变为企业IT协同的关键系统。文章提到的关键思路和我的想法不谋而合，某些细节方面又有不同，我想结合自己团队的实践分享下我的思路，希望大家一起探讨。

原文链接在开篇已给出，建议有心人多读几遍，本文不做过多引述。

一、金鱼哥的思路

和金鱼哥的团队一样，我们的IT团队也在纠结，究竟JIRA的“Project”应该按产品还是按业务项目，此处的“产品”可以理解为平台的“功能模块或者子系统”，背后往往是一个相对独立的技术团队。

金鱼哥的思路是在JIRA中，项目（project）分为两类，一类是“产品项目”（自发性内聚性的迭代），即与其他产品组互不影响的独立任务，仅管理“Story - 子任务”两级；

另一类是业务项目，通常是一组需求集合，会涉及多个团队，在研发过程中会产生较多耦合，就需要增加一级“Epic”，完成项目和产品（即子系统）间的关联，以该“Project”的“版本”管理整体的“上线版本”，细分需求和任务拆解到各产品“Project”中，这就满足了需求负责人和项目管理者的成本计算和项目排期。与Epic原本的定义是匹配的。

在业务项目的“Project”中增加 “Epic”级并进行独立管理，是这套IT协同管理模式的最关键因素，金鱼哥对Epic做出了以下说明。

1）一个业务需求通常会涉及多个产品线，Epic作为最小上线单位，要完成一个业务需求，必定涉及多个Epic。

2）Epic已是IT部门对业务需求的拆解，业务部门更关注的是各业务需求的实施进度以及某业务需求各阶段实现的内容。

下文会基于我们团队的实践情况，对Epic进行详细解释说明。

金鱼哥团队的JIRA管理模式如下图所示（原图摘抄）：

大规模敏捷导入工具实践

二、我们团队的一些前提情况

1、业务方面的情况

我们是一个物流行业的To B综合业务平台，有独立业务部门对接市场和负责运营，产品经理并不直接接触一线，而是对接来自业务部门的业务需求，同时ToB的属性又决定了产品经理和研发团队天然不是用户，因此比较不容易出现To C平台的“产品创意及爆品大卖”现象，并且研发团队经常难以理解业务内容。

业务人员仅熟悉业务语境，并且通常不具备场景抽象能力，而研发团队仅能听懂系统语境和经过抽象的场景描述，两者之间存在巨大的沟通代沟。产品经理则处在一个夹心的位置，要把业务描述通过文档等手段转换成研发能看懂的系统描述，并在细节确认过程中负责两种语境的翻译。

当出现描述不准确、确认不及时、理解不一致的时候，产品经理就会变成两端的抱怨对象，甚至被吐槽成“无附加价值的传话筒”，对于此现象，产品经理无力推动解决又压力重重。

2、研发团队及系统方面的情况

目前按照子系统来划分的研发团队，团队会持续负责该系统的开发维护，团队的研发Leader既负责团队管理，同时承担应用架构师的职责，平台并没有独立的应用架构师团队。

按照主负责的系统模块，研发团队可以分成三种：特性团队、基础团队、小前端团队。

特性团队：交易、流程管理、结算等业务核心系统的负责团队，承担业务类项目的主要研发工作。

基础团队：支付后台、成员管理后台、技术架构团队等，自身系统优化类工作较多，在业务类项目中承担一些配合研发工作。

小前端团队：负责前端页面的数据展示，页面跳转、交互体验等，通常不承担业务逻辑的研发。

以上描述是有些理想化的，实际上系统间存在各种耦合，比如支付后台会有交易结算的业务逻辑，前端页面也承载了一些业务逻辑，因此团队工作会有交叉和依赖。

3、JIRA利用的现状

目前各团队在进行敏捷实践，对于细颗粒度的STORY和TASK进行了有效管理，但并未明确STORY与业务项目、自发迭代、Epic的关联关系并未确定。

以上情况会对IT协同造成不同程度困扰，为了提高工作协同和IT管理成熟度，基于JIRA流程，设计了“项目-Epic-Story-子任务”的四层级结构，并在实践中进行了试点验证，认为是可行的，正在准备推广。以下展开说明。

三、关键之处：拆分Epic

根据现状：业务团队提出业务需求，产品经理负责把需求变成方案，并形成业务项目。因此提到业务项目，可以等同于“需求实现”或者“业务方案实现”。

业务项目需要拆解成Epic，Epic的拆解原则是这个结构的最关键之处。

1、业务项目拆解Epic的原则

1）对于业务团队来说，业务流程图由Epic组成，Epic是业务与产品沟通业务场景的最小颗粒元素。

2）每个Epic都能分配给明确的特性团队去负责，由该团队PO负责分解成STORY，需要依赖其他团队完成的部分，以STORY的形式指派给其他团队。Epic仍然是最小上线单位。

3）业务项目由产品经理负责按照1）、2）的要求拆分成Epic，要得到研发团队和业务团队的共同认可，实现语境的统一。

2、对各团队提出的要求

1）对于产品团队，在讨论业务流程和进行业务模块拆分时，要以上述原则为前提进行拆解，而不是完全按照业务语境。这对产品经理的业务场景抽象能力和工作习惯提出了一些更高要求。

2）对于业务团队，Epic组成的业务流程可能比纯粹业务语言的描述稍微复杂，业务团队要理解并愿意接受。

3）对于研发团队，业务架构实际负责人要尽早进入项目，参与Epic的梳理，并确保每个Epic能够分配给一个主负责团队。

3、业务项目以外的Epic定义

为各个团队建虚拟项目，按照任务分类生成若干个Epic，等同于金鱼哥的“产品项目”，但仍然是最小上线单位，统一在“项目-Epic-Story-子任务”的四层级结构中。

4、Epic的重要作用

1）Epic是业务团队的输出，是研发团队的输入，是实现共同理解一致的基准，能够有效减少产品团队的转译，降低理解难度，提高团队对项目业务的理解程度。

以下图的项目级看板为例，左侧两个图表是项目迭代看板和业务流程图，每个纸片代表一个Epic，是图表的最细组成颗粒。

Epic流程图代表了所有干系人的共同理解，在看板上展示出来就能够帮助研发小伙伴了解到自己的研发任务在整个业务流程上的位置。

大规模敏捷导入工具实践

2）Epic是最小上线单位，原则上可以独立交付，每个 STORY属于唯一定的Epic。这样就明确了项目、Epic、故事的从属关系，方便在JIRA上以各种维度统计分析研发工作内容及绩效数据。

3）Epic中可以有跨团队的STORY，明确规定由Epic的主负责团队牵头进行跨团队协作，以实现更明确的分工。如上图中的依赖项，为其中一个主负责团队依赖他团队的STORY一览。

4）能够在项目中追踪“业务项目负荷程度”和“系统耦合”

对于特性团队来说，日常研发任务应该既有业务项目的Epic，也有系统优化的Epic。如果某个阶段研发任务全部是业务项目的Epic，则说明团队业务研发负荷过重，从而忽视了系统自身的优化，这样容易积累技术债务，贻害未来。

对于基础团队来说，日常研发任务应该以自身系统优化的Epic为主，如果工作中有很多来自业务项目Epic的STORY，或者存在自己主负责的业务项目Epic，则说明该基础系统的不完善，或者与其他系统耦合性过大，需要进一步分析。

对于小前端团队来说，日常研发任务应该以业务项目Epic的STORY为主，如果存在自己主负责的Epic，则通常说明承担了业务逻辑，要进一步分析原因。

如果有独立的应用架构师团队存在，可以利用这些信息分析系统耦合的情况，持续推动系统优化。

四、大规模业务项目的敏捷实践

对于大规模业务项目，参考SAFE的思路，按照以下分工进行推进。项目与三个核心成员：CPO、CSA、RTE。CPO即项目的主产品经理，CSA即主架构师，RTE即项目总的Scrum Master。由核心团队牵头，完成Epic的切分，分配给各团队的PO去继续切分故事；RTE为PMO团队成员，去引导协调沟通会议、协同各个SCRUM团队，对齐信息；如果目前没有独立应用架构团队，为了促进研发较早进入项目，提高Epic拆解的效率和准确性，通常会推动主要参与研发团队的Leader来承担CSA工作。

想强调的一点是，Epic是核心团队与各敏捷团队共同需要关注的点，需要定期频繁的对齐信息。

大规模敏捷导入工具实践