2001年2月11日到13日，17位软件开发领域的领军人物聚集在美国犹他州的滑雪胜地雪鸟（Snowbird）雪场。经过两天的讨论，“敏捷”（Agile）这个词为全体聚会者所接受，用以概括一套全新的软件开发价值观。这套价值观，通过一份简明扼要的《敏捷宣言》传递给世界，同时即宣告了敏捷开发运动的开始。

敏捷宣言

《敏捷宣言》

个体与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划

敏捷开发十二原则

在敏捷开发中，我们遵循以下准则：

1. 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
2. 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
3. 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
4. 项目过程中，业务人员与开发人员必须在一起工作。
5. 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
6. 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
7. 可用的软件是衡量进度的主要指标。
8. 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
9. 对技术的精益求精以及对设计的不断完善将提升敏捷性。
10. 要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
11. 最佳的架构、需求和设计出自于自组织的团队。
12. 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

适用范围&特征

敏捷不是指某一种具体的方法论、过程或框架，而是一组价值观和原则。符合敏捷价值观和原则的开发方法包括：极限编程（XP），Scrum，精益软件开发（Lean Software Development），动态系统开发方法（DSDM），特征驱动开发（Feature Driver Development），水晶开发（Crystal Clear）等等。

特征：

1. 迭代式开发。即整个开发过程被分为几个迭代周期，每个迭代周期是一个定长或不定长的时间块每个迭代周期持续的时间一般较短，通常为一到六周。

2. 增量交付。产品是在每个迭代周期结束时被逐步交付使用，而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。

3. 开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时，团队对于用户的需求也能及时提供反馈意见。

4. 持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候集成， 有些项目则每天都在这么做。

5. 开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队，是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制，而非把过程和机制强加给人。

敏捷开发（agile development）是非常流行的软件开发方法。据统计，2018年90%的软件开发采用敏捷开发。
迭代开发将一个大任务，分解成多次连续的开发，本质就是逐步改进。一般采用"增量开发"（incremental development）划分迭代。
所谓"增量开发"，指的是软件的每个版本，都会新增一个用户可以感知的完整功能。也就是说，按照新增功能来划分迭代。增量开发加上迭代开发，才算真正的敏捷开发。

三、敏捷开发的好处

3.1 早期交付

敏捷开发的第一个好处，就是早期交付，从而大大降低成本。

还是以上一节的房产公司为例，如果按照传统的"瀑布开发模式"，先挖10栋楼的地基、再盖骨架、然后架设屋顶，每个阶段都等到前一个阶段完成后开始，可能需要两年才能一次性交付10栋楼。也就是说，如果不考虑预售，该项目必须等到两年后才能回款。

敏捷开发是六个月后交付一号楼，后面每两个月交付一栋楼。因此，半年就能回款10%，后面每个月都会有现金流，资金压力就大大减轻了。

3.2 降低风险

敏捷开发的第二个好处是，及时了解市场需求，降低产品不适用的风险。

请想一想，哪一种情况损失比较小：10栋楼都造好以后，才发现卖不出去，还是造好第一栋楼，就发现卖不出去，从而改进或停建后面9栋楼？

对于软件项目来说，先有一个原型产品，了解市场的接受程度，往往是项目成功的关键。有一本书叫做《梦断代码》，副标题就是"20+个程序员，三年时间，4732个bug，100+万美元，最后失败的故事"，这就是没有采用敏捷开发的结果。相反的，Instagram 最初是一个地理位置打卡 App，后来发现用户不怎么在乎地理位置，更喜欢上传照片，就改做照片上传软件，结果成了独角兽。

由于敏捷开发可以不断试错，找出对业务最重要的功能，然后通过迭代，调整软件方向。相比传统方式，大大增加了产品成功的可能性。如果市场需求不确定，或者你对该领域不熟悉，那么敏捷开发几乎是唯一可行的应对方式。

四、如何进行每一次迭代

虽然敏捷开发将软件开发分成多个迭代，但是也要求，每次迭代都是一个完整的软件开发周期，必须按照软件工程的方法论，进行正规的流程管理。

image

具体来说，每次迭代都必须依次完成以下五个步骤。

1. 需求分析（requirements analysis）
2. 设计（design）
3. 编码（coding）
4. 测试（testing）
5. 部署和评估（deployment / evaluation）

每个迭代大约持续2~6周。

image.png image.png
http://www.ruanyifeng.com/blog/2019/03/agile-development.html
image.png
https://www.lmlphp.com/user/3274/article/item/354123/
一边，有业界认可的scrum master，它的朋友极限编程者，以及由其衍生的 LeSS、SAFe、DAD等，是敏捷。

另一边，有精益文化机器，用代码持续交付其基础架构，它的名字左边是开发，右边是运维，合起来就是DevOps。

虽然我已尽我所能在普及这两个概念，但人们关于敏捷和DevOps的争论依然让它们听起来完全不同。更糟糕的是，尽管他们都已经有了各自的行业术语和口号，但两者的概念还是没办法准确定义。鉴于敏捷诞生早于DevOps ，所以它的定义也相对清晰一些，但DevOps五花八门的定义仍然让很多人都很困惑。而正是因为二者都缺乏准确的定义，所以导致人们经常会有一些误解。

毫无疑问DevOps和敏捷之间的联系由来已久。在2008敏捷大会上，Patrick DuBois和Andrew Clay Schafer尝试建立二者之间的关系并提出“敏捷架构”这一概念，这时，敏捷与DevOps之间的关系就已初现端倪。尽管Patrick后来提出了“DevOps”一词，但敏捷大会依然被追溯为DevOps的起点。所以我们不妨透过Scrum和持续交付的表面，深入了解二者的历史，来思考一下敏捷和DevOps之间还存在哪些关联。

一、敏捷绝不仅仅是Scrum
某些团队中，scrum让团队工作介于一成不变、苦苦挣扎和量产、高回报之间。还有一些团队，scrum用客观和聚焦代替主观和过度承诺。我们也可以把它视为一种教条。当业务收到限制或工作本身需要做出改变的时候，敏捷团队将利用scrum的基本原则，审视自身的工作并做出更有效的调整。尤其是当scrum应用于软件开发环境之外的业务时，这点尤为重要。

提前规划计划外的工作
在DevOps社区，有敏捷经验的人都觉得scrum能够有效追踪计划中的工作。一些正在运行中的工作可以被计划：如发布一个重大系统变更、切换数据中心或系统升级等。但在运行中大多数事情是没办法计划的：如性能到达峰值、系统中断或安全问题等。这些突发事件都需要快速做出反应。没时间等到把这些事项在backlog中确定优先级后再做或放到下个sprint规划会议中处理。正因如此，很多团队开始慢慢接受DevOps思想，Scrum之外再引入Kanban。这样使得团队可以同时追踪两种类型的工作，帮助他们理解两者之间的联系。或者，他们采取了一种综合方法，叫做Scrumban 或 Kanplan （也就是有backlog的看板）。

在很大程度上，scrum得以广泛应用的关键可能在于它不对技术方法设限。Scrum作为轻量级管理方法，往往能为团队带来巨大变化。之前，可能会有来自多个master的优先事项互相竞争，但在scrum中，backlog中只会存在一组优先事项。之前，团队中可能会存在同时推进很多工作的情况，而现在取而代之的是一个在限定时间内可以完成的工作计划。综合来看，这些都可以将团队的生产率带到一个新的水平。然而，团队可能会因技术实践的缺乏而受到限制，如代码审查、自动化验收测试、持续集成。

其他敏捷方法如极限编程，也对技术如何使团队保持可持续交付节奏并向管理层和利益相关者提供透明度和可见性提出了明确要求。一些Scrum团队倾向于将研发任务放在backlog中。虽然这在scrum的指导下适应得很好，但很快就会遇到Product Owner对产品功能的偏向性问题。除非Product Owner的技术能力很强，否则TA可能无法评估技术的成本或收益。尤其是当技术任务延伸到运维、可靠性支持、性能、安全性等方面时，对Product Owner来说更加困难。

Product Owner 和Service Owner
在Worktile，我们认识到，为我们运营的产品设置两个不同角色很有必要。Product Owner善于理解用户的功能性需求，但可能并不擅长权衡产品功能与性能、可靠性和安全性等非功能性功能之间的优先级。因此，一些SaaS产品也配备了Service Owner角色，负责确定前述非功能性功能的优先级。尽管两个角色经常需要讨价还价，但大部分情况下，独立的团队都可以自行完成这两个角色的任务。虽然这并不是“强化反馈”的唯一方法，但确实能够克服Product Owner对产品功能中比较常见的偏见问题。但设置‘两个Owner’并非实现DevOps的唯一途径。重要的是将非功能性特征理解为“功能”，并将它们像功能性的用户故事一样，进行规划和优先级排序。

敏捷方法中，Scrum有一个内在的“过程改进”机制，叫做回顾会议。因此，我们有理由相信一些scrum团队会想用DevOps作为灵感来源，用scrum回顾会议作为向DevOps方向调整的契机。然而，事实让我们意识到大多数团队需要注入外部思想。在DevOps成为主流前（哪怕成为学校必学内容），我们不能确定scrum自然发展的结果一定是DevOps。团队到底是有敏捷教练还是DevOps教练参与并不重要，只要他能给团队带来在构建、测试、部署等方面的自动化经验即可。

二、DevOps也不仅限于持续交付
如果应用得当，持续交付的规则可以有效限制在制品数量，而部署的自动化有助于打破工作局限。通过这样的方式，持续交付让软件开发团队频繁交付更高质量的产品，而不必在二者之间抉择。然而，正如仅专注于scrum的团队可能会忽视更广泛的敏捷环境那样，仅专注于持续交付的团队也会错过更广泛的DevOps环境。

持续交付实践并不能直接解决业务部门和开发团队之间的沟通问题。如果业务部门设定了一个为期一年的预算驱动计划，那么产品交付团队每次交付产品后都需要等待数月才能得到业务部门给的反馈。而这些反馈通常都是一些影响后续工作的步骤性功能，像取消项目或者更糟糕的是需要扩充项目团队（因为大量涌入新人会影响团队已有的稳定性）。

敏捷流畅度模型将“价值聚焦”视为流畅度的第一层级，即团队需要注重透明度和一致性。如果价值不聚焦，持续交付很容易陷入技术改进的无限死循环而无法向业务交付可观的价值。团队可能擅长快速高质量的交付，但就产品本身而言，可能对终端用户或者企业来说几乎没有价值。即使很多用户给出了较好的评价，但从较大的业务组合层面来看可能就会评估为低价值。因此，没有价值聚焦这一重要流畅度，团队很难在技术和功能之间权衡取舍。

这点对于有遗留代码库的团队来说尤为重要，因为遗留代码库可能没有自动化测试或适合频繁部署的设计。在一个遗留环境中，持续交付转换可能需要数年的时间。因此，证明产品的商业价值就显得尤为重要。

三种方法
DevOps不仅仅是自动化部署流水线。换句话说，DevOps方法要求“运维人员（Ops）能够像开发人员（Devs）那样思考，而开发人员（Devs）也要像运维人员（Ops）那样思考。” 以下是这一观点的进一步阐述以及可作为DevOps原则的三种方法：

第一种：系统思维
强调整个系统的性能，而不是特定的工作孤岛或部门的性能——这个系统可以大到涵盖整个业务部门，小到仅包括单个工作项。

第二种：扩大反馈循环
创建全流程的反馈循环。几乎所有过程改进计划的目的都是为了缩短并强化反馈循环，以确保可以不断进行必要的修正。

第三种：不断实践和学习的文化
塑造一种聚焦在这两件事上的文化：不断实践、勇于冒险并从失败中学习经验；要明白重复和实践是熟练掌握的先决条件。

持续交付侧重于第一种方法： 即实现从开发到运维的自动化流程。自动化在加快系统部署上的作用非常明显，但系统思维绝不止于自动化。

第二种方法的突出特点是实践， 即“开发人员也要随身携带传呼机”。虽然开发人员不一定真的要随身携带传呼机做到随叫随到，但他们也需要积极参与到运维工作中。这样能让开发人员了解到他们开发过程中所做选择带来的后续影响。例如，这样做能让开发人员将自己的日志消息存放到更好的位置让它们发挥更大的作用。开发人员不仅仅要了解运维工作，还要结合自己对系统的理解做一些故障排除的工作，这样可以更快地找到并实施解决方案。

第三种方法强调在整个系统中进行增量实验，而不仅仅是应用程序在流水线中移动的变化。 换句话说，看出自动化所需的时间并用日益强大的基础设施来不断改进它相对来说是比较容易的。而要清楚的知道角色或企业之间的交接如何导致延期是比较困难的。这意味着团队要“检查和调整”整个交付工作流，寻找可以提升人员协作效率的点。对于这个问题，持续交付要求团队养成不断适应和改进的习惯。如果团队从来不去思考如何变得更高效，并付诸行动去调整和改善，那么持续交付也无法持续发展和完善。团队要相信自己有能力解决自己的问题。

在scrum中，每次回顾会议都是一次改进实践和工具的机会。但如果团队没有抓住这些机会解决短期和长期的技术问题，他们就无异于坐等Product Owner将持续交付任务放到他们的backlog中，而事实上，Product Owner永远不会这么做。

DevOps是敏捷在软件开发团队之外的应用
Scrum主要遵循“欣然面对需求变化，哪怕变更出现在开发后期。敏捷过程正是利用变化来帮助客户取得竞争优势”这一敏捷原则。

而持续交付遵循的敏捷原则是：“我们的首要任务是通过尽早、持续地交付有价值的软件，来满足客户的需求”。

这意味着敏捷更强调输入和输出的变化，而不是每日站会和sprint规划会等仪式。事实上，《敏捷宣言》中还有另外10条原则。我们应该将它们视为一个整体，而不是从中选择某些原则。因为这些原则合起来代表的是敏捷和DevOps对变更的态度。

这些人一直在运行对于企业来说非常重要但同时又非常脆弱的系统。也正是因为它的重要性，所以也最迫切需要得以改进。因此，这里敏捷强调的变化并不是“为了改变而改变”。是为了让开发对其变更质量负责，同时提高整体交付商业价值。而这种对商业价值的关注是敏捷和DevOps的另一个共通点。

最后，敏捷和DevOps本身并不是业务指标。它们都是可以激励组织用更好的方法实现目标的企业文化。将敏捷和DevOps结合起来使用能取得更好的效果。而避免这两种文化发生冲突的诀窍就是要理解构成它们的更深层次的价值观和原则。武断而狭隘的定义会禁锢思维。相信看完本文，你已经知道敏捷不仅限于scrum，而DevOps也不仅限于持续交付。那么接下来，你就可以尝试强大的Agile + DevOps组合了。