《敏捷项目管理》知识要点整理

项目的属性

1、拥有特定的目标

2、临时性：具有明确的开始和结束时间

3、使用逐步细化的方式进行开发

4、通常需要不同领域的资源

5、应该要有一个主要的客户或者赞助商

6、不确定性

什么是项目管理

将知识，技能，工具和技术应用于项目活动中以满足项目要求

传统项目管理中一些概念

stakeholder

是参与或受项目活动影响的人
包含有：

1、the project sponsor
2、the project manager：97% of successful projects were led by experienced project managers, who can often help influence success factors
3、the project team
4、support staff
5、customers
6、users
7、suppliers
8、opponents to the project

项目经理最重要的十项技能和能力

人际交往技巧
领导力
倾听
正直，道德行为，始终如一
善于建立信任
口头交流
善于建立团队
冲突解决，冲突管理
批判性思维，解决问题
理解并平衡优先事项

领导技能的重要性

高效的项目经理以身作则提供领导力
领导者关注长期目标和大局目标，同时激励人们实现这些目标
经理负责实现具体目标的日常细节
项目经理经常同时扮演领导者和经理的角色

互联网+时代软件产品开发的变化

• 以用户为中心，而非客户
• 从不确定性出发，而非确定性
• 主导产品，而非交付项目
• 追求体验，而非质量
• 追求容错，而非完美
• 追求创新，而非执行

敏捷的背景与动机

• 软件危机及软件工程的出现
• 速度是企业竞争致胜的关键因素，软件项目的最大挑战在于
  • 一方面要应付变动中的需求
  • 一方面要在紧缩的时程内完成项目
• 传统的软件工程难以满足这些要求
• 所以软件团队除了在技术上必须日益精进，更需要运用有效的开发流程，以确保团队能够发挥综效。这正是 Agile Process（敏捷的软件开发流程）于近年来兴起的主要原因。

什么是敏捷软件开发方法

• 敏捷方法是一类软件开发流程的泛称
• 敏捷方法是相对于传统的软件过程提出的
• 敏捷方法可以用敏捷宣言（4条）、敏捷原则（12条）和 一系列的敏捷实践来概括
• 敏捷方法有很多软件开发框架

敏捷价值观之敏捷宣言（4点）

• 个体和交互胜过过程和工具
• 可以工作的软件胜过面面俱到的文档
• 客户合作胜过合同谈判
• 响应变化胜过循环计划

敏捷开发的12 个原则

• 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意
• 即使到了开发的后期，也欢迎改变需求
• 经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好
• 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作
• 项目由有激情的、值得信任的个体合作完成
• 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈
• 工作的软件是首要的进度度量标准
• 敏捷过程提倡平稳的开发节奏；发起人、开发者和用户 应该能够保持一个长期的、恒定的开发速度
• 不断地关注优秀的技术和好的设计可以增强敏捷能力
• 简单化是根本（不做过度设计和预测）
• 最好的构架、需求和设计是来源于自组织的团队
• 每隔一定时间，团队会在如何才能更有效地工作方面进行反思，并对自己的行为进行相应调整

Scrum

Scrum先开发的是对客户具有较高价值的需求，在每个迭代结束后，都会开发完成可交付的产品

术语：

• Sprint（冲刺） 一个小的迭代周期
• Backlog 按照商业价值排序的需求表, backlog意为“积压的工作”
• Burndown chart 燃尽图，记录迭代的进度
• User Story 用户故事，用于描述需求

Scrum敏捷开发的框架

Scrum 角色

Product owner（产品负责人）: 是利益相关方的代表，他的工作重点是产品的业务方面，他负责向团队介绍产品愿景那个。负责给出一份明确的，可度量的，合理的产品backlog，并从业务角度出发对backlog中各项问题按优先级排序。

**Scrum Master：**是整个团队的导师和组织者，他负责提高团队的开发效率，他常提出培训团队的计划，列出障碍 Backlog。Scrum Master 控制着检查和改进 Scrum 的周期，他维护这一团队的正常运行，并与产品负责人一起让利益相关方获得最大化投资回报。他关心的是这些敏捷开发思想是否能够得到利益相关方的理解和支持。

团队

技术负责人

Stakeholder：是参与或受项目活动影响的人

Agile Mentor

特质

团队成员特质：
• 创建产品
• 自组织、自管理
• 跨职能工作
• 专注且集中办公

Scrum Artifacts（可交付成果，工件）

• Product backlog（产品代办列表）：按照业务价值进行优先级排序的功能列表
• Sprint backlog（冲刺待办列表）：product backlog 中具有最高优先级的事项，将在一个 sprint （冲刺）中完成
• Product Increment（产品增量）：交付可用的产品
• Burndown chart（燃尽图）：展示了一个冲刺中每天的剩余工作量

Scrum Ceremonies（仪式）

• sprint planning session（冲刺计划会议）：团队举行的会议，从 product backlog 中选择一组工作在下一次的冲刺中完成。
• Daily Scrum（每日例会）：开发团队举行的一个简短会议，主要分享进度以及遇到的挑战，以及计划一天的工作。
• Sprint reviews（冲刺评审会议）：团队在会议中向利益相关者和 product owner 演示在冲刺过程中已完成的工作。
• Sprint retrospective（冲刺回顾）：根据开发团队的实际表现进行的会议过程，寻找改进产品的方法

Scrum 特点

Scrum 框架

价值路线图

产品愿景（product vision）

创建产品愿景声明的步骤：

1. 设定产品目标：需要考虑产品的关键目标、客户分析、需求、竞争者、主要差异

2. 创建愿景声明的草案：

   

3. 与项目干系人共同确认愿景草案，并修改

4. 确定愿景草案

创建产品路线图

产品路线图是指产品需求的综合提示图，是产品需求的概览，也 是组织开发过程的工具

与创建愿景相比，开发团队参与程度更大

创建步骤：

1. 识别产品需求

2. 整理（功能features）

3. 产品特性的估算和排序

   目的：确定核心需求，识别需求差异

   给需求的价值和工作量打分

   用Fibonacci数列作为分值： 用相对分数

   • 产品路线图的需求：分数在55—144 （主题、特性）
   • 发布计划的需求：分数在13—34 （史诗故事）
   • 冲刺计划的需求：分数在1—8 （用户故事）

4. 决定大致的时间框架

识别产品需求

通过愿景声明，确定需求的主题 ---- 是最高层次的需求

分析需求主题的特性，即拆分为具有若干特性的需求

整理产品特性

实例

• 主题：移动银行应用
• 特性：账户管理、交易管理、客服管理
• 史诗故事：
• 账户信息：登录验证、VIP、个人信息修改
• 交易管理：支付、账单管理
• 客服功能：查询余额、理财、自动付款
• 用户故事：登录验证、VIP、个人信息修改、支付、账单管理、
查询余额、理财、自动付款
• 任务：登录验证：输入用户名/账号，输入密码…

工作量估算方法

1. 绝对估算法： 以人时或人日为估算单位。但是，在计算优先级时，数据不能统一，即用户故事的价值值如 果随意取，则算出来的优先级难于理解。

2. 相对估算法： 也称为故事点(Story Point)估算法：选择一个较小的用户故事，给出故事点数，以此为基准，估算其他用户故事的故事点数。

3. 使用斐波那契数列打分的理由： 故事点估算使用斐波那契数列，用户故事越大，则数字间距越大，工作 量增长得也越快 也可以使用自然数列或其他数值，但是斐波那契数列的值会更符合用户 故事价值和工作量的估算对应，数据不太多，也不太少，容易建立多人 统一的打分标准。即分数与价值（或工作量）相对应。

4. 相对优先级=价值/工作量

决定产品特性的时间框架

• 根据产品特性的相对优先级排序，创建产品路线图
• 优先级高的排在完成时间的前面
• 当确定了产品路线图，可以确定产品发布时间
• 根据产品发布的优先级，确定大致的产品迭代时间增量

例如：

创建 Product Backlog

Product Backlog是指确定了用户故事优先级的用户故事列表，例：

用户故事

用户故事：是指一种对某个产品需求的简单描述（结合需求分析的用例图）

用户故事卡片：

• 标题<名称>
• 作为<用户 或 角色>*
• 我想<采取的行动> *
• 以便<能获得的益处>

注意：

• 发布级别的用户故事个数要求不超过34个故事点
• 冲刺级别的用户故事个数要求不超过8个故事点，每个故事点要分解为多个任务

分割用户故事的原则

• 按照用户故事所支持数据的边界分割大型用户故事（例如导入GBQ文件、Excel等）
• 按照操作边界分割，把大型用户故事分割成独立的建立、读取、更新和删除操作
• 考虑去除横切功能（例如安全处理、日志记录、错误处理等），为用户故事建立两个版本：一个 具备对横切功能的支持，另一个不具备这种支持
• 考虑功能性需求和非功能性需求隔离到不同的用户故事，从而分割大型用户故事（性能）

确保用户故事质量的INVEST方法

1. 独立的
2. 可协商的
3. 有价值的
4. 可估算的
5. 小型的
6. 可测试的

用户故事的描述

• 用户故事的形式很自由，没有什么强制性的语法
• 故事大致可符合这样的形式：“作为【用户的类型】，我希望可以 【先这样做，然后那样做，就应该得到…的结果】以便【业务价值】
• 用户故事的三要素：
  1. 角色（who）：谁要使用这个
  2. 功能（what）：要完成什么功能
  3. 价值（value）：为什么要这么做，这么做能带来什么价值

用户故事与用例的差异

• 用户故事的详细信息可能不会与用例记录在同一极端。
• 用户故事故意遗漏了许多重要细节。用户故事旨在通过在Scrum会议期间提问来引发对话。
• 用户故事用于更频繁地获得反馈的小增量，而不是像用例中那样具有更详细的前期需求规范。

估算用户故事的工具-估算扑克

例如：研发团队用估算扑克估算工作量

如何优化用户故事的估算

• 确定用户故事的规模类别：非常小型、小型、中型、大型、非常大型、史诗故事
• PO评审用户故事类别
• 成员给类别打分
• 成员给用户故事归类

如果有很多用户故事的时候，该怎么办？

使用相似估算，因为其中很多的故事非常相似。

1、确定故事的类型

2、将故事进行分类

3、开发团队评审并调整用户故事的位置

4、产品负责人进行评审

5、如果开发团队与产品负责人的期望估算值相差超过了一个尺寸时，他们会讨论这则用户故事。开发团队最终决定是否调整这则用户故事。

计划发布与冲刺

步骤：

1. 细化需求和估算
2. 创建用户故事
3. 创建Product Backlog
4. 发布计划
5. 冲刺：冲刺计划会议、创建Sprint Backlog、燃尽初始图、 冲刺计划

细化需求和估算

分析需求主题的特性，即拆分为具有若干特性的需求

特性可能包含有一些史诗故事，即包含了若干个单一行为的活动群

用户故事：单一行为的需求，可 以在冲刺中立即实现的活动

任务：将用户故事拆分为任务， 可以分配给团队成员的工作

发布计划

发布：指包含最小可上市的特征集

发布计划：确认团队能够行动的并推出最迫切产品的日期

product owner 确定发布目标和发布日期

发布计划的两项关键活动（团队成员共同完成）：

1、从产品待办列表（Product backlog）中选择优先级高的用户故事

2、制定发布计划：目标、日期

团队所有成员承诺发布计划

冲刺

• 指一次迭代，并提交能够正常工作的产品
• 一次冲刺的工作：
  1. 开始时的冲刺计划
  2. 每日例会
  3. 开发时间–冲刺的主体
  4. 结束时的冲刺评审和冲刺回顾
• 只为当前的冲刺选择用户故事

冲刺中的敏捷角色

冲刺阶段，敏捷角色每天的任务

1. 开发团队
   • 完成可交付的产品
2. 产品负责人
   • 审核产品待办列表和冲刺计划
   • 解决开发中的技术问题
   • 验证每天的测试结果
   • 监督指导持续集成的工作
3. Scrum主管
   • 每日例会
   • 解决遇到的非技术困难，保护开发团队不受外部干扰
   • 保持与stakeholders的良好沟通，建立好的人际关系

冲刺计划会议

• 在本次冲刺的第一天召开冲刺计划会议

• 参加者：product owner、开发团队、scrum 主管、客户

• 主要工作：

  • 制定冲刺目标并选择优先级高的用户故事
  • 创建Sprint backlog，即分解开发任务

• 会议时长;

  • 冲刺为1周：开会2小时
  • 冲刺为2周：开会4小时
  • 冲刺为3周：开会6小时
  • 冲刺为4周：开会8小时

燃尽图

（展示了一个冲刺中每天的剩余工作量）

燃尽图须体现Sprint Backlog完成进展，即围绕Sprint Backlog的任务

燃尽图与开发人员数量、周期、任务数量和时数等有关

燃尽图的时数（纵坐标）不包含冲刺的计划、评审和回顾时间

任务板

• 每个任务做在一个便利贴上，做成一个任务板
• 将任务分为4组：待办；正进行；待验收；已完工
• 用移动便利贴展示冲刺进度，实物变化的视觉更真实
• 将任务板放在醒目的位置上，以便每个人都能容易地看到

冲刺计划示例

创建可交付功能

冲刺中日常工作的目标是以可交付的形式创建产品的可交付功能。

冲刺开发中主要的三个活动：

• 细化

• 开发

• 验证

完成的定义

完成标准

完成标准确保开发团队每一步前进都奠定在坚实的质量基础之上

例如：完成的定义 1.编码完成；2.代码评审完成；3.单元测试Bug数小于三个；4.集成完毕；5.文档工作完毕

敏捷工程实践

结对编程

两位程序员在一台电脑前工作，一个负责敲入代 码，而另外一个实时检查每一行敲入的代码

结对编程的好处

• 有助于提升代码设计质量
• 研究表明结对生产率比两个单人总和低 15%，但缺陷数少 15%，考虑修改缺陷工作量和时间都比初始
  编程大几倍，所以结对编程总体效率更高（source: The Economist）
• 结对编程能够大幅促进团队能力提升和知识传播

持续集成（CI）

持续集成（CI）是一项软件开发实践，其中团队的成员经常集成他们的工作，通常每人每天至少集成一次，每次集成通过自动化构建完成。

持续集成提供产品质量的快速反馈，保证随时拥有可工作的软件

测试驱动开发（TDD）

• TDD以测试作为编程的中心，要求在编写任何代码之前，首先编写定义代码功能的测试用例，编写的代码要通过用例，并不断进行重构优化
• TDD要求测试可以完全自动化运行

测试驱动开发保证代码整洁可用（Clean code that works）

重构

是改善既有代码的设计，由Martin Fowler提出

重构可以弥补设计的不足

简单设计>>测试用例>>实现再说>>（重构>>回归测试）

冲刺中Scrum 主管的工作–识别障碍

障碍：基本上，任何阻止团队正常工作的，都可称之为障碍

• 每日例会可以汇报障碍
• 可能的障碍，如：
  1. 无法访问信息系统
  2. 所需要的信息不能及时提供或者提供的不正确，如界面规格或者其它软件模块不到位或不正确
  3. 开发环境或者原型系统出现问题
  4. 其他的任务分配：培训，售前支持
  5. 缺乏必要的信息或者相应的知识
• 对于团队提出的各项障碍，Scrum主管要以列表形式进行记录

谁来清除

• 所有人
• scrum 主管负责确定是否已经清除，不一定亲自清除

展示工作和集中反馈

冲刺结束的两个会议

• 冲刺评审：由产品负责人向用户代表和干系人展示用户故事**（展示工作、收集反馈）**
• 冲刺回顾：开发团队、产品负责人、scrum主管一起回顾本次冲刺 （评审冲刺 、改进流程）

冲刺评审

• 通过演示可交付的功能可以确认项目的进度，具有真实性
• 能尽早的获得用户对产品的反馈，使产品更加贴近客户需求

冲刺回顾

• 激励团队成员
• 帮助团队挖掘优秀经验并继承
• 避免团队犯重复的错误
• 营造团队自主改进的氛围

冲刺结束—两类冲刺

• 产品冲刺：若本次冲刺不产生发布产品，则冲刺结束，准备进入下一次冲刺
• 发布冲刺：若本次冲刺产生发布产品，则需完成发布冲刺的活动

发布准备

• 准备部署产品 – 发布冲刺
• 让组织为产品发布做好准备
• 让市场为产品发布做好准备

内部准备

• 除了产品生产部门，企业的其他组织部门要为产品发布做好准备
• 产品负责人和Scrum主管要准备一个发布冲刺待办列表
• 识别和确定完成发布活动的干系人
• 为发布产品的评审会准备正式的PPT，解释产品的背景、目 标、价值，确保干系人充分理解产品和产品客户
• 评审会应该由市场部或运营部主持，产品负责人只是负责冲刺发布任务的汇报

外部准备

• 营销支持—确定产品推广、品牌营销的时机
• 客户测试—运营和市场要把客户反馈转化为产品推广的依据
• 营销物料—产品推广文案、新闻发布会、产品包装等
• 支持渠道—所有类型客户到技术支持部的渠道要畅通

在企业中实施敏捷

重要的： 在企业的级别上，统筹组织，系统地制定敏捷实施方案软件开发项目组是逐步地实施敏捷管理方法

你到了企业：

可以成为敏捷导师，帮助企业建立敏捷实施方案

或快速地熟悉企业目前的敏捷实施方案，参与到敏捷项目管理团队

步骤：

1. 制定实施策略
2. 构建意识，培养热情
3. 实施团队转型
4. 确定实验的项目
5. 确定成功的标准：时间、成本、质量、风险、变更、交付的成果
6. 培训计划与实施
7. 总结和改进
8. 推广

实现敏捷转型的系统工程

敏捷转型覆盖7个方面：实践、组织、过程、绩效考核、管控、文化、技术和业务调整

敏捷在敏捷转型不同阶段，敏捷转型框架的7个方面引入的优先级不一 样，初期以实践为主

实践 (Practices)：团队根据自身情况选择合适的实践应用

组织(Organization)：组织适应产品业务架构、产品管理办公室(PMO)、测试、产品管理等

过程(Process)：流程、敏捷项目管理策略等，由企业管理者和敏捷导师共同制定

绩效度量（Performance)：业务价值、质量、过程改进

管理监控(Governance)：包括管控点设置，如投资评审和风险评估等

文化理念(Culture)：从命令控制式的管理文化转向领导协作的文化，加强透明性和实际性

技术和业务调整(Alignment)：业务策略、IT策略、企业/产品架构、产品组合管理、合同、能力规划等调整

企业中如何组织实施敏捷项目管理

• 组织与个人的承诺
• 选择正确的项目团队成员：
• PO：业务能力强，做事果断；
• Scrum主管：有影响力，善于沟通；
• 开发成员：愿意合作的
• 创建合适敏捷的环境：团队要整齐，要及时调整
• 持续地支持敏捷：选择合适的项目，拥有一位敏捷导师

其他敏捷开发方法

XP

要求客户与开 发人员最好以side-by-side的方式一起工作

精益软件开发方法

七条原则：

1. 消除浪费
2. 增强学习
3. 尽量延迟决定
4. 尽快发布
5. 下放权力
6. 嵌入质量
7. 全局优化

对应有精益用户体验

自适应软件开发方法（ASD）

ASD是一种方法论，没有很多具体的实践做法，主要为ASD的重要性提供根本的基础。

是从更高的组织和管理层次阐述开发方法为什么要具备适应性。

特性驱动开发方法（FDD）

• 是一套针对中小型软件开发项目的开发模式
• 是一个模型驱动的快速迭代开发过程（从需求特征的模型开始）
• 强调简化、实用、 易于被开发团队接受的理念
• 适用于需求经常变动的项目

水晶族方法

具有灵活、执行不严格、全透明的工作方式，一般团队人数少于6人

是个族系列，对不同类型的项目可以采用不同的实践方法

水晶族系列没有XP方法的效率高，但有适合的项目和人员接受并遵循该方法

水晶族系列方法的七大体系特征：

1. 经常交付
2. 反思改进
3. 渗透式交流
4. 个人安全
5. 焦点
6. 与专家用户建立方便的联系
7. 配有自动测试、配置管理和经常集成功能的技术环境

动态系统开发方法

倡导以业务为核心，快速而有效地进行系统开发

适用于系统升级的二次开发

看成一种控制框架，其重点在于快速交付并补充如何应用这些控制的指导原则

敏捷统一过程

由Craig Larman提出，是轻量型RUP，是过程的框架，可以包容许多不同类型的过程

以敏捷型方式使用RUP，其观点是：目前如此众多敏捷型方法，都不过是在接受被视为 RUP 的主流OO开发方法而已

敏捷度量

敏捷三角形

• 项目是否成功取决于主观的判断
• 不能度量就不能管理

Value度量的组成

Scrum Of Scrums

• 把Scrum扩展到大型项目团队的一个实践
• Scrum of Scrums可以是多层次的
• 是跨团队的沟通与交流
• 由各个Scrum团队的代表参加Scrum of
  Scrums会议
• 会议也采用固定的频率，如每周2次
• 会议时长也控制在15-30分钟
• 会议中提出的问题要及时处理

！敏捷项目管理的十大关键测量指标

敏捷项目管理的十大好处

额外的一些东西

经验性方式的三大支柱

可见性、检查及适应

全天的工作

1. 计划每天的工作

   每日例会（标注已完成的任务）、发现问题和难点、计划当天的工作

   目的：沟通交流，不是解决问题！有问题可以在另外的专题会上解决

   由scrum master主持，每位成员轮流回答以下问题

   • 昨天我完成了什么工作？
   • 今天我打算做什么？
   • 我在工作中遇到了什么困难？

2. 跟踪每天的进展，工具：燃尽图、任务板

3. 开发并测试每天的工作

4. 结束一天的工作

结束一天的工作

• 更新sprint backlog的任务状态
• 根据燃尽图的剩余工作量，调整：
• 任务（移除/增加）
• 人员安排（增加开发团队人员/任务再分配）
• 时间安排（是否需要加班?）
• 更新燃尽图（可以用两个燃尽图：工作人时数/任务点数）
• 产品负责人更新任务板便利贴的位置，如：待验收->已完成
• Scrum主管检查燃尽图和Sprint backlog，及时发现可能的风险

小结

问题

product backlog

• 是 product owner 编写的需求列表
• 优先级可能会变化
• 列表内容可能会变化