软件开发中计划制定的一点体会

在软件项目的开发过程中，做三类计划，第一类计划（总体计划）主要确定项目的范围，项目完成时间。第二类计划（发布计划）是在总体计划的基础上，与客户确定分阶段推出软件实现的业务功能，第三类计划（开发计划）是在发布计划的基础上，为保证如期发布业务功能而制定的计划。

1．计划的用途
总体计划一般是开发方在初步了解客户的需求后做出的对客户的一种时间上的承诺，明确项目的范围和规定项目完成的日期，一般项目的范围使用user case表示。
发布计划是根据每个user case的优先级、每个user case的可能变更程度，由开发方和客户共同安排的user case开发顺序，并根据业务可运行性和尽快反馈要求，分阶段制定要发布的业务功能单元和时间。如在开发物流系统中，我们确定了出库、入库、移库、库存报表、数据交换等use case。在制定发布计划时，我们将出库、入库、库存报表等use case作为一个业务功能单元，制定发布时间。所发布的业务功能单元要交付给客户评估，有可能的话，最好由客户试运行。评估的结果作为检验是否满足需求、需求理解是否存在差异、是否产生新的需求。
开发计划是针对每个use case做出的开发计划。同时，通过制定开发计划也进一步对需求进行分析、确认，对技术难度进行评估。

2．计划的制定
2．1发布计划
在制定发布计划时，应先确定use case 的实现顺序，其原则如下：
l        客户对业务的实现急迫程度高
l        业务简单，不确定因素少
l        业务复杂，但可以确定的描述，不确定因素少
l        业务复杂，不确定因素多
l        实现技术复杂（使用其它技术无法替代）
确定实现顺序后，暂时不考虑业务复杂不确定因素多的和技术实现复杂的use case。参考以前的项目或根据经验估算实现每个use case的时间，制定发布时间和发布内容，交付制定开发计划。对业务复杂不确定因素多的和实现技术复杂的use case进行再调研，在此过程中可能产生新的use case。制定过程中，先解决容易的，再解决难的，最终要明确每个use case的发布时间。制定发布计划的过程应尽量的短，不能影响开发计划的制定。同时要意识到，发布的业务单元有可能未被客户认可，遇到此类问题可采取如下办法解决：
l        如果项目的时间宽裕，应为每个发布点留有缓冲区
l        虽未被认可，但对开发方没有不利的影响，可在不变更发布计划、开发计划的情况下，采取见缝插针的方法安排修改程序
l        对有不利影响，但修改程度比较小的情况，可暂停开发计划，集中力量尽快修改
l        修改程度较大，或整个需求双方分歧较大，应向客户通报，重新制定发布计划和开发计划
2．2开发计划
制定开发过程中，应对每个use case再细化，同时将已确定的use case集中，从实现技术角度考虑，划分软件任务。如可考虑将出库、入库业务功能中的业务规则，先进先出、食品应将距有效期最近的批次出库等单独作为一个软件任务。在确定开发任务后，与开发人员讨论完成时间，同时项目负责人，还应考虑单元测试时间、业务单元模拟测试时间。确定的时间应与发布计划中的业务单元发布时间比对，如超出发布计划准许的时间，应修改开发计划。

3．几点注意事项
l        因最开始制定的发布计划未覆盖全部的use case，所以项目负责人应在制定发布计划时切不可造成前线宽松后面紧张的情况，应尽量加快已明确的use case开发速度
l        在制定发布计划时，应使用ken schwaber:scrum methodology中的关于需求复杂性、技术复杂性的系数，估算每个use case的时间
l        制定的软件开发任务应尽量做到每天可以度量，以便保证计划的顺利执行