软件过程与项目管理复习（1）

Week1

Project Introduction

定义

• 创造一种独特的产品、服务或成果的暂时努力。

特点

• 会给组织带来新的机会（chance）
• 是一个 temporary 的行为，所以一定有开始和结束
• 跨职能，跨越组织边界（cross-functional, cut across organizational boundaries)
• 要应对未知（UnKnown）
• 是独特的（unique）

Project management

参考资料

项目管理的价值

• 节省资源
• 管控风险
• 明确存在的问题
• 管理和实现 change
• 复用之前的一些经验和知识
• 从过去的成功和失败中学习

[引用文章中给出的答案]

项目管理的5要素

从定义来看：

项目管理的五大要素是：

• 时间 time
• 成本 cost
• 质量 quality
• 范围 scope
• 收益 benefit
• 风险 risk

Project manager项目经理的技能要求

参考文章：项目经理需要的十项技能

• 在压力下工作保持工作状态
• 能在一个经常与预期不同 / change 频繁发生的环境中游刃有余
• 知人善任（给合适的人分配合适的工作）
• 适应、解决问题的能力
• 是个高效的沟通者
• 很强的行动力和执行力，不拖延
• 会发号施令，能控制局面

好的 project manager 往往是核心人才，会有很高的报酬

project manager 的核心任务（key activities)

规划 planning

• 清晰地划分项目的范围 scope
• 制定 project management plan
• 制定项目时间表 project schedule
• 制定政策和流程来更好地实现项目目标

组织 organizing

• 决定项目团队的结构
• 分辨每个人的角色和职责
• 确认哪些服务是第三方公司提供的

领导 leading

• 设定团队的目标
• 协调不同组织和部门的能力
• 激励团队成员
• 分配任务

掌控 controlling

• 制定项目的基线 baseline
• 跟踪项目的进度
• 项目状态报告
• 确定和采取纠正措施

Agile Scrum master 的核心任务（key activities）

首先在 Agile 的工作风格下没有项目经理这个职位，scrum master 的工作核心任务与 PM 有相似但是还是非常不同：

• 在团队成员之间传播/共享
• 不再有 command & control 了，而是变成服务式的领导（servant leadership）
  • 督促团队交付
  • 强调团队目标
  • 是否有利于项目的整体表现
  • 需要咨询团队成员来获得某些问题的答案
  • 允许团队成员自发组织并取得一些进展
  • 帮助团队其他成员修正和完成工作

项目经理和Scrum master 的异同

参考资料

Projects

一些项目管理方法/规范 PMM

Waterfall

• 计划阶段非常详细，可以产生精确时间表
• 面对挑战难以调整，难以纠正之前的问题
• 需要再计划阶段积极地考虑后面可能发生的问题

Agile

• 专注于适应挑战
• 依赖于持续和定期的反馈
• 专注于以迭代的方式尽快交付产品
• 几乎没什么管理行为
• 团队成员自己选择任务，参与感更加明显
• 以顾客和需求为导向
• 灵活，返工少
• 团队成员需要经验
• 大型项目是短板
• 很难与供应商签约

项目成败的定义

• successful：按时完成，按预算完成，功能都实现
• challenged：完成但是超时或者超预算，或者少点功能
• 失败：没有成品，项目中途取消

项目成败的关键

参考资料

• 持续的资金投入
• 开发人员的性格稳定成熟
• 客户积极参与
• 优化——需求陈述

如何选择正确的项目（Project screening）

项目启动（初始化）阶段

Business case

商业案例的目的就是提供一个机制，来判断当前的项目是否值得继续投资，有没有继续下去的必要

• 为关键决策者提供事实基础，以决定是否应进行的项目
• 演示项目如何为组织增加价值
• 有一套预先定义的标准组织，包含特定的内容 (成本、收益、风险等)
• 与项目的 size 无关，因为 size 取决于成本 / 收益
• 它是贯穿整个项目的活动文档，应该被评审 并在关键阶段签字

主要内容

• 可执行总结
• 为什么这个项目是必须的，有价值的
• 商业候选方案有哪些
• 期待的收益是什么
• 预期的不利是什么
• 时间跨度
• 成本估计
• 投资估价
• 主要风险
  

business case 中不同的角色和职责

Coporate

• 授权
• 让高级用户负责实现利益
• 负责实施岗位项目的效益验证。

Excutive

• 拥有项目
• 审查收益

senior user

• 负责接受和发放利益。
• 负责确保交付的产品达到适当的质量标准
• 提供持续的实际预测效益实现

project manager

• 准备业务用例
• 进行风险评估和影响分析
• 在每个定义的阶段评估和更新业务用例

project assurance

• 协助开发业务案例
• 确保持续管理物有所值和风险
• 监视业务用例的更改并对其进行验证。

project support

• 负责收集数据并准备管理报告
• 对所有项目涉众的关键支持点-时间表
• 成本分析， 会议记录，行动，供应商联络等

投资技巧和经济模型（investment techniques & financial models）

投资技巧——投资回报率（ROI）

• 净收益 / 成本 = (投入 - 成本) / 成本
• 很多机构的最低可接受的 ROI 在 11%-14% 之间

投资技巧——净现值（NPV）

• NPV是最常使用的用来进行项目筛选的量化/财务方法之一
• 净现值（NPV）是一段时间内现金流入现值与现金流出现值之间的差额。NPV 用于资本预算和投资规划，以分析预计投资或项目的盈利能力。
• 应考虑NPV为正的项目，如果 财务价值是一个关键标准
• 一般来说，NPV越高，越有利

投资技巧 ——回收期（Payback Period）

• 回收期是指项目在应计收益超过应计成本之前所花的时间，或指一项投资收回初始成本所需的时间
• 根据对每年净现金流的跟踪 确定净收益超过净成本的年份 (非折现现金流)
• 许多组织希望IT项目的时间相当短 由于性质的变化，回收期(< 1年) 技术

投资技巧——项目估计大致数量级（ROM)

Project Charter

• 项目章程是一份正式的，通常是简短的文件，它完整地描述了你的项目——包括目标是什么，如何执行，涉众是谁。它是计划项目的关键组成部分，因为它在整个项目生命周期中使用。
• 正式文件还可以显示项目的可行性和可能的​​投资回报，帮助工作获得批准。
  

project charter 和 business case 的区别

参考资料
通俗来讲，可以想一下这个场景：

• 公司或者投资人会接受很多的项目案例，这些案例都要说自己的项目很有价值，收益是多少，风险是什么
• 然后决策者觉得哪个比较有价值，就选出来，投钱
• 然后让这个项目的发起人去写个项目章程把大致的里程碑，资源，成本什么的做个分析，所以项目章程是项目开始的第一份文件

所以 business case 一定发生在 project charter 之前

business case -> 项目被选中 -> 项目启动 -> 项目章程 -> 章程被批准

Week2

Process

• process 就是一套标准的流程
• process 的目的就是高效地完成具有相似特点的一系列事情

经验主义的流程控制

• 边进行边学习
• 能够应对 change
• 使用较短的开发周期进行检查和适应
• 估算仅是指示性的，可能并不准确

基于定义的流程控制

• 时间容易把握
• change 厌恶

Process 分别和 项目管理（PM) 以及软件工程有什么关系

• 项目管理可以看做是一个 Process 因为这个过程中要涉及到多个既定的步骤，这些步骤可以被标准化，从而提高每个项目的效率
• 系统开发生命周期（System Development lifestyle）SDLC 是软件工程中使用的术语。它描述了规划、创建、测试和部署信息系统的过程（这也是一个 process）。SDLC可以只由硬件组成，也可以只由软件组成，或者两者的组合。
• 总结一下：就是无论 PM 还是软件工程中的软件开发的 SDLC 本质上都是 Process。只要是 Process 就可以进行流程控制（Process control）而流程控制又分成两种：empirical 的和 defined；可以对他们的这个流程进行标准化提高开发和管理的效率

SDLC

系统开发生命周期(SDLC)，也称为应用程序 开发生命周期，是系统工程信息中使用的一个术语 系统和软件工程描述计划、创造、 测试和部署信息系统。

既然 SDLC 本身可以看成是一种 process，那么 Formal 对应的就是 process control 中的 defined 方式。Agile 也就对应的是流程控制中的 empirical 的方式

SDLC 中的主要任务（activities）

• 收集需求(requirements gathering)
• 设计架构(architecture design)
• 编码(coding)
• 测试(testing)
• 评估(evaluating)
  • 交付和发布——部署
  • 维护

Formal

Waterfall

• 简单，容易实现和使用
• 易于管理；因为变化的地方不多
• 流程是阶段性的，每次完成一个即可
• 结束阶段有 documentation
• 当需求定义很清晰的时候，waterfall 很容易实施也很容易理解

---

• 过程中难以应对 change
• 每次只能完成一个
• 不清晰的需求导致混乱
• client 只能在最终阶段决定是否 approval
• 很难将风险管理整合进来（因为即使分析出潜在的风险，在执行过程中也无法进行调整，因为 waterfall 的整个流程灵活性太差）

Incremental

• 每次发布都是一个可使用的版本
• 面对 change 的能力增强（相比 waterfall）
• 客户可以在每个 increment 发布阶段进行参与和回应
• 项目的启动比 waterfall 快（不用分析那么透彻需求）
• 客户可以更快得到实现的核心功能
• 核心功能可以更快地被测试

---

• 与 waterfall 相比需要更多资源（因为每个 increment 都要进行分析、设计、实现、测试、部署、维护 这一套完整流程，增量整合的时候也可能出问题，产生额外的成本）
• 需要更多的管理工作
• 很难对整体的任务切分的非常清楚、正确
• 迭代的每个阶段都是严格的，没有重叠
• 每个 increment 整合的时候可能出问题，产生额外的成本

V-model

参考资料

• 简单，易于管理
• 刚性（rigid）和顺序交付（sequential deliverable）
• 文件全面
• 需求稳定且精确

---

• 需要 discipline
• 坏消息是后来才知道的
• 客户反馈在后期才知道
• 阻碍 change
• 进行测试是昂贵的
• 风险和变化有很大的影响
  
  

Formal 什么时候比较好用

• 客户非常清晰地知道他们要什么
• 客户需求非常明确且documented
• 几乎不需要有任何 change
• 大规模的应用和系统开发

Agile

Agile attractive 的原因：

• 所有的东西都会变
• 客户的需求增长很快，必须持续交付
• 技术成本低，使用方便，已与全球市场接轨 增加竞争，降低进入壁垒
• 跨职能团队可以减少损失
• 开发周期短
• 阶段性进行测试，不放在最后才做
• 跨职能小组更有趣

Agile Framework

Manifesto（敏捷宣言）

• 重视个人和交流 > 流程和工具
• 重视工作软件 > 复杂的文件
• 重视和客户的合作 > 合约协商
• 重视应对 change > 按部就班的跟着 plan

12 key principle

• 客户导向
• 迎合 change
• 频繁发布
• 开发者和商业人员沟通
• 以积极成员为中心
• 面对面高效沟通
• 工作软件是进度的主要度量
• 敏捷过程促进可持续开发。发起人、开发人员和用户应该能够无限期地保持恒定的步调
• 持续关注技术
• 简单
• 团队自组织
• 定期反思

kanban

scrum

Scrum

• 是一种 agile 的 process
• 迅速地高质量开发
• 设置优先级，团队自组织
• 迭代发布，每个一段时间发布一个产品

特点

• 自组织团队
• 将 product 分为几个集中的 sprint
• 用 backlog list 来切分 requirements
• 是一种 agile 的 process，应用最广泛
• time frame 包含在可管理的范围内

Scrum Framework

Roles

• product owner
  • 定义产品特点
  • 为产品的收益和 ROI 负责
  • 根据市场决定产品开发的优先级
  • 在每个不同的 iteration 调整开发的优先级和开发的内容
  • 接受或者拒绝产品验收
• scrum master
  • 对 project 进行管理
  • 负责制定Scrum价值观和实践
  • 清除障碍/路障
  • 保证团队的运作效率
  • 保证团队成员的沟通
  • 保护团队不受外部干扰
  • 是团队中的积极成员
• team
  • 跨职能团队（从开发到测试）
  • 所有人尽可能全职
  • 同一位置(物理上或虚拟上)

Ceremonies

• sprint planning

  • 如何实现 sprint goal（design）
  • 创建 sprint log
  • 用团队的完成速度和 story point 来评估 sprint backlog
  • PO 安排任务的优先级
  • 制定发布计划（release plan)
  • high-level design

• sprint review

  • 目前的 sprint 完成的任务
  • 通常采用展示 demo 或者架构的方式
  • 非正式
  • 没有 ppt

• sprint retrospective

  • 每次 sprint 结束之后做
  • 讨论什么要开始做了，什么要停止，什么继续做
    

• daily stand-ups

  • 每天
  • 15-30分钟
  • 不解决问题，阐述一些 user story 的问题

Artifacts

• product backlog：可以看做比较笼统的 user story
  • 通常可以用 story point 来衡量一个 backlog 的条目占的分量
  • story point 可以帮助衡量一个 sprint 的工作量
• sprint backlog：可以看做 product backlog 中的一部分，粒度更细，可以用小时估计了
  • 剩余工作可以每天都更新
  • sprint backlog 很少发生改变
  • 在 sprint log 中的 user story 是原子性的，要么完成了，要么没完成
• burndown chart
  

Kanban

Extreme Programming

Agile 总结优缺点

• 客户可以得到很快且高质量、连续的交付
• 更强调人的感受和交互，不那么重视流程和工具
• 关心技术更新，好的设计和质量
• 拥抱 changing

---

• 很难开始的时候评估所需的 effort
• 占用客户的时间
• 对新手不友好
• 对 team 来说可能很紧张
• 需要有经验的开发者（稀缺资源）

如何选择 Formal 和 Agile

扩展 Wagile / PRINCE2 / PMBOK / SAFagile

Week3

风险管理（Risk management）

• risk 不一定是坏处
• positive 的 risk 可以是 opportunity

Risk 和 Uncertainty 的区别

• uncertainty 没有 impact
• risk 产生 impact（正向 / 负向）
• risk 是 uncertainty 的结果，但不是所有的 uncertainty 都是 risk

Risk 种类

Business Risk

• 会影响到 project 的经济成功
  

Project Risk

• 影响到项目的规划
  

Product Risk

• 影响到最终的产品表现和质量
  

Risk management 的意义

• 最小化 risk 的负面影响，最大化其正向影响

风险管理的流程（process）

Plan（risk management plan 的主要活动）

Identify

• risk 发生的概率是多少
• 是 generic risk 还是 product-specific risk：这个 risk 对所有的项目都可能存在还是只对这个项目有
• 列出所有可能的可能影响 project 的 risk
  identify risk 的方法：
  

Pondering 思考法

• 用笔和纸，思考哪些是 risk

Interview 采访法

• 通过询问专家，他们利用专业知识来判断哪些 risk 是可能的

brainstorming 脑暴法

• 大家进行头脑风暴
• 使用 risk framework 或者 work breakdown structure（WBS) 法来总结 risk

checklist 列举法

• 这涉及使用从经验中整理的可能风险驱动因素的标准检查清单
• 这些检查清单是专家们思考该领域可能存在的风险类型的诱因

Delphi

• 先让专家来 identify risk 并且判断他们的 impact
• 然后公开分享自己的分析结果
• 根据其他人分享的结果更新自己的评估，直到完全一致

SWOT Analysis(case study)

• S: 使业务或项目比其他业务或项目具有优势的特征
• W: 使业务或项目相对于其他业务或项目处于不利地位的特征
• O: 企业或项目可以利用的环境中的元素
• T: 环境中可能给业务或项目带来麻烦的元素

Indentify 的案例和思维训练

Analyse and assess

• Analyse 就是分析 risk 的可能性和影响程度
• Assess 就是优先考虑风险，以便制定有效的风险策略

Analyse

• 分析发生概率 P （0-1）
• 分析影响因子 I（1-5）
• 计算风险 risk exposure (P * I)
• 弄清楚根本原因是什么：确定所有风险的根本原因是很重要的——如果这个根本原因可以确定，那么所有这些风险都可以通过解决根本原因来控制

Assessment

Risk Matrix：定性分析

定量分析 quantitative

Respond（action）

四种应对 threat 的方法

接受或者忽略 accept / ignore

• 这意味着我们相信风险是可接受的暴露， 我们希望事件不会发生，或者风险暴露 比任何避免、减轻或转移污染的技术的成本都要低

避免 avoid

• 这意味着我们完全防止了危险事件的发生， 要么确保其概率为0，要么确保其影响为0。

减轻 mitigate

• 可能造成二次解决的隐患
• 这涉及到使用技术来减少发生的可能性 风险，或减少风险的影响。这就导致了剩余风险 也就是说，风险由相同的事件组成，但风险较低 概率/影响，因此曝光度低。然后我们必须分析 剩余风险和主要风险一样

转移 transfer

• 这涉及到将风险负担转移到另一方。 保险是风险转移的一个例子，其中的影响 风险被保险公司的赔付所抵消。另一个例子是 把一部分工作外包给更有知识的人 还有专业知识，这是有代价的。

四种应对 opportunity 的方法

Exploit 探索

Enhance 提升

Share 共享

Accept 接受

Risk Respond Plan 风险应对计划（risk register）

• 当风险被识别之后，就可以记录下来作为 risk respond plan 的一部分，这个过程称为 Risk register （风险注册）

Monitor and Control

• 一旦创建了风险响应计划，触发器必须 被监控以跟踪各种项目风险
• 在这一过程中，可能会出现新的威胁和机遇 项目-它们必须被识别，分析和响应
• 风险监测必须是整体监测和管理的一部分

Monitor & Control 的工具

Risk audits - 风险审计

• 外部团队关注识别过程的全面性，并确保其他程序和流程到位

Risk reviews- 风险审查

• 定期的内部风险审查，为项目经理和那些需要了解的人生成状态报告

Risk status meetings 风险状态会议

• 风险必须在项目状态会议上进行审查和讨论，项目状态会议是在项目中定期举行的(例如，周会)

Formal Risk Management & Agile Risk Management

Formal Risk Management（就是上面讲的管理方法）

1. plan risk management

2. Identify risks
3. Perform Qualitative Risk Analysis
4. Perform Quantitative Risk Analysis
5. Control risk

Agile Risk management

1. Identify： 在 product backlog 的过程中捕获 risk
2. Analyze： 制定产品待办事项清单，优先考虑所有用户故事，包括那些捕捉风险的故事
3. Respond： 在 sprint 过程中不断修正风险
4. Monitor： 在Sprint回顾、回顾和计划期间

Sprint review risk evaluation（Sprint评审风险评估）

• risk item 在 product backlog 中的形式多变，
• 可以选择使用 feature-driven development （FDD) 的语法来表示：
  

Scrum master 通过管理 risk 来帮团队扫清障碍
PO 负责业务风险，添加 risk item，对 product backlog 划分优先级
Developers 进行成本估算

Week 4

项目管理计划（project management plan）PMP

Formal

• 几乎每个组织都有自己的项目管理计划
• PMP 是一个正式的，经过授权的文件，它规定了 project 如何执行，如何被管理和控制，可能是一个 summary 或者更加详细的文件
• 是由 PM（项目经理） 全权负责的
• 一个好的PMP提供了跨关键项目组件所需的详细层级，并且是项目中所有参与方的真相来源。

Formal PMP 的主要内容

项目信息有关的（project information）

项目需要管理的内容（project governance）

项目经理协调 PMP 中所有的内容，并对其负责。

利益相关者管理（Stakeholder Management）

Identify 利益相关者 & Register

首先识别有哪些利益相关者

Internal 利益相关者

external 利益相关者

将利益相关者找出来放到表格里的过程叫做注册

利益相关者的参与和计划（Stakeholder Engagement & Planning）

不同的参与程度（Engagement level）

Unaware

• 不知道这个项目及其对他们的潜在影响

Resistant

• 了解项目，但拒绝改变

Neutral

• 知道这个项目，但既不支持也不反对

Supportive

• 了解项目并支持变更

Champion / Leading

• 了解项目并推动变更

Stakeholder Planning 的内容

• 利益相关者当前的参与度和未来期望的参与度
• 利益相关者之间的相互关系
• 沟通需求
• 每个stakeholder的潜在管理策略
• stakeholder 管理计划的更新方法

并不是所有人都参与到 stakeholder 的管理计划，只有 PM 和少部分成员参与其中

stakeholder 分析

沟通管理（Communication management）

沟通挑战（communication challenge)

个人挑战

• 语义
• 理解
• 沟通方式
• 反馈
• 沟通焦虑
• 文化背景

团队挑战

• 团队的状态
• 彼此之间的隔阂（silos）
• 信息过载（频繁的会议和群聊）
• 成员之间缺乏沟通
• 团队中的规则

倾听的重要性（listening importance）

倾听的好处

• 提升解决问题的能力
• 表现出对他人的接纳
• 在人际关系中建立并保持信任
• 增加说话者对他人思想和想法的接受能力
• 增加说话者的自尊，帮助你评估信息
• 帮助你理解和记住信息
• 让你帮助别人
  

listening 的过程（process）

• 预测别人要说什么
• 接收到信息
• 理解信息的意义
• 评估这条信息的重要性或者真实性
• 记忆
  

倾听的类型（types）

主动接受-tutorial

• 通过一些交互，问答来更好地理解信息
  

被动接受-lecture

• 只是接受这些信息

倾听的绊脚石（challenges）

• 生理上的缺陷
• 对信息背景不了解
• 选择性的记忆或者期望
• 害怕被影响 / 说服
• 偏见和被评判
• 无聊或者情绪上的波动
• 部分倾听和干扰，例如手机/背景噪音
• 物理障碍：环境，灯光，不舒服的座位
• 文化差异
• 过去的经验
• 一些术语和缩略词
  

主动倾听的重要性（active listening importance）

• 向主讲人表达你的兴趣
• 可以更好地吸收信息
• 鼓励主讲人与你有更深层次地交流
• 有增进关系的潜力
• 让沮丧的人平静下来
• 在问题解决上有更好的合作
  

沟通技巧和重要性（skills & importance）

沟通能力包括（skills）

• 传达你自己的观点
• 激励和影响其他人
• 授权和委派（delegating）他人完成一些任务
• 更好地认识问题并解决问题
• 进行演示/更新（presentation）
• 设定目标，明确愿景（setting goal）
• 管理和解决冲突（manage conflict）
• 与他人进行连接
• 与他人协商（negotiating）
  

沟通为什么重要

因为一个 PM 必须具备下列能力：

• 理解客户
• 主持会议
• 精准地沟通想法
• 管理团队
• 影响环境
• 确保与目标/结果保持一致

沟通计划（communication plan）

• 保证沟通效率
• 允许项目经理积极主动
• 对何时做什么达成共识
• 明确谁负责关键项目，交付什么，由谁负责
  
  
• 要传达什么信息-细节和格式
• 沟通渠道——会议、电子邮件、电话、门户网站等
• 何时发布信息-正式和非正式通信的频率
• 谁来负责
• 利益攸关方的沟通需求
• 项目将分配用于通信的资源
• 敏感或机密信息将被传递到何种程度;谁会授权
• 影响项目沟通的任何约束(内部或外部)
• 项目必须使用的任何标准模板、格式或文档，以解决任何基于沟通的冲突或问题

虚拟团队（virtual teams & communication）

虚拟团队(也称为地理上分散的团队) 团队，分布式团队，或远程团队)通常是指一组 来自不同地理位置的人一起工作 依靠通信技术。(维基百科)

• 有了虚拟团队，雇员可以有更好的灵活度
• 可以网罗世界范围内的人才
• 节省房地产成本

• 沟通不如面对面丰富，也不如面对面频繁

---

• 但是对那些社恐，可能感觉更舒服
• 不重视外貌和社交技巧
• 还是要注意一些偏见

如何沟通（communication）

• 创建沟通章程（communication charter）
  • 如何沟通
  • 沟通的行为规范
  • 一些沟通指南
• 利用通信技术
• 团建

如何构建好的 virtual team

• 良好的沟通
• 高情商
• 独立工作的能力
• 恢复力（身体弹性）
• 对其他文化的了解和敏感是很重要的，尤其是在全球性的群体中

沟通的关键考量（key communication consideration）

• 接收方几乎不会完全按照发送方那样思考
• 地理位置和文化差异加剧了沟通的难度
  • 不同的工作时间
  • 语言障碍
  • 不同的文化标准
• 沟通可以帮助减少 conflict
• 花费时间锻炼和培养沟通技巧
• 选择合适的沟通渠道

可能的冲突 Conflict

Week 5

项目规划（Project Scheduling）

重要的文件主要在这个阶段产生
在整个项目中使用和维护，以监视和跟踪项目进展——是一个 living document

project schedule 主要内容

• 每个任务的持续时间（duration）和任务之间的依赖关系 （dependencies）
• 每个任务需要的人力和物理资源（people and physical）
• 任务的里程碑（milestone）和交付的产品（deliverables）
• 项目时间线（project timelines）

构建 project schedule 的步骤

• 将任务切分成小块（Work breakdown structure）WBS
• 确定分解的任务之间的相互依赖关系 建立一个任务网络
• 评估每个小任务的时间并对其进行分配
• 为任务分配资源并验证工作成果
• 制定项目进度计划
  

之所以进行 schedule 是因为：

• 大任务的规划是有挑战性的
  
• 所以解决方案是将大任务切分成可管理的小部分：
  

1. WBS 将项目切分

2. 识别不同子任务之间的依赖（dependencies）

有约束的（Constrained）

• 取决于另一个任务(在删除装饰之前不能删除墙纸)
  

没约束的（Unconstrained）

• 任务可以随时开始(买油漆，拆下可拆卸的装饰)

依赖的类型（Type ）

Dependency 产生的原因是：

• 一个任务需要另一个任务的产出 / 结果
• 一个任务需要另一个任务正在使用的资源

Finish-to-Start

• 一个结束了，下一个才能接着开始

Start-to-Start

• 一个开始了，另一个才能开始

Finish-to-Finish

• 一个结束了，另一个才能结束

Start-to-Finish

• 一个开始了，另一个才能结束
  

3. 构建任务网络 (Task Network)

4. 评估每个 task 的任务量 + 分配时间（effort estimate & time allocation）

Effort estimate（人力评估）

• 评估软件工作量的一个常用度量方法是人月(更普遍的是人月)：一个人全职工作一个月的任务量
• 但是这种评估方式其实是有误导性的：因为人数的增加到一定程度之后，每个人的效率会降低，这个时候 person/month 就下降了，就不准确了
  

time estimate （时间评估）

• 理想时间 O
• 保守时间 P
• 最可能完成时间 M
• 期望时间 E
  

5. 资源分配（allocate resource）

如果总的 person-months 可以被评估出来，那么招募几个人就可以计算出来

• 虽然计算每项任务所需的人员数量似乎很简单，但资源分配是一项复杂的任务。
• 项目经理必须仔细考虑人员的专业知识，以及他们对任务的可用性，这可能需要验证和调整计划

6. 构建项目计划 （Project schedule）

• 用甘特图来表示时间跨度
• 用 PERT（Program evaluation and review technique) 图显示相互依赖关系的活动网络任务和关键路径
  
  

Critical Path 关键路径

• 关键路径活动的总空闲余量为0
• 可能有多个 critical paths
• 是具有最长 duration 的路径
• 任何一个步骤的拖延都会导致整个项目的整体延后
  

在对子任务进行 schedule 的时候，我们应该通过以下的内容对子任务进行描述：

Crashing the project schedule

• 通过缩短关键路径中的活动之间的依赖关系来缩短项目的总持续时间;
• 或缩短关键路径上活动的持续时间

Project Tracking & Control （项目进度跟踪和控制）

如何跟踪进度和控制

• 周期性会议
• 评估作为软件工程过程一部分进行的评审和审核的结果
• 跟踪正式项目里程碑
• 比较实际开始日期和计划开始日期
• 会见工程师，进行非正式讨论
• 使用 Earned Value Analysis（一种正式的方法）

Earned Value Analysis（EVA)

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

核心就是：假设一共完整项目相当于挣了 N 元钱，现在已经挣了 M，根据这个比例算出进度

PV

• 这部分核定费用概算计划在某一期间用于某一活动

EV

• 实际完成工作的价值

AC

• 在一定时期内完成某项活动的工作所产生的费用总额
  

Schedule variance

Schedule Variance index

cost variance

cost Variance index

Project schedule in Agile（agile 的方式进行项目安排）

• 不适用 Gantti 图和 PERT 图

取而代之的是：

• 规划简单而短的迭代
• 发布 working software
• 将做不完的放到下一个 iteration
• 借助团队的力量
  

Planning in scrum（在 scrum 中的不同层级的规划）

• 由外到内依次是：Strategy, Portfolio, Product, Release, Sprint, Daily 级别
  

Release Planning (发布计划)

Formal

固定规模 Scope fixed 的发布计划

• 需求要非常稳定（不能有 change）

固定预算 Budget fixed 的发布计划

• 成本核算和评估需要非常精准（不能产生额外的费用）

固定项目期限 schedule fixed 的发布计划

• 取决于 scope 和 budget
  

Agile

Fixed Date Release Planning

Fixed-Scope Release Planning

Week6

Cost estimation （成本估算）

• 估算构建一个基于软件的系统或产品将花费多少金钱、精力、资源和时间

成本估算的方式

Delay Estimation （延后估算）

• 项目完成后再估算

基于以前的项目估算

将项目切分成小块分别估算

使用基于经验的估算方式

成本估算技术（Techniques）

专家法（Expert judgement)

• 每个专家按照以下方法算出他们的期望 cost
  

  • p 是悲观预估
  • o 是乐观评估
  • m 是最可能的评估
  • e 是期望值

• 然后根据 Delphi 法：

  • 每个专家都给出他们的分数（私下）
  • 然后大家坐在一起公布各自的评估分数
  • 每个人调整自己的分数
  • 直到所有人达成一致

类比估计法（Estimation by Analogy)

• 新项目的成本是根据相同应用程序域中的类似项目估算的

帕金森法（Parkinson’s Law）

• 这条法律规定工作将扩展以填补可用的时间
• 成本是由可用的资源而不是客观的评估决定的。例如，如果软件要在12个月内交付，并且有3个人可用，那么工作量是36人月

Pricing to win 方法

• 成本是根据客户在项目上的花费来估算的——成本取决于预算，而不是软件功能（客户给多少就花多少）

算法建模（Algorithmic cost modelling）

• 模型是根据项目成本的一些软件度量(通常是其大小)使用历史成本信息开发的
• 当需要对项目 effort 进行估计时，使用 metric 来评估
• 公式如下：
  

Software size estimation（软件尺寸评估）

代码行数（Source lines of code）SLOC

• 基于代码的评估方式

真实的 SLOC

• 一共写了多少行代码 （真实代码）

逻辑的 SLOC

• 可执行的 statement 有多少（用伪代码表示）

优缺点

• 可以通过自动化技术来计算数量：因为代码行是一个物理实体，所以很容易计数，并且可以使用工具进行自动化
• 是一个非常直观的度量方式

---

• 取决于编程语言和编程人员的经验
• 从分析和设计阶段 获得的信息中，很难估计开发一个系统所需的代码行数
• 对于一行代码究竟是什么，缺乏一个被普遍接受的定义

功能点数（function points） FP

• 基于需求
• 用于表示用户所看到的软件系统中功能的数量
• 更多的 FP 代表系统更加复杂，功能更多
• 通常用来：
  • 估算设计、编码和测试软件系统所需的成本和工作量
  • 预测错误的数量
  • 预测组件的数量
  • 作为生产力指标
    
• FP 是通过 Software requirements specification (SRS) 来计算的

如何计算 FP

将需求分类（categorize requirements）

Functional

• Data function ： 关注应用程序的数据维护
  • Internal logical files (ILF)：系统维护的内部数据，通过外面的输入进行修改
  • external interface files（EIF）：在系统外维护的逻辑数据
• Transaction function ：关注与系统之间传递的信息
  • External input（EI) : 通过 user 或者外部的应用产生的输入，用来控制这个系统的流，或者为这个系统提供 data，通常用来更改 Internal logical files
  • External Outputs（EO） ：向用户提供有关系统状态的信息的输出
  • External Inquiries（EQ) : 输入不用于更新内部逻辑文件，而是用于查询内部逻辑文件并提供输出;直接检索输出，不包括派生数据

对每一个种类的 function 评估其复杂度

• 复杂度分三种：simple, average, complex
• 通常分配给一个类别，而不是每个需求
• 衡量复杂度经常使用的技术是：基于 DETs（Data element types），基于 RETs（Record Element Types）和 FTR (File Type References)

DETs

• 系统中唯一的、用户可识别的、非重复的数据字段

RETs

• ILF 或 EIF 中用户可识别的数据元素子组

FTR

• ILF, EIF 中事务引用的文件

计算总的复杂度

通过计算得到 value adjustment factor 值

计算总的 FP 点数

优缺点

• 衡量 解决方案 的规模，而不是问题的规模
• 只需要根据需求就可以计算
• 可以在设计和分析阶段就完成
• 独立于技术方案
• 独立于编程语言

---

• 一个定义良好的需求规范是必要的
• 获得熟练掌握并不容易，学习曲线相当长
• 可能是相当耗时，因此可能是昂贵的

Agile effort estimation（agile 的成本评估）

评估角度

Story point

• 描述点是用户描述大小的相对度量(回想一下，系统的需求是使用用户描述来记录的)

Velocity

• 速度是团队生产力的衡量标准，它由在特定时间段内交付的故事点的数量表示

评估流程（Agile estimation process）

构建 user story

为每个 user story 评估 story points

根据以往经验中团队的速度评估 delivery time

结合开发过程评估在当前项目团队真正的速度

使用真实速度重新评估 delivery time

Agile estimation guideline（agile 评估指南）

Agile 评估技术 (technology)

Planning poker

Bucket System

• 坐在桌旁的团队随机挑选一张用户故事卡，并将其放入第8桶中。
• 接下来的几张卡每次随机挑选一张，讨论并达成一致意见，并相对于之前的卡片放置在一个桶中。
• 然后每个人被分配一套卡片，并根据个人判断将其放置在合适的桶中

Relative mass valuation

• 1. 放一张大桌子，这样故事就可以很容易地相对移动。
• 2. 选择一个故事开始，团队估计他们是否认为它是相对的:大，中，小。
• 3. 大故事的一端放在桌子上。中故事在中间，小故事在另一端。
• 4. 继续步骤2 &3
• 5. 下一步是根据故事在桌子上的位置分配分数值。从最简单的值得分值的故事开始，称它为1。
• 6. 然后向上移动卡片列表，为每个故事分配1的值，直到你到达一个看起来至少比第一个故事难两倍的故事。这个故事得2分。

速度计算

关于评估的最后总结

• 留出足够的时间做一个适当的项目评估

• 匆忙估计是不准确的，高风险的估计

• 花费在评估上的时间回报递减
  

• agile 团队应该选择下图中靠左边的部分

• 要知道你不能从估算中消除不确定性，但是 小的努力会有大的收获