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

在软件开发的过程，如下的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次对已完成的部分软件的确认
系统测试， 未经公司系统测试通过，不能发布系统