详解敏捷历史：为什么敏捷可以帮到你？ | IDCF

敏捷历史

敏捷软件开发（英语：Agile software development），又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于「非敏捷」，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。

1986 年，竹内弘高和野中郁次郎在哈佛商业评论中发表了题为 The New New Product Development Game 的文章，他们指出，传统的职能筒仓“接力式”的、 阶段式的开发模式已经不能满足快速灵活的市场需求，而整体或“英式橄榄球式” 重叠各阶段的方法(团队作为一个跨职能的整体在内部传球并保持前进)也许可 以更好地应对当前激烈的市场竞争。受此文章的启发，肯·施瓦伯(Ken Schwaber)和杰夫·萨瑟兰(Jeff Sutherland)于 1995 年正式发布了 Scrum 框架， 而同期其他的“轻量级”开发方法也如雨后春笋般涌现出来，如极限编程(Extreme Programming，XP)、特性驱动开发(Feature Driven Development，FDD)、自适 应软件开发(Adaptive Software Development，ASD)及动态系统开发方法(Dynamic Systems Development Method，DSDM)等。
---引自《京东敏捷实践指南》

敏捷宣言及12原则

敏捷一词来源于2001年初美国犹他州雪鸟滑雪圣地的一次敏捷方法发起者和实践者（他们发起组成了敏捷联盟）的聚会。雪鸟会议共同起草了敏捷软件开发宣言。其中最重要的部分就是对一些与会者一致同意的软件开发价值观的表述。

敏捷宣言中还包括了12原则。

英文版

中文版

这是对应的中文翻译：

京东提炼版

每一条原则，强调的重点各不相同，这是摘自《京东敏捷实践指南》对各条原则的提炼，值得大家参考。

敏捷方法

除了敏捷宣言内所提到的价值观和原则以外，敏捷并没有一个完整的方法列表，因为所有的敏捷方法都是广大开发人员在日常的工作中摸索出来的，针对某种特定场景适用的方法。也就是说，以下所列出的敏捷方法并以一定适用于你的团队或者你的问题，但是敏捷鼓励所有人按照自己的方式尝试任何的方法，只要这种方法遵循以上价值观和原则，那么它就是一种敏捷方法。

• Scrum
• 看板方法 Kanban
• 敏捷建模 Agile Modeling
• 特性驱动开发 Feature-driven development (FDD)
• 测试驱动开发 Test-drive development (TDD)
• 极限编程 eXteme Programming (XP)
• 精益开发 Lean Development
• 微软解决方案框架敏捷版 Microsoft Solution Framework (MSF) for Agile
• 敏捷数据方法 Agile Data Method
• 自适应软件开发 Adaptive Software Development (ASD)
• Six Sigma
• 水晶方法 Crystal
• 行为驱动开发 Behavior-driven development (BDD)
• 动态系统开发方法 Dynamic Systems Development Method (BSDM)
• 探索性测试 Exploratory Testing

以下是Forrester在2009年针对各种敏捷开发方法进行的一项调研结果，其中显示在所有敏捷方法中，Scrum的接受度最高。同时，在接受调研的开发人员中，已经有35%的人员在使用某种敏捷开发方法。

敏捷道法术器

敏捷全景图如图 2-1 所示，包括道、法、术、器四个层面。

• “道”是敏捷价值 观，即对工作方式的普世认知和信念，是价值标准，决定思想决策模式和行为方式，这里主要是指《敏捷宣言》;
• “法”是敏捷原则，既是实现价值观的最根本的 战略、方法、指导方针、思路，也是规则和规律，同时也是一种规范性约束指导， 这里主要是指敏捷 12 原则;
• “术”是敏捷方法和实践，即战术、技术、具体的手 段、具体的活动方式等，同一种实践可能会被不同的敏捷方法使用;
• “器”是敏捷 工具，即支撑和提高效率及敏捷性，把复杂问题简单化，把手工操作自动化和智 能化，例如，目前在业界热度比较高的 DevOps 方法，其落地的关键就是通过工具链以自动化的形式实现需求快速上线。

--- 引自《京东敏捷实践指南》

为什么敏捷可以帮到你?

误解：敏捷是为了快速交付？

敏捷不是一种为了快速交付而出现的方法，它之所以比较快则是因为避开了许多浪费的处理方式。

敏捷改善了些什么？

• 前置时间：传统开发法依循计划、分析、设计、程序开发、测试再进行修改整合后发布的步骤进行，是一种顺序性的开发模式，当前一个步骤用掉越多时间时则后面步骤的前置时间就会越长，而形成时间上越多的浪费。反观敏捷开发，实行的是一种务实的做法，当收集到足够一次迭代开发的需求时即向下一个步骤前进，尽量缩短前置时间的浪费，然后将"分析、设计、开发与测试"形成一个开发步骤，减少了步骤与步骤之间的衔接时间。
• 首次发布：敏捷开发采用迭代的开发方式，每个循环都会有一个潜在可发布版本用来展示开发成果，这种展示给了客户进行回馈和改进的机会，让客户体会开发成果的作法同时也给予了客户决定开发方向的绝对主权。
• 需求过程：敏捷开发不作完整的需求分析(因为计划总是赶不上变化的)，当需求的搜集量和内容质量已经达到一定要求， 已经足够一个开发周期的工作量时就可以开始开发工作。
• 测试方法：敏捷开发对软件带来的最大影响便是测试了。传统的α(内部测试，注2)、β(交付客户测试)、γ测试(优化处理)方式在采用敏捷开发后几乎不存在了，因为敏捷开发在开发周期内不断的在进行测试的工作，因此也就没有了在交付做α、β、γ测试时必须停止开发，冻结开发的时间浪费了。

参考资料：

• 《京东敏捷实践指南》赵卫 王立杰

IDCF DevOps黑客马拉松，2021年度城市公开赛，11月6-7日，深圳站，企业组队参赛&个人参赛均可，一年等一回，错过等一年，赶紧上车~公众号回复“黑马”加入