微服务、服务化近两年发展的如火如荼，不同的业务背景下，目标不同，团队的组建模式也不尽相同。
对于项目制的软件开发，因为项目本身的资源和预算有限，人员的利用率，资源的平滑分配就很重要，因此一般采用如下模式：
这个模式的特点是代码共享，业务和系统上下文共享，整个team作为资源池存在，服务在team之间没有一对一的关系，可以互相修改。因此服务的治理就依靠团队的平均水平，如果团队的水准较低，那么服务很可能腐化，依赖严重，失去了低耦合的价值。因此为了改善这一状况，每个服务增加一个service owner，这个service owner是一个比较senior的技术人员，负责维护本服务自身的价值和低耦合性。
这个模式由于共享上下文，因此团队规模最大可能在30~40人之间，4个team左右。
无法支撑更大的团队。
对于更大的规模的团队一般存在于大型企业以及互联网企业之中，他们的组织形式一般如下：
这种组织形式一般可以支撑上百人的团队，每一个domain team可以指定自己单独的发布计划，对于比较大的发布，domain team内部可以对所有的微服务一起发布，对于较小的改动，每个微服务单独一起发布。
值得一提的是，虽然微服务所提倡每个服务独立发布与部署，但是对于大多数企业来讲，频繁到每周发布的节奏并不是必须的，比如很多的传统toB企业，每次发布都要经过严格的审核，这类企业普遍求稳。频发的发布对于互联网以及其他toC的企业是一个强需求，因此在这类企业中会对服务的治理投入更大的资源。
回过头来看，敏捷开发强调feature team，传统开发强调component team，实际上这两种方式都是分解功能耦合的一种模式，而解决因为耦合与集成带来的协同问题的方法，敏捷方法的精神都是shared context，shared codebase，通过发挥个人大脑的潜能，每个人要理解全部的业务需求以及代码逻辑，这样自然因为协同发生冲突的概率就比较低了，但是个人大脑是有极限的，当团队规模和业务领域范畴突破一定上线时，个人的理解力就不够用了，因此需要额外的沟通机构或者层级来进行沟通协调，就如portfolio team。这样当一个组织团队规模由500人的时候，可能就会出现3层的管理结构，规划需要逐层传递，沟通与协同的成本也会直线上升。
10个人的协同和500人的协同有什么区别？区别就在与大脑的理解力。因此10个智障在一起合作的难度和500个正常人其实是没有区别的。
同样是10个人的团队，为什么敏捷开发会比作坊式开发效果好质量高呢? 我认为关键在于其中每个人工作的时候都有一个快速的失败的反馈机制，即 build-quality-in, 在dev 开发的时候，如果破坏了与别人的契约测试，那么在他本地就知道出问题了，他可以再第一之间修改。就好像背后有一个大脑告诉你，你错了，你跑偏了，你该修正了。
这正是一种协同机制的技术化体现。
而这样的大脑如何应用于微服务架构呢？如何应用于500人的团队呢？
未完待续...