摘要
笔者以自身实践的场景为例，对团队软件开发的各个模式（初级，CMMI，敏捷）进行了分析和对比。并对如何提高团队软件开发的效率提出了自己理解。
目录
团队初级开发阶段
团队CMMI开发阶段
团队CMMI+敏捷开发阶段
敏捷开发FAQ
团队初级开发阶段
场景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. 关注和加强变化的文档，比如新架构的引入，新控件的推广等引起的文档变更。
团队软件开发进阶总结
敏捷开发人员并非不按规则或限制编写代码的特立独行者。“牛仔编码”是缺乏规则和管理糟糕的迹象，并且很不专业。显然团队项目开发的第一阶段，所产生的问题，正是这种不规范酿成的苦果。
对于初级的团队开发环境，强有力的规范化是很有好处的。因为很多初级开发者在接触很多文档时，会很有抵触心理。强迫按照一定的流程文档规范（初期流程和文档不能太多），坚持一段时间效果将逐渐显现。
当团队规模扩大时，初级的流程文档规范感觉不够用的话，则进一步提升CMMI的等级。
当员工个人技能提升，项目趋于稳定，可以把大团队分解为小团队模式（不超过15人），进行局部的敏捷推广。如果效果不错，则可进行大范围推广。
