图 3. 状态墙

消除浪费

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

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

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

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

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

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

计划偏差分析与控制

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

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

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

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

量化任务的计划偏差

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

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

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

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

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

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

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

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

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

结论

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