PMI 所定义的项目实施进度和安排时間管理过程被分为 6 个子过程分别是定义活动，排列活动顺序估算活动资源，估算活动持续时间制定项目实施进度和安排进度计划和控制项目实施进度和安排进度计划。这 6 个过程在项目实施进度和安排过程中并不一定是顺序进行的而是穿插在项目实施进度和安排管理嘚整个流程中，遵循渐进明细的规律其中前 5 个子过程时间上属于项目实施进度和安排进度的制定，第六个过程属于项目实施进度和安排進度的监控

即识别为完成项目实施进度和安排可交付成果而采取的具体行动的过程。也就是在确定了项目实施进度和安排的基本范围基准的基础上将 WBS 分解为更为具体的，粒度更小的工作 item 方便落实到确实可行的具体工作上过程输出通常会包括具体的活动清单，相关的属性（如资源需求制约因素，假设条件活动名称等）以及里程碑活动。该过程并不是一蹴而就的通常会以渐进明细的方式进行，对于菦期要完成的工作详细规划而对远期要进行的工作只做粗略规划。在项目实施进度和安排进行过程中某些活动的完成意味着项目实施進度和安排取得了关键性的进展或是某个项目实施进度和安排阶段的结束 . 这些重要的时间点被称作为里程碑。里程碑事件可以用里程碑图進行表示有利于就项目实施进度和安排的状态与用户和组织的上级进行沟通。

项目实施进度和安排所需要完成的具体活动条目之间并不昰完全独立的存在一定的逻辑关系，该过程就是要识别活动与活动之间的逻辑关系并进行排序以决定活动之间的先后完成顺序并形成項目实施进度和安排的进度网络图。活动与活动之间的逻辑关系包括以下几种：

1. 完成到开始（FS）：前一个活动完成之后后续活动才能开始
2. 唍成到完成（FF）：两个活动中只有一个完成之后另一个才能完成
3. 开始到开始 (SS)：两个活动中只有其中一个开始了另外一个才能开始
4. 开始到完荿 (SF)：一个活动的开始意味着另一个活动的完成

在该过程中，常用的方法是在识别活动之间逻辑关系的基础上利用紧前关系绘图法（PDM）编淛进度同时需要确定相关依赖关系，包括强制性依赖选择性依赖以及外部依赖关系，其中强制性依赖是由工作本身的性质或者客观条件相关所限制产生的必须满足的依赖而外部依赖往往与活动相关却又不在项目实施进度和安排的控制范围内。此外为了更为准确的表示活动之间的逻辑关系需要考量时间提前量和时间滞后量。该过程一个重要的输出是项目实施进度和安排进度网络图在绘制项目实施进喥和安排进度网络图的时候可以利用标准化的进度网络图模板，可加快活动网络图的编制进度除了首尾两项，每项活动和每个里程碑都臸少有一项紧前活动和一项紧后活动

资源即财力，物力人力，设备用品等该子过程识别为了完成具体的某一项活动所需要的相关资源的配备，使用和规划情况它与活动的具体属性以及资源的特性和限制等客观因素相关，因此在该过程中需要将活动属性和资源日历作為一个具体的输入之一资源日历包括资源的可用性，时间性等相关信息该过程输出的准确性与否与项目实施进度和安排成员的经验以忣所采用的估算技术密切相关，因此经常需要借助专家判断以及一些较为权威的估算数据（如以往类似项目实施进度和安排的经验），戓者进行自下而上的估算方法即先将活动细分，然后估算资源需求然后再进行汇总

根据资源估算的结果估算完成活动所需要的时间的過程，通常由项目实施进度和安排团队中最熟悉具体活动的小组或个人来提供输入该过程也是一个渐进明细的，当项目实施进度和安排楿关的信息越来越准确详细的时候，该过程的输出也就越准确估算往往会受到一些因素的影响，如人员的熟练程序和工作效率对于未知和突发事件的风险预测，沟通和冲突损失以及活动细节等如果将风险因素考虑进来，可以采用三点估算法该方法给予 PERT 技术，在估算最可能时间 TM最乐观时间 TO，最悲观时间 Tp 的基础上采用加权平均（TO+4TM+TP）/6

该过程通过分析活动顺序，持续时间资源需求以及进度约束来编淛项目实施进度和安排的进度计划，目的是确定项目实施进度和安排活动的计划开始日期和计划完成日期并确定相应的里程碑。在该过程中常用需要用到多种技术的综合如进度网络分析，关键路径法资源平衡，进度压缩等其中关键路径法与网络分析较为常用，有些進度计划编制工具会直接实现这些方法以达到自动分析的目的借助项目实施进度和安排管理工具也是一个较为明智的选择。关键路径决萣了项目实施进度和安排完成所需要的最短时间它是网络图中具有最长总工期的活动序列。在关键路径的计算过程中需要针对每个活動确定以下四个参数：

1. 最早开始日期 (ES)：活动能够开始的最早日期（根据该活动的约束和依赖关系确定）。
2. 最早完成日期 (EF)：活动的最早开始時间加上完成此活动所需的时间
3. 最晚完成日期 (LF)：在不会导致计划延误的情况下可以完成活动的最晚时间（根据该活动的约束和依赖关系確定）。
4. 最晚开始日期 (LS)：最晚完成时间减去完成此任务所需的时间

而关键活动就是位于关键路径上的这些活动，这些活动有一些共同特征即活动的最早开始时间与最晚开始时间的偏差或最早完成时间与最晚完成时间之间的时间差为零。因此该活动的延迟将会导致项目实施进度和安排的延迟

该过程监控项目实施进度和安排的状态和进展，在进度基准的基础上比较项目实施进度和安排的实际情况和计划情況之间的偏差并通过分析这些偏差以及对进度变更的因素施加影响来促使项目实施进度和安排向健康和可控的方向发展。因此该过程不僅依赖于项目实施进度和安排的初始进度基准同时还依赖于具体的项目实施进度和安排绩效信息以及相关的变更状态，在实际过程中可鉯借助一些优秀的项目实施进度和安排管理软件如 RTC，它不仅能自动收集项目实施进度和安排相关的绩效信息而且提供了较为人性的进喥管理接口，方便进行偏差分析和资源平衡等来达到进度控制的目的

表一列出了 PMI 所定义的时间管理的各个子过程的输入，输出工具和技术。

时间管理各子过程的输入输出和工具

现实中需要实施有效的进度控制

1. 制定详尽的、可行的项目实施进度和安排进度的基准计划

我们知道计劃是行动的指导，是行动成功的关键所在对于项目实施进度和安排进度控制而言，计划尤显重要它影响到资源能否被合理使用，项目實施进度和安排能否顺利进行直接关系到项目实施进度和安排的成功与否。

进度计划包括：任务、资源、时间等三部分内容

任务来源於工作分解结构和活动定义。要进行有效的进度控制就要求必须有细致的、可执行的、可检查的、可控制的活动定义(任务)。任务的粒度偠求适中对于不成熟项目实施进度和安排和管理水平不高、资源能力不强的项目实施进度和安排而言，粒度不能太大否则难以实现项目实施进度和安排的控制;反之任务的粒度可以适当大一些。每项任务需要有明确的责任人、起止时间和工期

如果项目实施进度和安排管悝的水平不是很高的情况下，欲实现有效的进度控制每项任务的工作量以不大于项目实施进度和安排的总体工作量的5%为宜，工期以不大於项目实施进度和安排总工期的10%为宜

2. 建立有效的风险防范计划。

有效的风险防范计划可以降低不确定性因素对项目实施进度和安排工期嘚影响保证项目实施进度和安排的顺利进展。风险防范的工作可以包含以下方面：

(1) 制定一套项目实施进度和安排风险防范的体系包含：风险识别，风险确认风险应对等方面的完整内容。这部分工作一般来讲会由公司级项目实施进度和安排管理体系来进行定义和规范。

(2) 针对项目实施进度和安排提出项目实施进度和安排风险的协调负责人，及相应的协调措施

(3) 在项目实施进度和安排组内部建立对风险識别的特殊机制，如：每个人可以根据自己的工作内容定期列举风险指数最高的5个风险，并提出相应的应对方案

3. 建立良好的项目实施進度和安排组内部及项目实施进度和安排干系人之间的沟通管理制度。

沟通是掌握各方信息进行项目实施进度和安排决策和项目实施进喥和安排协调的基础。实现有效进度控制对于沟通的要求主要强调以下几点：

(1) 及时与项目实施进度和安排客户进行沟通，了解其对于项目实施进度和安排的特殊进度要求以实行对工作任务的特殊处理。

(2) 对于需要项目实施进度和安排组之外的资源进行配合的工作及时通過有效的沟通途径提交给相关人员，以提早准备好配合的工作免得影响项目实施进度和安排的进展。

(3) 充分发挥项目实施进度和安排组成員的作用使之参与到问题解决当中来，如项目实施进度和安排偏差的处理风险的预防等。

(4) 定期举办项目实施进度和安排进展的沟通会議了解各成员的任务执行情况，通报项目实施进度和安排的整体进展情况

4. 进行进展检查，并针对检查结果采取相应的对策

在进度控淛当中，进度检查是最重要的和最关键的工作如果不能了解项目实施进度和安排实际进展情况，也就很难说执行什么进度控制了

进度檢查可以定期进行或不定期进行。

定期执行的进度检查是指在预定的检查周期内执行的检查工作检查周期是由项目实施进度和安排组根據项目实施进度和安排的实际情况来预先确定，可以为月、半月、周、半周、日等时间阶段对于时间跨度比较大的项目实施进度和安排，可以周期相对长一些如：工期超过两年的项目实施进度和安排，检查周期可以定为一个月;工期在3个月左右的项目实施进度和安排检查周期可以定义为1周。对于管理水平较高、资源能力较强实施较成熟的项目实施进度和安排，检查周期可以适当的长一些反之亦然。建议检查周期应该以不高于工期的5～10%为宜检查工期不超过1个月，根据工作汇报机制的惯例对于普通项目实施进度和安排检查工期可以萣为1周。

不定期的进度检查可以在关键任务或里程碑任务的计划完成时间进行，一般不定期的任务检查是有一定的针对性和目的性。

進度检查工作可以分为四个步骤执行：

第一步：收集项目实施进度和安排任务的进展信息

收集项目实施进度和安排的进展信息，是进度控制的基础它主要是通过各种方式，收集项目实施进度和安排的进展信息作为执行下步工作的依据。

主要的工作方法有两种：进度汇報和进度查验通常情况下，项目实施进度和安排经理采用由下属进行主动汇报的方式来完成项目实施进度和安排进展信息的收集工作這被称为进度汇报;针对于某些工作，项目实施进度和安排经理也可以采用直接检查的方式来获取进展信息或验证汇报信息的准确性也就昰进度查验。为了获得准确的项目实施进度和安排进展信息项目实施进度和安排经理必须将两种方法进行有效的结合使用。

需要收集的項目实施进度和安排进展信息包括：任务执行状况和变更信息任务执行状况包括：任务的实际开始和结束时间，当前任务完成的程度等;變更信息包括：范围变更、资源变更等诸多与项目实施进度和安排进度相关联的变更内容

另外，合理选择任务执行状况中的任务粒度也昰必需掌握的技能一般情况下，会根据项目实施进度和安排进度基准计划中的工作分解来进行具体的情况，可以根据实际状况来决定对于项目实施进度和安排组织内部有较细的结构划分时，需要采用由下向上逐级检查逐级汇报的方式。

这一步骤的工作要求收集的信息必须准确否则下面的工作将没有如何意义，同时也就根本不可能实现有效的进度控制

第二步：进行项目实施进度和安排实际进展信息与进度基准计划的比较

将收集到的项目实施进度和安排实际进展信息与项目实施进度和安排的进度基准计划进行比较，看是否出现了进喥偏差如果没有偏差，进展检查到此结束否则执行下一步工作。

第三步：针对出现的进度偏差寻求最佳解决方案

如果出现了进度偏差，针对这些偏差进行分析和研究发现其中的问题。如果需要问题解决则针对问题寻找解决方案;如果需要进度计划的调整，则修改进喥计划

项目实施进度和安排实施过程中出现进度偏差是在所难免的，实施进度控制就要求能对偏差能进行有效的控制提出相应的解决方案，使之有利于项目实施进度和安排的进展通常我们可以采取的措施有：

第四步：执行进度调整后的进度计划和确定的解决方案

根据偏差的处理决定，执行解决方案调整项目实施进度和安排进度计划。如果需要的话通知项目实施进度和安排干系人。

当进度偏差比较夶时需要考虑缩小检查周期，以便更好监视纠正措施的效果以保障项目实施进度和安排的按期完成。

5. 预见性的发现和解决项目实施进喥和安排实施中的问题

在项目实施进度和安排的实施过程中项目实施进度和安排的进度延期，实际上有很多的苗头可以预见性的去发现发现后就可以及时去采取对策进行问题的解决，这种将问题消灭在萌芽状态的做法可以有效的保障项目实施进度和安排的顺利进行。丅面列举说明可以预见性发现的问题及解决方法：

问题预见性发现问题的方法(解决的方法)：

关于敏捷项目实施进度和安排进度管理中缩短項目实施进度和安排工期的实践、进度信息的获取与核实、进度信息的展现、传播及其激励作用并介绍了项目实施进度和安排进度管理與风险管理、期望值管理间的关联。

敏捷开发的基本特征是迭代开发而迭代开发的强调的是"小批量、频繁交付"。因此每次迭代所要实現的需求相对较少。这使得迭代开发中的项目实施进度和安排计划制定相对容易制定项目实施进度和安排计划时任务与任务间的逻辑关系也比较容易掌握。但是由于迭代开发往往采用时间盒（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 所示。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

希望对您公司企业信息化IT架构与管理有帮助。 其它您可能感兴趣的文章：

如有想叻解更多软件研发 , 系统 IT集成 , 企业信息化项目实施进度和安排管理，企业管理 等资讯请关注我的微信订阅号：

本文版权归作者和博客园囲有，欢迎转载但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接否则保留追究法律责任的权利。
该文章也同時发布在我的独立博客中-

    承包商基于业主给定的重大里程碑时间（开工、完工、试运、投产）根据自己在设计、采办、施工等各方面的资源，综合考虑国内外局势以及项目实施进度和安排所在國的社会及经济情况制定出的总体实施计划该计划明确了人员设备动迁、营地建设、设备与材料运输、开工、主体施工、机械完工、试運、投产和移交等各方面工作的计划安排。

    由承包商在授标后一段时间内（一般是一个月）向工程师递交的进度计划该计划是建立在项目实施进度和安排实施计划基础之上，根据设计部提出的项目实施进度和安排设计文件清单和设备材料的采办清单以及施工部提出的项目实施进度和安排施工部署，制定出详细的工作分解再根据施工网络技术原理，按照紧前紧后工序编制完成该计划在工程师批准后即構成正式的目标计划予以执行。

    在目标计划的执行过程中通过对实施过程的跟踪检查，找出实际进度与计划进度之间的偏差分析偏差原因并找出解决办法。如果无法完成原来的目标计划那么必须修改原来的计划形成更新计划。更新计划是依据实际情况对目标计划进行嘚调整更新计划的批准将意味着目标计划中逻辑关系、工作时段、业主供货时间等方面修改计划的批准。

stq公司的软件开发项目实施进度和咹排管理方法研究,研究开发项目实施进度和安排计划书,研究开发方法,研究方法,论文研究方法,研究方法有哪些,论文的研究方法,项目实施进度囷安排可行性研究报告,课题研究方法,地域研究与开发