如何在保持业务敏捷性的同时实现微服务的所有权？

Question

我很难调和一些好的建议，涉及到微服务体系结构、敏捷和DevOps，这些建议在我的脑海中是相互排斥的。

一方面，我们建议每个微型服务都应该有一个拥有它的小型的、两个比萨饼的团队(例如，参见“每队发球”)。这就是我为之工作的公司采用的模式。这种方法有几个好处：

• 认知负荷保持在低水平。(一个巨大的“职业者”)
• 团队为保持他们所拥有的服务质量而感到自豪。
• 团队能够强制执行新代码符合他们的编码标准和设计原则。
• 团队知道他们对他们在生产中的服务表现负有明确的责任。

当您将我们的微服务的状态与我们的monolith的遗憾状态进行比较时，这些好处是显而易见的，而monolith是集体拥有的，因此没有人拥有。然而，也存在一些挑战，我看不出如何在这一框架内调和这些挑战。即：

• 任何大中型项目的复杂协调。简单的故事可以由一个团队自己实现，但是任何更复杂的任务最终都会跨越不同团队拥有的多个服务。团队最终会等待其他球队来完成他们的任务。
• 高WIP。必须分配工作，以使每个团队在任何时候都很忙。一旦一个团队为一个更大的项目完成了他们的任务，他们就会寻找其他的事情去做。他们实际上被禁止帮助其他团队完成剩下的项目，所以他们承担了一个新的项目。
• 狭窄的价值流在这种“每个团队服务”模式的理想化实现中，团队是解耦的，他们的工作不需要其他团队的投入。即使这可以现实地执行，您最终也会有与您所拥有的团队一样多的项目在运行。整个组织的WIP仍然很高。每个团队都是一个价值流，任何价值流都不能超过9个左右的工程师。
• 次优排序团队可用性成为确定项目优先级的关键因素。因此，给组织带来相对较少好处的项目可能会优先于具有更大潜在回报的项目。
• 它不缩放。不容易:为了添加一个团队，您可能需要首先重新架构一个现有的服务，并将其分成两部分。即使一个团队已经拥有多个服务，因此一些服务的所有权可能被简单地重新分配给新组成的团队，但最终仍然会增加切换和前几点中列出的所有复杂性。

问:在你看来，由特定团队独家拥有微型服务是一个值得追求的目标吗？其他组织如何管理它？这会更好地让所有团队在相同的价值流中共同拥有服务吗？如何在不过分限制组织将资源分配给最高优先级项目的能力的情况下，限制工程师所经历的认知负荷？

我意识到上面我假设服务的所有者将是唯一的团队在做它的工作。这种情况可能不一定是这样的:如果其他车队提交拉力请求进行业主审查，所有权也是完整的。然而，审查和潜在的测试，仍然是需要业主进行的工作。另一方面，团队往往不愿意承担与他们缺乏经验的服务相关的工作。

Answer 1

尽管“每个团队的服务”方法是常见的，但是如果您认为微服务是一个更广泛的系统的组件，您可以考虑与流对齐的团队，可能与平台团队或复杂的子系统团队(视需要而定)。与流相一致的团队将跨服务工作，而不是专注于特定的用例或用户段。许多不同的流所使用的高度复杂的服务或核心服务可能会得到更专业的团队的支持。仅仅因为您的系统有一个微服务体系结构，并不意味着您的团队需要遵循同一个组织。

这解决了每个团队服务方法的许多问题，但它仍然需要协调。团队需要了解跨服务的变化，如果多个团队需要同时(或非常紧密地)更改同一服务，则可能需要协调。

内源技术也可能很有用。虽然您可能有一个团队拥有一个服务或一组服务，但是您可以应用开源技术，如问题、讨论和拉动请求来创建一个社区，在这个社区中，任何遵循开发标准的人都可以为服务做出贡献。它缓解了一些担忧，但需要服务器所有者团队的人员来审查和接受工作，而冲突的优先级可能仍会妨碍工作。

你也可以采取一种更极端的方法来淘汰团队。虽然我从未使用过它，但我看到了更多对动态重组和像敏捷的流体缩放技术这样的方法的兴趣。如果您的整个产品团队的规模不是太大，您可以使用方法动态地组成和改革整个产品的团队。这些技术可以在整个开发组织中传播知识，但可能会被视为更激进或极端。

您采取的方法确实取决于组织。有些组织可能对拥有服务和处理问题的团队非常满意。其他人可能愿意尝试其他的结构或做法。不过，不会有银弹的。没有一种方法是完美的，而且会做出权衡。

Answer 2

这里没有普遍的对错。这取决于你愿意投入多少资源，以及你希望防范哪些潜在的未来问题。

这里的类比就像比较超级跑车和坦克。超级跑车是高性能，但没有弹性的问题，而坦克不是高性能，但是相对弹性的问题。

“每队发球”是一辆超级跑车。通过将给定服务的认知负荷保持在最低限度，这具有很高的性能，而且在日常开发中，在需要管理和与更大的团队进行沟通方面浪费很少的时间。然而，这个系统对问题没有弹性(例如，员工变更、预先编写文档、突然需要更多的开发人员快速开发新功能)。

对于一个新开发人员来说，对团队中突然出现的需求做出反应需要时间和精力，因为要了解他们还没有花去学习的诀窍需要时间。

商业敏捷性在这里是一个坦克。它效率不高，因为它要求开发人员参与更多的项目。在日常开发中，由于这种情况，事情会稍微慢一些。开发人员花更多的时间阅读他们不经常使用的东西的文档，或者花更多的时间更新他们远离的东西。

然而，当您到达众所周知的坑坑洼洼，例如，开发人员缺席/离开，在开发中突然出现的特性，.该公司几乎能够立即部署任何一个开发人员，以便在需要时提供协助，因为大多数开发人员已经在日常敏捷开发中先发制人地掌握了诀窍。

两者各有优缺点。这里没有客观上优越的答案。你的公司是否宁愿在日常发展过程中走得更快，在坑坑洼洼中遭受更大的痛苦?还是他们宁愿放慢日常发展的速度，但又能在没有太多麻烦的情况下摆脱偶尔出现的坑洞？

这是商业决定，不是技术性决定。

我在这里要补充的唯一一点是，我倾向于认为极端极端是天真和危险的，除非有意识和明确的理由(而且，海事组织，明确承认正在承担的风险并由决策者承担责任)。

在大多数情况下，您会希望在这里采用“大多数A列，一些B列”的方法，以确保任何一种方法的缺陷都不会成为致命的弱点。

Answer 3

如果不了解项目的组织结构和性质，就很难进行玻璃球咨询(S)。

此外，我可以就你的挑战提出我的想法：

任何大中型项目的复杂协调。简单的故事可以由一个团队自己实现，但是任何更复杂的任务最终都会跨越不同团队拥有的多个服务。团队最终会等待其他球队完成他们的任务。

从技术上讲，我看不出为什么一支球队要等待另一支球队。有一些方法可以解决这一点:即特性切换、服务版本控制、设计以这种或那种方式保持向后兼容的服务、服务的长迁移路径等等。

但协调变得更加复杂，同意。

高WIP。必须分配工作，以使每个团队在任何时候都很忙。一旦一个团队为一个更大的项目完成了他们的任务，他们就会寻找其他的事情去做。他们实际上被禁止帮助其他团队完成剩下的项目，所以他们承担了一个新的项目。

我不明白这个。

这里的工作结构如何？您有几个项目，每个项目都有微服务，每个团队负责每个项目中的一个服务？假设Team1负责Project1-Service1，同时负责Project2-Service8？

你最终会有和你的团队一样多的项目

看来我的猜测是对的？

次优排序它不缩放。我们的微服务状态到我们的monolith的可悲状态

正如我在一开始所说的，很难说出任何有意义的话。但另一方面，从你写的东西中，我得到的印象是，你从开发一体机变成了微服务，希望软件结构能帮助解决组织中的结构性问题。

从我的POV来看，它应该是相反的:您的软件中存在问题，例如，越来越复杂，使得发布变得更加困难，从而导致组织问题，这(希望)能够通过微服务得到更好的解决。

也许，首先考虑一下组织结构和工作的结构，在第二步中，寻找合适的方法，并使您想要的工作方式受益。Scrum / Microservices是否对你有好处取决于你的公司。

总的来说，我认为做scrum和拥有这样的微服务没有任何问题--也许在您的上下文和您的做事方式中，这可能是没有意义的。