《项目经理指导手册》规范篇3，计划规范

 

三、计划规范

　　3.1 创建计划

　　　　3.1.1 迭代计划与项目计划。

　　　　古人云，凡事预则立，不预则废。产品需要做规划，才能有轻重缓急，才能能做正确的事。因此，计划是必需的。

　　　　需要注意的是，由于我们是敏捷型项目，不同于瀑布型项目。瀑布型，此处计划为整个项目的执行计划。 而在我们Scrum的框架下，我们所建的计划是：迭代计划。

　　　　注：由于禅道的计划没有区分项目计划 和 迭代计划，所以项目计划需要单独用Project 工具来建立，并以文件形式保存在文档中。

　　

　　　　

　　　　

　　　　计划的内容包括，本次迭代要处理哪些需求，修复哪些bug。这些都可以通过关联需求，关联bug来导入。

　　　　

 

 

 

　　　　3.1.2  计划周期

　　　　关于计划的开始时间和结束时间，是可以留空的。 在这个问题上，我们先要识别“小瀑布” 和 “敏捷开发” 的区别。如下图：

　　　　

 

 

　　　　　在过往的经验中，我们很容易把敏捷做成一个一个的小瀑布，这样看似一个版本一个版本去迭代。其实只是将原来一次发布的“大瀑布”，拆成了多次发布的“小瀑布”。

　　　　小瀑布容易在上一个瀑布 与 下一个瀑布中间 出现空档期，同时由于并没有脱离瀑布思维也会造成阶段与阶段中间出现空档期。在这期间人员以及各项资源的利用率，并没有敏捷起来。

 

　　　　　 所以，如上图所示。我们在敏捷中是可以发布多个迭代计划，以及进行多个迭代。 至少，是可以发布多个迭代计划。

　　　　故此，在建迭代计划的时候，迭代开始时间和结束时间允许留空，但是迭代一旦开始，则不允许留空。

　　　　

 

 　　　　

　　　　　　3.1.3 迭代目标

　　　　　　　　首先我们对迭代的定义要清晰，我们单纯的修复bug，优化表单，增加字段。这些不能称之为迭代。 迭代一定是要有成果交付，如果一个项目只需要打补丁，而没有新功能

　　　　　　扩展，那么这个产品则处于运维状态，运维状态下的产品，因当以快速交付为准则，第一时间修复bug，优化界面、保障软件正常运行为主，因此运维状态无需任何项目管理模式，更无从谈起敏捷还是瀑布了。

　　　　　　综上所述，我们对每次一次迭代，应当提出迭代目标。 而迭代目标我们统一写在 迭代计划的 备注当中。

　　　　　　　

　　　　　　

 

 

 

 

 

　　　　

　　　　　　3.1.4  计划操作

　　　　　　　　创建完计划之后，可以为计划添加迭代、关联需求、关联bug。