规划、重规划与调整

概述

无论个人在专业领域拥有多少项目实施经验，项目规划始终存在改进空间。在传统项目中，规划仅在项目初期进行，只有当所有截止日期都被延误后才会进行调整。这类问题通常发现得较晚，例如开发进度延迟，或在测试阶段发现关键错误。

在最近一个短期敏捷项目中，需要实现的功能超出了六人团队在八个计划迭代内所能承担的范围。在项目尚未顺利推进时，项目经理决定扩大团队规模。第二轮迭代中增加了八名成员，第四轮迭代又增加了六人。最终，团队人数超过20人。原团队成员不得不将全部时间用于帮助新人熟悉工作，导致整体生产力下降至零。

在传统项目中，问题往往发现得很晚，纠正措施常常在最后一刻才采取。这可能导致工期推迟、范围缩减，或向团队增加新成员。然而，在项目后期进行前两项操作并不理想，而增加人员也难以奏效，因为新成员必须适应一个已处于高压状态的团队。布鲁克斯定律在此适用：向一个延期的项目增加资源，只会让项目更加延期。这一规律同样适用于敏捷项目。

当然，敏捷项目在开发过程中也可能出现延期，或在测试阶段发现关键错误。但由于每个工作项的分析、设计、开发和测试在短周期内连续进行，问题能够更早被发现，使团队得以尽早做出调整。

在一个复杂的面向服务的项目中，我们在完成两个迭代后发现团队速度远低于预期，无法在九个迭代后的截止日期前完成任务。在第二个迭代结束后，我们立即采取措施，为团队新增了一名SAP XI开发人员和一名测试人员，最终轻松实现了最终交付目标。

甚至敏捷所采用的工具和技术本身也有助于这种及时且持续的调整。项目待办事项列表管理项目中的所有工作内容。项目使用简单的仪表板，如墙上贴满便签的任务看板（Scrum中的典型形式）。每日通过在所谓的燃尽图上标记一个点来估算进度。简而言之，敏捷项目在结构上最有利于及时且持续地进行调整。

如何规划项目？

我们将项目规划的步骤总结如下：

• 规划

基于需求、工作项、技术及可用人力制定初步计划。目标是明确项目的范围、预算和周期。

• 重新规划

在过去25年中，我们所见过的任何项目都未能完全按照初始计划完成。日程安排不断受到内部和外部因素的影响而调整，这意味着对范围、预算或周期需要进行相应变更。传统方法与敏捷方法之间的重要区别在于重新规划发生的时间点。

在传统模式中，重新规划被视为失败的标志，因为原本已就范围、预算和时间达成协议，但未能兑现。而在敏捷模式中，重新规划被视为正常过程，是一种持续进行的活动。

• 调整

一旦发现最新计划不可行，就必须立即进行调整。传统项目中，调整往往发生得太晚，接近项目尾声。这是因为各阶段只执行一次。而在敏捷项目中，调整更加容易，因为每个迭代都会完整实现若干工作项，因此可以随时掌握项目进展状态。调整可以从项目启动之初就开始，效果显著。采用短周期迭代，使得团队能够持续应对突发情况。

适应性规划

在敏捷项目中，规划与调整被视为日常工作。问题能被早期识别，纠正措施也能快速实施。计划固然重要，但以灵活方式应对计划变化更为关键。或许“适应性”比“敏捷”更能准确描述此类项目的特点。

敏捷项目中的规划如下所示：

适应性敏捷项目通常在以下时间节点进行规划：

• 项目启动时：项目开始时即启动规划。此时确定项目的范围、预算和周期，填充项目待办事项列表，并组建团队。

• 发布周期的开始与结束：许多长期运行的敏捷项目会伴随发布周期进行。例如，项目可与组织的发布日历同步，或因产品持续演进而定期发布新版本。在每次发布开始时，确定本次发布可实现的工作项；在发布结束时进行评估。在规划和执行发布过程中，保持项目待办事项列表的优先级至关重要。

综合来看，仅包含迭代的敏捷项目可视为一个单一发布的项目。

• 每个迭代的开始与结束：每个迭代开始时，确定该轮迭代的工作项；结束时进行评估。这也是审视项目进展的良好时机。

• 每日：每日站会涉及当天工作项的规划以及对前一天工作的回顾。