我在这家公司带的团队规模较大（开发+测试总共16人），涉及业务域也较多，很显然引入敏捷scrum开发模型针对16人的团队沟通成本和管理成本会较大，如何有效提升团队开发效率降低管理成本的同时，又能避免沟通不畅造成线上问题就成为一个比较棘手而又关键的问题。方法有很多，我所做的就是引入SoS模型（scrum of scrums）。
先简单介绍下什么是SoS（scrum of scrums），简单来说SoS是一个机制，它是由多个scrum团队负责人定期协作整合沟通拉平共识的机制。主要是解决大型的多敏捷团队的沟通协作问题。
回到我的实践上来，首先根据团队人数和业务域情况，我调整了人员，划分了两个特性化的scrum敏捷小团队，人数分别是10人和6人，然后各自团队有一名SO（Service Owner）可以理解为团队负责人，另外大的团队又有一名TO(Test Owner)负责统筹团队测试，另外再加我作为PM，而在两个scrum敏捷团队上面又加上了由PM、SO、TO所组成的敏捷小组，大致架构如下：
平时两个团队正常按照sprint冲刺，规定每周五下午下班前SoS机制会执行，由PM组织，两个团队的SO,TO,PM会进行碰头会，两个团队会沟通本周所做的内容，下周的计划，是否需要对方团队协助或者是否对对方分支代码有所影响。在冲刺第三周前的周五TO会特别强调本来迭代冲刺测试侧重点或者注意点，会议类似于每日晨会，时间在5-10分钟左右。
SoS机制实践结果：对比之前两个团队业务相对独立，但是代码并未完全剥离，在没有有效的沟通机制下两个团队出现过代码合并问题，重复开发浪费问题，另外两个团队虽说相对独立，但是处于业务的上下游也还是存在一定的影响。在机制实行之后两个团队能够有效的沟通及时拉平共识，特别是在现状下，开发集成时能及时发现规避掉一些问题，目前实行结果不错。
SoS当然也会存在一定的问题，最大的问题还是在于沟通链路增长，需要进行二次沟通，由原本扁平化变为二级的沟通。但是对于大规模的团队来说，SoS还是一个比较可行有效的机制能够辅助团队进行敏捷管理。
网友评论