0

我管理一个由七名开发人员组成的团队，拥有十多种产品和 20 种产品之间的集成。一年前我接手了这个团队，我们一直在努力在整个团队中传播知识。一年前，每个开发人员基本上都是多个产品和集成的孤岛，这让我们非常脆弱。这已经有了很大的改善，我们今天的处境要好得多。这已通过共同开发和结对编程有机地和临时地处理。

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

首先，我认为这是一个好主意——每个人都不应该知道一切。但是仔细考虑一下，我也可以看到这种方法的一些缺点。计划冲刺并确保在这些限制下平均分配工作变得非常困难。我们可能会在开发人员在冲刺结束时无事可做，而其他人负担过重的情况下结束。这感觉不像是一个团队为冲刺负责。此外，我们可能会被迫在 sprint 中进行价值较低的工作，以确保每个人都有工作。

关于拥有一个没有太多漏洞的灵活团队，您是否可以分享任何最佳实践或经验？例如，如果有确切的语言和框架、通用的代码实践、有良好文档记录的代码、经过良好测试的代码和良好的审查流程，那么要求开发人员在许多产品中工作是否现实？还是我们必须将某些开发人员分配给某些产品？

4

2 回答 2

0

当然，scrum 只是一个框架，你可以根据自己的需要进行定制，但就我的经验而言，它不适用于拥有多个项目的团队。对于这种情况，看板是一种更好的方法。

此外，学习一个项目就是学习一个特定的历史时代；仅靠阅读是无法实现的。开发人员应该阅读代码和文档，与以前的开发人员/业务利益相关者交谈，练习解决一些实际问题。而这需要时间。如果你把这个和多个产品相乘，并保持开发人员的流动率，你会发现你的想法是不可行的。

我建议为每个项目准备一份运行手册，并使用导航器和驱动程序模型进行结对编程会话，并尝试让至少 2 名开发人员掌握产品，并且可以选择其他人在入门级别上了解，这至少可以帮助他们构建和调试它。这是我关于这种方法的文章。

于 2022-02-03T04:16:42.610 回答
0

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

所以基本上，问题是组建一个团队 A 和团队 B 并将职责分开，答案实际上在于产品的复杂性和这些产品产生的工作量。交叉培训非常好，但总是有一个限制，你作为一个最了解情况的经理必须做一个判断电话或一些 AB 测试。根据我的经验，变化和变化确实避免了倦怠。

您还可以提出诸如资源不足之类的问题？或者也许产品已经过时并且需要更换或重建？

我希望我有我可以建议的灵丹妙药，但最终这取决于你和你的团队，所以我的建议是避免倦怠，改变并接受改变，跳出框框思考，可能会淘汰一些产品，做一个团队轮换，例如 a 团队 3 个月，b 团队其他 3 个月，开始一些重建，以便团队保持积极性并学习新事物，其他可以聘请额外的远程开发人员更具成本效益。

于 2022-02-03T07:37:59.337 回答