项目开发中如何提升团队的战力？

前言

曾有1些好友和同事问我： 伴随着团队人数的增加，怎样样能让全部团队的产出是 1+1 >2？ 最少也是 1+1 = 2 。

结合我本身的1些角度和经验，我给出了我的1些想法和做法。

(这里的角度是从实际开发中合作的角度来斟酌的，提升薪资1般能在很大程度上提升战力 ^^, 这个不在本篇的讨论范围)

1. 统1团队的“语言”

之前看过1本书， 书中说了这样1个寓言-- “巴比伦通天塔”

内容大概是：人类希望能联合起来建立通往天堂的高塔。为了禁止人类的计划，上帝让人类说不同的语言，令人类相互之间不能沟通，计划因此失败，人类自此各散东西。

这里的统1的团队“语言”，只的是环境和编码上的1些习惯和规定。细部可以是：

1. 统1的规格文档

项目不管多少人做，规格文档总是需要的， 只是情势和标准上会有1些不同。

比较小的项目， 人比较少， 可以斟酌在 Wiki 上来写规格。情势也可能比较随机。 但是对触及人数比较多， 项目较大的状态，规范的规格文档就会比较重要。SA, SD , AP, QA 都需要能看得懂。 规格同样成为大家交换语言的"教材"。 设计1个好的规格文档的模板也就相当重要。

2. 统1的集成开发环境。

对 Java 开发者来讲，Eclipse 是个还不错的选择。 固然你也能够选择 IntelliJ IDEA。 但是对开发同1项目的团队来讲，大家1定要选择同1套。

对各种IDE工具来讲，优点应当是各有千秋，选择1个最合适项目，合适团队的。这个工作可以在项目进入开发阶段时大家1起挑选。

3. 统1的开发环境

开发人员常见的开发方式 1种是在本地建立个人开发环境进行开发， 另外1种是在1台共用的服务器上建立个人开发环境进行开发， 使用代码控管工具(P4 or Git)进行代码的获得或提交。

不论是哪一种，常常会有以下状态产生：

1) 新加入member请老员工查看本地开发遇到的问题

2) AP 1 请AP 2 在AP 1 上查看AP 2 写的Code 的问题

3) 大家1起在某台机器上会诊某个问题

如果每一个开发人员的开发环境相差甚异，必将会浪费1些没必要要的熟习环境的时间。 所以， 统1大家的开发环境的路径，开发项目名称，统1的部署测试脚本也就不无裨益了。

4. 统1的编码规范

衍生统1的开发环境， 团队成员使用统1的代码规范， 像代码文件路径，文件命名， 类的命名， 方法命令，变量命令，参数命令都能统1的话， 彼此之间熟习代码就会比较快，保护和更改也就方便了。

2. 共用功能组件的宣扬，推行

1般项目的设计与开发中， 必不可少的总有共用模组的存在。(如果没有，就要反思1下了)。

共用方法， 共用类， 共用模块。 总有1些部份是可以提取出来供团队来使用的。除方便其他人，加快开发速度。

相对每一个人都写1套类似的东西，花比较少的时间来提炼，锤炼共用的功能部份，使共用的部份无毛病，高效力，对提示项目的质量也大有好处。

但是，共用组件的提取和宣扬是需要有专门的意识和计划的， 相对单个开发人员来讲， 完成了既定功能的开发，是时间要求很紧的状态下，他个人是没有精力也不想花额外的时间去做共用化的，更别说宣扬和推行了。

固然， 即便共用的组件也不能从共用后就不再变化了， 功能完善与升级也是需要相应的途径的。

简言之， 以生命周期的方式来管控和保护共用组件。 从计划，到实行，到销售，到更新升级，到Release .... .

3. 代码质量保证

1个团队要做正确的事，要正确的做事， 在统1"语言"以后，是很有计划达成 1+1 >2 的效果。 但是1定要确保正确的做事，同理之，如果某个成员制造了1个Bug, 影响的不但是他自己， 毛病一样也会出现 1+1>2 的状态。

所以，每一个人代码质量都要尽可能有保证。

自动代码Check,  定期的Code Reviewer, 结对编程都不失为1种好的做法， 一样，选择合适团队的状态的方法就能够了。

生活不易，码农辛苦
如果您觉得本网站对您的学习有所帮助,可以手机扫描二维码进行捐赠