软件流程和管理（五）：Project Scheduling

目录

1. The role of a project schedule 项目进度表的作用

1.1 Project Schedule 的定义

1.2 Project Schedule 的内容

1.3 Project Schedule with Formal and Agile

2. How to develop a project schedule  如何制定项目进度表

2.1 Work Breakdown Structure 工作分解结构 – Step 1

2.2 Identify the interdependencies between the broken down tasks and develop a task network 确定分解的任务之间的相互依赖关系，并开发一个任务网络 – Step 2

2.2.1 识别任务的依赖性

2.2.2 任务依赖类型

2.2.3 Task Network

2.3 Estimate the effort and the time allocation for each task 估计每项任务的工作量和时间分配 – Step 3

2.3.1 Effort-time Estimation  工作时间的估计

2.3.2 Time Estimation  时间估计

2.4 Allocate resources for tasks and validate effort 为任务分配资源并验证努力程度 – Step 4

2.4.1 Resource Allocation 资源分配

2.5 Develop a project schedule 制定一个项目时间表 – Step 5

2.5.1 Project Schedule

2.5.2 Project Scheduling - Definitions 

2.5.3 Milestones vs Deliverables

2.5.4 Gantt Chart 甘特图

2.5.5 PERT Chart

2.5.6 关键路径方法

2.5.7 工具

3. How to use a project schedule to monitor and track project progress 如何使用项目进度表来监测和跟踪项目进度

3.1 项目跟踪和控制

3.2 Earned Value Analysis 挣值分析（EVA）

3.3 计算挣值分析

4. Agile planning principles 敏捷计划原则

4.1 敏捷开发中的规划

4.2 Scrum中的计划

4.3 Release Planning 发布计划

4.3.1 Fixed-Date Release Planning 固定日期的发布计划

4.3.2 Fixed-Scope Release Planning 固定范围的发布计划

---

1. The role of a project schedule 项目进度表的作用

1.1 Project Schedule 的定义

• 在项目规划阶段产生的重要 artefacts 工件之一
• 在整个项目中使用和维护，以 monitor 监测和 track 跟踪项目进展 —— 是一个活的文件

1.2 Project Schedule 的内容

1. 每项任务的 Duration 持续时间和 dependencies 依赖性
2. 每项任务所需的 People 人员和 physical resources 物质资源
3. Milestones 里程碑和 deliverables 可交付成果
4. Project Timeline 项目时间表

1.3 Project Schedule with Formal and Agile

Project Schedule with Formal SDLC Processes

Project planning 和 scheduling 适用于 Formal SDLC Processes —— Plan Driven 计划驱动

如下图左边所示，对于 Formal SDLC Processes，范围/需求作为约束条件决定了项目的成本和时间，即项目最初的计划创造了成本和时间表的估算，整个项目是计划驱动的。

Project Schedule with Agile SDLC Processes

Agile SDLC Processes 不使用 project schedule —— Value/Vision Driven 价值/愿景驱动

如下图右边所示，对于 Agile SDLC Processes，成本和时间作为约束条件决定了产品的最终范围/功能，即项目愿景创造了功能估算，整个项目是价值/愿景驱动的。

有趣的是，据传闻，使用 Agile 实践的组织也将 project schedules 项目时间表用于预算、合同和报告目的。

2. How to develop a project schedule  如何制定项目进度表

Developing Project Schedule – Steps

• 将任务分解成你能处理的小块——工作分解结构 Work Breakdown Structure (WBS)。
• 确定分解的任务之间的 interdependencies 相互依赖关系，并开发一个 task network 任务网络。
• 估计每项任务的 effort 工作量和 time allocation 时间分配。
• 为任务 Allocate resources 分配资源并验证努力程度。
• 制定 project schedule 项目时间表。

2.1 Work Breakdown Structure 工作分解结构 – Step 1

Planning 规划和 executing 执行大型任务是一项挑战：

• Estimating the time and resources 估算时间和资源
• Identifying interim goals and deliverable 确定中期目标和可交付成果
• Progress monitoring 进展监测

解决方案是将任务分解为可管理的单元：

• 每个任务都应该有一个具体的结果或可交付的成果
• 形成一个工作分解结构（WBS）

Work Breakdown Structure – Examples

Non-software project

Software Project

2.2 Identify the interdependencies between the broken down tasks and develop a task network 确定分解的任务之间的相互依赖关系，并开发一个任务网络 – Step 2

2.2.1 识别任务的依赖性

任务可以分为：

• Unconstrained 不受限制：任务可以在任何时候开始（拆除可拆卸的装饰物）
• Constrained 受限：取决于另一个任务（在拆除装饰物之前不能拆除墙纸）
  • 如果 task B depends on task A（A->B）
  • B是一个 Successor task 后继任务 —— Successor task (S)
  • A是一个 Predecessor task 前置任务 —— Predecessor task (P)
  • 移除可拆卸的装饰物 Predecessor task（P）->移除墙纸 Successor task （S）

依赖性是由以下原因造成的：

• 一项任务需要另一项任务的工作成果
• 一项任务需要另一项任务使用的资源

2.2.2 任务依赖类型

Finish to Start

Finish to Start 是四个任务依赖类型中最简单和最常见的。The Finish to Start dependency states that – the predecessor task must be finished before a successor task can be started. Finish to Start 的依赖关系指出——前置任务必须在后继任务开始之前完成。换句话说，一个任务必须在另一个任务开始之前完成。

Finish to Start example

想象一下你负责建造一栋新楼。在这种情况下，从完成到开始的依赖关系可以是这样的任务——“获得建筑许可”和“打地基”之间的关系。在开始为你的新建筑打地基之前，你必须获得所有的建筑许可。或者换句话说，在开始另一个任务之前，你必须先完成一个任务。

Finish to Finish

Finish to Finish 任务的依赖关系要复杂一些。It states that the successor task cannot be finished before the predecessor task is finished. 它指出，在前置任务完成之前，后继任务不能完成。这通常适用于同时进行的任务，但其中一个任务不能在另一个任务完成之前真正完成。与前面的任务关系相反，这个和下面两个依赖关系的使用有时会在项目管理专业人士之间产生争论。提出了这种关系是否有必要的问题。

Finish to Finish example

回到我们的建筑物的例子，这一次考虑在内部工作。在这个阶段，许多事情都在同时发生，例如 "铺设干墙 "和 "安装电器"。这两项工作将同时进行，然而，在所有的干墙完成之前，电气安装不能完成，这就形成了一个从完成到完成的依赖关系。

Start to Start

这第三种类型的任务依赖性与前一种相似。Start to Start states thatthe successor task cannot be started before the predecessor task has been started. Start to Start 是指在前置任务启动之前，不能启动后继任务。同样，这通常与同时进行的任务有关，但重要的是，在另一个任务开始之前，先启动一个任务。

Start to Start example

在我们的建筑例子中，让我们说现在是“粉刷外部”的时候。在'组装脚手架'任务开始之前，这项任务不能开始。这两项任务都可以同时进行，而且通常都是同时进行的，但是，脚手架必须在油漆开始之前开始。

Start to Finish

最后，Start to Finish 的任务依赖关系规定，在前一个任务开始之前，后一个任务不能完成。这是四个依赖关系中最复杂和最有争议的一个。一些项目经理说它根本不应该被使用，而另一些则为它的使用和好处辩护。简而言之，这个依赖说的是后继任务必须继续进行，直到前置任务准备好被启动。

Start to Finish example

就我们的建筑而言，在“提供建筑管理”（后继者）和“移交建筑管理”（前置者）这两项任务之间可以找到从开始到结束的依赖关系。在这里，建造大楼的公司必须继续管理该大楼，直到选定的供应商准备好接管。由于继任者的任务是在前任者之前完成的，这是使用和理解起来最复杂的依赖关系。

2.2.3 Task Network

单个任务和子任务根据其顺序具有相互依赖性。此外，当一个软件工程项目有超过一个人参与时，开发活动和任务很可能是平行进行的。当这种情况发生时，必须对同时进行的任务进行协调，以便在后面的任务需要其工作成果时，它们能够完成。

任务网络，也叫活动网络，是一个项目的任务流的图形表示。它有时被用来作为一种机制，通过这种机制，任务顺序和依赖关系被输入到自动项目调度工具中。在其最简单的形式中（用于创建一个宏观的时间表），任务网络描述了主要的软件工程任务。

软件工程活动的并发性导致了一些重要的调度要求。由于并行任务是异步发生的，计划者必须确定任务间的依赖关系，以确保持续的完成进度。此外，项目经理应该意识到那些位于关键路径上的任务。也就是说，如果整个项目要按期完成，这些任务必须按期完成。 

Task Network – Software Project

2.3 Estimate the effort and the time allocation for each task 估计每项任务的工作量和时间分配 – Step 3

2.3.1 Effort-time Estimation  工作时间的估计

估算软件工作量的一个常见措施是 man-months（更普遍的是 person-months）。

Person-months

一个人全职工作完成任务所需的时间，以月为单位。

The Mythical Man-Months [Brooks seminal paper]

• man-months 是估算软件的一个误导性措施
• 在一个进度落后的项目上增加人手，可能会造成更大的损失，而不是帮助它。

Effort vs Time

2.3.2 Time Estimation  时间估计

Terminology

• optimistic time 乐观的时间估计 -
• pessimistic time 悲观的时间估计 -
• most likely time 最可能时间估计 -
• expected time 预期时间 - 

2.4 Allocate resources for tasks and validate effort 为任务分配资源并验证努力程度 – Step 4

2.4.1 Resource Allocation 资源分配

如果 effort 工作量（person-months）和 Time 是已知的，人员的数量可以计算为：

为任务分配人员

• 尽管计算每项任务所需的人员数量看似简单，但资源分配是一项复杂的任务
• 项目经理必须仔细考虑人员的专业知识，以及他们是否能完成任务，这可能需要验证和调整时间表。

2.5 Develop a project schedule 制定一个项目时间表 – Step 5

2.5.1 Project Schedule

Project Schedule 将回答两个迄今为止尚未回答的重要问题

• 该系统需要多长时间来开发？
• 它将花费多少钱？

两种广泛使用的表示项目进度的图形符号

Gantt charts 甘特图

一种条形图，对照日历显示时间表

PERT（Program Evaluation and Review Technique 计划评估和审查技术）charts

显示任务之间的依赖关系和关键路径的活动网络

2.5.2 Project Scheduling - Definitions 

Activity (Task)  活动（任务） 
Is part of a project that requires resources and time 是一个项目的一部分，需要资源和时间。

Milestone 里程碑 
Is the completion of an activity that provides evidence of a deliverable completion or end of a phase – is an event that takes zero time 是一项活动的完成，为可交付成果的完成或一个阶段的结束提供证据 - 是一个需要零时间的事件

Free float (free slack) 自由浮动（自由松弛）
Is the amount of time that a task can be delayed without causing a delay to subsequent tasks 是指一项任务在不导致后续任务延误的情况下可以延迟的时间量

Total float (total slack) 总浮动(总松弛)
Is the amount of time that a task can be delayed without delaying project completion 是指一项任务在不耽误项目完成的情况下可以延迟的时间量

Critical path 关键路径 
Is the longest possible continuous path taken from the initial event to the terminal event 是指从初始事件到最终事件的最长可能的连续路径

Critical activity 关键活动 
Is an activity that has total float equal to zero 是指总浮动量等于零的活动

2.5.3 Milestones vs Deliverables

Milestones 里程碑

• 标记项目时间表上的特定点
• 这些点可能是信号锚，如：
  • a project start and end date 项目的开始和结束日期
  • a need for external review 需要进行外部审查
  • start and end of a phase 一个阶段的开始和结束
  • a completion of a deliverable 某项可交付成果的完成

Deliverable 可交付成果

• 有意义的具体 artefacts
• 可交付成果的例子包括：
  • Project documents such as the Project Management Plan, Requirements Specification, Design Document, Test Plan etc. 项目文件，如项目管理计划、需求规格、设计文件、测试计划等。
  • Prototypes 原型
  • Final application 最终的应用

2.5.4 Gantt Chart 甘特图

• 是由亨利-甘特在1910年提出的
• 甘特图是一个水平条形图，显示任务与时间线的关系—— project schedule 项目进度
• 可用于查看计划活动与进展情况，因此是监测项目进展的一个有用工具

Linked Gantt charts

• 包含表明任务之间依赖关系的线条

Progress Gantt charts 进度甘特图：

• 任务的着色与完成的程度成正比
• 用于进度跟踪——提供进度的可视化表示

2.5.5 PERT Chart

PERT（Program Evaluation and Review Technique 计划评估和审查技术）chart：

• 一个任务网络，它显示了与时间有关的信息和关键路径的依赖关系。

PERT分析有助于：

• understand the characteristics of the project that will let project managers do scheduling trade-offs 了解项目的特点，让项目经理进行时间安排的权衡
• perform critical path analysis 进行关键路径分析
• monitor project progress and re-plan 监测项目进展和重新规划

涉及到计算以下估算：

• Earliest start time 最早开始时间 (ES)
• Latest start time 最晚开始时间(LS)
• Earliest finish time 最早结束时间(EF)
• Latest finish time 最晚结束时间(LF)
• 松弛时间 Slack time

 PERT Chart - Example

对于多个并行任务，最早开始时间和最晚结束时间是由持续时间最长的任务决定的，对于这个例子，1.3系列任务的最早开始时间和最晚结束时间由1.3b决定，由于1.3b的持续时间为4天，所以整个系列任务的最早开始时间是4，最晚结束时间是8。

对于系列任务的最早开始时间都是4，但是由于1.3a和1.3c的持续时间较短，所以按照最早开始时间计算，1.3a有3天的松弛时间，1.3c有2天的松弛时间。

对于系列任务的最晚开始时间，1.3b只能从4开始，否则将造成项目整体延期，而对于1.3a最晚可以从8-1=7开始，因为只要保证任务能在8结束即可。同理1.3c的最晚开始时间是8-2=6。

注意：

• 关键路径活动的总自由松弛度为0
• 两条平行路径可能是关键路径
• 可以有一条以上的关键路径

2.5.6 关键路径方法

定义 Critical Path 关键路径

• path with the longest duration 持续时间最长的路径。
• activities on the critical path have a total free slack of 0 关键路径上的活动的总自由松弛度为0。
• a delay in any of the activities in the critical path will cause the project to delay 关键路径上的任何活动的延迟都会导致项目的延迟。

Crashing the project schedule 使项目进度加速

• 通过缩短关键路径来缩短项目的总工期。
  • 通过消除关键路径中的活动之间的依赖关系。
  • 缩短关键路径中活动的工期。

2.5.7 工具

3. How to use a project schedule to monitor and track project progress 如何使用项目进度表来监测和跟踪项目进度

3.1 项目跟踪和控制

软件项目是如何落后于进度的？

One day at a time 因为日复一日的落后，每天落后一点

项目日程安排很重要，但 tracking and controlling 跟踪和控制更重要!

如何跟踪和控制项目进度？

• Periodic meetings where team members report progress 定期会议，团队成员报告进度
• Evaluating the results of reviews and audits conducted as part of the software engineering process 评估作为软件工程过程一部分进行的评审和审计的结果
• Tracking formal project milestones 跟踪正式项目里程碑
• Comparing actual start dates with scheduled start dates 比较实际开始日期和计划开始日期
• 与工程师会面并进行非正式讨论
• 使用挣值分析等正式方法

3.2 Earned Value Analysis 挣值分析（EVA）

EVA可以用来

• 报告当前/过去的项目绩效
• 根据当前/过去的绩效预测未来的项目绩效

结果可以用美元和/或百分比表示

3.3 计算挣值分析

Planned Value 计划价值（PV）

• that portion of the approved cost estimate planned to be spent on the given activity during a given period 在特定时期内，计划用于特定活动的已批准的成本估算部分。

The Earned Value 挣值（EV）

• the value of the work actually completed 实际完成的工作的价值

Actual Cost 实际成本（AC）

• the total of the costs incurred in accomplishing work on the activity in a given period 在特定时期内，为完成该活动的工作而产生的成本总额。

例子：

你被指派管理一个计划在12个月内完成的项目，估计费用为100,000美元。在第三个月末，根据项目甘特图，20%的工作被报告为完成。财务部门报告该项目迄今为止的成本为35,000美元。

PV = $100,000*3/12 = $25,000 计划这三个月的成本应该事$25,000

EV = $100,000*20/100 = $20,000 实际完成的工作价值由完成的工作量决定

AC = $35,000 实际成本由题目直接给出

Schedule Variance Analysis 进度差异分析

使用EV和PV来计算项目进度的差异

Cost Performance Index 成本绩效指数

成本绩效指数（CPI）是一种通过以下公式计算特定项目的成本效率和财务效益的方法。

  实际完成的工作的价值 / 成本总额

• CPI > 1: 项目在预算方面表现良好。
• CPI = 1: 项目在预算内执行。
• CPI < 1: 一个项目超出预算。

Schedule Performance Index: expressed as a fraction 计划绩效指数：以分数表示

计划绩效指数（SPI）是一个更大的项目绩效衡量方法的一部分，称为挣值管理（EVM）。SPI本身是一个挣值与计划（或实际）值的比率。根据不同的整数，SPI反映了一个项目是按计划进行的，还是落后于计划的，或是超前的。

 实际完成的工作的价值 / 计划成本

• SPI > 1: 项目超前；已完成的工作比预期的多。
• SPI < 1: 项目落后于计划；已完成的工作比计划的少
• SPI = 1: 项目按计划进行；挣值和计划值相等。

Schedule Variance: expressed in dollars 时间表差异：以美元表示

 计划成本 - 实际完成的工作的价值

Cost Variance 成本差异

 实际完成的工作的价值 - 成本总额

良好的 Cost Performance 成本绩效的潜在原因

• Efficiencies being realized 正在实现的效率
• Work less complex than anticipated 工作没有预期的那么复杂
• Fewer revisions and rework 更少的修改和返工
• Favorable Market Fluctuations in the Cost of Labor or Material 劳动力或材料成本的有利市场波动
• Overhead Rate Decreases 间接费用率下降

不利的Cost Performance 成本绩效的潜在原因

• Work more complex than anticipated 工作比预期复杂
• Design review comments extensive 设计评审意见广泛
• Rework 重工
• Unclear Requirements 不明确的要求
• Scope Creep 范围蠕变
• Unfavorable Market Fluctuations in the Cost Labor or Material 劳动力或材料成本的不利市场波动
• Overhead Rate Increases 间接费用率增加

以下是有效的挣值管理的五个基本规则：

1. Organize the project team and the scope of work, using a work breakdown structure. Each task should have a single WBS number and organizational code. 使用工作分解结构组织项目团队和工作范围。每个任务都应该有一个 WBS 编号和组织代码。
2. Schedule the tasks in a logical manner so that lower level schedule elements support subsequent elements and the top level milestones. 以逻辑方式安排任务，以便较低级别的计划元素支持后续元素和顶级里程碑。
3. Allocate the total budget resources to time-phased control accounts. 将总预算资源分配给时间分段控制帐户。
4. Establish objective means for measuring work accomplishment. Budget should be earned in the same way that it was planned. 建立衡量工作成就的客观手段。预算应该以与计划相同的方式获得。
5. Control the project by analyzing cost and performance variances, assessing final costs, developing corrective actions, and controlling changes to the integrated baseline. 通过分析成本和性能差异、评估最终成本、制定纠正措施以及控制对集成基线的更改来控制项目。

4. Agile planning principles 敏捷计划原则

4.1 敏捷开发中的规划

• Takes a significantly different flavour from traditional approaches 与传统方法截然不同
• Detailed planning is deferred until the start of the iteration 详细计划被推迟到迭代开始时进行
  • Designed to handle change 为处理变化而设计
  • An iteration includes all phases (requirements, design and test) 一个迭代包括所有阶段（需求、设计和测试）
• Planning is based on light weight lists 规划是基于轻量级的清单
  • Gantt and PERT charts are considered less useful 甘特图和PERT图被认为不太有用
• Plan short iterations 计划短期迭代
• Deliver working software 交付可用的软件
• Use “Just in time (JIT) planning” – next iteration 使用“及时（JIT）计划”——下一次迭代
• Use the team 使用团队

4.2 Scrum中的计划

Level	Horizon	Who	Focus	Deliverables
投资组合	可能是一年以上的时间	利益相关者和产品所有者	管理一个产品的组合	产品组合积压和正在进行的产品收集
产品(设想)	长达数月或更长时间	产品所有者、利益相关者	愿景和产品随时间演变	产品愿景、路线图和高级功能
释放	三个月（或更少）到九个月	整个Scrum团队，利益相关者	不断平衡客户价值和整体质量与范围、进度和预算的限制。	发布计划
冲刺	每个迭代（一周到一个月）	整个Scrum团队	在下一阶段要交付哪些功能	冲刺阶段的目标和sprint backlog
每日	每一天	Scrum Master, 开发团队	如何完成承诺的功能	检查当前进度和调整

4.3 Release Planning 发布计划

Formal Planning 中的假设

• Scope fixed 范围固定——需求是稳定的
• Budget fixed 预算固定——成本估算是准确的

推出：

• Schedule fixed 时间表固定——基于范围和预算得出

Agile Planning

• 认识到所有三个因素：范围、预算和时间在现实中都不能固定——不推荐
• 我们可以固定范围和日期而使预算灵活吗？
  • 并非如此，因为增加预算，也就是增加资源，并不总是有助于提高速度——不推荐
• 那么我们有什么选择呢？
  • 固定日期和预算，使范围灵活。Fixed-Date release planning 固定日期的发布计划
  • 固定范围，使日期和预算灵活。Fixed-Scope release planning 固定范围的发布计划

4.3.1 Fixed-Date Release Planning 固定日期的发布计划

1. 确定sprint的数量N：总的持续时间除以每个Sprint持续的时间
2. 通过对故事的估计和优先级的确定 product backlog。
3. 测量团队速度范围: Vmin & Vmax
4. 根据速度计算最小和最大故事点
   • SPmin = Vmin * N
   • SPmax = Vmax * N
5. Draw lines through the Product Backlog to show the above

4.3.2 Fixed-Scope Release Planning 固定范围的发布计划

1. 通过创建、估计和确定优先级来梳理产品积压，并确定必须要有的故事
2. 确定必须完成的故事点的总数（𝑆𝑃𝑡𝑜𝑡𝑎𝑙）。
3. 测量团队速度范围：𝑉𝑚𝑖𝑛 , 𝑉𝑚𝑎x
4. 计算冲刺的最小和最大数量
   1. 𝑆𝑚𝑖𝑛 = 𝑆𝑃𝑡𝑜𝑡𝑎𝑙/𝑉𝑚𝑎𝑥,
   2. 𝑆𝑚𝑎𝑥 = 𝑆𝑃𝑡𝑜𝑡𝑎𝑙/𝑉𝑚𝑖x
5. Show on Burndown Chart