规模化敏捷下小队的协作机制

点击👆蓝字 关注我们

本文作者｜陈泽荣

导语

为什么要实施规模化敏捷？我们认为规模化敏捷本质上是对抗组织熵增的过程，当组织中的人员增加，小队数增加的时候，我们意识到组织的研发能力并没有想象中的产能线性提升，研发产能和人数呈现的是一条亚线性曲线，这种现象我们认为是组织的熵也随之在增加。

伊利亚·普利高津（比利时物理学家，也因“耗散结构理论”而获得1977年诺贝尔化学奖，这个理论是和“熵”有关，也是至今为止唯一因复杂科学研究而获得诺贝尔奖的得主）提出：在一个开放系统里，有两种力量在打架，系统到底走向无序还是有序，取决于两种力量哪个强。一个是“熵产生”，一个是“负熵流”。

类比到组织研发系统中来，人数每增加一个，就无形之中带来了“熵产生”，因为每个个体都有主观能动性，都是信息的传播者和保持者，人与人协作的摩擦、小队和小队之间的协同摩擦都是“熵产生”的主要来源，而我们要做的就增大的“负熵流”，这个过程要对抗的就是协同无序、信息不透明、规范不清晰等可能导致“熵产生”的“罪魁祸首”们。

让组织协同更加顺畅本质上是减缓熵的增加，相当反向减熵，也是负熵流，但是绝对不是组织唯一的负熵流，对应大多数组织而言最大的负熵流应该来自与外界的能量交换，如利润。

规模化敏捷的背后诉求

回到规模化敏捷，笔者认为绝对不仅仅是一堆小队做敏捷实践就可以了，本质上还是希望通过透明协作流程和机制，让需要相互协同的小队了解彼此的流程和机制。其次是可以通过标准化流程构建研发数字化，发现实践和流程是否要改进。当然这个过程不是生搬硬套的，我们需要深入小队的运作过程中，识别问题，发现可改进点。本文重点也是在小队层面的实践（有关组织内大规模协同的版本火车的内容参考公众号相关文章和直播，不做赘述），更多是在实际的小队运作中抽取的共性问题，提出实践中可行的解决方案，以供读者参考。

关于工作流程的标准化，当代著名的管理思想家明茨伯格提出的五大协调机制里也提到“工作流程的标准化”和“工作输出标准化”，本质是希望将研发流程中的一些活动固化下来，做到标准化，同时在跨职能角色的协同上做到相对的职责分明。

组织要做全面研发效能数字化前提是必须有标准化流程和协作机制，基于协同下产生的数据，反馈出团队的协同运作是否存在改进点，这是在这个组织规模化敏捷中的重要抓手（本篇主要在小队协作上，更多度量内容请移步公众号其他文章）。

本文更多是聚焦于规模化阶段如何构建小队的协作机制，以贴合小队的实际运作，解决实际研发问题。

规模化敏捷下，小队协作机制的三项重要实践

在研发小队的日常运作中，笔者认为有三点是跨职能协作中不可忽视的，因此这一部分内容着重点主要是在相应的三个实践上：

01

第一个

业务或者产品经理将需求交接给到研发侧，需要两边进行评审达成达成共识，称之为技术评审；

02

第二个

产品、业务、研发需要协商优先哪些需求在接下来的版本里面开发，称之为「需求排期」；

03

第三个

研发内部，开发和测试的协同，大多数敏捷方法论强调的是流式移测，在本文中我们也会讨论流式移测的必要性。

实践1：技术评审

现实研发过程中，我们经常面临这样的场景：业务希望研发能及时反馈需求能不能做？要多少人天？，但是研发普遍不会轻易给出这么个评估，一是需求质量没达到评估标准，二是评估和承诺混淆在一起，最终导致双方不满意，业务得不到需求质量反馈和工作量的及时反馈，吐槽研发太慢，而研发普遍吐槽需求质量不高，需求经常变更（但是有可能是研发终于给出反馈了，但是业务认为这个需求先不做或者调整方案）。

我们认为技术评审是业务或者产品经理和科技正式交接需求的第一道关卡，需要达成一定的目标。至于这一道关卡设在哪，不可两眼一抹黑就一刀切，要因组织而异。我们认为主要还是和组织的角色定位有关，例如下面2张图分别代表2种不一样的协同机制。

第一种，产品经理是在科技侧，针对业务提出来的需求评审要在需求分析之前。

第二种，产品经理是业务侧的为主，业务需求分析主要由业务侧的产品经理把控，这个时候技术评审在具体的需求分析之后。

上述的价值流以及相应的技术评审活动的的设置，不是唯一标准，更多时候要基于组织内的真实情况进行设计且组织内的流程和规范也不应该太个性化。

这个实践活动的本质是缩短科技和产品侧的反馈环，产品侧给出需求的预期，开发及时给出规模和可行性的反馈。不管是规模、预期、还是可行性，都会影响需求的优先级排列。无形之中，我们给这个活动定义了一个粗略的准出规则：技术评审中可以进行估算和有上线预期的需求才会往下流转，在这个“规则”之下，可能我们会面临以下几种情形：

01

情形1

研发没法评估出来人天，有可能需求完全不清晰，范围不明确，需要进一步讨论，这个时候需求是不能往下流转的，意味着接收方（研发）并未完全接收需求，需要业务方对需求的目的和范围进一步细化后（相比之前，这种情况下，可能科技的产品经理就拿了个不确定的需求去做分析了，要么过程重复确认浪费双方时间，要么需求加工结果和业务出入较大，造成浪费），要待第二次评审。

02

情形2

研发已给出了人天评估，如果工作量和预期差距太大，这个时候就有可能触发产品和业务进行需求裁剪（例如：一个需求要两个月的工作量，而业务要两周要上线。这件事取决于一是否有完全充足的研发资源，二是否能够把现在手头的需求都暂停掉来专攻该需求。但是大概率情况是裁剪需求、调整方案。），这个时候可能会出现不同需求方案对应不同的工时投入，这个时候应该和业务进一讨论方案再让需求流转到下个转态。

03

情形3

大致上评估和需求的预期上线时间严重不符，需要产品和业务进一步拆分或者思考短期方案，如同情形2。

04

情形4

估算人天太大，没法单版本上线，要经历好几个版本才能上线，这个时候视业务或者产品的验收需要进行拆分。

05

情形5

大致上能给出人天，且业务没有太大的异议，且科技能大体上判断期望计划上线时间并没有太离谱，那这个需求就可以正常流转。

我们认为以上种种情形，原则上只有情形5是可以被挪到研发“蓄水池”待排期中的，其他情况理论上应该是待确认，不进入待排期。

这个实践向业务方传递一个信号，需要推动需求通过技术评审，才认为是真正的需求交接，而且我们认为在这个实践上科技容易“自误”，放低标准或者允许部分需求悄悄走特殊通道，这将对各方协同带来信任危机。

相信有人会问，理想很现实，现实很骨感。假如说研发已经没有其他需求做了，难道需求评审不过就不做吗？要卡这么严吗？在我们看来这种情况是没法避免的，但是有了这个机制后，我们就可以制定相应的度量指标来观察需求评审阶段的情况。如：统计移入待排期（或者已规划）后需求的人天估算、计划上线时间、负责的小队和负责人的填写情况观察该活动是否运作正常，以及技术评审前后状态的停留时长是否过短，等情况，如果太短，说明需求一评审就过，可能要警惕评审质量不高。

实践2：需求排期

需求排期：对已经达到一定需求质量（能相对准确评估工作量，提测时间，验收时间，识别出了关联方，开发测试能具体到人）的需求进行版本排期，同时将需求拆成对应的系统功能作为研发的迭代规划输入。

技术评审和需求排期是不是可以一起开，取决于团队的成熟度。通常如果在技术评审后会有因为需求依赖多，复杂度高等情况需要二次确认的情况，我们是建议至少有2天的时间间隔召开（具体的时间取决于团队需求本身的复杂性，是否有跨团队协作，是否有多个业务方等因素）。两个环节错开的目的是，第一，让需求在有足够的积累下，能够进行优选；第二，确保进入开发的需求质量；第三，需求纵向拆分系统任务到小队。这个活动上，再次明确需求计划上线时间、需求计划验收时间、需求估算矫正、任务的估算、任务的提测时间，并且将需求从待排期挪到已排期。

需求排期本质上是一个决策点，在一堆需求里面决策需求什么时候做，而且这个过程应该是邀请业务方参与的，而且排期了的需求的确定性80%是可以交付的（100%不行吗？不行，追求确定性容易带来科技的自我保护和保守估算），这个指标我们称之为为迭代/版本完成率，是规模化敏捷阶段观察的核心指标。且对于相互协同的团队，只有将协作需求的系统功能排期了才算是真正给予承诺。

我们希望需求排期的需求是从待排期的就绪池里筛选出来的，此举的作用是——第一：从待排期的需求池里进行优选比全量需求里优选容易得多，成本也比较低；第二：进入研发中的需求都是高质量的需求。我们可以通过排期前后停留时长来进行观察，如果这两者的时效太短，则我们要审视需求排期质量了。

实践3：敏捷开发测试

现在大家一提到敏捷开发测试，大部分人的反应就是“需求要拆分到3人天”，“每个需求开发完成就流式移测”......这就一定是对的吗？我们说对了一半，这需要基于特定的上下文——团队对需求的响应要求很快、测试资源相对比较紧张、探索性需求需要更快的反馈周期等等。但是，事实上在规模化阶段，并不是所有的团队都是上述的处境之下，因此开发测试的是存在批量移测的。团队需求拆得越小或流式提测的要求越高，团队所投入的人力越多。相反，团队需求颗粒度较大或大批量移测，团队存在更大的质量风险。所以在规模化阶段，开发测试视紧迫程度而定，而不是一味地追求流式移测。但是需求的横向拆分成小需求，纵向拆成任务的还是有要求的，但是挪到待测试的任务是否立马测试，取决于团队的测试人力、紧迫程度、反馈时效、提测质量。

这个实践为什么单独说呢，敏捷开发测试都说烂了。但是这里想传达的观点是团队可以批量移测。这在敏捷教练看来就是“大逆不道”，怎么能批量移测呢？但是规模化敏捷阶段不同小队的开发测试配比不一致，也取决于紧急程度。但是单故事，单任务的单独可测试依旧是不变的旋律。

需求层面我们不强调需求一定是3人天，但是一定是单版本可上线的。在开发阶段的短期，我们注重风险的管理，开发人员测试人员的协同精细化到系统任务，站会实时关注系统任务的时效和移动情况，同时也强调任务一定是来源于需求的（技术需求或者业务需求等）。

规模化敏捷下跨小队协作

笔者经常在客户现场听到各种跨小队协作的痛点、抱怨，更多是寄希望于工具来提升协同水平。但遗憾的是协同本质上还得回归到人，工具能协助信息透明但是解决不了跨小队协同上的摩擦问题。

技术评审阶段，产品经理初步识别关联方小队，并邀请管理关联方的小队的小队长共同参与到技术评审中来，共同识别需求的可行性和规模。

需求排期阶段，应该是和关联方小队一起排期，关联方主要参与角色是小队长。原则上，有关联的需求，需要双方约定好是共同版本还是前后版本，确定联调时间，前后版本则警惕发布时间差距过大的情况。

在开发测试阶段，原则上是在本小队内先走完开发测试，按需mock外部请求，再根据约定好的时间进行联调测试。甚至当联调需求复杂，依赖方多时，建议是集中面对一起联调（或者通过会议形式）减少等待时间。

写在后面

规模化敏捷对抗组织熵增，从研发系统来看，随着人数的不断增加，熵增主要来源将会是人与人的摩擦，小队与小队的摩擦。而在规模化敏捷小队的协作上我们要识别并挖掘标准活动/动作，根据以往落地经验也总结了三个活动——技术评审，需求排期，开发测试协同，且也明确表达每个活动应该有自己的活动规则，涉及跨小队协作情况应该按需要求对方参与关键活动，这个阶段我们也会用迭代/版本完成率来牵引小队的各个活动最终执行的成果，是个结果指标。

另外我们也将收获基于小队的日常协同来构建研发效能数据，从而能够在组织级进行看数改进，进一步能够为组织资源投入优化提供决策依据。

END

点分享

点收藏

点在看

点点赞