与自己定制开发相比,你可能会选择购买一款适合你的业务的软件。这似乎是一种更好的方案,因为它不仅满足了你的业务需求,还不需要自己定制代码。简直太完美了。通常,你会根据自己的业务需求,确定一个最佳的软件实施日期。举个例子,如果你是做糖果的,你不会在情人节前或者复活节周末前实施这款软件,(毕竟你需要在重要的业务活动期间保证业务的稳定)。
软件供应商会根据你的公司情况以及类似公司的软件实施经验,预估软件的实施期限。这时,你可能还不清楚,实施这款软件都需要什么以及哪些是必不可少的。你的预期是,这款软件会百分百适合你的业务并且非常容易部署。而且,这款软件必须一次性部署完毕,而不能一点一点地部署。你也许还能够预先进行一些数据转换,但是重要的新功能必须在一个时间点部署完毕,并且部署时间不能超过几周。
高层管理人员通常非常期望通过实施新软件,来利用更好的新功能。他们分析业务需求,从而推算出“上线”的最佳时间,然后将这个日期告诉主题专家和IT部门。但是,通常这些专家在经过简短的调查之后会回复高层管理人员,这个日期是不可能的。
这些人才更专业,知道必须要做什么。他们是专家,你不能忽视他们的话。这时,高层管理人员问,“那么,到底都应该做些什么?”专家们然后会尽力用一种简单明了的方式,在一个比较高的层次解释如何实施这个软件。高层管理人员对于细节不感兴趣,他们需要有一个高层次的理解,即有哪些主要项目活动、每项活动要花费多少时间、谁来做这项活动。
团队通常面临三大挑战:
敏捷规划时间表(PAL Schedule,即Planned Agile Leadership Schedule)可以用每个人都能够理解的方式,清晰地展示高层次的工作分组。请注意下面的插图:
在创建敏捷规划时间表的过程中,团队会面临一个挑战。你们已经非常艰难地转向了敏捷流程,但是软件包的部署通常是一个瀑布模型。瀑布模型和敏捷模型有点像油和水的关系,互不相容。你怎样来调和这两种流程模型呢?你想要保持敏捷流程,但是你又有一个指定的上线截止日期。
软件实施团队由负责评估现有功能和新功能的主题专家、负责基础设施的IT专家以及某些业务属性所需的各种专家。这些专家必须开会决定必须做什么来实施新的软件。将必须做的大型活动分派给每个小组,制定绝对能够完成这些活动的最短时间范围。不要担心具体的计划,保持高级别的角度。将这些安排到一个基于高层管理人员指定日期的时间线上。如果你不熟悉IT软件实施,供应商可以帮助识别需要考虑的高级组件。
和高层管理人员沟通,告诉他们,只有在满足时间表的情况下才能在规划的日期达成目标。如果你错过了第一个迈向下一个大领域的关卡,你就会很快清楚为什么那个日期是不可行的。
让我们具体说下敏捷规划时间表是什么以及不是什么。
它不是:
首先它不是一个MS Project计划表。它很简洁!它不会给出所有的任务,只会给出主要的团队活动。各个团队应该根据计划通过像Jira之类的工具确定任务来完成分组。每个阶段都各自定义了一些需要完成的任务。对于测试团队来说,测试阶段定义了需要执行的测试任务,这些任务需要在那段时期内完成。这些应该记录在Jira、Jama或者HP ALM之类的工具中。
所有任务都在一个工具内定义。这就是敏捷。
截止时间
时间表不应该是一个死亡竞速。令人非常吃惊的是,有那么多明知不可能完成的或者至少对于当前团队来说非常难以完成的时间表。时间表的目的是切合实际地预估,什么人在什么时候应该围绕项目完成什么任务。时间表的预估应该基于最合理的团队猜测。
它是: 所需项目进度的一种可视化展示
敏捷和六西格玛方法论最基本的元素之一是,可视化展示对于团队来说可能是最好的指引。这就是所谓的敏捷规划时间表——一个关于整个实施过程(从头到尾)应该做什么的可视化展示。这个时间表如此有用的原因是,它保持了主项目活动与什么时候必须完成之间的强关联。完成情况直接链接到在敏捷项目工具中用文档跟踪记录的活动。除了在选中的工具中跟踪单独的活动之外,活动分组也在时间表中进行跟踪。团队用颜色标记,使得每个团队成员负责的计划内容可以很快识别出来。为了达成这个时间表,团队必须准备好下一个迭代和增量阶段。每个阶段都关联到对应的标准,这些标准必须由工具生成的可测量和识别的统计数据所支持。如果统计数据不支持进入下一个阶段,高级管理人员和整个团队会立刻知道这个时间表可能有风险。这使得执行力比通常快得多。可以立即采取补救措施,要么转移计划,要么采取行动让计划回到正轨。
与各个团队一起创建这个计划的人员应该努力让这个时间表易于阅读和理解。这就需要只将需要知道的信息放在时间线上。在项目的各个时间点,当需要的时候,再将更详细的计划信息发布到团队中,在那之前团队不需要考虑这些详细的信息。
任务时间
所有权:时间表由整个团队负责。
这是敏捷方法论的一个基本原则。所有团队成员都全力以赴,坚持在时间表期限内完成工作。团队自发支持和实现计划目标。最好组织一个正式的会议,来使团队接受规划的时间表。如果任何一个团队认为这个时间表不合实际,这些担心应该被着重处理。如果团队决定带着问题继续原有的时间表,那么在每个分组的具体就绪标准中包括含有疑问的标准会是一个不错的主意。这使得管理层和团队能够在标准没有实现的特定时刻评估这些顾虑,从而作出必要的补救措施。
敏捷流程是由各个具体的交付阶段组成的。这些具体的冲刺阶段会映射在时间表上。各个冲刺阶段所要完成的任务都是清楚透明的。
不像普通的冲刺跟踪那样,敏捷规划时间表使得团队可以持续了解项目当前时期的计划安排。这使得团队不仅能够持续了解当前冲刺阶段的状态,也能够持续了解整个项目的状态。
秘方:计划是基于可量化的频繁交付的。
其中的秘方是,敏捷规划时间表与可量化的频繁交付密切相关。所有的冲刺阶段和测试阶段都罗列在内。你的冲刺阶段和测试阶段都有具体的交付产品,至少包括当前阶段的所有组件以及相关缺陷时期的所有测试。在表中,这些时期用红色圆圈圈起来。这些都是在这个比较短的时间段内必须完成的工作。
注意需要完成的具体工作。在时间表中不会定义每个详细的组件,而是会给出一个非常高层次的分组描述。例如,在列出的第一个时期内,团队集中验证与客户、任务、管理、会计、邮件相关的功能以及相关缺陷。通过给出这种高层次的描述,整个团队就可以知道需要聚焦的领域。他们还能够识别出现在哪些应该做并且能够做,而哪些必须等到下个迭代再做。如果有哪些方面没有完成,这些都会记录成文档,从而让团队会知道他们必须回过头去完成所需的功能。通过标示这种分组,团队还能够保证所有领域都被完成了。这些都是主要领域,通过识别其中每一个领域,团队可以放心地预期在安排的时间内完成计划。最后一个好处是,这些领域不会被遗漏。所有团队成员都可以审核列出的内容。令人吃惊的是,有时标准领域或者标准领域的组件会在时间表的第一份草案中被忽略。
这些交付在预定时间内要么完成了,要么没有完成。通过跟踪这些交付,团队和高级管理人员就会知道时间表达成了没有。应该每天公布这些统计数据。在每个时期的尾声,应该对这些统计数据进行评估。万一交付总是延期或者未完成,团队就可以很早知道项目偏离了预期。
只有所有成员一起往前努力,项目才会往前推进。这是对团队活动和团队协作的一种聚焦。如果其中一个团队没有按时交付给他们指定的交付物,整个项目都会被向后推迟。这种情况的一个例子是IT团队搭建测试系统。如果测试系统没有按时准确地搭建,后续的测试阶段就没法启动。如果集成的IT结构不到位而且不具有操作性,相关的测试也无法进行。如果开发阶段的交付物没有完成,相关的测试就会被延迟。
如果来自遗留系统的数据没有针对测试进行转化,整个项目会被延期。在下图中,你可以看到,如果数据没有转化,Core Billing Validation(核心对账功能)就无法启动。
频繁的里程碑
上图中的计划展示了频繁的里程碑。这些里程碑都是时间表上具体的交汇点。里程碑代表了相关标准的关卡。如果这些标准没有实现,其中的差异必须修复解决。这些标准由使用的工具生成的统计数据所支持。因此,里程碑对应的标准是否完成是可以测试和验证的。与冲刺及测试阶段交付的唯一区别是,里程碑交付是一种更高更复杂级别的表示。
通常,团队基于里程碑来决定项目是否能够进入下一个阶段。下面是里程碑“上线就绪”的一个例子
所有上述就绪标准都应该由可展示的统计数据支持。
敏捷规划时间表的沟通安排很充分。团队所需知道的关于如何向前推进的一切事情都应该包括在内。
团队通常由遍布全球的各种各样的人组成。对所有人员来说,敏捷规划时间表是一个非常有价值的工具。每一个团队成员和高级管理人员都可以通过它来理解和支持计划安排。
我工作过的项目中,敏捷规划时间表都成为了整个团队都认可的很有价值的工具,还从没有过例外。
让敏捷规划时间表保持充分沟通和敏捷精炼。
有时,具体的沟通应该公布出来,从而让团队明确知道将会在什么时候发生什么事情。注意截图中开始的部分,在集成测试、并行测试和终端用户验收测试之前,都有一个星星。这三组活动都是各种团队完成的。大部分项目都需要整个团队齐心协力。IT部门负责构建系统并集成;核心主题专家负责验证功能;最终用户(通常刚刚接触这个项目)负责以他们的角度来验证功能。大部分参与人员都需要提前充分了解这项活动的时间安排。
团队协作
这些最终用户通常必须整个工作日都投入这项验证。有时,由于业务需求与项目规划冲突,时间表还需要额外的资源或者重新规划。通过这个可视化的展示,核心团队能够确保沟通足够广泛和深入,从而避免发生意料之外的事件。
注意下面的截图。其中你可以看到项目活动的负责人从一个团队变更为另一个团队,这时应该向团队公布一个详细的时间表。在详细的时间表中,你可以看到所有权转移的准确时间和日期。这对于团队非常苛刻并且需要坚决遵守。你只需要适时将它发送出去,而不需要现在就操心这个级别的细节,除非你达到了这个时间点。最终的详细时间表在发送之前,需要得到团队的同意。大多数时候,这个时间表是经过高度协商的。每个团队都仔细确保他们能够实现其中的计划。Resource(资源)栏罗列的人,负责向团队确认具体计划已经开始。团队还应该知道成员都有哪些人以及谁有权力在流程中改变这些安排。因为这是一个非常严谨的沟通,因此一旦最终公布,我很少看到偏差。通常,团队都为计划做好了准备,因此偏差会给针对这个时期已经计划好的活动造成巨大的破坏。因此,即使有些活动稍微提前完成了,后续的活动也不会马上跟进。
注意,这个时间表没有提供其中的具体工作。这又是一种精炼方案。不要给所需之外的信息。应该由各个团队详细制定各自必须完成的工作,从而支持敏捷规划。因为它对这些人员是如此严苛,因此通常可以放心地认为这些详细的工作已经被仔细地审核过了。没有哪个团队想要因为没有完成时间表而变得尴尬。在针对具体活动的准备会议中,团队可以解释他们打算做些什么来实现这个时间表。
所有权传递
敏捷规划时间表的英文名字是PAL Schedule,即Plan Agile Leadership Schedule。如何创建这种时间表,以下活动可以说是最简单的解释:
将所有精英团队都映射到敏捷规划时间表上。
每个团队控制他们各自的流程(冲刺、项目计划、任务活动、测试等等)。充分明确团队的集成时间点,并将时间安排公布给所有的团队成员。时间安排要精确到天和小时。每个人都拥有活动完成的发布权和任务归属的转移权。
关于“明确主要领域”的更多信息
你的项目经理如果经验丰富,通常在一点点帮助下就能够画出敏捷规划时间表的初稿。然后主题专家主管可以补充所需的工作和时间。IT团队则负责补充IT领域。
在完成第一份草稿的基础上,团队可以和高级管理人员开会讨论这个时间表并决定其中的日期是否合理。
敏捷规划时间表是增量迭代的。时间表的每个阶段都是基于前一个阶段构建的。每个过程领域指定的任务都更加困难。
总之,集合你的伙伴,想一个计划,用可演示的统计数据支持计划中的所有活动,每天查看统计数据来确保你遵循计划。这样,你就会收获“没有意外”。你可以清楚看到,一切都是按计划进行的,而且会在上线日期内按时完成。