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

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

个体与交互

重于

过程和工具

可用的软件

重于

完备的文档

客户协作

重于

合同谈判

响应变化

重于

遵循计划

十二个原则

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

持续尽早向客户交付软件

欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势

拥抱变化

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

频繁的发布可用软件

项目过程中，业务人员与开发人员必须在一起工作

客户和开发一起

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

以人为本

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

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

面对面交谈

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

衡量开发过程的手段是可用的软件

敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度

稳定的开发速度

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

敏捷高效的设计

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

简单有效

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

重视teamwork

团队要定期反省如何能够做到更有效，并相应地调整团队的行为

积极调整

项目开发生命周期

预测型生命周期

定义：完全计划驱动的生命周期，在项目前期确定项目范围及交付时间和成本，瀑布模型

适用场景：

充分了解拟交付产品

有厚实的行业实践基础

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

迭代型生命周期

定义：将项目分成和多个冲刺

适用场景：

管理技术风险

不断演化需求

增量型生命周期

定义：将产品分成多个模块，每次交付其中的一个模块

适用场景：

管理日常风险

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

混合型生命周期

定义：预测型+适应型

适用场景：

传统到敏捷转型过度期

使用每种生命周期的优点

敏捷框架和方法

XP

编程方法

结对编程

简单设计

重构

代码更加简洁优雅

测试驱动开发（TDD）

单元测试

减少bug

快速定位bug

提高代码质量

减少调试时间

技术债务

验收测试驱动开发（ATTD）

对业务文档统一

自然语言描述

可以运行的需求和用例

活着的文档

探索性测试

系统级测试

单元测试

集成测试

冒烟测试

回归测试

自动化测试

小组实践

持续集成

减少风险

减少重复过程

产生可部署的软件

是项目更加透明

建立项目信心

代码集体所有

编码标准

隐喻：讲故事的方式

稳定高速

知识共享

交付和管理

完整的团队

现场客户

小规模发布

计划游戏

水晶方法Crystal

最佳实践

项目章程

建设团队

探索360

为团队指定规范

建立初试计划

交付迭代

渗透式沟通

项目总结

反思提高研讨会

特征驱动开发FDD

动态系统开发方法DSDM

AUP敏捷统一过程

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

消除浪费

过度生产

等待

传输

过度流程

库存

再作业

情绪

SCRUM

3355模型

3个角色

产品负责人（product owner）

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

定义所有产品功能

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

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

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

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

ScrumMaster

对项目的直接管理

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

排除团队遇到的困难

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

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

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

Team

经典团队3/5-9人

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

团队成员都全职工作

团队组我组织和管理

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

3个组件

产品待开发列表（ProductBacklog）

冲刺待开发列表（SprintBacklog）

燃尽图（Burndownchart）

5个仪式

冲刺规划会议（SprintPlan）

冲刺评审会议（SprintReview）

冲刺回顾会议（SprintRetrospective）

每日站立会议（DailyScrumMeeting）

冲刺（Sprint）

5个价值观

承诺

专注

公开

尊重

勇气

典型场景

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

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

PO每轮迭代前，Review需求列表，并筛选高优先级的需求进入本轮迭代开发

开发团队细化本轮迭代需求，并按照需求的优先级依次在本轮迭代完成

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

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

回到第3部，开始下一个迭代

看板

3个规则

可视化的工作流

可视化价值

可视化价值流动

可视化问题和阻塞因素

可视化队列、瓶颈

可视化流转规则

限制WIP（work in progress）

关注平均完成时间

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

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

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

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

相应时间（Responsetime）:Leadtime-Cycletime

协同改进

1个工具

看板墙

建立敏捷团队