敏捷管理

先敏捷后预测

预测和敏捷结合

预测为主敏捷为辅

敏捷为主预测为辅

混合生命周期类型

Stacy斯泰西图

敏捷适用性过滤器

敏捷项目的选择

个体以及互动   而不是  流程和工具

可用的软件   而不是   完整的文档

客户合作   而不是   合同谈判

应对变更   而不是   遵循计划

敏捷宣言

最高目标

团队原则

工作原则

敏捷十二原则

敏捷宣言和原则

1、构想 - 启动2、推测 - 规划3、探索 - 执行4、适应 - 监控5、结束 - 收尾

敏捷阶段框架VS预测五阶段

产品愿景驱动产品路线图

愿景

最小可行产品（MVP）

最小可售功能（MMF）

故事地图

产品路线图驱动发布计划产品线路图是项目可视化的描述，包括所有版本和产品功能

产品路线图

发布计划规定迭代计划发布计划包含高度概括的发布进度时间轴，确定发布的迭代次数；查阅发布计划能确定迭代周期和迭代次数；

发布计划

迭代计划安排功能开发功能开发满足用户故事

迭代计划

用户故事创建任务

每日计划

图片理解

洋葱圈（滚动式规划）

用户画像（人物）

用户故事的INVEST属性：lndependent ：独立的Negotiable：可协商的Valuable：有价值的Estimable：可估计的Small ：小的Testable：可测试的

INVEST 原则

验收标准 DOD

每人10张数字牌，每个人选一张卡片，这个时间点选择的卡片不能给他人看。所有参与者同时展示自己的卡片。团队一起来讨论这些估计值，尤其对异常值(最高的和最低的)要着重讨论。最后选择连续几轮的估算。

计划扑克

一种基于团队共同参与的估算方法，一群专家匿名提交估算结果，彼此不知道真实的结果，这样可以提升团队成员对结果的认同感，也可以避免产生一些“花车效应”和“花环效应”。一般会进行多轮，直到达成共识。

宽频德尔菲

除了使用故事点来估算用户故事的相对规模外，敏捷团队还可以用理想时间来估计，即估计构建各个工作项所需的实际时间，而不考虑速度或中断。

理想时间

故事点估算

Must：必须做的必须有。如果不包含，则产品不可行。通常就是最小可行产品(MVP)。Shoud：应该做的应该有。这些功能很重要，但不是必需的。Could：可以做的可以有。这些要求是客户期望的，但不是必需的。Would not：不要做的不要做的。在当下是不适合的要求。

MOSCOW法则

卡诺模型(KANO模型）是对用户需求分类和优先排序的有用工具，以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意之间的非线性关系。

卡诺分析

敏捷团队通常会维护工作项的一个有序列表，把最高风险的项放在这个列表最上面，使它们最先得到处理。这种实践叫已调整风险的待办列表。

风险四象限

优先级排序

刺探

用户故事

速度，即本次迭代中实际完成功能的故事点大小的总和，让团队得以通过观察历史表现来更准确地规划下阶段的能力。

速度的概念

关于速度的计算：速度是对每一迭代完成的用户故事点或故事数量的衡量;只有用户故事完成了，计算速度时才能计入其故事点数;1速度=1故事点;

速度的计算

燃尽图和燃起图

*不同团队之间不能横向比较

速度监控

速度控制

产品思维

对接客户、创建产品待办事项列表、优先级排序、监控需求、定义“已完成”；与客户对接对接客户，收集需求，定义需求，注重演示审查管理需求监控需求，根据实际情况，清理变更需求及排序对产品待办事项列表负责关注价值，创建(优于团队)产品待办事项列表并排序对内把控用户故事质量参与项目，及时给出反馈，鉴定“已完成的用户故事”

产品负责人（PO）

催化剂、垫脚石、老母鸡解决团队问题催化剂-促进作用，没有决策权只能促进辅导，鼓励提醒提示建议，不能做决定清除组织遇到障碍消除组织障碍，包括但不限于详尽的文档、冗长的过程、频繁的打扰、跨部门工作、行政任务让团队更敏捷为他人贡献铺路，基于敏捷原则及实践提供培训或支持性工作(技术性问题团队自行解决)敏捷教练插手的情况被求助、团队违反敏捷、不会使用敏捷工具、冲突自行解决无效

敏捷教练（SM：仆人式领导）

自主决策，自助担责；3-9名，100%参与，通才型专家；集中办公和虚拟办公特点聚焦绩效、自主决策、自主担责、自行认领任务，不对敏捷教练承诺构成3-9人正负2变动，通才(跨职能)+专职（(专注单任务)通才型专家的好处具有某个特定领域的专业技能，同时也能对很多其他专业领域做出改进。包括但不限于，减少瓶颈、提升效率、减少孤岛/竖井适用环境集中办公，渗透式沟通，知识共享，鱼缸窗口和远程结对团队规模变动3-9人正负2变动，如果题干表明团队人数太多影响了敏捷时，可以根据情况分割团队

项目团队（自组织团队）

三个角色

功能性内容产品用户故事、拆分大颗粒的用户故事非功能性内容非功能性(技术债务、系统重构、培训需求、根本原因、纠正措施、风险应对、运维工作)变更细化待办、上期遗留、新增事项、优先插队、删除事项、办成增量DEEP模型详略适宜、可估计、涌现（渐进明细的)、排好优先级

产品待办事项列表

内容定义这次迭代的目标，明确具体任务，团队自行讨论领取变更等待，直接接受，需要PO判断何时创建迭代规划会议即时需求细化分解用户故事，使之能按小增量规划

迭代待办事项列表

一次迭代中实际完成的用户故事

可交付产品增量

三个工件

冲刺/迭代

内容细化评估故事，制定迭代待办事项列表，团队成员自行领取任务相关方参与相关方可以通过参加冲刺计划会议了解团队情况和产品情况审查变动当出现变动(目标、需求变化)可以在迭代计划会议时评估

冲刺规划会议

作用识别风险、找出障碍、共享项目状态、协调保持共同目标、促进团队持续改进必要性每日站会是支撑敏捷原则最重要的基石之一，不可以轻易取消内容完成什么，计划完成什么，我的障碍是什么;只共享信息，不解决问题变动—般不超过15分钟，根据情况可以适当延长时间或者划分团队

每日站会

时间盒4小时，1小时/每周根据迭代周期来看，一个月的迭代周期是4小时验收已完成的产品演示产品负责人确认完成的产品，获得客户通过讨论下次预期产品讨论下次迭代的产品功能，关注结果已完成的定义经过产品负责人确认的产品，团队内检通过未完成的故事协商退回产品待办事项列表参加人员产品负责人、相关干系人，敏捷团队，一般不能缺席

迭代评审会议

时间盒一个月迭代周期的时长不超过3小时作用检视自身，总结经验教训，关注过程，回顾措施有效性，创建迭代改进计划参加人员团队或员和敏捷教练，敏捷教练起鼓励、促进作用、最后发言

迭代回顾会议

五个事件

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

五大价值观

相关图示

*迭代0：启动敏捷开发前的准备工作阶段；是计划迭代，创建安排故事卡片，不交付客户价值；

SCRUM实践

要想获得最大化的价值，必须将浪费最小化。延期、没有用的功能、等待都是一种软件浪费。

消除浪费

尊重团队成员并由font color=\"#ff0000\

授权团队

通过快速交付有价值的软件来最大化项目的投资回报率(ROI) 。

快速交付

去检视系统的整体而不是一部分，关注整个组织的优化改进，关注团体。

全面优化

精益开发不是测试为先，而是通过重构、持续集成、单元测试等技术手段来加强质量保证。

品质为先

尽早计划和最晚决策

晚做决策

通过尽早沟通和频繁的反馈来建立学习的内容。软件项目是业务和技术两项经验的积累，需要尽快开始并保持学习的状态。

强化学习

精益思想就是花最少的钱，办最好的事；核心是消除浪费；

精益七大核心理念

运输、等待、动作、缺陷、库存、过量生产、过度加工

制造七浪费

部分完成的工作、多余的流程、多余的特性、任务切换、等待、动作、缺陷

软件七浪费

1、浪费；2、不均衡；3、负荷过重；

必须消除的浪费三大来源

常见浪费

步骤一：选定需要分析的产品族步骤二：调查现状步骤三：绘制现状图步骤四：检讨问题点步骤五：绘制未来图步骤六：制定改善计划*找出不能为产品提供增值的活动，识别一个工作项中各个流程的流动过程，找出缺陷并改进；

价值流图

精益

1、可视化工作流程2、约束在制品(WIP)3、度量和管理流动(拉动)4、显示化规则5、建立反馈环6、在协作及实验中改进

六大核心实践

燃尽图

燃起图

累积流图

信息发射器

Kanban

两个开发成员一起，一个开发一个检查；

结对编程

团队开发成员经常集成他们的工作

持续集成

先写测试程序，然后编码实现功能

TDD

避免交付后故障频繁，避免人工测试增加成本

自动化测试

不改变代码行为的前提下，对其进行一系列小的改造，旨在改进系统结构的实践活动

重构

XP

其他敏捷实现

文化是否具有支持该方法？并已建立信任的团队环境？团队是否有自主决策能力？团队适当规模的团队？客户/业务反馈？敏捷经验水平？项目变更速度极快？增量交付可行？项目关键性如何？分越低越符合敏捷

变革管理模型

动态系统开发方法（DSDM）

多层结构主协议：固定项目(担保、仲裁等）锁定;主要服务协议：可能会变更的服务价格、产品说明等;轻量级工作说明说：范围、进度和预算等更多动态变化项目。总价增量项目可以将范围分解为总价微型可交付成果（例如用户故事)，而不是将整个项目范围和预算锁定到单个协议中。固定时间和材料将整体预算限制为固定数量。如客户需纳入新观点，必须管理给定能力，用新的工作替代原有工作。累进的时间和材料|共担财务风险法，合同期限之前交付，则奖励;反之，则惩罚。

敏捷采购与合同

敏捷变革

自由主题

+7