进入具体的管理工作，我们只谈真实的敏捷团队和问题，本文总结了敏捷实践中最关键的一些概念来诠释敏捷这个词本身的含义。
敏捷的概念包含价值观和原则、敏捷软件开发具体的工作框架、常见敏捷实践、敏捷迭代会议等内容。
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 等，不过这些实践也不一定是敏捷的专利。
敏捷中很多实践更多的被当做工具库，按需实践，很多实践甚至需要付出巨大成本，因此在我们实际工作中都需要被裁剪。
实话说，有些被纳入敏捷中的实践在工作中并不好用，更像是皇帝的新装。
迭代和增量式开发（IID）
迭代是敏捷开发最显著的特征。我个人的理解为人们无法做到像瀑布模型描述的那样准确完成所有的设计，并精确实施。
迭代的用途有下面一些：
- 响应在开发阶段接收到的最新需求和变化。
- 我们无法精确完成所有的前期设计。
- 不能接受在最后一刻才进行集成。
- 。。。
在现实中，迭代是一种克制和权衡。 敏捷拥抱变化，但是尽量在迭代中别变化，否则固定的迭代就没有了意义。
迭代这个话题的另外包括迭代周期是否固定、周期多长的问题。
在实践中，迭代周期不固定非常难操作，团队的整体习惯难以培养，有点类似倒时差的感觉。
常见的迭代周期有一周、两周、四周等，迭代周期越长越像瀑布，迭代周期越短越像精益，而迭代周期适中就很像 Scrum。
Scrum 一般以两周、四周作为迭代周期，适合大部分项目。
其实，由于每个迭代都要重复很多活动，迭代会增加成本。迭代在敏捷中的作用是：牺牲局部效率，减少分工，提高整体效率。
跨职能团队
敏捷的另外一个显著特点是跨职能团队。跨职能团队的意思是，不会将团队按照专业岗位划分，而是将不同的角色混编到一个团队。
在跨职能团队的每个人集成起来，让敏捷团队看起来像一个增强的开发者，团队和团队之间是原子化和去中心化的。
我对跨职能团队的理解是，软件开发无法做到像生产型企业一样有序传递信息，知识型团队和生产型团队有本质差异。
举个例子，生产型团队的加工过程都是被优化过的固定模式，所以他们更强调流程、秩序，产品从设计部门、组装部门、测试部门都有明确的标准、考核方式。
但是，软件工程不是这样的。软件工程长期以来被比喻为建筑业、制造业，其实更像是出版业。 我们无法像工厂一样工作，几十上百人合作编写一部百万字的巨著。
知识性团队的信息传递变得更加不可靠、不确定且多变，跨职能团队才能合作更加紧密。
看板和消息辐射器
使用看板并不是敏捷最初的特点，甚至不是必选项，看板在敏捷中作为"消息辐射器"存在。
看板是"消息辐射器"最主要的形式。"消息辐射器"是指在团队日常工作中，需要一个信息发布的公告板，这样所有人都能及时同步获取所有的信息。
一般来说常见的消息辐射器有：
- 任务看板：用来同步团队工作状态和任务清单。
- 燃尽图：用来显示团队的进度状态，燃尽的意图是团队作为一个整体，不以某个人作为进度追溯单位，而是整体拉通看项目进展。
- 流水线健康看板：展示持续集成流水线的健康状态，避免因为构建失败阻塞其它人的工作。
- 。。。
部署"消息辐射器"的意图有：
- 团队保持透明，不需要对来访者（客户和干系人）隐藏信息。
- 团队内部共享信息，不需要隐藏问题、知识和困难。
持续集成和发布
即使在迭代中，也需要避免返工和增量式构建，因此敏捷提倡持续集成和发布。
让软件随时处于集成状态和可发布状态。传统意义上，集成需要花费程序员一些工作和时间，但是结合持续集成工具的使用，持续集成环境被设置好后，现在几乎没有成本。
持续集成是现代软件工程显著的特点，让上规模的软件能可靠交付的保障之一，也让团队有序扩展变得可能。
用户故事和待办事项
为了做到上述实践和期望，在敏捷中需要将任务拆分到足够小，但是又能单独被验收、测试和集成。
所以使用了用户故事（User Story）这个概念。一个好的用户故事需要满足 INVEST 原则，这个原则对于其它形式的任务拆分也适用。
INVEST 分别代表以下原则：独立性（Independent）、可协商性（Negotiable）、有价值（Valuable）、可以估算性（Estimable）、短小（Small）、可测试性（Testable）。
这几项原则的出发点是为了让任务像水流一样可以流动，不至于阻塞团队。我们不必同时满足这几项原则，因为这几项原则可能在某些条件下矛盾，而是根据情况尽可能做到这些原则。
其中，独立和可被测试让任务可以一定程度上"单件流"，这样测试人员可以提前进行测试；可以估算和短小是为了不阻塞其他人，并能在迭代内部完成集成，满足迭代周期要求；可协商性、有价值是为了能快速给客户演示，并获取反馈。
反之，如果一个迭代必须所有任务合并起来测试，这就像瀑布一样整体分析、开发、提测，会带来人员空闲、集成风险增加的问题。
将用户故事放到团队的代办清单中就叫做 Backlog。Backlog 是一种弹性空间，我们需要假定团队的工作速度往往不是恒定的，如果工作状态良好就从 Backlog 中获取任务，如果团队进展不理想，就先把任务放回 Backlog。
估算和迭代计划
单纯有了用户故事还不够。如果我们需要计划迭代过程，就需要任务。团队中的任务往往分为四类：
- 用户故事
- 技术事项
- 日常工作事项
- Bug
团队 Backlog 主要构成为用户故事、技术事项，可以把用户故事进行估算就成了任务。技术事项往往不满足 INVEST 特点，所以常常不被看做用户故事，特殊处理不过也需要估算工作量。
在常见的敏捷实践中，有两种估算形式。一种是通过人天来进行估算，一种是通过复杂性来估算。
通过人天估算很容易理解，就是团队的平均水平而言，完成一项任务需要多少天时间。而通过复杂度估算比较复杂，需要找到一项可以参考的任务作为 1 个基本点，其它任务根据这个基本点来进行估算。
在以前的项目中，非常流行使用复杂度估算，并通过斐波那锲数列进行递增（这当中的科学道理我并不知道，也可能是一种文化）；现在越来越多的项目回归人天估算，因为更具有操作性。
通过对任务的估算并结合每个迭代投入的人员数量，可以计算出这个迭代的能完成的任务量，并做合理的规划。
毕竟制定一个永远无法完成的计划和没有计划的结果类似。
敏捷会议
当我们谈论敏捷时，另外一个方面是敏捷的会议。
敏捷中有很多会议一般以 Scrum 为代表，有很多文章都介绍过这些会议。这篇文章中，我尝试把这些会议和具体解决的问题映射上。
和敏捷实践相比，会议更像套路，所以需要根据实际环境裁剪制定，这也是为什么没有一套标准的工作框架流行开的原因。
站会
站会和大家熟悉的晨会是一样的，站立会议的目的是为了更加高效，追求尽快结束。
站会的目标是更新每项任务的状态，同步团队信息，发现和解决阻塞项。一般有两种运行模型，一种是基于任务清单更新，也可以基于参会人轮流更新。
站会陈述的模板一般为三段：
- 昨天做了什么？
- 今天做了什么？
- 遇到了什么困难？
工作量评估会议
工作量评估会议和敏捷实践中的估算对应，是为了更好的进行迭代计划。
工作量估算会议的另外一个用途是对需求的进一步澄清，在工作量评估会议之前，需要完成技术方案设计，才能有效评估出工作量。
在某些团队中，工作量评估会议需要全员参与并投票，并陈述差异。不过这种实践参会成本太高，往往会被简化为关键人员参与即可。
工作量评估会议发生在迭代开始之前。
迭代计划会议
工作量评估会议完成后，项目经理或者迭代经理需要计划下一个迭代，包括需求、人员规模、时间等内容。
迭代计划会议的目的是将迭代计划和整个团队同步，有时候也会包含业务需求串讲和同步。
迭代计划会议往往发生在迭代前或者迭代的第一天，迭代计划会议前需要准备好所有的任务清单。
开卡、结卡
在敏捷会议中，非常具有仪式感的会议就是开卡、结卡（因为很多时候任务被以卡片的形式书写并放到看板上管理的）。
开卡的意思是开发人员领取任务时候需要找业务人员、测试人员对齐该项任务的内容，所以一般由三方人员参会故被称为 "Three Amigos"。
结卡同理，当完成任务后，开发人员需要找到业务人员、测试人员进行验收，然后该任务会流转到下一环节。
实际上 "Three Amigos" 会占据大量的时间，但是在实践中却能起到非常不错的效果。其原因是，业务人员无法通过需求文档将任务无歧义的传递清楚，认真践行"Three Amigos"可以澄清需求，甚至需求不清楚的情况下，开发人员可以拒绝领取该任务。
回顾会议
回顾其实就是复盘，回顾会议让敏捷迭代自洽，让其工作方式也能更新。
回顾会议往往发生在迭代结束后，通过组织全员的头脑风暴，主持者营造一个安全的环境下，获取团队的反馈，并进行改进。
回顾的方式非常多，有兴趣可以参考我之前的文章《用归零的心态，做好团队回顾》
在敏捷中回顾会议是周期性，这一点和很多企业内部的复盘会议不太一样。敏捷中的回顾强调向前看，不能将其变成惩罚性质的批评会，这样无法起到改进工作流程的目的。
总结
敏捷概念的开放性让敏捷学习者和实践者无所适从。其实很多时候，我们在谈敏捷时，仅仅在谈一种理念，因此这种理念可以被用到除了工作之外的很多地方。
如果要在团队中实践敏捷最好选择一个框架执行，例如 Scrum 就是一个经典的敏捷框架。
关于敏捷和技术管理，不仅要坐而论道，知道原理，还需要下地干活，在实践中体会。