由小型开发团队支持的多个产品

Question

我管理着一个团队，有七个开发人员，拥有十多个产品和20个产品之间的集成。一年前，我接任了这个团队，我们一直在努力在团队中传播知识。一年前，每个开发人员基本上都是几个产品和集成的筒仓，使我们变得非常脆弱。情况有了很大改善，我们今天的处境要好得多。这是通过共同开发和配对编程的有机和临时处理。

最近，一些开发人员提出了一种更结构化的方法，以确保我们的所有产品和集成在团队中广为人知。他们希望每个开发人员对他们可以被要求进行更改的系统承担特定的责任范围。因此，系统x中的开发只能由developer x、y或z完成，而不是由开发人员a、b或c完成。

首先，我认为这是个好主意--每个人都不应该什么都知道。但仔细想想，我也能看到这种方法的一些不利之处。很难计划冲刺，并确保工作与这些限制平均分配。我们的结局可能是开发人员在sprint结束时没有什么可做的，而其他开发人员则负担过重。这并不像一支承担冲刺责任的团队。此外，我们也可能被迫在冲刺中做一些不那么有价值的工作，以确保每个人都有工作。

是否有任何最佳实践或经验，您可以分享，有一个灵活的团队，没有太多的脆弱性？例如，如果有准确的语言和框架、通用代码实践、文档完整的代码、经过良好测试的代码和良好的评审过程，那么要求开发人员在许多产品中工作是否现实？还是我们必须为某些产品指定特定的开发人员？

Answer 1

当然，scrum只是一个框架，您可以根据自己的需要进行定制，但据我所知，它并不适用于一个拥有多个项目的团队。对于这种情况，kanban是一个更好的方法。

此外，学习一个项目是学习一个特定的历史时代，它不能仅仅通过阅读来实现。开发人员应该阅读代码和文档，与前面的开发人员/业务涉众交谈，练习用一些实际问题解决问题。这需要时间。如果您将此与多个产品相乘，并保持开发人员的周转率，您将发现实现您所设想的目标是不可行的。

我建议的是为每个项目准备一本运行簿，并使用导航器&驱动程序模型进行一对编程会话，并设法使至少有2名开发人员掌握一项产品，并在入门级(至少帮助他们构建和调试该产品)了解其他人的情况。这是我关于这种方法的文章。

Answer 2

似乎你和团队在过去一年的努力打破了知识筒仓(通过共同开发和配对编程)。如果是这样的话，开发人员具有T型专业知识；对大多数产品/集成以及与特定产品相关的深厚历史专业知识以及他们的技术技能集有着广泛的理解。如果取得进展，我将采取分阶段责任小组的做法：

社区规则：与每个责任组关联的定义需要共同定义。它们不应该太窄，这样在Sprint时，责任很少与DEV成员保持一致(认为OR's not和‘s)。最初的想法要么是语言/框架、具有特定产品的历史专业知识，要么是过程角色(例如质量保证)，但是您和团队最了解。责任组的定义以及DEV团队的自我分配应该记录在案，并且可以在团队可访问的位置上使用。

代码评审:负责小组内部的人员在合并前审核拉请求。无论人员/对是否属于责任组，这都会生效。特别是当代码由责任组内的人员提交时，责任组中的另一个人的评审确保技术专长被分发(技术领域的对等学习)。

如果团队喜欢在他们的专业领域(责任小组)内做出贡献的过程，那么所有DEV成员都以平衡的方式(如果不是审查责任组)为代码评审做出贡献，而且他们仍然希望更进一步，然后我将介绍一个试验时间框架和容量规划王牌。

试验时间框架：--这是一个带有结束日期的实验，而不是一个永久的进程更改。实验持续时间应足够长，以观察基于责任小组的能力分配过程变化是否具有团队所期待的积极影响(提高工作场所joy的技能适应/降低职业倦怠风险、提高工作速度等)。预定义的结束日期提供了一个思考和决策点(继续或停止)的机会.如果团队在成功度量上预先达成一致，这将使评审更加顺畅。

容量规划王牌:如果代码评审是以平衡的方式进行的，那么一般情况下，跨sprint的容量规划也应该是可行的。在冲刺计划中，重点将放在与社区规则保持一致上。但是，如果容量(与责任组分配一致)与sprint工作负载不匹配，则sprint完成将超过责任组分配。根据团队成员的能力，根据责任小组，填补空白。冲刺到冲刺，同样的DEV成员不应该被迫离开他们的责任小组。如果是这样，则需要审查社区规则。

Answer 3

我不认为看板是真正的解决方案。我用看板来解决生产问题，用scrum来进行标准开发。

因此，基本上，问题是组建一个团队A和团队B，并将责任分开，答案确实取决于产品的复杂性和它们所产生的工作量。交叉训练是非常好的，但总是有限度的，而作为一名经理，如果你最了解情况，就必须做出判断，或者做一些AB测试。在我的经验中，变化和变化确实避免了倦怠。

你也可以问一些问题，比如资源不足？或者是产品过时了，是时候更换或重建了？

我希望我有一颗灵丹妙药，但实际上这取决于你和你的团队在最后阶段，所以我的建议是避免倦怠，改变和拥抱改变，跳出框框，可能是退休一些产品，做一个团队轮换制，就像在团队中的3个月，开始一些重建，以保持团队的积极性和学习新的东西，其他可以雇用更多的开发人员远程更节省成本。