两种组织团队的方式：按职能组织团队和跨职能组织团队。
1）在按职能划分的方式中，按照专业来将人员分组，并采用职能化的汇报线方式，最后将人员分配到有时间限制的项目中。大多数组织投入资金支持的项目都是为了实现特定的需求，并有时间限制。衡量项目是否成功的依据是有没有准时交付并完成需求。
2）跨职能搭建的团队由具有不同技能集的人员组成，通常与长期的产品目标或远大的使命保持一致。在需求范围内，可以自由安排项目的优先级，并根据需要构建的功能完成这些任务。衡量团队是否成功的依据通常是其对业务关键性能指标（KPI）和结果的影响。
按职能分组
传统意义上，许多工程组织都按照水平的职能线来划分：后端工程师、前端工程师、设计师、测试人员、产品（或项目）管理人员和系统管理员/运维工程师。在其他情况下，团队或个人可以在多个有时间限制的项目之间流动。
这种方法能够优化专业知识，能够确保专家之间的沟通路径很短，能够有效地分享知识和解决方案，并采用一致的技能；相似的工作和方法能被分到一起，职业发展和技能提升更清晰。
假设现在正在构建一个新功能。这种职能划分的方法看起来几乎像一条流水线：分析师团队收集需求—工程师构建后端服务—QA团队安排测试时间—系统管理员部署服务。可以发现，这种方法的协调负担是很重的——功能交付依赖于多个独立团队之间的信息同步。这种方法不符合高效组织团队的3条原则，存在以下问题。
1）所有权不清晰。没有哪个团队对业务结果或业务价值有明确的所有权，他们只是价值链中的一颗螺钉。因此，单个服务的所有权是不清楚的：一旦项目完成，谁来维护所构建的这个服务？如何迭代、改进或丢弃这些服务？基于项目的工作分配往往缺乏长远思考，并鼓励工程师只负责代码，而这是我们想要避免的。
2）缺乏自治。这些团队之间是紧密耦合的，而不是自治的。他们的工作优先级是在其他地方制订的，当工作需要跨多个团队时，团队被阻塞和开发工作被阻碍的可能性就会增加。这将导致交付时间变长、返工、有质量问题和延期。如果不能与正在构建的系统架构保持一致，那么团队将无法在不被其他团队阻碍的情况下开发出自己的应用。
3）没有长期责任感。面向项目的方式不利于对所开发的代码或产品质量承担起长期责任。如果团队只是为了一个有时间限制的项目而聚到一起，那么他们可能会将代码交给另一个部门来运行应用，因此原团队将无法进一步迭代他们最初的想法和实现。组织也将无法从原团队积累的知识中获益。
一个新的团队将高效的工作行为进行规范化也是需要时间的——人们在一起工作的时间越长，团队凝聚力就越强，效率也就越高。另外，长期团队也存在风险，团队可能会过于安逸或固守自己的想法。在建立长期关系与引入具有新视角和新技能的人到团队之间实现平衡，这是非常重要的。
4）竖井风险。这种方式也可能出现竖井风险——团队在目标上出现分歧，不能为对方着想，无法进行有效的协作。在某些项目中，测试与开发，或者开发与运维之间的关系几乎是对立的，希望大家从未在这种团队工作过，但这确实是发生过的。
跨职能分组
通过优化专业知识，按职能划分的方法旨在消除重复劳动以及由技能欠缺导致的效率低下，从而降低总体成本。但这会造成僵局：增加团队摩擦，降低实现组织目标的进度。这并不好，微服务架构旨在加快进度和减少摩擦。
跨职能分组的团队由具有不同专长和角色的人员组成，旨在实现特定的业务目标。将这些团队称为市场驱动型团队：可能要完成一个特定的长期任务，构建一个产品或直接与终端客户的需求连接起来。
与按职能划分的方法相比，跨职能分组的团队可以更紧密地与团队活动的最终目标保持一致。团队的多技能特点有利于加强所有权。通过承担规范制订、部署和运维的端到端职责，团队可以自主工作来交付功能。团队通过承担对业务成功具有重要影响的任务，能够获得明确的责任。不同专家之间的日常合作消除了竖井，因为团队成员共同拥有最终工作产品的所有权。
将这些团队设计为长期团队(至少6个月)也是有益的。一个长期存在的团队能够建立融洽的关系，这种关系能够提高效率，而知识共享能够在开发时提高优化和改进系统的能力。
跨职能的端到端的团队组织方式有利于微服务开发。
1）团队与业务价值保持一致将体现在所开发的应用中，这些团队所构建的服务将明确实现业务功能。
2）每个服务拥有清晰的所有权。
3）服务架构反映团队间低耦合和高内聚。
4）不同团队中的职能专家可以非正式地合作，制订共同的实践和工作方式。
跨职能方法将速度放在更高优先级，但并不是以牺牲质量为代价的。
摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》
网友评论