已经有很多介绍什么是敏捷开发的文章了，为什么还要写一篇呢。我最近也在思考中，主要有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）。
常见敏捷软件开发框架包括（但不限于）：
在2020年我曾经写过一篇重温Scrum精髓 - Scrum的核心到底是什么，在这篇文章中我重点提出了3个要点：
敏捷宣言的提出已经有20年了，随着时间的推移敏捷远远不止在软件开发领域进行应用。比如敏捷宣言除了最初版本之外，还有：
在如此广泛的领域中应用敏捷，敏捷的含义也发生了一些变化。而其最根本的2点不变：
持续学习，终身学习。中国有句古话，“活到老，学到老”说的就是这个道理。
持续改进，日语中有一个对应的词是 Kaizen。它的含义不是改进1次，10次，100次，而是针对一个流程一个方法改进至少1000次。仔细体会一下这个改进的含义。
针对于敏捷开发，你还有什么疑问吗？欢迎留言。
已经有很多介绍什么是敏捷开发的文章了，为什么还要写一篇呢。我最近也在思考中，主要有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）。
常见敏捷软件开发框架包括（但不限于）：
在2020年我曾经写过一篇重温Scrum精髓 - Scrum的核心到底是什么，在这篇文章中我重点提出了3个要点：
敏捷宣言的提出已经有20年了，随着时间的推移敏捷远远不止在软件开发领域进行应用。比如敏捷宣言除了最初版本之外，还有：
在如此广泛的领域中应用敏捷，敏捷的含义也发生了一些变化。而其最根本的2点不变：
持续学习，终身学习。中国有句古话，“活到老，学到老”说的就是这个道理。
持续改进，日语中有一个对应的词是 Kaizen。它的含义不是改进1次，10次，100次，而是针对一个流程一个方法改进至少1000次。仔细体会一下这个改进的含义。
针对于敏捷开发，你还有什么疑问吗？欢迎留言。