PMI-ACP 思维导图模板_ProcessOn思维导图、流程图

敏捷联盟宣言（核心价值观）

个体和交互

高于

流程和工具

可用的软件

高于

详尽的文档

客户合作

高于

合同谈判

响应变化

高于

遵循计划

十二个原则

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

持续尽早向客户交付软件

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

拥抱变化

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

频繁的发布可用软件

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

客户与开发在一起

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

以人为本

无论是对团队内还是团队间，最有效的沟通方法是面对面的交谈。

7%语调+38%声音+55%肢体语言

交互式沟通

可用的软件是衡量进度的主要指标。

衡量开发过程的标准是交付可用的软件

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

稳定的开发速度

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

敏捷高效的设计

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

简单有效，效能为上

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

重视teamwork

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

积极调整

项目开发生命周期

预测型生命周期

定义：传统方法，提前进行大量计划工作，然后一次性执行。执行是一个连续的过程。

特点：（瀑布、统一交付）

需求：固定

活动：完整项目一次性执行

交付：一次性交付

目标：管理成本

适用场景：

充分了解拟交付产品

有厚实的行业实践基础

整批一次性交付产品有利于相关方

迭代型生命周期

定义：允许对未完成的工作进行反馈，从而改进和修改相应工作任务。

特点：（重复、循环）

需求：动态

活动：重复执行直到取得正确成果

交付：一次性交付

目标：正确的结果

适用场景：

管理技术风险

不断演化需求

增量型生命周期

定义：向客户提供各个已完成的交付成果，从而可以立即使用。

特点：（渐进、持续交付）

需求：动态

活动：每个增量执行一次

交付：多次交付

目标：速度

适用场景：

管理日常风险

应对小的需求变更，难以处理影响到架构的变更

敏捷型生命周期

定义：敏捷方法，既有迭代，也有增量，便于完善工作，频繁交付。

特点（小步迭代、快速试错）：

需求：动态

活动：重复执行直到取得正确成果

交付：多次交付

目标：得到客户反馈持续交付价值

适用场景：

根据Stacey矩阵分析，需求不确定但技术确定或需求确定但技术不确定的情况下使用

出现繁杂问题，需要小步迭代，快速验证试错

混合型生命周期

定义：预测型+敏捷型

使用场景：

传统到敏捷转型过渡期

使用每种生命周期的优点

敏捷框架和方法

XP

编程方法

结对编程

简单设计

重构

代码更加简洁已复用

测试驱动开发（TDD）

单元测试

减少bug

快速定位bug

提高代码质量

减少调试时间

精益开发

验收测试驱动开发（ATTD）

对业务文档统一

自然语言描述

可以运用的需求和用例

活着的文档

探索性测试

系统级测试

单元测试

集成测试

冒烟测试

回归测试

自动化测试

小组实践

持续集成

减少风险

减少重复过程

产生可部署的软件

使项目更加透明

建立项目信心

代码集体所有

编码标准

隐喻：讲故事的方式

稳定高速

知识共享

交付和管理

完整的团队

现场客户

小规模发布

计划游戏

Crystal 水晶方法

最佳实践

项目章程

建设团队

探索360

为团队制定规范

建立初试计划

交付迭代

渗透式沟通

项目总结

反思提高研讨会

FDD 特征驱动开发

DSDM 动态系统开发方法

AUP 敏捷统一过程

精益方法（严格意义上不是一种敏捷方法）

消除浪费

过度生产

不合格产品

待工

过度流程

库存

再作业

迁移

SCRUM

3355模型

3个角色

产品负责人（product owner）

决定产品发布的内容及发布日期

定义所有产品功能

根据市场的变化对需要开发的功能排列优先排序

合理的调整产品功能和迭代顺序

对产品投入产出负责（ROI）

认同或者拒绝迭代的交付成果

ScrumMaster

对项目的直接管理

领导团队完成SCRUM实践以及体现其价值

排除团队遇到的困难

确保团队的胜任其工作，并保持高效的生产率

使得团队紧密合作，使得团队个人有多方面职能的工作能力

保护团队不受外来无端的干扰与影响

DevTeam

经典团队5-9人

团队成员都是多面手/跨职能（开发人员、测试人员、用户设计师等）

团队成员都全职工作

团队自组织和自管理

团队关系在一个迭代内是固定的，个人的职能可以在新的迭代开始时调整

3个工件

产品待办事项列表 (ProductBacklog)

冲刺待办事项列表 (SprintBacklog)

产品增量 (ProductIncrement)

5个仪式

冲刺规划会议 (SpringtPlan)

冲刺评审会议 (SprintReview)

冲刺回顾会议 (SprintRetrospective)

每日站立会议 (DailyScrumMeeting)

冲刺 (Sprint)

5个价值观

承诺

专注

公开

尊重

勇气

典型场景

PO和开发团队对产品业务目标形成共识

PO建立和维护产品待办事项列表（需求会不断新增和改变）并进行优先级排序

PO每轮迭代前，Review产品待办事项列表，并筛选高优先级的用户故事进入本轮迭代开发

开发团队细化本轮迭代的用户故事，并按照用户故事的优先级依次在本轮迭代完成

开发团队每日站立会议、特性开发、持续集成、使开发进度真正透明

PO对每轮迭代（2-4周）交付的可工作软件进行现场验收并反馈

回到第三步，开始下一个迭代

Kanban 看板

6个核心实践

可视化的工作流

可视化价值

可视化价值流动

可视化问题和阻塞因素

可视化队列、瓶颈

可视化流转规则

限制在制品WIP (work in progress)

度量和管理流动

关注平均完成时间

速度：对每次迭代完成的用户故事或故事点的衡量

生产量：在一个特定时间内团队能够开放的特征数量

周期时间 (Cycletime) ：处理一个工作项目所需时间。团队通过衡量周期时间发现瓶颈和延迟问题（开发-发布）

前置时间 (Leadtime) ：交付一个项目花费的总时间，从项目添加到看板直至完成。衡量交货时间可了解外部依赖关系

响应时间 (Responsetime) ：Leadtime 减 Cycletime

显示化规则

在协作及实验中改进

建立反馈环

3个工具

看板墙

累积流量图

利特尔法则

平均吞吐量 = WIP 在制品
Delivery Rate ——————————
Lead Time 前置时间

建立敏捷团队