首页>
敏捷项目管理中，计划（Planning）非常重要。计划之前，开发团队要估算出任务的大小（size）。
这和传统的瀑布式项目管理究竟有何不同呢？敏捷软件开发中，估算有两个特征：一是以顾客能够管理的需求为单位进行估算，另一个是只需估算出需求的相对大小。
关于这两个特征，解说如下。
1.以客户能够管理的需求为单位进行估算
第一个特征是要义客户能够管理的需求为单位进行估算。虽然这并非是敏捷项目管理固有的东西，但对于敏捷项目管理来说，至关重要。因为采用这样的管理方法，顾客可以自主排序选择需求。首先，敏捷软件开发前，客户有责任准备需求列表。当然啦，大多数情况下，由开发团队帮客户制作需求列表。但开发团队要认识到需求列表的制作和管理是顾客的责任。
关于这种需求列表，每种开发方式都有自己的叫法，其中需求的粒度和表现形式也不同。例如，XP中，有Story。Scrum中有Product Backlog。无论哪种，都是利害关系者期待的软件功能（Feature）。
以客户能够管理的需求为单位进行估算，其本质在于使客户能够判断功能的优先度，以决定每次交付时，软件需要具有什么功能。
2.只需估算出需求的相对大小
这里的估算并不是项目所需时间（人月）的估算。因为估算出来的累计时间，很可能因为人力资源等限制，会与实际需要的时间大相径庭。第二点，需求的相对大小是由经验和感觉得来的，客户比较容易理解，也比较容易操作。
敏捷项目管理的前提是项目的不可预测性。因此，精细估算得来的计划和概算估算得来的计划，其精度差别不大 -都是不确实的计划。因此，与其在估算上花费成本，倒不如把侧重点放在体制的整备上，以应对意外事态。
敏捷项目管理中，以需求的相对大小为单位进行估算。这个单位在XP中称作Story Point。
3.也有不能对应的不确定性
敏捷项目管理接受不确定性，需要时，可以调整估算值。但是，有时，估算阶段的前提条件中，也有一些不得不确定的要素。这些要素一旦变更，其变更成本往往不可接受。比较极端的例子，比如，一旦选定某种开发语言，就几乎不可能再变了。还有，架构的再构也是这样。
因此，事先必须详细调查这些不可更改的因素。例如，多数情况下，开发团队根据经验定义非功能需求，整理出架构的优缺点，明确其适用范围和潜在风险。
敏捷项目小知识：迭代（Iteration）
敏捷项目管理的要点在于能够设计出一个流程以平衡为获取反馈所花费的成本和获得反馈给项目带来的好处。客户从开发人员那儿得到关于可交付成果的报告，并进行决策。该决策作为仕样反馈给开发人员。然后，开发人员基于该仕样改进开发，并继续向客户报告结果。如此这般，客户和开发人员一边切磋琢磨，一边做出更好的软件。
敏捷软件开发采用迭代（Iteration）管理开发项目工作。一个迭代，一般持续一周或一个月。迭代是分配任务和制作可交付成果的管理单位。
迭代的长度一旦决定了，就不再更改。即，迭代的长度是固定的，不是由分配的任务大小决定的。Scrum使用Rugby中的术语，每个迭代被称作一个Sprint。
粤公安备案 44010602008731号