划分开发堆栈-对角线？

我们正在进行一个新项目，目前开发人员已分为两个团队，即团队A和团队B。该项目有两个部分，需要在整个开发堆栈中进行开发。堆栈的简化示例如下所示：

项目的每个部分都需要在整个堆栈上进行开发，因此我通常希望使用完整的堆栈开发人员方法，这就是我们如何分解团队B中的工作，设计和设计不同部分之间的交互的方式。

但是，我最近了解到，团队A要负责堆栈的某些部分，他们提议在两个团队之间进行划分，其中数据抽象层（并将内容放入数据层）由团队B没有任何发展。这种鸿沟看起来类似于：

对我来说，这感觉很不自然。每个团队都有不同的目标和时间表来实现这些目标，但是B团队将依赖于A团队来实现功能。提出的解决方案是预先定义通用接口（该项目可能需要2年的时间，因此可能会很多）。尽管有自己的目标，团队A仍将尽早为这些接口开发所需的位，而团队B则在短期内取消所有呼叫，以便他们继续前进。

我对此方法感到担忧：

• 接口可能会更改，并且组A可能没有带宽或时间来适应不断变化的需求。
• A团队代码中的错误可能会阻止B团队前进，并且由于A团队的优先级队列不同，它们可能也不是解决这些错误的优先事项。
• 团队之间缺乏知识传播-团队B可能无法完全了解幕后情况，因此可能会做出糟糕的设计决策。

已经提出，该行业中的许多公司都有子团队，并且必须能够处理此问题。根据我的理解，通常团队会按照最初的期望进行拆分（全栈），或者通过如下分解技术栈：

因此，我有兴趣了解其他行业的情况。大多数拆分是垂直/水平的吗？对角线分割有意义吗？如果发生对角线分裂，我的担忧似乎是成立的，并且B团队还有其他需要关注的问题吗？请注意，我可能要对B团队的成功或失败负责。

您的担忧是非常有效的。尤其是关于团队A的前两点，没有时间去添加影响团队B的功能或修正错误。

如果满足以下条件，这可能是一个好主意：

• 众所周知，团队A将致力于需要数据库中新功能的项目，而团队B的目标实质上是“仅前端”功能。例如，如果B团队正在编写您公司的新iPhone应用程序，则很可能他们暂时不会添加新的数据库字段，因为他们需要移植/重新实现桌面版本的所有功能。

• “完整堆栈”已经变得足够复杂，以至于没有一个开发人员（或开发团队）可以有效地“拥有”整个产品。所谓“拥有”，我的意思是不仅要添加功能和修复错误，而且要理解并关心整个系统，以至于他们可以避免随着时间的推移而增加更多的技术负担。在这种情况下，如果团队A拥有非常简单或不可避免地与DAL /数据库实现紧密耦合的UI / Web API（也许有一些内部诊断工具？），那么“对角线”分割就是明智之举。所有复杂的面向用户的前端材料。

• 管理层了解团队A成为瓶颈的风险，并且如果这种风险变成实际问题，则愿意消除这种情况。

我无法谈谈行业中多少常见的问题，但是至少在我工作的地方，所有应用程序开发人员都明确需要“全栈”。我们所拥有的是“基础设施”团队，他们开发/维护我们的内部数据库，我们的Web服务框架和我们的UI框架（我说过我的公司很大吗？），因此我们所有数百个应用程序都可以拥有完整的堆栈。虽然整个公司仍然可以为我们的所有服务提供一致的性能和UI。

最近，我们公司一直在开发一个全新的UI框架，因此一段时间以来，我们的一些新应用程序在新框架中的错误和缺少功能方面被严重阻塞。情况不再如此，主要是因为我们中的一些人被允许向拥有框架的团队提交拉取请求（不是很“对角线化”，但您知道了）。