软件开发项目管理的十大精华指南

1.理解用户和市场要求，明确功能需求和范围
市场需求是产品立项重要依据，没有市场的产品是没有存在的价值的．用户需求是产品好卖的重点，是对市场需求的进一步细化，只有真正理解了用户需求才可能生产出符合用户需要的产品．

范围确定后可以出相关的需求规格说明书．详细的需求规格说明书应该包含输入，输出，流程，界面，业务规则等各种因素．对于采用面向对象的用例分析的需求说明书应该包含用例，业务对象模型，状态和活动图，用例的场景，前置，基本流，扩展流，异常流和业务规则，DEMO等各种重要的信息．

 

2.撰写完整的设计规范书，包括使用方案和界面
功能设计规范说明书是整个开发项目的中心指南．它是一份陈述或总结软件产品或系统的功能设计的文件．它由软件开发的设计项目经理或系统架构设计师撰写，向读者提供某一软件产品或系统的具体功能及其设计的详细叙述．软件工程的开发队伍以此为依据和规范进行软件产品或系统的开发．是整个项目做为蓝图的设计依据．

 

3.制定从下到上的项目进度时间表并对其进行追踪
WBS分解一般是从上到下进行的．针对WBS分解的估算一般既可以从上到小，也可以从下到上．或者两者混合使用．在我们安排进度表时候必须确定活动的依赖关系，确定每一个活动或任务的资源以及其持续时间，可以借助网络图等工具寻找关键路径，最终得到最终的进度表．并且设置相关的里程碑点和检查点，当进度计划确定并基线后．后期的进度跟踪和控制就要依据进度计划进行，并对偏差进行分析和应对．

 

4.以设计规范书为准制定构架设计及开发设计
以可以说设计规范中的某一些内容其实就是架构设计的内容．架构设计和模块设计都要以设计规范的约定进行．是对架构设计和模块设计进行指导的文件．在组织中，过程资产一般会提供需求开发，架构设计，模块设计，编码，数据库设计建模等诸多规范．但每个项目有其特殊性，每个项目还应该制定自己的设计开发约定．

 

5.进行源代码审核、提交、版本的管理
代码的Review是很重要的一个内容，在于加强代码的可维护性，健壮性和可扩展性，发现潜在的性能问题等．这些是通过黑盒测试无法测试出来的．源代码必须进行版本管理和受控制．这可以通过CC,VSS或通过其它开源的版本控制工具来实现．

源代码进行版本管理是进行开发协同和每日构建的基础．每日编译和构建一般都需要独立的环境，需要获取所有开发人员的最新代码．

 

6.编程以测试为目标、将测试作为编程的一部分
首先要考虑代码的可测试性，自己写出来的代码一定是很容易去进行白盒测试的．在写代码的过程中就要考虑相关的测试，如增加Debug或Assert断言信息．性能测试是一个测试的重要内容,因此在编码过程中必须考虑程序的性能，也需要自动构造些大数据量的表进行性能测试．

单元测试的一个重要指标就是代码测试覆盖率，这个可以通过工具协助统计，最好覆盖率能够在90%以上．代码的完全覆盖还不能代码全部的组合条件都覆盖到．测试驱动是XP的一个重要观点，通过推测试驱动和单元测试，可以为后续测试自动化进行积累，对后续的每日构建后的冒烟测试有很大的好处．

 

7.制定完整的测试方案，进行执行的追踪和把关
测试计划和执行应遵循典型的V模型，测试计划，单元测试，集成测试，系统测试一般是必须要求进行的测试．同时对系统和产品的测试还应该包括易用性测试，安全性测试，性能测试等多方面的内容．

 

8.进行严格的更改控制管理
配置管理和变更管理是两个重要的内容，基线和配置项是软件开发中的重要概念．项目经理的一个重要责任就是控制不必要的变更，对于基线化的需求或工件，及时有变更也必须通过正式的CCB进行分析和批准．

 

9.设定发行合格标准，进行发行管理

 

10.记录项目的历程，建立项目历史档案
项目的阶段性总结，里程碑报告，经验教训和最后的复盘报告都是项目很好的资产．吃一堑，长一智．只有认证分析这些经验教训才能够在后续的项目中得到进步和更有效的控制．

软件开发管理的七大关键理念

1整个开发历程是个循环型的重复过程
   将一个开发周期分成多个短里程，多做短阶段的“发行”
2.注重灵活机动进行调整、避免死板计划
   Embrace Change. Anticipate Change. Iterative Planning
3.设计三步法:  使用方案→功能需求→功能设计
4.将测试设计到程序里去: Build Test Into Code
5.渐近发行:  锁定纠错，降低失误率、提高稳定性
6.更改控制建立在“三国会议”的意见基础上
7.任何项目都受“金三角”的影响:  No free lunch

 

 

 

微软的值得中国软件业学习的良好管理实践

1.使用统一的纠错追踪系统 (Raid, Product Studio)
2.没有设计规范书不写一行程序编码
3.频繁的审核 - spec, code, test cases reviews
4.严格的源代码的提交的流程管理制度:源代码只允许一人改动. 改动前先要从原码提交库申请出原代码.改动完先要在开发工程师的机器上编译, 与其它组件一起运行过, 确证没有致命的缺陷后，才能送进原代码的提交库.在产品发行前, 整个提交库都被锁上, 只有被批准修补的原代码才能提交进库.
5.执行原代码互审的制度- Code Review, Buddy Review
6.建立原代码编写的规范 – Coding Convention
7.测试方案有专人执行，测试与开发同步进行

8.严格测试结果的审核:修改完毕先进行初步质量验证 (Smoke Test)，通过后才能提交. 任何影响到其它组件的程序纠错改动, 不仅是经过改动的程序要重新测试, 任何可能受到影响的其它组件也必须重测 (Regression Test). 发行前要进行全程测试 (Full Test Pass).
9.专门的汇编团队负责整个产品每天汇编。
10.所有害虫被分类成三种严重性及三种修改优先权的级别. 所有员工必须先除级别高的.
11.执行 “害虫监狱” (Bug Jail) 制度
12.“吃自己的狗食”: 产品发行前团队成员要自己使用尚未完善的产品，找错并修改

13.测试开始后，每天进行“三国会议” (Triage Meeting – PM, Dev, QA) ，讨论决定对每个害虫的决定
14.产品发行前团队召开定时的“战前会议” (War Meeting)
15.每个团队都大量使用信息系统管理项目
16.每次项目完成，召开总结会 (Postmortem)