任甲林

  无论是否参考CMMI的模型，在软件开发的过程，我认为如下的15条实践比较经济实用：
  （1）控制项目组的团队规模不超过10人，人员要少而精。
  （2）需求文档化，无论大小项目必须清晰的描述需求。
  （3）采用用例、界面原型描述需求，采用这2种手段强制使需求描述的完备而清晰。
  （4) 项目的阶段计划与2周计划，阶段计划定义总体承诺，2周计划定义近2周的详细任务安排。
  （5）逐日跟踪+周例会，每天轮询项目组每个成员的进展，每周召开全组成员的协调会议。
  （6）需求评审+设计评审，需求与设计文档必须经过评审，评审可以是正式的审查可以是不规范的走查，但是通过评审可以发现问题，促进沟通。
  （7）测试驱动开发，写代码前写测试用例，采用自动化的单元测试工具，通过编写测试用例可以提醒开发人员规避那些问题，通过自动化测试，可以重复、频繁的进行回归测试。代码总是在修改的过程中变的越来越差的。
  （8）单元测试+代码走查+重构，单元测试与代码走查合起来做到100%语句覆盖，重构可以提高代码的结构，优化设计，提高软件的可维护性。
  （9）每日联调，早发现接口的问题，并始终保持有一个可以演示的版本。
  （10）需求阶段编写系统测试用例，作为验证需求的一种手段，促进需求的描述达到可测试、可度量的程度。
  （11）小版本发布，定义需求的优先级，定义在开发过程中明确的发布版本，使开发过程可见，使项目组成员有成就感。
  （12）进行项目的经验教训总结，向历史学习，向案例学习，自己的经验教训最容易为自己所接受。
  （13）有标准就要安排QA人员检查执行情况，无论规范的完备性如何，首先要说到做到，培养组织的执行力。
  （14）采用SVN等配置管理工具管理代码与文档，规避基本的版本混乱。
  (15) 客户方参与的需求变更控制，需求的变更很大程度上源于项目组外部的原因，应从源头规范化需求的变更。

  对于不同的企业、不同的项目，上述的实践可能也难以做到，但是我想上述的15条应视为一个基本集合。