敏捷开发、PMP、ACP基础知识

什么叫敏捷

敏捷是许多方法的一个总称，敏捷是一种思想,一种态度,
倡导简单设计,快速交付,价值导向,响应变化。

一、敏捷的由来

2001 年，17位软件开发领域的领军人物在Utah的Snowbird会面，分享他们的想法，这些软件业思想领袖共同发表《敏捷宣言》，正式宣告敏捷开发运动 的 开始。

二、敏捷宣言

个体和交互胜过流程和工具

• 重视个体及团队的力量
• 坚持以人为本，倡导共同参与
• 流程和工具的局限性，不能适应所有团队

可工作的软件胜过详尽的文档

• 文档够用就好（并非否定文档的作用，强调过犹不及）
• 避免镀金

客户合作胜过合同谈判

• 客户不是敌人，我们的价值是为客户创造价值，营造合作双赢的局面

响应变化胜过遵循计划

• 优先实现价值大的需求
• 重视客户的实际利益

三、敏捷十二项原则

1）我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
2）欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
3）经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4）业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5）激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标

6）不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
7)可工作的软件是进度的首要度量标准。
8)敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9)坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10)以简洁为本，它是极力减少不必要工作量的艺术。
11)最好的架构、需求和设计出自自组织团队。
12)团队定期地反思如何能提高成效，并依此调整自身的举止表现。

四、敏捷和传统(瀑布)开发区别

瀑布三大开发特点

• 预测
• 文档驱动
• 过程控制

敏捷三大开发特点

• 透明
• 检查
• 适应

五、适用范围（项目开发模式选型）

需求、技术明确采用传统项目管理模式
需求、技术都不确定的情况下采用敏捷，快速交付、快速试错、避免浪费

六、敏捷家族成员

1.png

6.1精益Lean

是衍生自丰田生产管理方式

• 基于以下其七种原则的敏捷方法论，消除浪费、强化学习、尽可能晚决策、尽可能快交付、授权团队、构建完整性和全盘检视

6.2看板

看板分为物理看板和在线看板。看板的初始目的在于可视化工作，让每个人看到所有工作项的进展和相应的优先级，进一步提高工作透明度，并且在面临新工作时帮助排定优先级。

6.3 FDD

• 特征驱动开发

6.4 DSDM

• 动态系统开发方法

6.5 ATDD

• 验收测试驱动开发

6.6 TDD test- driven-development

测试驱动开发

七、敏捷团队组成（Scrum）

常规意义下敏捷只存在以下三种角色。

7.1 PO Product Owner

• 确定产品的功能
• 决定发布日期和内容
• 为产品的ROI负责投资回报率
• 排定功能优先级
• 接收或者拒绝开发成果
• 维护PBI
• 听取各方的信息和建议
• 从用户的角度及公司业务的角度思考问题

担任角色：业务方代表/客户、产品经理、市场人员、项目经理

7.2 SM Scrum Master

• 组织推进Scrum活动
• 指导团队成员
• 和PO梳理PBI
• 清扫障碍

7.3 ST Scrum Team

• 设计人员
• 开发人员
• 测试人员
• 其他

八、用户故事 User Story

8.1 故事三要素：

角色 活动 价值
模板：
英文：As a , I want to , so that
中文：作为一个 <角色>, 我想要 <活动>, 以便于 <价值>
用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述

8.2 3C原则

卡片(Card): 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。
交谈(Conversation): 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
确认(Confirmation): 通过验收测试确认用户故事被正确完成。

8.3 用户故事的六个特性

简称INVEST原则：独立性(Independent) 、可协商性(Negotiable)、有价值(Valuable)、可估算性(Estimable) 、短小(Small)、可测试性(Testable)

• 独立性(Independent) 要尽可能的让一个用戶故事独立于其他的 用戶故事。用戶故事之间的依赖使得制定计划，确定优先级，工 作量估算都变得很困难。通常我们可以通过组合用戶故事和分解 用戶故事来减少依赖性。
• 可协商性(Negotiable) 一个用戶故事的内容要是可以协商的，用 戶故事不是合同。一个用戶故事卡片上只是对用戶故事的一个简 短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一 个用戶故事卡带有了太多的细节，实际上限制了和用戶的沟通。
• 有价值(Valuable) 每个故事必须对客戶具有价值(无论是用戶还 是购买方)。一个让用戶故事有价值的好方法是让客戶来写下它 们。一旦一个客戶意识到这是一个用戶故事并不是一个契约而且 可以进行协商的时候，他们将非常乐意写下故事。
• 可估算性(Estimable) 开发团队需要去估计一个用戶故事以便确 定优先级，工作量，安排计划。但是让开发者难以估计故事的问 题来自:对于领域知识的缺乏(这种情况下需要更多的沟通)， 或者故事太大了(这时需要把故事切分成小些的)。
• 短小(Small) 一个好的故事在工作量上要尽量短小，最好不要超 过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint 中能够完成。用戶故事越大，在安排计划，工作量估算等方面的 ⻛险就会越大。
• 可测试性(Testable) 一个用戶故事要是可以测试的，以便于确认 它是可以完成的。如果一个用戶故事不能够测试，那么你就无法 知道它什么时候可以完成。一个不可测试的用戶故事例子:软件 应该是易于使用的。

九、敏捷的会议

原则一 所有会议都要准时开始、准时结束 。
原则一 展开讨论时会议的推进人必须在场，他不能参与到具体讨论中， 但是他需要-注意讨论进程，如果讨论参与者失去重点，他还要将讨论带回正轨。
原则三 敏捷不提倡加班。

9.1 迭代计划会 Sprint Planning Metting

参与人：整个团队
时长：迭代周期（每周两小时）如一个迭代为两周：会议为4小时
输入：PB（产品代办列表）
第一部分：PO讲解排好优先级的需求
第二部分：团队规划迭代选取内容
输出：SB(迭代代办列表)、各个故事的验收测试用例

具体流程：

1. PO依次展示PB中的故事，选择最小的故事作为计量单位：1个故事点
2. 每展示一个团队就对该故事进行估算(用计划扑克或猜拳游戏等 方式)并记录平均故事点数
3. 如果其中两个人的估算点数超过两倍则分别说明原因，然后重新 估算
4. 如果某个故事过大应将其划分为较小的故事然后进行估算

讨论过程中应该包含以下内容
1）团队依次讨论PB中的故事2） 找出验收条件 3） 找出非功能性需求(性能、安全......) 4） 确定每个故事的验收测试用例 5） 确定每个故事完成的定义

5. SM向团队正式提问“是否能在本Sprint周期内完成该故 事”，如果是则放入本次 SB 中
6. 根据团队能力，选取故事放入SB
7. 确定本次Sprint要达成的目标

注意事项：
△ 只有团队能估算 PB 中的故事，PO 不参与估算
△ 上一个 Sprint 遗留下来的故事需要重新估算
△ 不要讨论技术细节

9.2 站立会 Daily Scrum Meeting

每日站立会
参与人：SM及团队（其他人员可参与，但不能讲话）
时长：15分钟
输入：昨天做了什么？今天计划做什么？我遇到了什么困难？
输出：看板

注意事项：

• △ SM 站在圈外，不要提问题、移动任务卡或更新燃尽图，团队不是向 SM 汇报
• △ 不要讨论技术细节问题，可以会后单独讨论
• △ 不要在没有准备的情况下参会
• △ 进行中的任务不要过多

9.3 评审会 Sprint Review Meeting

评审会
参与人：所有利益相关方
时长：迭代周期（每周一小时）如一个迭代为两周：会议为2小时
输入：待评审功能
输出：评审结果，用户代表及各方的反馈

注意事项：
只演示完成了的功能

9.4 回顾会 Sprint Retrospective Meeting

回顾会
参与人：SM及团队
时长：迭代周期（每周一小时）如一个迭代为两周：会议为2小时
输入：过程数据累积
输出：改进待办事项列表

注意事项：
建议每次迭代改进排列优先级，且一个迭代中不宜改进项过多
会议开场需要营造开放的环境，让大家放下包袱，大胆说话。

十、敏捷的常用图表

10.1 燃尽图

2.png

关注点：
灰色柱子为周末
剩余的工作量（红线）应该是平稳下滑的，完成的工作（绿色）应该是平稳上升。
异常：突然的上升，如红圈处为临时增加了工作

10.2 速度图

3.png

查看每个迭代预估和完成的能力
绿色为实际完成任务耗时，灰色为预估。
正常情况下应为：随着时间流逝，版本迭代，逐步的绿色契合灰色。

10.3 控制图

4.png

绿色圆圈代表：问题
绿点代表：问题的集合
红色线为平均完成耗时，蓝色线为移动完成耗时
浅蓝色背景：标准方差

异常：偏离红绿线越远的任务：完成耗时越大
可能导致原因：1.任务预估不足； 2.开发人员疏漏，没有及时更改任务状态

看点：
1、平均线越低越好
2、标准方差的范围越小越好，并波动较小
3、平均移动线持续性的向下

十一、 团队发展的五个阶段

• 形成期
• 振荡期
• 规范期
• 成熟期
• 解散

十二、团队冲突的5个等级

• 解决问题
• 不同意
• 竞争
• 讨伐

十三、倾听的三个阶段

• 听到对方的言语，但从自身的角度解读
• 站在对方的角度思考，具备同理心，理解对方的情绪、经验和想法
• 在第二条的基础上全方位、高知觉的了解对党，包括身体细节和环境细节

十四、XP（极限编程）部分最佳实践

• 结对编程
• 测试驱动开发
• 持续集成
• 集体代码所有权

十五、极限编程的五个价值观

• 沟通
• 简单
• 反馈
• 勇气
• 尊重

十六、敏捷三重反馈机制

• 站立会
• sprint 评审会
• sprint回顾会

十七、敏捷的5个核心价值观

• 承诺
• 专注
• 开放
• 尊重
• 勇气

十八、项目管理三角

• 成本
• 时间
• 范围

十九、敏捷项目流程图

5.png

敏捷之路一 概念的熟悉
敏捷之路二 工具的使用
敏捷开发、PMP、ACP基础知识
敏捷之路三 ACP考试重点