如何管理软件开发项目？一些实践原则！

在软件开发的过程，如下的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条应视为一个基本集合。

如何管理小型软件项目？    

所谓的小型项目一般是指估计工作量大于3人月小于9个人月的项目。对于没有实施CMMI的企业，这类项目一般是放任自流，少有管理了，对于实施CMMI的企业，如果这类项目也想要达到CMMI的要求，管理的成本相对投入比较大，难以平衡管理的成本与收益，因此，需要做裁剪。如何裁剪，就是难点。

经过与多个客户讨论，最终形成了如下的参考意见。每个企业的特点不同，这些实践对于不同的企业，仍然有不同的实现困难，可以在下述实践的基础上继续裁剪。但是，管总比不管要好，有总胜于无，总是要有基本的管理才可以。


1，商务管理
 商务人员与客户谈判时，应要求客户明确需求
 商务人员与客户要确定需求变更的流程
 商务人员谈判时，应定义需求变更的成本由哪方承担
 商务人员与客户商定项目验收标准
 商务人员与客户的商定双方合作中的沟通问题，包含沟通渠道、沟通方式、沟通时间以及反馈时间约束，并商议多长时间内不给反馈信息，即可默认接受。
 合同评审应由项目经理参与


2，项目策划
 项目经理与高层经理、客户确定项目的平衡策略，即需求、质量、进度、成本哪个指标优先
 项目经理根据本项目实际情况，制定项目执行的过程规范
 项目经理确定代码评审和单元测试的代码覆盖率等质量目标
 项目经理确定项目的生命周期模型、阶段划分
 项目经理制定项目阶段计划，并明确每个阶段的交付物
 项目经理进行WBS分解，并细化《项目阶段计划》，采用MS project工具
 识别需求与进度风险，定义规避措施


3项目监督与控制
 项目经理负责召开周例会，并生成《周进展报告》或会议纪要
 项目所有成员填写日志，项目经理根据日志每天跟踪项目组成员的任务进展情况
 建立日志软件，每天填写日志的工作量要少于5分钟
 定期向高层经理汇报进度
 周例会时要监督风险的状态情况
 项目结束时，项目经理负责召开结项总结会，并生成《项目总结报告》


4 质量保证活动
 代码规范的检查
 需求变更流程的检查
 缺陷关闭情况的检查
 监督项目组单元测试和代码评审的覆盖率的落实情况
 监督项目各工作产品是否满足组织级标准与规范

5 配置管理活动
 使用SVN工具进行配置管理
 所有的工作文档均应入库
 项目结束时，所有的文档应完整入库
 客户往来邮件定期整理备份



6 度量与分析
 根据工作日志，按计划内外、工作类型、阶段进行统计分析，由日志系统自动进行
 统计全生命周期生产率
 工作量数据均来自日志系统，代码规模数据在项目结束时采集


7 需求工程
 识别重要的功能需求和非功能需求，形成文档化的SRS
 描述需求时采用界面原型与USE CASE方式
 接受客户电子档形式的需求变更（含邮件）
 至少2人以上参与需求变更的影响分析，并反馈客户
 项目需求须项目经理确认同意后方可变更


8 软件设计与实现
系统架构设计文档化，形式不限
系统架构设计评审
编码
单元测试及代码重构，引入Junit、Nunit等工具
代码走查
每日联调所有已完成的模块，并进行冒烟测试
在开发过程中，请客户每月参与1次对已完成的部分软件的确认
系统测试，未经公司系统测试通过，不能发布系统