第1章 敏捷的定义
1776 年，英国的亚当·斯密在《国富论》中首次提出劳动分工的概念，成为工程管理相关思想的萌芽和发展的里程碑。
20 世纪初，美国的泰勒及海尔和雷斯夫妇等工程师们经过不断研究和探索，提出了科学管理和提高生产力的原则，为工业工程的发展做出了极大贡献，而奉勒更被誉为“工业工程之父”
1913 年，福特公司实验了第一条汽车流水线。流水线使汽车的组老制造时闻大大缩短，工人的效率也极大提升，福特公司的T型车产量因此占据当时全世界汽车总产量的一半以上。
工业工程推动软件工程，提出：JIT JustIn-Time)的精益理念和看板_(Kanban)等。
第一个程序早在 1842 年就被设出来了，负责设计程序的人是Ada Lovelace。她父亲是英国著名诗人拜伦
1968年,为了解决软件开发的混乱状态，当时的北大西洋公约组织 (NATO) 在德国小城举行了次学术会议，这次会议被命名为“软件工程大会”，标志着软件工程学科的诞生。
1970年，美国计算机科学家温斯顿·罗伊斯(Winston Royce)在发表的文章《管理大型软件系统的开发》中首次提出了著名的瀑布模型。
1 什么是敏捷
敏捷类型
1994 年，英国一个由 17 家公司发起的联盟提出了动态系统开发方法 (Dynamic Systems Development Method、DSDM)
1995 年，美国软件开发专家Jef Sutherland 和 Ken Schwaber 共同提出了 Scrum开发框架
1996年，美国软件开发大师，同时也是 JUnit 作者的 Kent Beck 提出了极限编程(Extreme Programming，简称XP)
1996年，Alistair Cockburn 和Jim Highsmith 共同提出了水晶方(Crystal)
1997 年，Jeff De Luca、Eric Lefebvre 和 Peter Coad 一起提出了特性驱动开发(Feature Driven Development , FDD)
2001年，17 位来自 DSDM、Scrum、XP、FDD 等流派的专家代表在美国犹他州一个名为雪鸟的滑雪胜地齐聚一堂，提出敏捷宣言
敏捷软件开发宣言
敏捷软件开发宣言在身体力行的同时也帮助我们一直在实践中探寻更好的软件开发方法。由此，我们建立了如下价值观：个体和互动 高于 流程和工具工作的软件，高于 详尽的文档客户合作， 高于 合同谈判响应变化，高于 遵循计划。也就是说，尽管右项有其价值，但我们更重视左项的价值。Kent Beck James Grenning Robert C. MartinMike Beedle Jim Highsmith Steve MellorArie van Bennekum Andrew Hunt Ken SchwaberAlistair Cockburn Ron Jeffries Jeff Sutherland Ward Cunningham Jon Kem Dave ThomasMartin Fowler Brian Marick |
敏捷宣言遵循的原则
敏捷宣言遵循的原则我们遵循以下原则: 1.我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。 2.欣然面对需求变化即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。 3.经常地交付可工作的软件,相隔几星期或一两个月，倾向于采取较短的周期。 4.业务人员和开发人员必须相互合作，项目中的每一天都不例外。 5.激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任,从而达成目标。 6.不论团队内外，传递信息效果最好、效率最高的方式是面对面交谈。 7.可工作的软件是进度的首要度量标准。 8.敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。 9.坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。 10.以简洁为本，它是极力减少不必要工作量的艺术。 11.最好的架构、需求和设计出自自组织团队。 12.团队定期反思如何能提高成效，并以此调整自身的举止表现。 |
2 敏捷定义
(1)敏捷是一系列方法，如XP、Scrum、Lean 等的总称，其目的是通过选代和增量的开发，以及经常性地检视和调整来提升项目的管理和交付水平。
首先，敏捷并不是某种具体的方法，而是各种方法的总称
其次，敏捷是通过造代和增量的方式来进行开发的
最后，敏捷通过经常性地检视和调整来提升项目管理和交付水平
(2) 敏捷不只是一个新的流程，还要用新的文化方式来进行软件开发
敏捷涉及的不仅是流程，还有文化、理念、组织等方面的转变
(3) 需求和解决方案通过自组织、跨职能团队之间的协作而发展
强调敏捷团队需要是自组织且跨职能的团队，因为只有跨职能的团队才能最大限度地提升沟通和执行效率。
3 敏捷Scrum介绍
起源
根据 CollabNet VersionOne 在2019 年公布的第 13 届年度敏告，Scrum 在敏捷方法的使用占比高居第一，达到了 54%。
核心内容
“3355”：Scrum框架
3个重要角色
3个重要工件
5个重要事件
5 个价值观
3 个角色。
(1)产品负责人(Product Owner)
(2)Developers
(3)Scrum Master
3个重要工件
(1)产品待办列表(Product Backlog): 产品的需求列表，由 PBI (ProductBackloItem)组成。PBI一般包括新特性、变更、缺陷或技术改进需求等。
(2)选代待办列表(Sprint Backlog)：每次 Sprint 选代需要完成的需求列表集
(3)产品增量(Increment):当次选代中完成的可交付的工作输出件
5 个重要事件
(1)Sprint
(2)Sprint 计划会(Sprint Planning Meeting)
(3)每日站会(Daily Scrum Meeting)
(4)Sprint 评审会(Sprint Review Meeting)
(5)Sprint 回顾会 (Sprint Retrospective Meeting)
需求梳理(Requirement Refinement)
DEEP原则，如下所示。
适当的细节(DetailAppropriately)
不断涌现(Emergent)
经过估算 (Estimated)
经过排序(Prioritized)
5个价值观
(1)勇气 (Courage)
(2)公开(Openness)
(3)专注(Focus）
(4)承诺(Commitment)
(5)尊重(Respeet)
4 规模化敏捷
SAFe 框架
主导设计者 Dean Lefingwell
SAFe 框架的核心理念是，通过在 Scrum 的基础上增加不同的层级和角色来应对大项目、大型复杂解决方案，甚至是产品组合管理对于敏捷的需要。
SAFe 分层结构是从团队级(Team Level)->项目群级(ProgramLevel)->价值流级(Value StreanLevel)->投资组合级 (Portfolio Level)
在此过程中合了精益-敏捷、质量内建、系统思考、排队论等知识体系。
CollabNet VersionOne 在2019 年公布的第13 届年度敏捷状态报告，SAFe框众多规模化敏捷体系中的占比最高，达到30%。
SAFe的基本原理
根据其作者，SAFe基于十个基本概念，这些概念源自现有的精益和敏捷原则以及观察：
1.Take an economic view
2.Apply systems thinking
3.Assume variability; preserve options
4.Build incrementally with fast integrated learning cycles
5.Base milestones on objective evaluation of working systems
6.Visualize and limit work-in-progress, reduce batch sizes, and manage queue lengths
7.Apply cadence (timing), synchronize with cross-domain planning
8.Unlock the intrinsic motivation of knowledge workers
9.Decentralize decision-making
10.Organize around value
1.从经济角度来看
2.运用系统思维
3.假设可变性；保留选项
4.通过快速集成的学习周期逐步构建
5.基于工作系统的客观评估的里程碑
6.可视化和限制正在进行的工作，减少批量大小，并管理队列长度
7.应用节奏（计时），与跨领域规划同步
8.释放知识工作者的内在动力
9.分散决策
10.围绕价值进行组织
在SAFe 5.0版中，有四种配置：
Essential SAFe （基本SAFe）：描述了所需的最关键要素，旨在提供大多数框架收益。它包括团队和程序级别（称为敏捷发布培训或ART）。
Large Solution （大型解决方案）：SAFe允许跨多个程序进行协调和同步，但无需考虑产品组合。在SAFe的早期版本中，此级别称为“ 价值流”。
SAFe Portfolio SAFe（SAFe投资组合SAFe） ：包括对战略方向，投资资金和精益治理的关注。
Full SAFe（完整SAFe）：结合了其他三个级别
Scrum@Scale 框架
创建者 Jef Sutherland
两个好朋友
Jef Sutherland 和 Ken Schwaber：共创Scrum
Jef Sutherland：Scrum@Scale
Ken Schwaber：Nexus
ScrumMaster 循环(Scrum Master Cycle)：How
产品负责人循环(Product Owner Cycle)：Wat
LeSS 框架
LeSS是 Large Scale Scrum 的简写，由 Bas Vodde和 Craig Larman 共同设计并率先队扩展和协调的问题诺基亚公司的网络部门进行实践
“less is more”，“请神容易送神难”，以后想要去掉这个色就会非常困难，所以，LeSS 框架的理念和 SAFe 框架存在很大不同。
其他大规模敏捷框架，如
·纪律敏捷交付（DAD）：Scott Ambler提出
·Spotify：亨利克·尼伯格
·Nexus
