团队软件开发进阶

摘要

笔者以自身实践的场景为例，对团队软件开发的各个模式（初级，CMMI，敏捷）进行了分析和对比。并对如何提高团队软件开发的效率提出了自己理解。

团队初级开发阶段

场景1

研究生导师王教授接到一个企业信息化的项目，是对一家中小型企业做一套产品数据管理的解决方案。

具体的参与人员：高博士，硕士：小马，小赵，小李，小徐，小万

马教授是行业专家，在企业信息管理，研发流程优化上比较高造诣。

高博士：是研究企业研发信息管理的博士，担当项目经理的职责，主要负责客户需求的落实和整个项目的计划和分配，向王教授汇报项目和工作进展

硕士：小马负责整个技术框架的实现，并指导其余研究生进行代码编写工作

小赵：负责 XX1 某模块功能实现

小李：负责 XX2 某模块功能实现

小万：负责 XX3 某模块功能实现

……

高博士仅仅和客户确定大方面的需求实现。

具体需求细节问题，没有和客户确认，需要在项目开发的时候和业务人员确认。

五名开发人员前期在客户那里办公，具体把大致的需求制定了一下。因为客户本身的信息化经验也不多，只能讲一个大概，所以待了不几天就回去，整个项目开始启动开发。

经过大概5个月的紧张开发和反复修改，该系统上线，客户可以基本应用。

客户在使用项目和项目维护时期暴露出来的问题有以下几点：

l 每个人的编码风格不一致，界面风格不一致，异常机制不一致；

l 缺少公共的基础类收集，很多类似方法重复被不同开发人员多次实现；

l 大家自己负责的那部分业务还比较熟悉，对其他人业务不熟悉，代码只能本人维护。

l 团队不稳定，小徐毕业，小杨接手，小杨看不懂徐的代码，遇到客户问题，只能自己重新编写。

团队CMMI开发阶段：

场景2：

某大公司供应商关系管理开发

项目经理：王经理

开发人员：老汤，老李，大万，大曹，小张，小马，小陈，小纪

测试：小黄[兼]

DBA：小刘[兼]

配置：小沈[兼]

这个团队新毕业生比较多，新毕业生的特点是技术能力一般，比较容易规范和管理。公司研发流程比较正规，整个软件项目开发采用CMMI3级标准作为研发指导规范。软件开发过程中，对软件开发流程规范，文档规范等要求比较高。

CMMI 规范要求按照岗位从事工作，比如编码人员只能接受设计人员的工件，按照设计模型定义的方法在生成的代码框架上进行编码工作，不能从事设计工作。

这一点，对于刚刚毕业的新同事有比较好的指导作用，因为有经验的人员可以把比较成熟的技术，设计思路通过设计模型和文档传递到新同事那里，避免新同事在初级技术水平下自由发挥。新员工也可以通过这种约束限制，对学习老员工成熟的技术解决方案，设计模型有比较深刻的体会。

另外由于新员工数量较多，采用CMMI的研发流程，对项目的组织和控制比较严谨，保证了项目实施的进度。

强调了文档传递的重要性，保证了新员工的工作的文档积累性，使项目成员的流失风险降低，使得大家按照文档的文档进行业务理解，保证了程序开发的有章可循。

体会

CMMI是给出所有可能需要考虑的点，如果项目开发团队在项目管理和业务上，技术上缺乏经验时，CMMI2级或3级是一个比较好的管理参照方法，它可以基本保证项目的研发进度，降低了人员变更的风险。

缺点

l 文档太多，流程太多，研发效率有所降低，如果是以市场为导向的项目，可能会面临成本的压力。

l 因为关注点太多，代码质量的核心地位下降。客户要求业务需求快速变更和高质量的实现。但CMMI仅对流程可控和文档齐套有保证作用，它本身并不能提升代码的质量。代码质量和效率提升需要用别的手段进行保证。

团队CMMI+敏捷开发阶段

场景3：还是上面那种场景，场景未变

Z公司的待遇较好，两年过去了，当初的新从学校毕业出来的学生都成了技术骨干。原来老人带新人的阶梯式团队，变成了技术水平差不多的平行式团队。团队技术差不多，且均为熟手，对当前系统的开发流程，编码规范和架构设计比较熟练。并且在项目开发过程中可以与业务代表（业务人员）面对面沟通。

采取措施：

1. 交叉检查。两块功能两个负责人，每个人对各自编码功能实现负责，同时对另外一个人的功能点负责，交叉测试。

系统测试或正式上线出现问题后，两人负连带责任。这样强制措施保证同一模块有两人以上熟悉，避免人员流动对项目造成的影响。

2.功能内部的实现修改，开发人员自己作主。

当开发人员具有一定技术水平，被信任程度和责任心时，系统内部简单功能的实现修改，开发人员可以直接与业务代表沟通，独立完成，不需要别的人员参与，这样可以保证项目开发的效率。

3. 强调技术积累和最佳实践。

总结设计复用，代码复用，代码模版最佳实践。大家共享知识，对新员工能力提升有良好的帮助作用。

4. 增强关键文档

增加重要文档的审核和理解力度，比如软件需求讲解，概要设计讲解，关注数据库设计，主要类设计，对内对外接口设计，主要实现方式的讲解。而类内部的具体实现可以交给开发人员自己作主。

5. 削减和裁减不必要的文档

削减和裁减不必要的文档，比如不必要的计划文档，不必要的设计文档，不必要部署文档，减少重复的设计，减少无变化文档的版本升级，对重复的设计可以自动生成模型等。

6. 关注和加强变化的文档，比如新架构的引入，新控件的推广等引起的文档变更。