什么是敏捷开发
已经有很多介绍什么是敏捷开发的文章了，为什么还要写一篇呢。我最近也在思考中，主要有2个原因：
- 现在找到的文章，介绍敏捷开发非常简短，不够详细
- 甚至有一些文章，没有介绍出敏捷的本质
作为一名 Scrum培训师（CST），有必要为大家澄清一下什么是敏捷开发。
敏捷开发调查
介绍敏捷之前，先了解一下背景。这是一份敏捷开发2020年问卷调查结果。在这份报告中，我们可以看出：
Scrum仍然是大趋势，SAFe也得到了更广泛的应用（Bob认为SAFe虽然解决了问题，但也带来了更多的问题，持有保留态度）。
更多详情，可以点击查看问卷调查。
什么是敏捷开发
敏捷一词来源于2001年初美国犹他州雪鸟滑雪圣地的一次敏捷方法发起者和实践者（他们发起组成了敏捷联盟）的聚会。
迭代和增量式软件开发方法可以追溯到1957年。进化式项目管理和适应性软件开发出现在1970年代初期。在1990年代，因针对重量级的软件开发方法的批评，而发展了许多轻量化的软件开发方法、项目与细微化开发管理。包含了，从1991年开始的快速应用程序开发(RAD)、从1994年开始的统一进程与动态系统开发法（DSDM）、从1995年的Scrum、从1996年的水晶清透法（Crystal Clear）与极限编程法（eXtreme Programming）、1997年的功能驱动开发（Feature Driven Development）。虽然那些开发法都起源于敏捷开发宣言之前，但都统称为敏捷软件开发法。在此同时，制造业与航空业也遭遇相同变化。
在2001年，十七名软件开发人员在犹他州的雪鸟度假村会面，讨论这些轻量级的开发方法，并由Jeff Sutherland，Ken Schwaber和Alistair Cockburn发起，一同发布了“敏捷软件开发宣言”。
在2005年，由Alistair Cockburn和Jim Highsmith领导的小组编写了一份项目管理原则的附录，即“相互依存声明”，以便根据敏捷软件开发方法来指导软件项目管理。
在2009年，罗伯特·C·马丁（Robert C Martin）编写了软件开发原则的扩展，即软件工艺宣言（Software Craftsmanship Manifesto），根据职业行为和掌握程度来指导敏捷软件开发。
在2011年，敏捷联盟创建了敏捷实践指南（2016年更名为“敏捷词汇”）、敏捷实践、术语和元素工作定义的演化开放式汇编，以及来自敏捷从业者社区的经验指南。
了解了上面的背景后，我们能看出敏捷中绝大部分是有关于Scrum的，敏捷当中除了Scrum还有很多的一些流派（分支），那到底什么是敏捷开发呢？这个我们要回到2001年，十七名软件开发人员他们在一起进行了一次聚会，努力去解救程序员这个群体。在这次聚会当中他们提出了敏捷软件开发宣言。敏捷开发最早确实就是软件开发，甚至于只是软件开发行业的总结。针对于软件开发的宣言下面我们来详细解读什么是敏捷软件开发宣言
敏捷开发的特点
敏捷开发相对于传统的瀑布式开发，有其特点：
- 迭代式
- 增量式
- 价值驱动
迭代开发 - 敏捷开发的特点
迭代或冲刺指的都是固定时间盒（时间段），通常持续一到四周。每个迭代都具有跨职能的团队，包含了规划、分析、设计、程序编码、单元测试和验收测试所有的活动。在迭代结束时，将工作产品向利益相关者展示。透过上述方式让整体风险降至最低，并使产品能够快速适应变化。迭代的方式，可能不会一次增加足够的功能来保证可立即发布使用，但是目标是在每次迭代结束时，有一个可用的发行版（最小化程序缺点）。因此完整产品的发布或新功能可能需要多次迭代。
迭代更深层次的含义是在固定时间盒内，不断的重复，重构，改进。
增量开发 - 敏捷开发的特点
敏捷开发中的每个框架，都提倡将软件（产品）切分成很多的小块，来进行增量的开发。即每次只开发其中的一小块，不断的累加。通过增量的方式，可以让客户（或最终用户）尽早看到软件功能，尽早的体验到部分的应用，以尽早获取反馈。
价值驱动 - 敏捷开发的特点
这是一句“废话”，正确的“废话”。每个产品都号称是有价值的，但是作为开发团队是否真正问了以下的问题：
- 这个产品解决的问题是什么
- 这个问题发生的频率如何
- 这个问题客户（或用户）现在是怎么解决的
- 你的产品为客户带来了哪些不同的体验
如果能想清楚以上的问题，并且有清晰的答案，那么你的产品价值自然会体现出来。
敏捷软件开发宣言
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人，由此我们建立了如下价值观：
个体和互动高于 流程和工具 工作的软件高于 详尽的文档 客户合作 高于 合同谈判 响应变化 高于 遵循计划
也就是说尽管右项有其价值，我们更重视左项的价值
- 个人和交互：自我组织和动机是重要的，像坐在一起办公和结对编程开发，这样的模式中的沟通是重要的。创建一个良好的沟通和协作的开发团队，优于一个孤立运行的专家团队。沟通是一个基本的概念。
- 工作的软件：工作软件比在会议中向客户呈现文档更有用并更受欢迎。最好的做法是和代码一起评审，保持外部文档的轻量化，而不是沉重的文档，后者需要花费很大的精力，且很快就会过时。
- 客户合作：在软件开发周期的初始阶段，需求无法完全收集，所以最好直接涉及到付费客户、最终用户或者代理，以便在反馈的基础上逐步阐述和调整详细的需求。
- 响应变化：敏捷软件开发方法的重点是快速响应变化和持续改进。
一些软件开发者组织了敏捷联盟，为非营利组织，根据宣言的价值观和原则促进软件开发。吉姆·海史密斯（Jim Highsmith）代表敏捷联盟（Agile Alliance）介绍宣言：
“敏捷运动并不是反方法论，实际上我们很多人都想恢复对方法论的可信度。我们想恢复平衡。我们接受建模，但不是为了在尘土飞扬的企业存储库中提交一些图表。 我们拥抱文档，而不是数百页从未维护和很少使用的文档。 我们计划，但要认识到动荡环境下的规划极限。 那些将XP或SCRUM或者其他敏捷方法的支持者称为“黑客”的人对于黑客术语的方法和原始定义都是无知的。”
敏捷宣言遵循的原则
我们遵循以下原则：
- 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
- 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
- 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
- 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
- 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
- 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
- 可工作的软件是进度的首要度量标准。
- 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
- 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
- 以简洁为本，它是极力减少不必要工作量的艺术。
- 最好的架构、需求和设计出自自组织团队。
- 团队定期地反思如何能提高成效，并依此调整自身的举止表现。
敏捷软件开发框架
敏捷软件开发框架最常见的是 Scrum，极限编程和看板，但除此以外还有很多框架（有人叫它们是方法，但方法并不能很好的描述了最初的设计和想法。框架 vs. 方法）。有的专注于实践（例如，极限编程、敏捷建模），而有的专注于管理工作流程（例如Scrum，看板），有的支持需求规范和开发（例如FDD）的活动，而另一些则试图涵盖整个开发生命周期（例如DSDM，RUP）。
常见敏捷软件开发框架包括（但不限于）：
- 敏捷建模
- 动态系统开发法（DSDM）
- 极限编程（XP）
- 特性驱动开发（FDD）
- 精益软件开发
- 看板
- Scrum
敏捷的精髓
在2020年我曾经写过一篇重温Scrum精髓 - Scrum的核心到底是什么，在这篇文章中我重点提出了3个要点：
- Scrum精髓 Part1 - 解决客户问题
- Scrum精髓 Part2 - 关系
- Scrum精髓 Part3 - 反思
更加广泛意义的敏捷开发
敏捷宣言的提出已经有20年了，随着时间的推移敏捷远远不止在软件开发领域进行应用。比如敏捷宣言除了最初版本之外，还有：
在如此广泛的领域中应用敏捷，敏捷的含义也发生了一些变化。而其最根本的2点不变：
- 持续学习
- 持续改进
持续学习
持续学习，终身学习。中国有句古话，“活到老，学到老”说的就是这个道理。
持续改进
持续改进，日语中有一个对应的词是 Kaizen。它的含义不是改进1次，10次，100次，而是针对一个流程一个方法改进至少1000次。仔细体会一下这个改进的含义。
针对于敏捷开发，你还有什么疑问吗？欢迎留言。
