前言
曾有一些好友和同事问我： 伴随着团队人数的增加，怎么样能让整个团队的产出是 1+1 >2？ 起码也是 1+1 = 2 。
结合我自身的一些角度和经验，我给出了我的一些想法和做法。
(这里的角度是从实际开发中合作的角度来考虑的，提升薪资一般能在很大程度上提升战力 ^^, 这个不在本篇的讨论范围)
1. 统一团队的“语言”
之前看过一本书， 书中说了这样一个寓言– “巴比伦通天塔”
内容大概是：人类希望能联合起来建立通往天堂的高塔。为了阻止人类的计划，上帝让人类说不同的语言，使人类相互之间不能沟通，计划因此失败，人类自此各散东西。
这里的统一的团队“语言”，只的是环境和编码上的一些习惯和规定。细部可以是：
1. 统一的规格文档
项目不管多少人做，规格文档总是需要的， 只是形式和标准上会有一些不同。
比较小的项目， 人比较少， 可以考虑在 Wiki 上来写规格。形式也可能比较随机。 但是对于涉及人数比较多， 项目较大的状况，规范的规格文档就会比较重要。SA, SD , AP, QA 都需要能看得懂。 规格也成为大家交流语言的"教材"。 设计一个好的规格文档的模板也就至关重要。
2. 统一的集成开发环境。
对于 Java 开发者来说，Eclipse 是个还不错的选择。 当然你也可以选择 IntelliJ IDEA。 但是对于开发同一项目的团队来说，大家一定要选择同一套。
对于各种IDE工具来说，优点应该是各有千秋，选择一个最适合项目，适合团队的。这个工作可以在项目进入开发阶段时大家一起筛选。
3. 统一的开发环境
开发人员常见的开发方式 一种是在本地建立个人开发环境进行开发， 另外一种是在一台共用的服务器上建立个人开发环境进行开发， 使用代码控管工具(P4 or Git)进行代码的获取或提交。
不管是哪种，经常会有以下状况发生：
1) 新加入member请老员工查看本地开发遇到的问题
2) AP 1 请AP 2 在AP 1 上查看AP 2 写的Code 的问题
3) 大家一起在某台机器上会诊某个问题
如果每个开发人员的开发环境相差甚异，势必会浪费一些不必要的熟悉环境的时间。 所以， 统一大家的开发环境的路径，开发项目名称，统一的部署测试脚本也就不无裨益了。
4. 统一的编码规范
衍生统一的开发环境， 团队成员使用统一的代码规范， 像代码文件路径，文件命名， 类的命名， 方法命令，变量命令，参数命令都能统一的话， 彼此之间熟悉代码就会比较快，维护和更改也就方便了。
2. 共用功能组件的宣传，，推广
一般项目的设计与开发中， 必不可少的总有共用模组的存在。(如果没有，就要反思一下了)。
共用方法， 共用类， 共用模块。 总有一些部分是可以提取出来供团队来使用的。除了方便其他人，加快开发速度。
相对于每个人都写一套类似的东西，花比较少的时间来提炼，锤炼共用的功能部分，使共用的部分无错误，高效率，对提示项目的质量也大有好处。
但是，共用组件的提取和宣传是需要有专门的意识和规划的， 相对单个开发人员来说， 完成了既定功能的开发，是时间要求很紧的状况下，他个人是没有精力也不想花额外的时间去做共用化的，更别说宣传和推广了。
当然， 即使共用的组件也不能从共用后就不再变化了， 功能完善与升级也是需要相应的途径的。
简言之， 以生命周期的方式来管控和维护共用组件。 从计划，到实施，到销售，到更新升级，到Release …. .
3. 代码质量保证
一个团队要做正确的事，要正确的做事， 在统一"语言"之后，是很有计划达成 1+1 >2 的效果。 但是一定要确保正确的做事，同理之，如果某个成员制造了一个Bug, 影响的不仅是他自己， 错误同样也会出现 1+1>2 的状况。
所以，每个人代码质量都要尽量有保证。
自动代码Check, 定期的Code Reviewer, 结对编程都不失为一种好的做法， 同样，选择适合团队的状况的方法就可以了。
一定要成为你工作最大的资产。
