英文原文：The
Best Developer Team Structure
在灭火时，有一种“水桶阵型”——队伍中所有人排成一列或几列，将水桶从水源处传递到火灾现场。这样在团队协作时甚至不需要语言交流，但显然不适用于软件开发。
Scott根据自身经验，针对软件开发总结了以下几点建议，不一定全面但是值得参考。CSDN编译如下：
组织架构是完成工作的工具，你需要好的工具来增加工作效率。没有永远最佳的组织架构，每一个项目都有最适合它的架构。
我个人的工作经历主要是关于网站早期开发，这是一门非常特定的工作，因此非常偏向于敏捷/迭代的工作模式，如果你是为银行或者航空公司做开发，肯定需要不同的工具和组织架构。
根据我的经验，通常3-5个开发者围绕这一个PM（项目经理）能够达到最佳的工作效率。PM是一个过于复杂并且常被滥用的术语，坦率地说，我非常讨厌这个词。这里我所说的PM是指“解释、阐明项目需求的人”，因此从产品战略的角度PM需要有强烈的想法，清楚需要构建的是什么，但他们更重要的任务是权衡从客户到设计师等等的全部利益相关者的需求，并据此制定计划。
工程师可以是PM，我也见到过很多成功的案例，但需要注意的是，实际上他们的职能完全不同。作为一个PM，你需要理解“团队”和“一群人”之间的区别：团队的工作方式更像一个单位；团队中有角色之分，比如四分卫、组织后卫，游击手等等，但每个人都为了同一个目标努力完成自己的任务。一群人则是指很多聚集在一起的人，而非一起工作的人。你需要构建的是一个团队而非一群人。
组建团队的方式有很多种，这里列举一些：强制结对编程；通过将项目按组件分解，保证多人同时作业；技术设计与编码分离；降低WIP（Work-in-Progress）能够驱动结对乃至多人编程项目。
注：保持低的WIP度是一个非常神奇的解决方案，当你不知道该做什么时，降低WIP！
每当我的团队增长到7-10个开发者时，我总会将它分为两个团队。不论是什么项目，10人的团队都过于庞大，这时候你需要以子团队为行动单位。团队划分应该很自然，需要能够明显地区分两个团队。有个非常有名的原则叫做“pizza原则”，就是说：如果两张pizza喂不饱你的团队，那么它太庞大了！
记住，团队复杂度不是线性的，而是指数式，当你有更多的员工、更多的团队，花费在沟通上的时间也就会更多。
新团队的组建不能凑合，不是随便雇5个人就能称之为一个团队，最好的方式是“有丝分裂”（类似于举荐）。
如果你拥有多个团队，那么就需要有人来担当“首席架构师”一职。随着时间和团队人数的增长，这会很自然地成为一个任务。首席架构师不需发号施令，这只是一个头衔，但总需要有人顶着这个头衔！记住，他绝不是“软件设计之神”。如果你真的这样认为，你会失去招聘好员工的机会，因为好的员工应该对“什么是好的软件设计”有自己的观点。这个角色更像是“软件设计协调者”，帮助所有人取得架构设计的共识。首席架构师如果做得称职会非常辛苦，因为他需要车前马后地与人辩论，并最终保证大家得到共识，但这正是关键！
如果你的公司非常大，就像财富500强那样，也许这时候你需要有一个能轻而易举地决定软件架构的“软件设计之神”，但我并没有这样的工作经验。
根据我的经验，最好还需要有一个“团队主管（Team Lead）”。这个职位应该从项目经理那里分离出来，经理负责绩效考核，主管负责帮助员工完成工作。当然，团队主管的职责更应该依项目而定，有时甚至不是必须的。
团队从组建到揉合一般需要六周时间，这仅仅是针对公司的正式员工，新员工融进团队的时间还会更长。
另一方面，不要害怕修改团队的组织架构。和运动一样，队员间的化学反应非常重要！有些人在一起工作时能发出更高的工作效率，同时让员工做自己关心的事也很重要，致力于自己关心的工作通常也能带来更高的工作效率。我通常会安排合适的人去做他喜欢的工作。
当然，没有任何人愿意做的事，应该让所有人都轮流去做。如果你的团队是真正的团队，这就不会是什么问题，他们会愿意投入这些肮脏的工作。
最后，随着组织的增长，“软管理”会变得越来越重要。你需要将组织或者公司的使命、价值观、愿景这样的东西文档化，比如写在纸上或者wiki上。只有愚蠢的老板会认为这是在浪费时间。