敏捷规划时间表

本文要点

• 敏捷规划时间表能够可视化展示项目进度
• 使用敏捷方法在一个比较高的层次控制项目
• 敏捷规划时间表可以作为可量化的高层次交付的挽具
• 它提供了一种工具来协调项目活动
• 它有助于强化有效沟通

与自己定制开发相比，你可能会选择购买一款适合你的业务的软件。这似乎是一种更好的方案，因为它不仅满足了你的业务需求，还不需要自己定制代码。简直太完美了。通常，你会根据自己的业务需求，确定一个最佳的软件实施日期。举个例子，如果你是做糖果的，你不会在情人节前或者复活节周末前实施这款软件，（毕竟你需要在重要的业务活动期间保证业务的稳定）。

软件供应商会根据你的公司情况以及类似公司的软件实施经验，预估软件的实施期限。这时，你可能还不清楚，实施这款软件都需要什么以及哪些是必不可少的。你的预期是，这款软件会百分百适合你的业务并且非常容易部署。而且，这款软件必须一次性部署完毕，而不能一点一点地部署。你也许还能够预先进行一些数据转换，但是重要的新功能必须在一个时间点部署完毕，并且部署时间不能超过几周。

高层管理人员通常非常期望通过实施新软件，来利用更好的新功能。他们分析业务需求，从而推算出“上线”的最佳时间，然后将这个日期告诉主题专家和 IT 部门。但是，通常这些专家在经过简短的调查之后会回复高层管理人员，这个日期是不可能的。

这些人才更专业，知道必须要做什么。他们是专家，你不能忽视他们的话。这时，高层管理人员问，“那么，到底都应该做些什么？”专家们然后会尽力用一种简单明了的方式，在一个比较高的层次解释如何实施这个软件。高层管理人员对于细节不感兴趣，他们需要有一个高层次的理解，即有哪些主要项目活动、每项活动要花费多少时间、谁来做这项活动。

团队通常面临三大挑战：

1. 合理预估必须做什么以及做多久。
2. 建立实施控制，提供反馈，从而满足时间表。
3. 协调软件实施和现有的敏捷实践之间的冲突。

敏捷规划时间表（PAL Schedule，即 Planned Agile Leadership Schedule）可以用每个人都能够理解的方式，清晰地展示高层次的工作分组。请注意下面的插图：

敏捷规划时间表

方法论的冲突

在创建敏捷规划时间表的过程中，团队会面临一个挑战。你们已经非常艰难地转向了敏捷流程，但是软件包的部署通常是一个瀑布模型。瀑布模型和敏捷模型有点像油和水的关系，互不相容。你怎样来调和这两种流程模型呢？你想要保持敏捷流程，但是你又有一个指定的上线截止日期。

方法论调和：敏捷模型vs 瀑布模型

软件实施团队由负责评估现有功能和新功能的主题专家、负责基础设施的IT 专家以及某些业务属性所需的各种专家。这些专家必须开会决定必须做什么来实施新的软件。将必须做的大型活动分派给每个小组，制定绝对能够完成这些活动的最短时间范围。不要担心具体的计划，保持高级别的角度。将这些安排到一个基于高层管理人员指定日期的时间线上。如果你不熟悉IT 软件实施，供应商可以帮助识别需要考虑的高级组件。

和高层管理人员沟通，告诉他们，只有在满足时间表的情况下才能在规划的日期达成目标。如果你错过了第一个迈向下一个大领域的关卡，你就会很快清楚为什么那个日期是不可行的。

让我们具体说下敏捷规划时间表是什么以及不是什么。

它不是：

首先它不是一个MS Project 计划表。它很简洁！它不会给出所有的任务，只会给出主要的团队活动。各个团队应该根据计划通过像Jira 之类的工具确定任务来完成分组。每个阶段都各自定义了一些需要完成的任务。对于测试团队来说，测试阶段定义了需要执行的测试任务，这些任务需要在那段时期内完成。这些应该记录在Jira、Jama 或者HP ALM 之类的工具中。

MS Project 示例

所有任务都在一个工具内定义。这就是敏捷。

截止时间

时间表不应该是一个死亡竞速。令人非常吃惊的是，有那么多明知不可能完成的或者至少对于当前团队来说非常难以完成的时间表。时间表的目的是切合实际地预估，什么人在什么时候应该围绕项目完成什么任务。时间表的预估应该基于最合理的团队猜测。

它是：
所需项目进度的一种可视化展示

敏捷和六西格玛方法论最基本的元素之一是，可视化展示对于团队来说可能是最好的指引。这就是所谓的敏捷规划时间表——一个关于整个实施过程（从头到尾）应该做什么的可视化展示。这个时间表如此有用的原因是，它保持了主项目活动与什么时候必须完成之间的强关联。完成情况直接链接到在敏捷项目工具中用文档跟踪记录的活动。除了在选中的工具中跟踪单独的活动之外，活动分组也在时间表中进行跟踪。团队用颜色标记，使得每个团队成员负责的计划内容可以很快识别出来。为了达成这个时间表，团队必须准备好下一个迭代和增量阶段。每个阶段都关联到对应的标准，这些标准必须由工具生成的可测量和识别的统计数据所支持。如果统计数据不支持进入下一个阶段，高级管理人员和整个团队会立刻知道这个时间表可能有风险。这使得执行力比通常快得多。可以立即采取补救措施，要么转移计划，要么采取行动让计划回到正轨。

与各个团队一起创建这个计划的人员应该努力让这个时间表易于阅读和理解。这就需要只将需要知道的信息放在时间线上。在项目的各个时间点，当需要的时候，再将更详细的计划信息发布到团队中，在那之前团队不需要考虑这些详细的信息。

任务时间

所有权：时间表由整个团队负责。

这是敏捷方法论的一个基本原则。所有团队成员都全力以赴，坚持在时间表期限内完成工作。团队自发支持和实现计划目标。最好组织一个正式的会议，来使团队接受规划的时间表。如果任何一个团队认为这个时间表不合实际，这些担心应该被着重处理。如果团队决定带着问题继续原有的时间表，那么在每个分组的具体就绪标准中包括含有疑问的标准会是一个不错的主意。这使得管理层和团队能够在标准没有实现的特定时刻评估这些顾虑，从而作出必要的补救措施。

挽具：时间表是敏捷流程的挽具

敏捷流程是由各个具体的交付阶段组成的。这些具体的冲刺阶段会映射在时间表上。各个冲刺阶段所要完成的任务都是清楚透明的。

不像普通的冲刺跟踪那样，敏捷规划时间表使得团队可以持续了解项目当前时期的计划安排。这使得团队不仅能够持续了解当前冲刺阶段的状态，也能够持续了解整个项目的状态。

秘方：计划是基于可量化的频繁交付的。

其中的秘方是，敏捷规划时间表与可量化的频繁交付密切相关。所有的冲刺阶段和测试阶段都罗列在内。你的冲刺阶段和测试阶段都有具体的交付产品，至少包括当前阶段的所有组件以及相关缺陷时期的所有测试。在表中，这些时期用红色圆圈圈起来。这些都是在这个比较短的时间段内必须完成的工作。

注意需要完成的具体工作。在时间表中不会定义每个详细的组件，而是会给出一个非常高层次的分组描述。例如，在列出的第一个时期内，团队集中验证与客户、任务、管理、会计、邮件相关的功能以及相关缺陷。通过给出这种高层次的描述，整个团队就可以知道需要聚焦的领域。他们还能够识别出现在哪些应该做并且能够做，而哪些必须等到下个迭代再做。如果有哪些方面没有完成，这些都会记录成文档，从而让团队会知道他们必须回过头去完成所需的功能。通过标示这种分组，团队还能够保证所有领域都被完成了。这些都是主要领域，通过识别其中每一个领域，团队可以放心地预期在安排的时间内完成计划。最后一个好处是，这些领域不会被遗漏。所有团队成员都可以审核列出的内容。令人吃惊的是，有时标准领域或者标准领域的组件会在时间表的第一份草案中被忽略。

这些交付在预定时间内要么完成了，要么没有完成。通过跟踪这些交付，团队和高级管理人员就会知道时间表达成了没有。应该每天公布这些统计数据。在每个时期的尾声，应该对这些统计数据进行评估。万一交付总是延期或者未完成，团队就可以很早知道项目偏离了预期。

合作：团队需要协作。

只有所有成员一起往前努力，项目才会往前推进。这是对团队活动和团队协作的一种聚焦。如果其中一个团队没有按时交付给他们指定的交付物，整个项目都会被向后推迟。这种情况的一个例子是 IT 团队搭建测试系统。如果测试系统没有按时准确地搭建，后续的测试阶段就没法启动。如果集成的 IT 结构不到位而且不具有操作性，相关的测试也无法进行。如果开发阶段的交付物没有完成，相关的测试就会被延迟。

如果来自遗留系统的数据没有针对测试进行转化，整个项目会被延期。在下图中，你可以看到，如果数据没有转化，Core Billing Validation（核心对账功能）就无法启动。

频繁的里程碑

频繁的里程碑：里程碑从一个高级别的角度跟踪完成情况

上图中的计划展示了频繁的里程碑。这些里程碑都是时间表上具体的交汇点。里程碑代表了相关标准的关卡。如果这些标准没有实现，其中的差异必须修复解决。这些标准由使用的工具生成的统计数据所支持。因此，里程碑对应的标准是否完成是可以测试和验证的。与冲刺及测试阶段交付的唯一区别是，里程碑交付是一种更高更复杂级别的表示。

通常，团队基于里程碑来决定项目是否能够进入下一个阶段。下面是里程碑“上线就绪”的一个例子

• 所有功能都符合业务要求。
• 突出的缺陷是可以接受的。它们都无关紧要或者有解决办法。
• 所有的数据都进行了转换和清洗。
• 性能达标。
• 满足安全或合规要求。
• 培训已经完成。
• 切换计划经过测试并已经就绪。

所有上述就绪标准都应该由可展示的统计数据支持。

沟通：所需的所有沟通都应该包含在内

敏捷规划时间表的沟通安排很充分。团队所需知道的关于如何向前推进的一切事情都应该包括在内。

团队通常由遍布全球的各种各样的人组成。对所有人员来说，敏捷规划时间表是一个非常有价值的工具。每一个团队成员和高级管理人员都可以通过它来理解和支持计划安排。

我工作过的项目中，敏捷规划时间表都成为了整个团队都认可的很有价值的工具，还从没有过例外。

让敏捷规划时间表保持充分沟通和敏捷精炼。

有时，具体的沟通应该公布出来，从而让团队明确知道将会在什么时候发生什么事情。注意截图中开始的部分，在集成测试、并行测试和终端用户验收测试之前，都有一个星星。这三组活动都是各种团队完成的。大部分项目都需要整个团队齐心协力。IT 部门负责构建系统并集成；核心主题专家负责验证功能；最终用户（通常刚刚接触这个项目）负责以他们的角度来验证功能。大部分参与人员都需要提前充分了解这项活动的时间安排。

团队协作

这些最终用户通常必须整个工作日都投入这项验证。有时，由于业务需求与项目规划冲突，时间表还需要额外的资源或者重新规划。通过这个可视化的展示，核心团队能够确保沟通足够广泛和深入，从而避免发生意料之外的事件。

注意下面的截图。其中你可以看到项目活动的负责人从一个团队变更为另一个团队，这时应该向团队公布一个详细的时间表。在详细的时间表中，你可以看到所有权转移的准确时间和日期。这对于团队非常苛刻并且需要坚决遵守。你只需要适时将它发送出去，而不需要现在就操心这个级别的细节，除非你达到了这个时间点。最终的详细时间表在发送之前，需要得到团队的同意。大多数时候，这个时间表是经过高度协商的。每个团队都仔细确保他们能够实现其中的计划。Resource（资源）栏罗列的人，负责向团队确认具体计划已经开始。团队还应该知道成员都有哪些人以及谁有权力在流程中改变这些安排。因为这是一个非常严谨的沟通，因此一旦最终公布，我很少看到偏差。通常，团队都为计划做好了准备，因此偏差会给针对这个时期已经计划好的活动造成巨大的破坏。因此，即使有些活动稍微提前完成了，后续的活动也不会马上跟进。

注意，这个时间表没有提供其中的具体工作。这又是一种精炼方案。不要给所需之外的信息。应该由各个团队详细制定各自必须完成的工作，从而支持敏捷规划。因为它对这些人员是如此严苛，因此通常可以放心地认为这些详细的工作已经被仔细地审核过了。没有哪个团队想要因为没有完成时间表而变得尴尬。在针对具体活动的准备会议中，团队可以解释他们打算做些什么来实现这个时间表。

所有权传递

如何创建敏捷规划时间表：

敏捷规划时间表的英文名字是 PAL Schedule，即 Plan Agile Leadership Schedule。如何创建这种时间表，以下活动可以说是最简单的解释：

• 在时间表的表头标明月份和星期。
• 挑选一个日期。
• 根据这个日期进行倒推。
• 确定完成计划所需的主要领域 / 团队。
• 各个团队用颜色进行标注。
• 标注关键路径上的主要工作。关键路径通常由功能主题专家所说的领域组成。
• 评估每项工作的持续时间。
• 有些领域可以并行进行，而其它领域则需要按顺序进行。
• 标注并行工作。这些通常都是数据转换、性能、基础建设、设置和安全所需的活动。
• 确保将依赖记录和考虑在内。例如，只有基础设施就位才能进行集成测试。
• 建立里程碑。里程碑通常是下一次主要迭代的终点或开端。
• 明确每个里程碑的就绪标准和完成标准。这是团队在下一个后续阶段开始之前，如何判断什么必须被完成的方法。这使得目标保持清晰和可测量。
• 几乎所有工作都是增量迭代的。

将所有精英团队都映射到敏捷规划时间表上。

• 标注冲刺。
• 上文定义的时间表“挽具”适用于所有的冲刺。
• 明确交汇点或者里程碑。
• 所有团队都可以查看时间表并依据时间表跟踪工作进度。
• 如果里程碑标准达成，团队对时间表的所有验收就是“可行的”。
• 清晰可测量的数据应该支持就绪标准的完成情况。
• 指标要每天发布和评审。

每个团队控制他们各自的流程（冲刺、项目计划、任务活动、测试等等）。充分明确团队的集成时间点，并将时间安排公布给所有的团队成员。时间安排要精确到天和小时。每个人都拥有活动完成的发布权和任务归属的转移权。

关于“明确主要领域”的更多信息

1. 配置和初始化测试（迭代 1）：业务主题专家可以审核软件的菜单结构。负责各个领域的主题专家能够审核他们各自负责领域的菜单结构。只需通过了解遗留功能和查看菜单选项的数量，业务主题专家能够对他们会花费多长时间来配置那个领域并针对配置进行测试有一个粗略的评估。这是增量迭代方案的非常初期的阶段。通常在这个时间点，只重点关注主要的客户、产品等。这时的功能领域通常分开考虑，而不会将这些模块集成起来看。使用的数据是由主题专家创建的，而不是经过转换的遗留数据。

2. 数据迁移验证（迭代 1.1）：这项工作通常被轻视。时间表上的每项主要工作都必须完成迁移。这意味着，数据应该针对功能测试、系统测试、集成测试和终端用户验收测试进行迁移。这些迁移工作的时间应该考虑在内。其中一些挑战是：

3. 一变多：一个遗留数据元素转换为多个元素。

4. 多变一：多个遗留数据元素转换为一个元素。

5. 新数据：新系统所需的数据在遗留系统中不存在。

6. 脏数据：遗留系统的数据必须在转换之前进行清洗。

7. 数据在遗留系统中是一个文件，而在新系统中是一个配置元素。

8. 功能测试（迭代 2）：这是验证新系统的重中之重。对于每一个领域，所有的功能都应该考虑在内。这也是团队通常开始“快乐之路“（Happy Path）的地方。这里是指，从功能的开始一直到功能的结束（都没有任何异常和错误）。通常如果集成没有完成，则需要 IT 人员帮忙获取从一个点到另外一个点的数据来完成完整的“快乐路径”。主题专家通常具有通用访问权限，可以测试没有安全限制的功能。团队就是在这时指定角色和相关事务。完成和验证情况由工具统计数据支持。

9. 系统集成测试（迭代 2.1）：新的软件包必须集成其它系统。明确敏捷规划时间表上的所有集成及其相关测试是非常重要的。必须执行这些测试来验证集成是否生效。没有明确时间表上的所有集成是一个非常糟糕的失误。验证由工具的统计数据支持。

10. 性能测试（迭代 2.2）：当主题专家通过功能测试，就应该将性能问题作为缺陷录入测试软件。这些缺陷必须被重点关注。主题专家必须指出哪些性能是必需的。应该使用测量性能的软件工具来证明性能指标是否被实现了。这些统计数据由工具支持并且每天发布。

11. 系统集成（迭代 2.3）：IT 部门必须完成这些工作来执行集成测试。所有的集成测试应该是“黑盒”的，IT 主题专家无需做额外工作来让集成生效。系统应该在不需要 IT 团队任何调整的情况下执行。这由工具中定义的活动支持。

12. 安全（迭代 1—4）：这是另外一个经常被轻视的领域。通过明确所需的角色和角色相关的事务，给用户赋予一个角色。这是增量迭代的。其中的关键是，随着时间表上的每次迭代分组，安全性在具体问题和全局上就更明确。你从系统中的高级别的角色定义和由主题专家进行的终端用户测试中逐步推进。这些角色定义了系统中的相关事务。安全团队必须在将要进行测试的用户之前解决安全问题。这由工具统计的所需活动的完成情况支持。统计数据反映完成情况。

13. 终端用户验收测试（迭代 4）：对于企业来说，终端用户可能分布在所在国家或者全球的不同地点。他们不是主题专家。他们是运行公司的实际员工。这项测试非常重要。它要实现两个目标：针对特定地点的功能验证能够通过，以及终端用户获得关于系统如何运行的宝贵经验。但是，不要将这与培训混为一谈。培训是分开的。

14. 切换计划和执行（迭代 1—4）：随着团队完成数据迁移，他们会开始构建切换计划。他们会这样演练很多次。当准备好的时候，IT 和业务主题专家就可以进行实际切换所需的其它工作。

你的项目经理如果经验丰富，通常在一点点帮助下就能够画出敏捷规划时间表的初稿。然后主题专家主管可以补充所需的工作和时间。IT 团队则负责补充 IT 领域。

在完成第一份草稿的基础上，团队可以和高级管理人员开会讨论这个时间表并决定其中的日期是否合理。

警示

敏捷规划时间表是增量迭代的。时间表的每个阶段都是基于前一个阶段构建的。每个过程领域指定的任务都更加困难。

• 小心 80/20 原则。不要自以为是地认为你已经完成了大部分工作，实际上你可能只完成了一小部分。最后的 20% 功能验证通常是最复杂的功能，比最初的 80% 花费的时间要更长。
• 尽早实施“快乐路径”。这意味着，你从业务流程的开始推进到新软件的结尾。如果一切正常会怎么样呢？你可以将一个功能从开始推进到结尾，然后投入其它的功能验证工作。
• 对于非常复杂的功能，仔细写下来，要先写综合测试，再写代码。这也要求你稳定针对测试的数据。这是大部分团队都会犯的比较常见的错误。我过去几乎在每一个项目都听到，“这个方法很难说清…“。口头解释功能如何生效是很常见的。更好的方案是用预期数据建立测试，对测试中的功能执行特定操作并提供预期的结果。这可以在电子表格上高效完成。这种方案有许多好处。大多数时候，不同的主题专家可能会对系统应该如何工作有不同的期待。商定的电子表格消除了这一误解。如果数据没有稳定，那么数据会影响预期的结果。通过创建数据或者“修复”数据元素为特定的数值，主题专家和开发人员才会知道这个功能上的数据影响。在数据稳定期间加入额外的元素是非常常见的，因为团队在创建电子表格的时候还不会考虑到这些。当然，这个电子表格也在工具支持的敏捷流程中。
• 每天公布工具的统计数据。在统计数据中给出有意义的可执行的信息，例如什么完成了，什么没有完成。记住，在这里，低级别的活动连接到敏捷规划时间表。工具应该支持所有这些活动。如果工具中的低级别活动没有完成，敏捷规划时间表就存在风险。最好的数据统计通常是可视化的，因此，在数据统计中包含这三种可视化展示（燃尽图、柱状图和饼图）。所有的工具都有使得团队深入这些图标背后具体信息的功能。这使得团队很容易确切知道什么被完成了。
• 许多工具都有仪表板，团队可以在其中跟踪进度。确保仪表板给出了团队保持跟踪所需的信息。
• 不要用电子邮件来描述或支持团队活动，例如需求收集、测试或缺陷跟踪。几乎毫无例外，电子邮件是每一个实施团队的祸根。最好在项目一开始，就教导团队成员应该怎么写邮件以及邮件应该抄送给谁。团队成员应该在基本的指导方针上达成一致。指导方针应该始终如一地执行。需求应该在你的开发软件中明确规定（而不是在邮件中）。测试应该在测试软件中明确规定（而不是在邮件中）。这些软件通常非常稳健，能够给出非常棒的文档和跟踪记录。它向你给出展示项目状态的统计数据。邮件会从上到下麻痹团队，最好少用为妙。
• 测试软件是必需的。项目状态的测量数据来自这个软件。如果需求、活动、测试等没有在软件中展示，那么它不算必需的软件。你必须寻找能够验证完成情况的指标。软件记录了冲刺活动，记录了测试。当团队演示证明就绪标准的完成指标时，管理人员可以根据敏捷规划时间表查看相关数据。

结束语

总之，集合你的伙伴，想一个计划，用可演示的统计数据支持计划中的所有活动，每天查看统计数据来确保你遵循计划。这样，你就会收获“没有意外”。你可以清楚看到，一切都是按计划进行的，而且会在上线日期内按时完成。

关于作者

Leigh Koetter 是一位六西格玛黑带和一位注册项目经理，拥有超过 25 年的世界 500 强软件实施项目的管理经验。专注领域：项目管理、敏捷流程和方法论、质量管理、SAP 测试管理、SAP HP ALM 集成、SAP 项目管理、Workday 测试管理和自动化测试。

查看英文原文： PAL (Planned Agile Leadership) Schedule

感谢冬雨对本文的审校。