敏捷项目的多层面规划

导语

“不做计划的人注定要失败。” ——匿名

“今天把计划做好，胜过明天把计划做完美。” ——匿名

“你的计划没做好，不会让我的工作变糟糕。” ——匿名

“当机会遇上计划，就会变成好运气。” ——发明家 托马斯·爱迪生

“计划只有马上变成努力工作，才能算是好想法。” ——管理学大师 彼得·德鲁克

“正确的准备，产生出众的表现。” ——著名橄榄球四分卫 Charlie Batch 【译注 1】 “你永远无法根据过去规划未来。” ——爱尔兰政治家 埃德蒙·博克 【译注 2】

“响应变化重于遵循计划”，这是敏捷的核心价值观之一，可是它有时会被人错误诠释为敏捷项目中不需要规划。然而，真实情况根本并非如此。在适应性敏捷项目中，规划的次数要远多于在预先规定好计划的（predictive）【原注 1】项目中做规划的次数，因为我们要将必然会出现的诸多变化纳入到考虑之中。适应性项目的特点就是不确定性，主要存在于以下领域：

• 需求：所有的项目都需要绝对清晰的目标和方向，然而，要达到这些目标需要实现很多具体需求细节，这些细节在一开始很难完全理解透彻，而且很容易在项目的生命周期中改变。
• 对问题域的理解：要知道我们的理解不可能完全正确，而且随着我们深入了解问题域的现实，我们对于解决方案最初的想法很可能会改变。
• 交付率：适应性项目其本质是创造性工作，而且团队试图在解决方案没有完全想清楚之前开始解决问题，解决方案的产生需要发明和创意。人和人之间的差异导致彼此无法完全替换，而且各人的工作效率也不完全一样。

适应性项目需要对应的适应性的方法，这样一来，在项目的生命周期中，我们对于项目的理解不断加深，产品也会逐步演变。敏捷项目中采取迭代和增量式的工作方法，就能提供必要的反馈机制【原注 2】，以此交付适应性项目。

尽管敏捷项目的本质是适应性，管理层还是希望了解“项目成本如何？需要多少时间？”这样的要求合理而现实。要向项目中分配组织资源，要完成哪些工作也需要相关决策。这就意味着我们要在某些层面上提供反馈，以回答项目开始时的一些问题，并定期提供相关信息，确保我们可以利用组织的投资交付最好的价值。

要达到这个目标，我们需要在多个层面规划。

以下是规划会发生的两个宽泛层面：

1. 最高层面的规划，往往在团队之外进行，而且与应该资助哪些行动方案相关——“做正确的工作”。
2. 一旦某个项目通过了“我们应该做这个项目吗？”这个问题，我们就需要将重点放在“把工作做正确”之上。此时，就需要在 5 个层面上做项目规划。

做正确的工作

这里的流程主要是要选择出投资哪些项目，可以看下面的幻灯片：

创新和问题

所有组织都需要一种鼓励机制，鼓励大家产生各种好主意、发现问题。在开始的主意和问题辨识阶段，应该尽量不做过滤，组织的所有成员都可以指出某个未处于最佳效率的工作环节，识别组织需要解决的问题（比如市场中的某些变化或是新颁布了某条组织必须遵守的法律），或是提出某种能够完成的全新事物。

当很多主意提出之后，需要有一种粗略的过滤机制——想想这个想法是否值得深入考虑。很多时候，可以对这些主意进行成本－收益分析和可行性评估。有些主意会自动通过第一次过滤（比如：为了符合某条法规的变化，某个项目必须要完成），有些很快就被抛弃了（成本不允许，或是与组织的战略目标完全不符），有些还需要深入研讨。

得到自动通过和值得深入研讨的主意将会进入“项目组合规划”流程。

项目组合规划

“项目组合规划”是监管层面的活动，其目的是要选出组织应该投入资源完成的项目组和项目。毫无疑问，希望完成的项目要多于能够投入的项目，项目组合管理流程就是要选出可以投入资源的项目。

判断要完成哪些工作，应该依据组织的使命和目标：只有交付物符合组织最高战略层面要求的项目和工作，才能得到投资。项目组合规划是基于风险－回报的活动，组织的风险管理策略有助于选择投资哪些项目。

“项目组合规划”应该在公司的职能层面的组织架构之上进行，以确保端到端的影响，并且选择出来的工作的价值也得到分析。在这个组织架构层面之上，项目将会影响多个职能领域，还要避免发生“争地盘”的情况，这一点很重要。这个层面上，任何重大的工作还会要求组织中多个职能领域提供资源（比如：全新客户自服务系统的上线不仅仅是 IT 项目，是会有 IT 方面的工作，不过市场部要宣传提倡大家使用自服务系统网站，服务部门要给知识引擎提供内容，等等）。

各个组织的“项目组合规划”流程各自不同，但是都应该遵循理解透彻的流程，还要为下列步骤提供指导方针【原注 3】：

1. 构建所有项目的项目组合
2. 定量和定性评估项目
3. 判断现在投资哪些项目
4. 为项目组合排序
5. 维护项目的 backlog，并基于新项目需求和已完成的工作主动管理 backlog

当工作需要跨越组织的多个职能领域进行时，可将其拆分为相关但是独立的、合理的工作活动流，并将这一系列项目作为项目组管理。

项目组管理

要对项目组做更多协调工作，以保证互相关联的工作流程得以同步。当软件完成时，广告营销活动要准备好对外发布；在广告营销活动启动前，呼叫中心的人员要雇佣到位，而且完成培训；在广告营销活动启动前，软件要部署在生产环境服务器上。诸如此类工作要保证完成。

项目组经理是专有职位，此人对于所有的相关工作项目有战略视角，以确保整体的项目组得以顺利交付。项目组经理为不同项目团队提供统一的愿景，这些团队会完成不同的工作项目。

项目组经理是所有项目团队最终的客户，并设置整体的优先级和里程碑。

项目组管理是适应性流程，其中各个项目要响应组织不断变化的现实，以及其他项目团队的产出和交付物。

应该制定出整体的项目组规划，当事情发生变化时，还要调整该规划。项目组规划的关键要素包括（【译注 3】）：

• 产品整体大致需求，要交付的目标和关键特性
• 项目组承诺完成的组织目标
• 项目组各方面的成本－收益分析
  • 市场投入和方法
  • 销售方法
  • 整个产品生命周期预期可能带来的收入
  • 要交付所有工作的预估成本
  • 服务、支持和维护成本
  • 内部和外部人员培训
• 项目组的关键里程碑和大致日程，包括进行中的发布周期
• 不同项目和时间段涉及的人员档案
• 整个项目组的整体风险登记册

项目组管理需要为各个子项目提供方向。理想情况下，“产品愿景”要提供这方面信息，而且所有团队都要对其完全理解，并做出承诺。

把工作做正确

这是说：要确保团队要交付的产品符合产品愿景。就是在这个过程中，适应性敏捷团队基于迭代和增量的方式来交付业务价值。

下图展示了规划活动如何在越来越详细的层面上进行。

产品愿景

在产品愿景中，我们从监管和组织级战略决策层面转向战术上的产品交付层面，并改变组织中人们的工作方式。

产品愿景是至关重要的工具，向团队传达为什么要工作，他们的工作方向，以及他们的工作要服从的关键约束条件。

产品愿景常常以项目章程文档的方式传递。

理想状况下，项目章程准备活动应该由整个团队以协作式工作组的方式完成。项目出资人和产品负责人应该出席该工作组，他们负责阐述清楚：为什么项目对组织非常重要，以及衡量产品是否成功交付的关键标准。

Sanjiv Augustine 提出项目愿景要回答的关键问题：“我们希望该项目为组织达成什么目标？”【原注 4】

这个问题的答案会指导团队在项目中的所有工作，也能告诉团队何时停止工作。产品愿景中要传达出项目整体层面上“完成”的定义。

典型的项目章程包括：

• 问题、机会描述和理由——为什么这个项目对组织很重要？
• 该项目为组织交付哪些价值？
• 该项目如何与组织的战略目标达成一致？
• 解决方案综述——我们要交付什么？
• 待构建产品的关键特性
• 驱动该产品的假设
• 项目必须服从的技术或其他约束条件
• 范围——哪些是团队的工作职责？哪些不是？
• 项目交付应依据的关键时间线
• 预算和成本－收益分析
• 依赖项目和相关项目，以及与这些项目协调的关键里程碑——尤其是当前项目是某个大项目组的构成部分之一时，这一点非常重要
• 当前项目相关风险，包括如何正确消除这些风险

有不少简单的工具可以在愿景工作组中使用，帮助参与者明确阐述和表达产品愿景。接下来列出一些，以资参考。

“中心问题（Focusing Question）”或“电梯说明（Elevator Statement）”

用一、两句话说明项目的目标和方向。

“电梯说明”能让任何团队成员在乘电梯过程中把项目的意图说清楚（想象一下你和公司的 CEO 一起进入电梯，对方请你说明你现在正在做的项目，而且你要在对方到达目的楼层前说清楚）。

在工作组里面，这是应该最先产出的东西，而且要写出来，让所有人都能看到——工作组接下来的活动要围绕它开展。

愿景盒子（Vision Box）

“愿景盒子”展示项目的特性及其带来的好处，可以用一个麦片盒子说明：盒子前面有名字和品牌，还有要传达给购买者的主要好处列表（这里的购买者是最终将会使用产品的人，可能是组织内部人员，也可能是真正的付费用户）。盒子背后包括操作指南（大致的设计决策），还有产品将会提供的关键特性列表。

构建愿景盒子是创造性活动，能帮助团队明确表述他们的想法。分成多个小组的方法更有效，各个小组可以各自构建一个愿景盒子，然后他们可以把盒子“卖”给团队其他人。各个小组展示完成后，应该可以产生一个共享的愿景盒子，并传达出整个团队的想法。

业务受益矩阵（Business Benefits Matrix）

使用简单的矩阵，把产品希望提供的战略价值表述出来。该矩阵类似下表：

首要

次要

第三

增加收入

在上线 12 个月后增加 25% 收入

  降低或避免产生成本
 
  不可行

改进服务

在每季度的满意度调查结果中，将客户满意度评分提升 20%
 
其他
 
  由于客户满意度提升，降低呼叫中心人员流失率

根据战略驱动因素，项目的目标得以表述。只能有一个首要驱动因素，也许会有多个次要或第三目标。如果某列中有多于一个目标，那么就要对他们排序，以避免“所有的都很重要”之类的冲突。

以小组形式准备该矩阵，团队能从中深入理解项目清晰明确的中心目标。

滑动器（Slider）

从多个维度向团队展示优先级的工具。

滑动器的范围从“ON”到“OFF”。如果某个因素处于“ON”一侧，那么它就是最强有力的因素，推动项目前行时的决策制定过程。任意两个滑动器不能处于同样水平。处于“ON”一侧的滑动器越多，项目发生灾难性失败的风险就越大。当项目滑动器所展示出的活动余地越少，这个项目就会面临“要么交付一切，要么交付空白”的境地。更多的活动余地能够允许部分交付，这有助于达成组织目标。

Rob Thomsett 在他的《 Radical Project Management 》一书中描述了滑动器工具。Mike Cohn 也在他的网站上提供了设置滑动器的在线工具。

项目范围矩阵（Scope Matrix）

“功能进出列表（in/out list）”是简单的工具，能够清晰说明当前项目要完成的工作，哪些不需要在当前项目完成，以及可交付物存在哪些不确定性。

议题

进

出（责任）

（接听服务电话）

X

（将服务电话转给技术支持人员）

X

（通过服务中心推广新产品）

X

（债权人通过服务台跟进）
 
X
 
          未确定

（基于 Web 的自服务能力）

如果议题处于“进”这一列，项目团队就要负责交付相关组件。如果某些功能明显超出范围，团队就根本不会花费时间或精力在其之上。如果“出”这一列中的议题是大项目组依赖的功能，那么必须明确定义谁负责完成相关工作，定义其属于哪个项目和负责人，确保该议题相关功能得到交付。

范围不确定的议题进入“未确定”区域。团队不会开发这样的功能，产品负责人或是项目经理要深入调查，以确定该工作是否属于项目范围。

Rob Thomsett 在他的《 Radical Project Management 》一书中也描述了该工具。

成本 / 收益矩阵（Cost/Benefit Matrix）

对于组织为当前项目付出的成本和得到的收益，我们会有一个估算。该工具会告诉大家：这个估算的不确定性程度如何。在项目早期，成本会有一个不确定性圆锥【原注5】，随着项目推进，该圆锥的顶角会越变越窄。收益的不确定性也很大。只要估算范围正确，在成本和收益方面的不确定性算不上大问题。成本和收益都应该展示出三个水平：乐观情况、最可能发生情况、悲观情况。例如：

表格中每个单元格的数字是收益减去成本之净差。

该项目应该被视为高风险项目，因为有明显的风险表明组织可能在上面赔钱。如果一切顺利的话，也许有其他驱动因素能够保障投资和回报。

对项目进行成本/ 收集分析主要是管理层的责任，但是在财务方面的目标和驱动因素应该分享给团队。

明确说出愿景

借助这些工具，团队可以明确了解项目的目标和方向，知道为什么要展开当前项目的工作。

准备产品愿景，是一个项目非常重要的起点，并为团队在项目进行中保持正确的方向和重点提供保障。之前工作组讨论中产生的墙件（wallware）【原注6】应该出现在团队的工作环境中，为项目工作的任何人只要一抬眼就可以看到项目的驱动因素和目标。撰写正式的文档来综述产品愿景，这样做也很有价值。要知道：文档只有一部分价值，另一部分价值来自于团队在产生愿景的过程中对产品和项目的共同理解。

如果开发产品的团队分散多地，应该在产生产品愿景时，把他们聚在一起。这可以塑造出“一个团队”的文化，并对他们分开之后的沟通有帮助。

如果有成员在愿景产生之后加入团队，必须要有人带着他们把项目章程过一遍，这个人还得是参加过工作组讨论的。唯其如此，新成员才能理解工作背后的驱动因素。

产品愿景的管理是产品负责人的责任，他负责将业务需求带给项目团队。如果在项目执行过程中，环境发生变化，愿景无法达到，或者组织的目标和驱动因素发生作用，使得项目无法在其基础上交付，项目应该停下来，并重新评估。产品愿景的变化，常常是组织生态系统发生重大变化的证明。

产品路线图

产品路线路是一个列表，列出为了达到产品愿景需要交付的关键功能和特性。当项目需要延伸到产品的多个版本发布时，产品路线图是非常重要的。如果只需发布一个版本，那么产品路线图和发布规划就没有区别。

产品路线图基于时间的视角，来看产品的预期交付周期。它是高层面的规划，由产品负责人和项目经理维护，并随时间发生变化。

产品路线图要定期与产品愿景互相验证，并让团队和其他人知道产品各个组件可能的发布日程。

产品路线图处于特性和“史诗故事（epic）”的层面，用户故事不包括在内。

产品路线图要通过可见大图标来展示重要的里程碑、功能特性和目标发布日期。发生变化时，可以从路线图中加入、移动或是移除一些条目。

下图是一个真实项目的路线图实例，展示出六周之内的两个版本发布周期：

（图片来源：新西兰， Livestock Improvement Corporation ）

该路线图位于团队环境的过道中，起到信息辐射器作用，让所有工作在同一个项目组的团队们都能看到，其他任何对项目感兴趣的人也可以参考。产品路线图为从事同一个版本发布的各个团队们提供上下文。

版本发布计划（Release Plan）

版本发布计划展示出产品当前发布版本要交付的特性，其中包括当前大家达成一致意见的、经过排序的史诗故事和用户故事。版本发布计划基于预期的团队速度，并告诉大家当前版本中包括哪些对产品的共同理解。

最初的产品规划活动要由团队和产品负责人共同完成，产品负责人要提供当前版本的目标。一个版本发布包括一系列迭代，团队在这些迭代中完成工作，交付一系列特性，为组织提供可度量的价值。一个迭代中要完成的一系列功能特性构成了版本发布的条件，并且是当前发布版本要交付的产品整体功能特性的子集。

故事和史诗的大小应该使用故事点数【原注 7】或是理想工作日估算出来，并按优先级排序，这样工作就可以分配到各个迭代之中。版本发布规划活动以产品负责人解释待发布版本的目标开始。团队讨论在这样的目标下，需要交付哪些东西，并表明在交付时需要考虑哪些因素。其他要考虑的因素包括风险，以及史诗和故事之间的依赖。高风险、高价值的功能特性应该排高优先级，以早日交付，这样项目就可以调整，以应对风险是否会演化成严重问题（比如，我们掌握的技术无法做到我们期望的结果）。依赖关系也许会影响交付的顺序（如果我们先完成这一块，那一块后面做起来就容易了）。

版本发布规划活动从团队的速度开始，如果这是第一次版本发布，就需要估算团队速度，对于后续的版本发布，此前版本发布时的实际速度就可以用来作为参考（除非团队在版本发布之间发生巨大变动）。

刚开始只能猜测估算速度，要想得到更为准确的猜测，就要花更长时间来得到结果。最简单的方式是：询问团队，让他们估计自己能够在一个迭代内完成多少个故事点数，并在这个数字上做计划。结果可能不准确，但是已经可以作为好的起点。

要对团队的交付能力有更好的估算，就得使用更彻底的估算技巧，要知道想得到更准确的结果，就得付出更多成本，而且付出的成本不一定能够提供更多价值。James King 在自己的网站上提供了一个有用的估算工具包，可供下载。

得到估算速度之后，就可用其规划迭代，步骤如下：

1. 按照优先级顺序，列出故事和史诗，并注明它们的故事点数大小。
2. （根据估算活动）判断一个迭代中可以交付多少故事点数。
3. 考虑团队需要完成的非用户故事工作可能产生的影响，比如在早期的迭代中，由于工具和工作环境不到位，工作效率会受到影响。
4. 向计划中加入一个新的迭代。
5. 向迭代中加入故事，直到用掉所有的工作能力。
6. 询问：是否所有的故事都已经解决、版本发布目标是否达成。
7. 如果没有，那么向计划中加入新的迭代，并重复步骤 5 和步骤 6.
8. 一旦所有的故事都已经分配完成，与大家就计划进行交流，并征求他们的反馈，看看这些计划是否现实并且可以完成。

这个流程可以通过下图展示：

版本发布规划是一个具备适应性、可调整的计划，它将会随着项目推进而改变。一旦版本发布规划完成，而且大家对之达成共识，它就可以用来指导迭代中的工作。版本发布规划也可以用来制作项目的最初目标速度图。

迭代规划

在每个迭代的开始，团队根据从已完成工作中得到的经验教训、以及项目所处的更大环境，可以重新规划项目剩余的工作。迭代规划会议有两个主要活动。

• 验证、更新版本发布规划
• 为当前迭代制定迭代计划

第一个活动中，可以检查当前的版本发布规划，并根据自上次更新来发生的任何变化，更新当前版本发布规划。迭代的开始，就是敏捷项目调整的时候，基于项目环境的实际情况，可以改变规划。

有可能影响、修正版本发布规划的事情包括：

• 上个迭代中交付工作的实际速度。它比预计的是快还是慢？速度的变化会改变在项目剩余时间中的工作范围。
• 现有故事和史诗在优先级方面的变化。
• 由于项目环境发生的变化，导致需要引入新的故事和史诗。
• 随着工作进行而显现出来的缺陷和技术债务【原注 8】。
• 风险识别完成后，出现了新的故事，或是已有故事发生改变。
• 之前迭代中悬而未决的故事。
• 非项目工作，降低了团队领取项目工作任务的能力。

迭代规划会议的首要任务，是要发现当前最重要的故事和史诗，团队将会在当前迭代中针对它们开展工作。产品负责人会说明当前的优先级，还有发生改变的原因，确保整个团队对于优先级为什么要改变有明确认识。

当史诗和故事的列表重新排序完成，而且所有团队成员都已经了解了修正后的发布规划之后，团队就会制定当前迭代中需完成工作的详细迭代规划。

团队会基于“昨天的天气”（很可能他们在当前迭代完成的工作量与上一个迭代相同，除非工作环境或是团队构成发生重大变化）和常识，估算自己能够在当前迭代中完成多少工作。然后团队就会基于自己的工作交付能力，选择当前迭代要开发的工作。

选定故事和史诗之后，团队就会把工作拆分成特定的任务，并分配给每个团队成员。理想状况下，任务分配会以“拉”的形式完成，团队成员根据自己的工作能力，选择自己要做的任务。任务应该非常小，从几个小时到 1 天不等，而且要是分散的、可度量的活动。迭代经理（Scrum 中就是 Scrum Master）确定所有的工作任务都有人领取，而且会对承诺完成的工作做健全性检查（sanity check）：根据项目的环境现状，团队是否有能力交付他们承诺完成的任务？

当任务都被识别完成后，团队成员会对其排序和估算。估算现在基于完成某项任务需要的小时数。这些任务应该写在任务卡片上，并在故事墙上跟踪这些任务卡。

任务与故事连在一起，在故事墙上跟踪某个故事的状态迁移，要与其所包含任务的完成状况相联系。

迭代中的任务，包括为了完成故事需要完成的所有工作，还有为下个迭代的准备工作。

迭代 Backlog 列出了当前迭代中在故事墙上要跟踪的故事和史诗。

下面展示了一个任务列表的部分示例。

故事 ID

任务

负责人

估算小时数

剩余小时数

实际小时数

S123

将故事分解为验收条件

Bob, Mary, Peter, Steve

4

4

S123

从验收条件构建测试用例

Mary

2

2

S123

UI 设计

Peter, Steve, Bob

2

2

S123

UI 编码

Peter, Steve

4

4

S123

中间件编码

Peter, Steve

4

4

S123

数据库编码

Peter, Steve

4

4

S123

编写 Furblesplong 系统接口

Garth

8

8

S123

将 Furblesplong 接口整合到代码库中

Peter, Steve, Garth

2

2

S123

执行系统测试

Mary

4

4

S123

系统探索测试

Mary

6

6

S123

设计验收测试

Bob, Mary

2

2

S123

编写版本说明

Peter

1

1

S123

执行验收测试

Bob

4

4

S123

故事编写工作组，将史诗拆分成下个迭代要开发的故事

Bob, Mary, Peter, Steve

2

2

在迭代中，团队成员要根据任务来报告和跟踪他们的工作进度。这是他们个人每天做出的承诺。

燃尽图能够展示出初始的估算和迭代剩余的工作。每个任务实际花费的时间会得到跟踪，并用来帮助团队在下次迭代规划会议中的改进估算效果。

每日承诺

团队成员就是在这时候监控他们的进度，并根据他们承诺要完成的任务报告进度。

在迭代内，每日立会是团队沟通进度的首要沟通工具。在项目的每个工作日里，团队聚在一起，并向彼此报告各自承诺要完成的任务进度状况。每日立会有一些简单的规则：

• 它采取站立方式进行。
• 最长持续时间是 15 分钟。
• 每个团队成员发言时间不超过 1 分钟。
• 仅从用户故事和任务的层面报告进度。
• 任务报告只有两种状态：完成或未完成。
• 未完成任务要说明还需要几个小时 / 几个点数 / 多少工作量才能完成。
• 阻止任务完成、或是项目进度的障碍要单独报告。
• 每个团队成员都要回答以下 3 个问题：
  • 从上次会议开始，你完成了哪些工作？（要指明完成哪些任务，而不是如何度过你的一天）
  • 你将会在下次会议之前做哪些工作？
  • 哪些东西阻碍你的进度？（“没有问题”，意味着你能够交付自己当前的任务，而且符合估算的时间范围）
• 如果遇到需要解决的问题，可以在每日立会之后处理。在每日立会之后进行一个简短的 1 对 1 会议解决特定问题，这是常用做法。
• 迭代经理主要负责移除障碍，让团队充分发挥工作效率。

敏捷项目必须提供能够“安全失败”的环境，团队成员不会因为没有达成任务承诺遭受惩罚。大家要能够安全说出任务状态的真实情况，并且了解项目环境的现实情况。有时，我们的估算可能很糟糕（只是估算而已，又不是报价），又或者某些事情的发生让某些成员无法完成任务，整体环境必须让他们能够说出真实情况，这样团队成员就能调整他们的日程表，将任务排序，并调整适应项目的现实。

当一个故事所有的任务都已经完成后，故事就会移动到“完成”状态，而且这部分工作的故事点数会算到团队速度中。

结论

“在准备战役的过程中，我常常发现：计划是没有用的，但是计划的过程却必不可少。” 艾森豪威尔

下表总结了规划的多个层面，还有各个层面规划流程中的活动：

个人

团队

扩展团队

项目出资人

PMO

战略组织

每日承诺

个人任务规划

        迭代规划
为迭代规划任务和工作

影响

    版本发布规划
  定义版本发布里程碑

影响

  产品愿景
 
    定义并明确表述愿景
  项目组复审
 
      整体项目组结构和集成
项目组合复审
 
      根据战略目标，选择开发哪些项目

影响

战略复审

        提供整体方向

计划活动遍布敏捷项目之中，简单的工具和安全的环境能够支持适应性的规划和真实的报告，这意味着进度能够得到真实了解，管理层也因此能够获得他们需要的信息，来做出优秀决策，为组织、团队和项目交付出最有价值的成果。

系统开发常常在复杂和难以预测的环境中进行，敏捷规划需要考虑到这一点，而且要知道灵活性和响应变化的能力无与伦比。

参考

• 《管理敏捷项目》——Sanjiv Augustine
• 《敏捷项目管理》—— Jim Highsmith
• 《项目管理修炼之道》——Johanna Rothman
• 《管理你的项目组合》——Johanna Rothman
• 《Radical Project Management》——Rob Thomsett
• 《敏捷估算和版本发布规划》——Software Education
• 参考该链接

原注：

• 【原注 1】：我们使用“预先规定好计划的（predictive）”这个词，而不是更易于挑动感情的“瀑布式的”。在预先规定好计划的项目中，需求不太可能发生变化，而且完成的工作也易于辨别和度量。举个例子：向组织中所有的电脑上部署新的操作系统，这就可被称为是预先规定好计划的项目。升级每台电脑需要的工作量和时间都是可以预计的，而且在某个范围内，增加参与工作的人数，会让工作所需时间线性减少。适应性项目中，需求很可能发生变化，而且工作在很大层面上是创造性的，不确定性很高——软件开发在本质上是适应性流程，难以设计出预先规定好计划的项目管理框架。
• 【原注 2】：Alistair Cockburn 对迭代式和增量式的讨论很有价值：迭代意味着服从变化，增量意味着一小块一小块地进行。敏捷开发既是迭代式的，又是增量式的。可参见此链接。
• 【原注 3】：见 Johanna Rothman 的《项目管理修炼之道》第 16 章。
• 【原注 4】：见 Sanjiv Augustine 的《 Managing Agile Projects 》。
• 【原注 5】：参见该链接。
• 【原注 6】：墙件（wallware）指团队空间之中及其周围明显陈列出来的挂图、图片、故事卡和其他产物。这些东西提供了项目的可视化记录，说明关键决策，任何对项目感兴趣的人都可以看到。其他类似常用属于包括信息辐射器和大型可见图表。
• 【原注 7】：故事点数是估算工具，基于相对的工作量大小和需交付产品的复杂度。使用故事点数规划，利用了协作的能量，所有团队成员加入到评估活动中，从复杂度方面评估用户故事。针对某个故事，估算时要考虑实现困难程度、理解清晰程度和技术风险。相对于传统的在项目开始时一次性完成的估算，人们发现该方法要更为有效。
• 【原注 8】：参见该链接。

译注：

• 【译注 1】：这是著名的 7Ps 谚语，原文为"Proper preparations prevents poor performance."因该句话中共有 7 个 P 而得名。
• 【译注 2】：埃德蒙·伯克（英语：Edmund Burke，1729 年 1 月 12 日－1797 年 7 月 9 日），爱尔兰的政治家、作家、演说家、政治理论家、和哲学家，他曾在英国下议院担任了数年辉格党的议员。他最为后人所知的事迹包括了他反对英王乔治三世和英国政府、支持美国殖民地以及后来的美国革命的立场，以及他后来对于法国大革命的批判。详情可参见其维基百科页面。
• 【译注 3】：可参考 Johanna Rothman 的《项目管理修炼之道》第 14 章。