优化项目计划

敏捷开发的基本特征是迭代开发。而迭代开发的强调的是"小批量、频繁交付"。因此，每次迭代所要实现的需求相对较少。这使得迭代开发中的项目计划制定相对容易，制定项目计划时任务与任务间的逻辑关系也比较容易掌握。但是，由于迭代开发往往采用时间盒（Time-box）的方式进行，即要求每次迭代的时间是固定的（业界推荐的是 2~4 周）。而每次迭代所要实现的需求（Story）的个数及其难度都不尽相同。这就要求我们在某些情况下要尽可能地优化项目计划，以保证工期不会超出时间盒的范围。

优化项目计划的常见方法是尽可能地使各个任务并行。比如，有两个功能的开发任务，其中一个功能 A 依赖于另外一个功能 B。但这并不意味着我们必须将这两个功能的开发任务串行安排（即先开发 B 功能，再开发 A 功能）。此时，可以使用测试桩（Testing Stub）来模拟 B 功能的实现，这样使得 A 功能的开发和测试可以先独立于 B 功能的实现。因此这两个功能的开发可以并行。

计划安排时考虑避免重复劳作也是缩短工期的一个常见方法。在 Story 驱动的一个迭代开发过程中，从第二个迭代开始，往往存在多个 Story 的实现涉及同一个模块的代码修改。此时，计划可以安排多个人并行开发这几个 Story、但是转 Story 测试时，这几个 Story 可以合并成一个"大 Story"一起转测试。从而避免了多次测试同一个模块带来的浪费。

出于应对风险的需要在安排计划时留出所谓的缓冲时间有其合理性。但是，这个缓冲时间延长了任务的持续时间。而关键任务持续时间的延长则延长了整个迭代持续的时间。值得注意的帕金森定律（Parkinson's Law）所阐述的现象却给了我们在某些情况下要适当压缩任务尤其是关键任务的持续时间。帕金森定律告诉我们：只要还有可用的时间，一件工作消耗的时间就会不断地扩展，直到用完所有的可用的时间。也就是说，一件任务如果需要 3 天时间完成，而计划安排的持续时间是 5 天的话，这个任务会消耗 5 天甚至更多的时间才能完成。这种现象的方面给了我们一个启示：如果一件任务如果需要 3 天时间完成，而计划安排的持续时间是 2 天，那么这件任务真的可能在 2 天内完成，最多也可能是 4 天时间完成。这也比将该任务计划为 5 天完成节省时间。可见，过于宽松的机会反而可能拖慢了进度，而有一定紧迫感的计划所带来的适当压力可以激发人的动力和潜能反而可以加快进度。

对于迭代中的技术风险点要优先安排进行验证。比如，对于从未使用过的技术或者新技术，要优先安排原型的验证，避免中途才发现技术障碍。

进度信息的获取

由于团队开发中的每个团队成员的日常工作之间都存在或多或少的依赖关系：某个人的工作要以其他人的一件工作产出为输入，同时其工作的输出又是另一个人的某件工作的输入。

从团队自我管理的角度来说，进度信息是将团队成员的工作自主得衔接起来的重要因素。因此，敏捷开发团队中，进度不应该是只有项目经理才关心的事情，而是整个团队成员都应该关心的事情。但事实上，团队成员往往倾向于只关心自己手头上的工作。因此，项目经理需要引导和鼓励团队成员主动关注自己手头上的任务所依赖的任务的进度。

另一方面，进度是整个团队应该关心的事情，这就要求在团队内有一个统一的进度信息获取与发布的平台和途径。这个平台可以是一个管理软件，比如工作流软件。也可以是一个即时通讯软件。不管采用什么样的平台，项目经理应该引导和鼓励团队成员主动将各自的进度信息推送到这个平台，而不是每个人进度还要等其他人来询问。

站立会议也是进度信息的发布和获取的一个常见途径。站立会议中，每个团队成员都要介绍自己昨天完成了什么，今天计划做什么。这样，每个人的进度信息都可以让其他人了解到。

定义完成的标准和进度信息的核实

获取进度信息后，要及时对其进行核实。敏捷开发中的优秀实践"定义完成的标准"（Definition of Done）可以帮助我们对进度信息进行核实。

下面我们讨论什么是完成的标准、定义完成的标准的作用以及如何定义完成的标准。

曾经有个刚刚开始带领团队的人向我咨询这样一个问题：他向他的组员分配一个任务，然后他不定期得检查这个任务的进度。可是每次他检查进度的时候，他的结论都是这个组员的工作成果没有达到他所期望的，而这个组员却是认为自己已经完成了当天的任务。这种情形导致这种组员不断得为返工而加班，最后导致其身心俱疲，提出离职申请。事实上，这样一个问题产生是因为任务的分配者和执行者事先没有约定好什么叫做"完成"。双方都只是在依照自己心中的"标准"来判断是否完成，从而导致了对于进度认定的冲突。

可见，在我们断定一个任务是否完成、进行到什么情况前，首先要规定什么叫"完成"，否则就会在衡量进度的时候产生上述例子中的冲突。这种对于什么才叫做完成的规定就叫做完成的标准。显然，进度不能在脱离质量的前提下孤立得衡量，因此完成的标准不仅定义了质量要求（通常是最低质量标准），也是进度衡量的重要依据。

比如，如果你让一个没有什么工作经验的人去安装一个数据库管理系统（DBMS），他很可能就是把安装程序执行一遍，若执行过程中没有遇到安装程序提示错误就认为是完成了软件的安装。而最后，其他人都不知道这个已经安装"完成"的软件的访问信息，比如它所在机器的 IP 地址、侦听端口。甚至知道了这些信息后，在实际使用时却发现所安装的软件根本就无法正常运作。

其实，对于这样一个任务我们可以定义一个完成标准：所安装的 DBMS 要经过验证（比如使用 SQL 能够在数据库中插入一条记录，并能够使用相应 SQL 查询到插入的记录），并输出软件的相关使用信息（如软件所在机器的 IP 地址、软件的侦听端口）。

可见，完成的标准不仅定义了质量要求（通常是一个最低质量要求），也定义了任务所要交付的产出物。完成的标准所定义的产出物和质量要求正是评估任务进度的依据。一个任务在整个团队中有了一个大家一致认同的完成标准时，任务完成的质量和进度的衡量才不会出现冲突。

进度风险控制

进度管理中很重要的一个方面是进度风险控制。

提高进度信息的获取频率可以尽可能早得发现进度障碍，为消除障碍争取了最大时间，从而有效减低进度风险。由于敏捷开发中的一个迭代周期持续的时间较之传统项目要短得多，进度信息的获取频率也要相应有所体现。笔者通常每天对项目进度信息进行汇总。

任务采用认领的方式而非采用分配的方式落实到人，也有助于规避人力风险导致的进度风险。

比如，在需求评审与分析的时候，笔者并不指定谁负责哪个 Story，而是要求全体成员对本次迭代的所有需求都要有所理解，并能够讲解自己对本次迭代中的任意一个需求的理解。敏捷开发采用迭代的方式，每次迭代所要实现的需求量同传统项目比较要少得多，这使得每个团队成员对本次迭代的所有需求都进行理解成为可能。在确认每个团队成员对本次迭代所要实现的所有需求都有所理解之后，笔者才让团队成员对相应需求的开发测试任务进行认领，具体落实到人。采用这种任务认领的方式，使得每个团队成员对本次迭代的所有需求都有所理解。从而，在人力变更（如原先负责某个需求的开发人员请假了）时，可以快速得找到能够承接任务的人。进而规避了进度风险。从一开始就将需求落实到相应的开发测试人员，很容易就造成团队成员只关注自己手头上的"一亩三分田"，从而使得对于需求的理解没有备份人力，一旦人力变更则很容易影响项目进度。

笔者在项目组中强调一个个人规避进度风险的原则。该原则要求团队成员在遇到问题时，通过个人的努力消耗了 30 分钟而仍然未能将问题解决时，要及时寻求帮助，而不是继续在问题上打转，甚至于走进问题的死胡同。当然，团队成员在遇到自己无法解决的问题时，可能会觉得不好意思让被人知道，而项目经理要消除他们的这种顾虑。尤其是一些工作经验不长的员工，由于个人经验、能力等方面的限制，在遇到问题时候，往往容易只是一门心思地想着要解决问题，而完全没有顾及到时间。这往往使得他们对于问题的解决就像是走进了一条死胡同，心里明明想要走出去，可是越是往前走，就越是走不出去，而时间却悄然而逝！

进度信息的展示、传播及其激励作用

Scrum 中提倡的采用燃尽图（Burn-down Chart）来直观得展现项目总体进度。它展示了时间和项目剩余总体工作量间的关系，如图 1 所示。

图 1. 燃尽图

笔者认为，燃尽图更多得是给人以一种压迫感－－－让人清晰直观得感受到随着时间的推移，项目所剩的工作量逐天减少！因此，燃尽图也受到了一定的批判。

而燃起图（Burn-up Chart）则直观地展现了时间与已完成的工作间的关系，如图 2 所示。

图 2. 燃起图

传统项目由于项目周期较长，团队成员往往在漫长的开发过程中看不到自己的工作成果，慢慢得失去工作的热情。因此，让团队成员看见其工作成果，对其来说也是一种激励。敏捷开发由于采用迭代的方式，一定程度上能够让员工更快得看到自己的劳动成果。而燃起图则更加有助于展示团队的工作成果。因为它将团队成员的工作成果直观得展现出来。因此，某种程度上燃起图不仅仅展示了项目进度，也是对团队成员的一种激励形式。

状态墙则直观得展示了每个任务的进度。许多推行敏捷项目管理的团队，都采用这种方式来管理进度。如图 3 所示

图 3. 状态墙

消除浪费

时间是软件开发过程中最为稀缺并不可替代的资源。其浪费将直接影响项目的进度。而软件开发过程中存在各种各样的浪费。因此，消除浪费是加快进度的一种重要途径。

返工则是软件开发过程中常见的一种浪费。避免返工不仅有利于加快进度，同时也能够提升软件的质量。敏捷开发中的一些优秀实践，如"定义完成的标准"、"结对编程"、"测试驱动开发"（TDD）等都有助于避免返工

定义完成的标准"通过定义质量要求和产出物避免返工。"结对编程"通过及时的 code review 避免缺陷在后期才被发现而造成返工。"测试驱动开发"则是通过明确需求，避免因需求理解错误引入缺陷而造成的返工。

过度设计也是一种常见的浪费。所谓"过度设计"，指在设计阶段为未来可能发生的变化做过多的预测，并针对这些预测在设计上做过多预防。正如俗话所说"计划不如变化快"，过早地为这些可能根本就不会出现的变化做处理成了一种浪费。因此，敏捷开发中提倡的是"简单设计"（Simple Design）。所谓简单设计并不是没有设计，而是采用尽可能简单的设计方案。事实上，真正能够以"不变应万变"的设计方案是不存在的。如果它存在，它必然是一种简单的方案，因为其简单，它可以被轻易得推倒重来，这才是适应"万变"的方法。

迭代速率（Velocity）与期望值管理

迭代速率反映了一个团队在固定的时间（一个迭代周期）内所能交付的 Story 个数。它反映了团队的生产能力。前文我们讨论的是如何从进度的角度提升这个生产能力――加快以及如何保证迭代进度。另外值得注意的是，有时候我们有必要适当得放慢进度，进而"减低"团队生产力。所谓"得寸进尺"，这反映了项目管理中很重要的一面――期望值管理。"得寸进尺"式的期望值提升告诉我们当团队生产能力越大，组织上层和客户对团队的期望值也就越大。但是，作为团队的管理者要适当控制他们的期望值的提升，因为团队的生产能力应该有它的上限，而期望值的提升取可能远比团队的生产力的提升要来得快，但这无论对于组织和客户还是团队来说都不是好事。因此，在进度管理中使得控制迭代进度，不要使其让人感觉过快，也是进度管理中很重要的一方面。

计划偏差分析与控制

布鲁克斯法则 ( Brook's Law ) 告诉我们往一个已经滞后的项目增加人力会使这个项目更加滞后。不幸的是，当一个项目滞后的时候，往往管理层首先想到的是增加人力，因为这样他们会安心些。值得注意的是，此时增加的人是否反而使项目更加滞后，某种程度上说取决于我们如何使用新增的人力。虽然新增的人力由于对本项目并不熟悉、而本项目原有人力也不可能抽出时间给这些"新人"培训。但是，我们却可以以扬长避短的方式去发挥新增人力的作用――把一些不需要项目背景知识的工作交由这些人做，从而使原有的开发人员能够集中精力做他们最值得做的事情。比如，可以把开发过程需要使用的与项目背景没有直接联系的函数交给"新人"开发。也可以将一些非项目开发相关的而平时大家又不得不做的一些例行任务（即通常所谓"项目干扰"）交由这些人做。

从长期的角度看，对计划偏差进行分析和控制要求我们做以下几件事情：

精确记录任务消耗的实际时间

爱因斯坦曾经幽默地解释什么是相对论：坐在美女旁边一小时就像是一分钟，坐在火炉旁一分钟则像一小时。可见，人对时间的感知在缺乏时间衡量的情况下是多么不可靠。所以，要计算计划偏差（通常是偏慢了），必须要有精确的实际消耗时间。一些软件比如 JIRA 可以帮助我们轻松得记录每个任务的实际消耗时间。

量化任务的计划偏差

度量计划偏差通常有持续时间偏差和进度偏差，其计算公式如下：

持续时间偏差 (%) =(( 实际持续时间 - 计划持续时间 )/ 计划持续时间 )*100［持续时间不包含非工作日］

进度偏差 (%)=(( 实际结束时间 - 计划结束时间 )/ 计划持续时间 )*100

持续时间偏差反映了任务实际消耗工作时间与任务计划持续工作时间的偏移程度，而进度偏差则反映了任务实际结束时间与计划结束时间的偏移程度。对于项目中的关键任务，进度偏差反映了项目总体进度的偏差。

将任务的计划偏差进行量化可以让人清晰、准确认识到偏差的程度。通常，笔者会让导致计划偏差的人员自己去计算这两个指标的值，而不是由"专职人员"来计算。因为只有让问题的引入者自己清晰得地意识到问题，这个问题才能从根本上解决。

对计划偏差进行根因分析（Root Cause Analysis）

有了计划偏差度量值后，固然要对这些度量值进行根因分析，以便找到规避和改进的措施。

但是，这些规避和改进措施，通过由专人（比如，项目经理自己）给出然后交由开发、测试人员去执行其效果不见得落实到位，因为这些措施对于其执行者来说，它们都是"别人"的，不是执行者"自己"的东西。

笔者则将根因分析的方法教给团队成员，然后由团队成员自行对偏差进行分析，并给出他们自己的规避和改进措施。笔者在组织全体成员对这些分析和改进措施进行讨论，然后帮助团队成员跟踪和落实这些改进措施。

结论

本文分享了缩短项目工期的实践以及进度信息的获取、展现与核实。并讨论项目进度管理与项目风险管理以及期望值管理间的关联。