最适合于进度管理方法的项目

　　我发现有三种项目最适合用基于进度的方法来管理：产品启动、范围模糊的项目、有特定时间要求的项目。

　　产品启动项目只是一个开始而已，它们可以永远地扩展和持续下去，因为新产品没有明确已知的边界。新特性能被随意地定义为“必需的”并添加到产品涵盖范围内。敏捷方法虽然使边界的延展变得容易，但是如果有预定的时间计划，那么就可以这样回答：“当然，这个很棒，但是这会延误其他剩下的功能。”敏捷方法使得对一些通常很容易掩盖的事情必须做出艰难的权衡取舍。

　　涵盖范围模糊不清的项目特别适合用基于进度的管理方法。在敏捷术语里面，这些工作被称为spike（即对不确定的需求进行尝试和探索），它们一般不能成为是一个项目，而是对还处于模糊状态的新特性、功能或者方法的探索，这种探索的目的就是在固定时间内去除模糊性从而使工作变得可评估。

　　最后就是有确定时间目标的工作，这显然是适合基于进度来进行项目管理的，比如一个为假日而发布的新软件游戏，或者为了新产品上线而对公司网站的更新，这些都是最典型的例子。团队成员将会首先完成游戏或者网站更新中最重要的特性，然后在最后期限之前尽可能多地完成其他工作。最重要的功能总是能按时完成并发布。

　　在铁三角维度下的敏捷项目管理方法

　　单纯把铁三角的一个维度作为常量，可以帮助你通过以下几点来对敏捷项目进行控制：

• 专注在项目最重要的因素上。
• 专注于使项目平滑运转。
• 在一定的约束下进行管理：固定的范围、时间安排、预算。

　　正如我们在前面讨论的：敏捷原本是作为一种产品开发的方法出现的，但是只要清楚地了解了它的局限性，敏捷模式可以被作为一种项目实施的方法。同样的，在正确理解的基础上，来自于传统项目管理的铁三角也能够运用到敏捷项目上。下面的总结表可以起到一定的指导作用：

　　现在回想下我们以前提到的那个可定制化的报告站点项目，它的问题到底出在哪里呢？就是把这个原本应该划归到固定进度的项目错误定义成了固定范围的类型。把项目改为按固定进度的类型来管理可以有显著的改善作用。该产品原本可以进行持续地开发和改进，在初始版本发布后，项目本可以结束并将剩余的工作作为后续的改进任务。