一、Scrum框架的3355

不要求完全能背，重要的是理解。

Scrum框架有3个角色，3个工件，5个事件，5个价值观，简称3355。

3个角色：

产品负责人PO(Product Onwer)

开发团队 （Develop Team）

敏捷教练（Scrum Master）

3个工件：

产品待办列表（Product Backlog）

迭代冲刺列表（SprintBacklog）

产品增量（Increment）

5个事件：

Sprint（Sprint本身是一个事件，包括了如下4个事件）

Sprint计划会议（Sprint Planning Meeting）

每日站会（Daily Scrum Meeting）

Sprint评审会议（Sprint Review Meeting）

Sprint回顾会议（Sprint Retrospective Meeting）

5个价值观：

承诺 – 愿意对目标做出承诺

专注– 把你的心思和能力都用到你承诺的工作上去

开放– Scrum 把项目中的一切开放给每个人看

尊重– 每个人都有他独特的背景和经验

勇气– 有勇气做出承诺，履行承诺，接受别人的尊重

总之，大脑里面一定记住Scrum框架图，及3355在图中的位置。

51CTO项目管理：PMP试题+电子版PMBOK+高效备考课程+PMP必备教材+项目管理必备工具zhuanlan.zhihu.com/p/458474116

二、《敏捷宣言》四大价值观，十二大原则：

不要求完全能背，选项给你之后，能分辨出来就行。

4大价值观：

个体和互动 高于流程和工具

工作的软件 高于详尽的文档

客户合作 高于合同谈判

响应变化 高于遵循计划

12大原则：

我们的最高目标是，通过尽早持续交付有价值的软件来满足客户的需求。

欢迎对需求提出变更，即使在项目开发后期也不例外。敏捷过程要善于利用需求变更，帮助客户获得竞争优势

要经常交付可用的软件，周期从几周到几个月不等，且越短越好。

项目实施过程中，业务人员与开发人员必须始终通力协作。

要善于激的项目人员，给予他们所需的环境和支持，并相信他们能够完成任务

无论是对开发团队还是团队内部，信息传达最有效的方法都是面对面的交谈

可用的软件是衡量进度的首要衡量标准。

敏捷过程提信可持续的开发。项目发起人、 开发人员和用户应该都能够始终保持持步调稳定。

对技术的精益求精以及对设计的不断完善将提高敏捷性。

简洁，即尽最大可能减少不必要的工作，这是一门艺术。

最佳的架构、需求和设计将出自于自组织团队。

团队要定期反省怎样做才能更有效，并相应地调整团队的行为。

三、敏捷项目章程

敏捷项目也是有项目章程的。

项目章程是重要的管理文件，需要所有干系人的参与。

虽然专家建议章程应不超过一页，但是因为所有的干系人必须参与进来并且达成一致意见，所以创建项目章程是非常具有挑战性的。

敏捷项目章程中应包含3个关键信息：愿景，任务和成功标准。

四、敏捷项目范围管理

敏捷项目管理中的范围管理，大概是这样：每次迭代开始之前，由PO和团队开一个迭代规划会，从产品待办列表至上而下切出来优先级最高的内容，作为当前迭代的内容。确定之后，需求锁定。

每个迭代的版本要实现的需求，是由PO来决定。决策的依据是投资回报率，优先做最有价值的需求。

五、敏捷项目进度管理

敏捷中，故事地图本质上等同于项目计划，它将用户故事，产品特性按逻辑主题排列，作为开发的计划。

敏捷项目一般是采用看板来展示进度，用看板作为信息发射源。如果团队成员要了解进度，看公开出来的看板即可。

六、敏捷项目成本管理

敏捷中，成本管理很少，几乎没有。

记得有一个敏捷估算，估算故事点的大小。这种一般都是轻量级的估算，不会估算的特别精细，因为敏捷的需求变化很快，没有必要花太多时间进行精细化估算。

七、敏捷项目质量管理

敏捷项目中，质量管理主要体现在每日站会，迭代产品评审会和回顾反思会。

1）团队每天开每日站会，可以暴露问题，防止成员摸鱼，Scrum Master可以及时协助团队处理障碍，保障项目质量和进度。

2）迭代评审会，由PO和团队一起开，主要审查做出来的产品是否满足客户的需要，如果不符合，将由PO修改用户故事，并放到产品待办列表，重新排需求优先级，纳入下一个迭代。

3）回顾反思会，团队总结经验教训，哪些做的好的，哪些做的不好的，识别出问题，在后续的迭代中加以优化改进。

八、敏捷项目资源管理

基本没啥，team是固定的，一般3到9人。

九、敏捷项目风险管理

基本没啥，有不满足要求的可交付成果，纳入未完项，由PO重新排优先级，下一个版本迭代。

十：敏捷项目沟通/相关方管理/采购管理

没啥。

十一：精益,敏捷相关的名词/概念

1、WIP 在制品限制

work in process，是指材料或部分已开始生产但是还未完成的产品，也就是半成品。

2、看板 ，kanban ,kanken，板

看板是丰田公司在19世纪40-50年代开发的一个及时（JIT）生产调度系统。它是通过卡片或者信号来请求（需求信号）其他独立系统中（供应方）生产流程的必须部分，以此控制和减少库存。看板已被应用于敏捷中，来帮助控制工作流。他可以帮助团队意识到他们是如何工作以及下一步要做什么，让团队形成自我指挥。

3、XP极限编程

极限编程(XP)是一项以编程人员为中心的敏捷架构，注重小而迅速的发布。XP极限编程强调以下原则：结对编程 可持续速度 不断自动测试 有效沟通 简单性 反馈 勇气 集体所有 持续集成 激励工作 共享工作空间 现场客户代表 使用隐喻说明概念。

XP极限编程用语中“caves和common”指的是，为团队成员创造的两个分区。common是一个公共的空间，在此常有渗透沟通和协作。caves是一个私人的交易预留空间，需要一个孤立且安静的环境。

4、计划扑克

计划扑克是基于宽带德尔菲估算技能、是以共识为基础的工作量估算技能。有时候也称为敏捷扑克，往往在故事点和开发用户故事中用来估算相对工作量。

在计划扑克会议中，每一位成员各持有一副相同价值的计划扑克卡片。

计划扑克会议按如下的步骤运行：

1）一名调停人，主持会议，不参与估算。

2）产品负责人对用户故事做概述，并回答开发者提出的澄清问题，往往产品负责人不参与投票。

3）每一位成员抽取一张卡片来估算工作量。

4）每人抽取一张卡片后，同时将他们的卡片翻转，

5）持高和低估算的成员各有一次辩护机会。

6）达成共识前，不断重复以上流程。

5、用户故事：

用户故事：User Strory，它是这样来描述需求的：身为某一个角色，为了什么价值，需要什么功能。

用户故事三要素：角色，动机，价值。

举例：作为一个60后的微信用户，为了高效地完成信息交流，需要一个语音聊天的功能。这就是用户故事来描述用户需求的方法。

用户故事开发时长：开发一个用户故事的理想持续时长是2-5天。

用户故事3C：卡片card，对话communication，确认confirm. (罗恩•杰弗里斯提出的)

6、亲和估算

亲和估算是预测工作量的一个方法，基本的亲和估算模式涉及从小到大范围测量用户故事。这个范围可以是斐波那契数列或者T-shirt尺码，常常贴在大型会议室墙上。然后参与者在估算时可将他们的用户故事贴到这面墙上。

7、优先级排序技术 MoScow

MoSCoW技术通常用在敏捷项目中，主要用来对用户故事进行优先级排列：

M-must have必须有；//完成业务需要/价值所必须的功能，合规，安全等，没有要丢命。

S-should have应该有；//不涉及核心功能，但是严重影响用户体验，没有要丢钱。

C-could have可能有；// 影响不大，忽略也没有问题，没有可能会丢脸

W-won't have this time这次不会有；// 团队决定本次迭代不予实现，丢来没事。

8、价值流程图：

价值流程图就是用来寻找增值和非增值的工作，从而识别关键改进区域。价值流程图是敏捷采用的精益生产分析技能，用于对形成客户产品或服务的原料和信息（即价值）的流动进行分析。

51CTO项目管理：PMP试题+电子版PMBOK+高效备考课程+PMP必备教材+项目管理必备工具zhuanlan.zhihu.com/p/458474116

执行价值流程图大致包括5个步骤：

1）确认产品，客户和范围（即流程的始末）。

2）确认流程步骤，延时和信息需求。估算流程步骤的持续时长和前置期持续时长（lead time duration）。前置期是指在发生前一项流程或者事件需等待的时长。

3）分析价值流程图来确认浪费存在的地方（比如前置期）和流程可完善的地方（流程时间通常认为是价值增加时间，但是应尽量减少整个流程的时间，由此来缩短向客户交付价值流的时间）。

4）通过分析，总结出一份展示价值流应努力达到的前景或者目标的未来价值流程图。

5）通过流程完善活动（即完善）或者其他方法来达到目标的一些工作。

9、解聚

将史诗故事或大型故事分解成小型用户故事。解聚类似于传统项目的分解。

（史诗是大型故事的意思，实现的时候，要进行分解，分解的过程就是解聚）

10、迭代速度的计算

题目：在上一次迭代中，Paula和她的敏捷团队完成了10个各值1个点的用户故事，2个各值5个点用户故事，还有1个值5个点的用户故事即将完成。请问该团队在之前的迭代中的速度是<20>。

10×1+2×5=20.部分完成故事的故事点不包括在速度指标里。

11、教练指导

敏捷里面提供教练式指导，让富有动力的团队运作更流畅，生产效率高，表现超越期望值。

可提高动力的简单步骤包括：

1）共度黄金时间，团队成员可在个人层面上了解他人以此营造轻松氛围，

2）提供反馈，指导和训练，赞扬和感谢团队成员的出色工作，同时为技能和能力提升提供指导和训练，

3）授权，授权团队成员作关键决策，在此期间，建立信任并显示领导对团队能力的信任。

12、燃尽图

项目的燃尽图是一个常用来展示迭代进度的信息发射源。它记录两项序列，横轴是时间，纵轴是剩余的实际工作和剩余的理想/预估的工作。

13、燃起图

与燃尽图相反，它的横轴是时间，纵轴是已完成的实际工作和剩余的理想/预估的工作。

14、累积流量图

展示用户故事的未完项、过程中的工作及完成功能与时间关系的一种图表，是信息发射源的组成部分。

15、概念性和感知性

精益软件开发架构中存在的两种完整性类型有：概念性的和感知性的。

概念上的完整性是由开发者决定的，如果产品集成良好和功能详细，那么完整性会非常高。

感知上的完整性是由客户观察得出的，如果客户最初对产品满意，然后产品满足需求，那么完整性会很高。

16、FDD

FDD （Feature-Driven Development，特性驱动开发）由Peter Coad、Jeff de Luca 、Eric Lefebvre共同开发，是一套针对中小型软件开发项目的开发模式。此外，FDD是一个模型驱动的快速迭代开发过程，它强调的是简化、实用、 易于被开发团队接受，适用于需求经常变动的项目。

17.Crystal Methods

Crystal Methods（水晶方法族）由Alistair Cockburn在20实际90年代末提出。之所以是个系列，是因为他相信不同类型的项目需要不同的方法。虽然水晶系列不如XP那样的产出效率，但会有更多的人能够接受并遵循它。

18.DSDM

DSDM（动态系统开发方法）是众多敏捷开发方法中的一种，它倡导以业务为核心，快速而有效地进行系统开发。实践证明DSDM是成功的敏捷开发方法之一。在英国，由于其在各种规模的软件组织中的成功，它已成为应用最为广泛的快速应用开发方法。

DSDM不但遵循了敏捷方法的原理，而且也适合那些成熟的传统开发方法有坚实基础的软件组织。

19.ASD

ASD（Adaptive Software Development，自适应软件开发）由Jim Highsmith在1999年正式提出。ASD强调开发方法的适应性（Adaptive），这一思想来源于复杂系统的混沌理论。ASD不象其他方法那样 有很多具体的实践做法，它更侧重为ASD的重要性提供最根本的基础，并从更高的组织和管理层次来阐述开发方法为什么要具备适应性。

20.轻量型RUP

RUP其实是个过程的框架，它可以包容许多不同类型的过程， Craig Larman 极力主张以敏捷型方式来使用RUP。

他的观点是:目前如此众多的努力以推进敏捷型方法，只不过是在接受能被视为RUP 的主流OO开发方法而已。