制定迭代软件项目开发计划

迭代软件项目开发计划的编制林振峰（深圳康拓电力自动化，PMP）摘要制定项目计划对于项目的成功实施起着非常重要的作用. 在软件开发领域中，由于不确定的用户需求，瀑布式项目计划经常变成空白纸迭代的开发计划，并且迭代项目计划没有规则. 针对这种现象，本文提出了一种迭代软件项目开发计划的编制方法. 简介我们知道，对于软件开发而言，不断变化的需求是相同的. 制定计划时，期望一切都按照计划进行是不现实的. 如果我们制定了一项评估绩效的计划，那么人们会说，即使出现了危险迹象，一切都很好，而且一步一步地完成了. 在过去的几年中，越来越多的软件工程领域的有识之士提出，现实中有两种生产方法: 可预测的生产和不可预测的生产，软件开发是不可预测的生产方法，因此软件开发项目并不是适用于可预测的计划. 经过数十年的发展，软件工程领域已经出现了许多类型的软件生命周期模型，包括瀑布式，迭代式和增量式. 软件项目开发计划的准备取决于软件项目的生命周期模型. 换句话说，瀑布项目和迭代项目的开发计划是不同的. 瀑布模型起源于和制造业的可预测产量，并且固有地无法适应需求不稳定的软件项目.

因此，尽管许多项目在开始时就规定了瀑布类型，但在实践中它们逐渐变得迭代. 许多使用瀑布的项目计划与现实相距太远，最终成为无法实施的死信. 实际上，迭代并不是一个新发明. 这个想法与PDCA相同. 两者都通过螺旋过程接近目标或期望. 该原理非常简单，在现实世界中无处不在. 客户心目中就有这样的模型. 难怪他们经常说: “刚才提到的需求，您首先开发了它，我们将尝试一下是否合适，然后再进行改进. ”例如，我还发现重构在编程领域是一种体现. 迭代思维. 所谓的重构是一个过程: “在不更改代码外部行为的前提下，对代码进行更改以改善程序的内部结构. ”重建是一种经过训练的有序，有条理的程序分类方法，可以最大程度地减少在分类过程中意外引入错误的机会. 本质上，重构就是“在编写代码后改善其设计”. 我们可以做个比喻. 重构是编码过程的迭代. 通过重建迭代可以获得更好的设计. 重建的每个迭代可确保程序正常运行，这意味着可以观察到每个迭代的结果. 图1瀑布图和迭代瀑布图软件的开发进度表通常按阶段划分，分为计划和估计，需求研究和分析，概要设计，详细设计，编码和单元测试，集成测试，系统测试，实现交付以及项目结束.

迭发计划可以分为两个级别. 第一层是总体计划，可能要花几年或几个月的时间，例如XP发布计划和RUP阶段计划. 第二层是短期详细计划，范围从一周到几个月. 总体计划将整个项目的工作划分为每个迭代周期，并且不注意执行细节. 由于需求的变化，可能会修改较大的时间范围；短期计划是一个迭代周期计划，重点在于执行细节和将特定任务落实到人员身上，并且由于时间跨度较小而相对稳定. 项目始终存在约束. 例如，客户要求在某个年月中完成该系统的版本，并且该版本应包含多个功能. 或者，与类似项目相比，该项目可以获得大约的完成日期. 这些是制定总体计划时的关键信息. 总体规划为团队的工作指明了道路. 在总体计划中，主要重点是里程碑，以及每个里程碑要完成的目标或功能项目. 因此，总体计划也可以称为里程碑计划. 不要为每个活动设置完成时间点，例如为详细设计设置完成日期，编码和单元测试完成日期是没有意义的. 由于这些活动在整个项目中会不断重复，因此即使对系统进行了测试，它们也将回来进行详细的设计和编码. 有了总的完成日期和各种里程碑，该计划的框架已基本确定. 我们可以估计功能点以获得参考估计，例如系统需要消耗的工作量（人月或人时）. 进一步估算，我们可以得出每项活动所花费的工作量，例如编码个人月或人时的量，并结合项目此时的实际人力资源状况，当两者匹配时，该计划是可行的

否则，需要调整计划. 有了更多客观的估计，这种调整就更具说明性. 最后，总体计划应确定迭代周期的长度，通常为2-3. 总体计划获得批准后，建立计划基线. 如果需要修改，则必须征得客户的同意. 项目经理的困境经常更新计划. 确定总体计划后，我们可以为每个迭代周期制定一个计划，但是并非所有迭代周期计划都可以一次完成，我们只需要为当前迭代周期制定一个计划，就可以确定需要制定的计划. 在迭代的后期阶段迭代的开发计划，事物以一个周期完成. 时间装箱迭代是一种固定迭代结束日期且不允许更改的实践. 一旦无法达到某个迭代的时间范围，我们就不能推迟迭代的结束日期，而是减小范围，如下图所示. 在将时间变量固定为四个变量之后，我们只需考虑范围，质量和人员. 变量. 图2可以使用项目进度表来准备和跟踪迭代计划. 项目管理理论对如何准备进度表进行了详细的讨论. 这包括准备wb，任务之间的关系，分配人员，确定任务的持续时间，确定任务的开始和结束时间，执行资源平衡，并行任务以及填补提前任务中的时间和其他技能. 由于迭代计划的时间跨度较短，因此项目经理和团队成员完全有能力对该短期计划做出相对准确的判断和估计，还可以根据实际情况进行微调，因此修订并能很好地跟踪迭代计划.

实践是检验真理的唯一标准. 软件项目更适合采用迭发模型，软件项目计划还应采用更符合实际情况的有效准备方法. 通过几年的实践经验，作者总结了一种迭代软件项目计划的编制方法，希望为从事迭代软件项目的项目经理提供一些有用的参考. 规划敏捷项目[英语] Martin Fowler敏捷迭发-经理指南[美国] Craig Larman

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-219320-1.html