作为一名软件开发人员已有6年，我从不同的团队中获得了一系列的经验，从消极到积极。
我最好的经历之一是在金融机构的某个项目团队中。
有许多因素使项目成功，但我认为团队结构是其中的一个关键方面。
总结：
我们的开发人员专注于不同方面。 2位擅长UI的开发人员和2-3位擅长编写业务逻辑和数据库接口代码的开发人员。
代码严格分为演示，业务和数据层。
每位开发人员都拥有整个系统的基本知识。即使他们不是所有人的专家，他们也会大致了解所有内容是如何挂在一起的，如果有必要，可以在任何层编写代码。
有些任务涉及开发人员的整个垂直功能（涉及所有图层的工作）。
其他任务只涉及开发人员专门研究的应用程序区域（例如，只是一个UI任务，或者只是一个数据库任务）。
我认为这很有效，因为：
开发人员能够学习整个系统，并在必要时跳转到不同的层。
开发人员保留了专业化，如果开发人员需要帮助他不熟悉的东西，总会有一个人选。
架构很严格，但人非常灵活，应该是这样。
这种团队结构是否有正式用语？这听起来像是敏捷/ SCRUM安排吗？
（当时似乎没有完全计划。）
有什么想法吗？
答案 0 :(得分：2)
您的开发人员可以学习的技能越多，您的团队就越强大，更多样化，更快乐。
交叉训练非常重要。如果您的UI专家被公交车碾过，会发生什么？团队中已有其他人可以接管他的职责吗？
工作任务应该根据工作的结构来划分（例如，在界面细分）。给予工作任务的开发人员应该能够在他的特定部分上或多或少地自主工作。
答案 1 :(得分：1)
我认为这种团队没有正式名称 - 除了明智之外！ :)为此，我当然同意罗伯特哈维。
每个解决方案（通常）都会涵盖UI，BL，Data等一般领域;您通常还会涉及日志，部署包装等交叉问题;所有这些都将使用某些技术。因此，对于一个适合该项目的团队来说，它需要很好地涵盖所有这些事情 - 作为一个开始。
这是“横向”视图，垂直视图（实现功能切片）是那些人需要互动的地方 - 这就是同行程序编程等XP实践的地方，以及交叉培训真正可以开始的地方发生。
与此形成鲜明对比的是，你可能会对弗雷德里克·布鲁克斯（Frederick Brooks）在他的着名着作“The Mythical Man-Month”中概述的“外科手术团队”方法感兴趣。
该页面上还有一个链接“Organization and Team Patterns”，这可能会引起人们的兴趣。