敏捷经典框架：框架选的好成功没得跑
敏捷经典框架：框架选的好成功没得跑极限编程XPScrum 的内容核心是“3355”，具体是指3个角色、3个工件、5个活动、5个价值。具体步骤是：PO 整理 User Story，形成 Product Backlog →发布计划会议输出 Sprint Backlog →迭代计划会议，任务分解并有明确负责人→每日站会，跟进进度解决问题→演示会议→回顾会议。上图来自于网络，侵删
本文几乎涵盖了市面上所有敏捷框架，内容较长，可先收藏后反复阅读，亦或下拉至最后看简单总结。
Scrum
Scrum 是用于开发、交付和持续支持复杂产品的一个框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成。适用于单个团队的产品管理过程。
它起源于软件开发项目，经过长期的实践现已适用于任何复杂的或是创新性的项目。比如：现已被用于开发软件、硬件、嵌入式软件、交互功能网络、自动驾驶、学校、政府、市场、管理组织运营，以及几乎我们（作为个体和群体）日常生活中所使用的一切。
具体步骤是：
PO 整理 User Story，形成 Product Backlog →发布计划会议输出 Sprint Backlog →迭代计划会议，任务分解并有明确负责人→每日站会，跟进进度解决问题→演示会议→回顾会议。
上图来自于网络，侵删
Scrum 的内容核心是“3355”，具体是指3个角色、3个工件、5个活动、5个价值。
极限编程XP
极限编程（Extreme programming，缩写为XP），是一种基于频繁交付周期的软件开发方法，是敏捷软件开发中应用最为广泛和最富有成效的几种方法之一。它的主要目标在于降低因需求变更而带来的成本。
极限编程和传统方法相比，更强调可适应性而不是可预测性。且欣然接受变更，并关注锻造在项目周期内适应变化的能力。相当于为管理人员和开发人员开出了一剂指导日常实践的良方；这个实践意味着接受并鼓励某些特别的有价值的方法。
它的重点是12个核心实践、4个价值 、5个原则。
看板方法
看板方法是为了解决“各个环节忙闲不匀，流程难以衔接”的问题而产生的，也就意味着它最大的优势是流程可视化。看板方法就像一个空货架，从视觉上对产品的流动进行追踪，以至于很容易发现瓶颈在哪里，空缺在哪里，生产流程是否衔接紧密等问题。
多用于制造业，有三个基本元素：板（Board）代表整个项目、列表或通道（List）代表一个分类，和卡(Card)代表进行的工作。
它的流程大概是：把当前项目的任务项贴到白板上，每一个卡片代表一个任务，经过几个通道（完成部分任务进入下一个通道）后，即完成了当前的一个任务。
水晶方法Crystal
水晶方法是由 Alistair Cockburn 和 Jim Highsmith 建立的敏捷方法系列，目的是发展一种“机动性”方法，每个方法都包含共性的核心元素，且都含有独特的角色、过程模式、工作产品和实践。敏捷团队可以根据其项目和环境灵活应用。
与 XP 一样，水晶方法也是以人为中心，但两者实践方式有所不同，XP 有严格的纪律性，水晶的约束较少，所以相对来说XP运用成功会有较高的产出率，但水晶却有更多团队愿意接受。
水晶方法系列及适用情况和重点，如下图。
Scrumban
Scrumban 是 Scrum 和看板的混合体，其中，使用 Scrum 作为工作方法，使用看板作为查看、理解和改进工作的镜头，它出现的目的是为了满足希望将工作分批最小化并采用基于拉动系统的团队需求。
Scrumban 方法合并了 Scrum 和看板中的元素，详情如下：
Scrumban 关键原则和属性包括：
特性驱动开发 FDD
特征驱动开发（FDD）来源于新加坡的一个大型软件开发项目，由著名软件专家 Jeff de Luca 、Eric Lefebvre、Peter Coad 共同提出。强调特征驱动，一个特征映射到业务过程中一个步骤。
整体包括5个过程：开发整体模型→构建功能列表→计划功能开发→按照功能设计→计划功能构建。
且有以下优势：
1、快速迭代，每个功能开发时间不超过两周，专注于抓住软件的核心问题领域开发。
2、对项目的开发进程进行精确及时地监控，为每个需求限定了粒度，具有良好可执行性。
3、打破了传统的将业务专家/分析师与设计者、实现者隔离开的壁垒。分析师会直接参与到开发人员和用户所从事的产品开发中来。
FDD 的重点：角色、过程和最佳实践方式如下。
动态系统开发方法（DSDM）
DSDM 是一整套的方法论，包含了项目管理的各个方面，比如：软件开发内容和实践、组织结构、项目管理、估算、工具环境、测试、配置管理、风险管理、重用等内容。
它倡导以业务为核心，用20%的时间完成80%的有价值功能，且快速有效地进行系统开发，快速交付并补充如何应用这些方法的指导原则。
强调制约因素驱动交付，和传统开发模型相比区别如下：
它的周期和基本原则为：
敏捷统一过程(AgileUP)
敏捷统一过程（Agile Unified Process，AUP）采用的是“全局串行，局部迭代”的原理来构建系统。目的是在每个过程之间执行更多迭代的周期，并在正式交付之前纳入相关反馈。
为企业用不好敏捷的问题，提供了一个解决框架，让软件开发人员不会感觉自己在很多管理方法、技术中分别工作，而是流畅地在一个统一的过程框架下工作。
它在执行的过程中，应用了多种敏捷技术，包括测试驱动开发（TDD）、敏捷模型驱动开发（AMDD）、 敏捷变更管理和数据库重构等等，以提高生产效率。
扩展框架
扩展框架是指在scrum的基础上扩展，是一种最早的规模化敏捷技术，简单且有效，用于集成多个（建议不超过3-9个）在同一产品上工作的 Scrum 团队的工作，比如scrum of scrum，Scrum of Scrum of Scrum等等。
出现这种框架的原因是 Scrum 是适合小团队的敏捷框架，而现实中企业会有多个小团队，企业要逐渐应用敏捷，进而就有了这种扩展框架。
它的优势是转型敏捷易于复制，有利于团队之间有效沟通，不同团队的软件输出能更好地集成一起交付客户。
规模扩展总会根据情况而定，因此，具体的协作形式将由开发团队确定，典型的策略包括：
大规模敏捷开发 SAFe
Scaled Agile Framework ( SAFe ) 是一个大规模敏捷框架，专注于为所有级别企业的大规模开发工作提供模式知识库。主要是从三个层面解决企业问题：团队，计划和投资组合。
团队层面，大部分和 Scrum（包括 XP 实践）很像， 但有一个比较明显的区别，就是并非每个 sprint 都会产生潜在的可发布增量，它可能会发生在强化冲刺之后。
计划层面， SAFe 提供了大量细节，关于敏捷团队的工作怎么得到调整和整合，以用来满足企业及其利益相关者的需求。
投资组合级别提供投资级别与组织运营级别之间的类似产品和目标一致性。
大规模敏捷开发 LeSS
LeSS 是 2005 年由诺基亚员工 Bas Vodde（一位精益敏捷教练）和 Craig Larman（一名组织设计顾问）创建的，它的产生是为了解决以Scrum为首的敏捷方法论对大规模开发团队不友好的问题。
在LeSS方法下，大规模Scrum适用于大规模开发的常规Scrum，也保留了很多Scrum 中的基本要素，例如：每日站会、产品待办列表、Sprint计划会议、Sprint评审会议、回顾会议等。但在Scrum框架的基础上延伸出了更大的范围。
LeSS具体细化为两种框架：
Framework-1专为最多10个团队的项目而设计。基本角色不变，但会议中的一部分会发生变化，有些会在团队级别复制；
Framework-2是为超过10个团队的大型项目而设计的，增加了一个额外的角色，即区域产品负责人，他承担产品主要部分的产品所有权。
但不论是哪一种具体的框架，对团队自身的要求都没有改变。
规范敏捷（DAD）
DAD框架是由 IBM的两位大佬Scott Ambler和Mark Lines所创建的一套面向过程的交付框架。它是一种以人为核心、注重学习的混合型方法论，它拥有“风险—价值”共同驱动的生命周期，采用目标驱动的方法，具有可扩展性和支持企业意识。
某些方面可以说它是一个弹性框架，把已有的敏捷框架组成一个百宝箱，企业可根据自己情况拆卸掉没用的部分，另外还强调可扩展性，所以，有新的内容还可在组装到里面。
总结
因为内容较多，在这给大家做了简单总结，大致标出了每个框架的重点，希望对你有帮助
好了，经过多位老师的询问、几十个网站的搜索、3天的整理，终于完成了这篇文，希望我的努力对你有益。
同时为了更多人看到，需要你的助力，期待你的分享、评论~
