当我们在谈敏捷时我们在谈什么？ _敏捷

文章插图
本文转载自微信公众号「DDD和微服务」，作者 shaogefenhao 。转载本文请联系DDD和微服务公众号。
进入具体的管理工作，我们只谈真实的敏捷团队和问题，本文总结了敏捷实践中最关键的一些概念来诠释敏捷这个词本身的含义。
敏捷的概念包含价值观和原则、敏捷软件开发具体的工作框架、常见敏捷实践、敏捷迭代会议等内容。
Agile 敏捷想要弄明白敏捷是什么，首先需要弄明白敏捷这个词本身，以及容易混淆的其它软件开发方法的概念。例如：瀑布、RUP、精益、看板等容易被混淆的词汇，还有被人津津乐道的小瀑布。
瀑布模型（Waterfall model）是人们最早的软件开发方法，它的本质是模仿制造业、建筑业的管理方式，将软件开发过程分为若干个阶段，每个阶段线性、依次进行。
瀑布模型被描述为 5 个经典的步骤：

需求定义（Requirements）
设计（Design）
实现（Implementation）
集成与测试（Integration）
移交与维护（MAIntenance）

由于固化的工作流模式，对于复杂软件来说并不好用，在瀑布模型一出现就引来不少批评，甚至包括提出瀑布模型之一的 Royce 。于是业界致力于探索增量式开发、迭代式开发，因此出现了一大堆相关方法论：水晶清透法、特性驱动、极限编程、Scrum 等。
敏捷实际上不是某个明确的开发方法，而代表增量、迭代的一类开发方法。由于其特征明显区别于瀑布，说敏捷打败了 RUP 实际上不是非常准确。
在 2001 年，十七名软件开发人员在犹他州的雪鸟度假村会面，将这些方法论概括起来，并取了一个标志性的名称——敏捷，同时也发布了著名的敏捷宣言。谁也料不到，当时一个小会议，对软件开发方法产生了巨大的影响。
这群人还搞了一个联盟，将敏捷的一些词汇做了定义，将其标准化，网站为：https://www.agilealliance.org/agile101/agile-glossary/
这个网站是目前能找到对敏捷相关词汇最权威的网站。
总结一下，与瀑布瀑布代表的是严格遵守过程的开发风格相对，敏捷代表增量、迭代的一类开发风格。
在概念上，符合此类特征的软件开发方法都可以被称为敏捷，例如：

Scrum
极限编程（XP）
功能驱动开发（FDD）
看板
精益软件开发
RUP

但是，由于敏捷不是一个明确的开发框架，所以就经常被当做一个任人打扮的小姑娘。
“没有文档，我们这是敏捷”
“需求调整，明天上线，我们这是敏捷”
“不做规划，做一点改一点，我们这是敏捷”
“项目没有做好，不够敏捷”
所以敏捷是一个非常宽泛的概念，很多工作框架都指敏捷（我现在也不知道 Thoughtworks 敏捷是指的哪一种敏捷）。在维基百科中，敏捷软件开发被定义为：
是一种应对快速变化需求的一种软件开发模式，描述了一套软件开发的价值和原则。
敏捷宣言和价值观在提到敏捷时，必不可少的就是敏捷宣言。敏捷宣言是雪鸟会议最具代表性的产出物，更像是口号性质的内容。
【当我们在谈敏捷时我们在谈什么？】敏捷宣言：
个体和互动：高于流程和工具。工作的软件：高于详尽的文档。客户合作：高于合同谈判。响应变化：高于遵循计划。
参考资料：https://agilemanifesto.org/iso/zhchs/manifesto.html
敏捷宣言中有很重要一句补充，当往往被人选择性忽视：“虽然他们也很重视右边的内容，但是更重视左边的内容” 。
也就是说为了实现左边的目标，我们更应该做好右边的内容。所以我们应该警惕：
敏捷不是三边项目，不是边设计、变开发、边验收。
敏捷不是随便响应变化，没有“纪律”和不能保持克制的团队无法运行敏捷。
敏捷不是抛弃文档、流程，而是避免形式化的文档、流程。
敏捷不是万能的软件工程方法，有些流量需求更适合看板方法，甚至有些公司采用多模的方式运行。
敏捷实践除此之外，一些工作实践也往往被敏捷文化吸收了，例如结对编程、TDD 等，不过这些实践也不一定是敏捷的专利。