打造最佳开发团队的几点建议-转载

原文： http://www.csdn.net/article/2013-03-21/2814583-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上。只有愚蠢的老板会认为这是在浪费时间。

  青春就应该这样绽放   游戏测试：三国时期谁是你最好的兄弟！！   你不得不信的星座秘密