前言
在本系列上一篇博文 《敏捷Agile概述，何为敏捷？》 中，我们初步介绍了何为敏捷，敏捷提出的背景和为什么目前得到了广泛的应用。
但敏捷本身，更多只是一种价值观，是一个思想层面的指引。在组织中实际应用，还是需要借助一些具体的实践模型来进行落地。随着敏捷的发展，其实涌现出非常多不同的实践模型，基于这些模型来组织我们的研发过程，都可以称之为敏捷研发。
下面，我们将重点梳理下，在敏捷研发实践中，比较常见的一些模型以及它们的优缺点。
团队级敏捷
敏捷从提出之初，更多是首先从开发者的个人视角出发，在软件开发、协作过程中，希望建立的合作关系和开发理念，这种合作，通常是团队内部的开发协作。所以敏捷初期的主要实践模型，主要还是面向团队级别的实践。
Scrum
Scrum其实提出得比较早，1995年，Jeff Sutherland和Ken Schwaber在他们的论文《Scrum_软件开发过程》中首次提出了Scrum框架。这两位也都参与了敏捷宣言的签署。
随着敏捷的推广，Scrum被广为采用。根据最新版的敏捷状态报告(17th)，Scrum 依然是目前最流行的团队级敏捷框架，调查的团队中使用率超过6成。所以完全可以说，Scrum就代表了敏捷的主流实践。
我们这个系列后续的敏捷实践分享，也将主要以 Scrum 为准来进行探讨。
Scrum 模型框架的的构成：
- 核心过程：以Sprint 为固定研发周期
- 三大角色定义：PO、Scrum Master、Dev Team
- 三大工件： PBI（产品待办清单）、SBI（Sprint 待办清单）、Increment（产品增量）
- 四大工作仪式：计划会、站会、评审会、回顾会
Scrum框架强调以一个固定的短研发周期（sprint），定期地交付产品的增量，通过四种不同的工作仪式来跟踪、协作日常工作，强调团队自组织和紧密、机动的合作关系。
Kanban
Kanban 其实起源更早，来源于上世纪四十年代丰田汽车的生产管理理论。强调的是用一种可视化的方式来提高工作效率，同时便于工作流的调整和优化。
Kanban的核心原则是通过可视化的看板向所有成员清晰地展示项目进度和工作分配情况，限制在制品的数量避免过载和积压导致资源浪费，在看板上定义并区分出清晰的工作流程，如任务的创建、分派、执行、测试和完成等。 强调持续集成，通过定期回顾来进行持续改进。
极限编程（XP）
极限编程（Extreame Programming）简称 XP，是Kent Beck在1996年提出并在自己参与的C3项目中进行了实践。
Kent Beck 进行 XP 实践的C3项目，是克莱斯勒公司的一个薪酬管理系统，项目参与人包括多位后来敏捷运动的重要人物，如敏捷宣言的另两位签署人Ron Jeffries， Ward Cunningham也都参与过该项目。但该项目其实并不成功，延期多个月才交付，并且在运作了一段时间后因为存在严重性能问题，之后被彻底关闭。还是比较讽刺的。
XP 主要从团队运作、研发过程和开发技术实践三个维度， 定义了13种实践原则，包括持续集成、结对编程、测试驱动开发、客户验收等等，对后续敏捷宣言以及敏捷的12条原则有重要影响。
精益研发（Lean）
Lean Development，精益研发，其实也是脱胎于丰田的精益生产管理理论。
后来发展到软件领域，主要包括以下7大核心：
-
消除浪费：Eliminate Waste
-
内嵌质量：Build Quality In
-
创造知识：Create Knowledage
-
延迟决策：Defer Commitment
-
快速交付：Deliver Fast
-
尊重他人：Respect People
-
整体优化：Optimize Whole
精益更强调在向用户交付价值的同时尽可能消除浪费，并从更整体的业务环境来看待研发。
水晶方法（Crystal）
水晶法是Alistair Cockburn于 1991 年为 IBM 开发的一种团队协作和沟通制定指导方针，Alistair Cockburn被认为是敏捷早期的普及者，敏捷宣言发表后，包括Crystal在内的方法开始走入大家的视野。
水晶方法可细化为透明水晶方法（Crystal Clear）、黄色水晶方法（Crystal Yellow）、橙色水晶方法（Crystal Orange）以及红色水晶方法（Crystal Red）。这几种水晶方法论按照项目重要程度以及参加人员规模进行划分。
- Crystal Clear ： 6人左右的团队
- Crystal Yellow：20人左右
- Crystal Orange：40人左右
- Crystal Red：80人左右
Crystal方法中同样也强调了7大主要特征：
1. 经常交付
2. 反思改进
3. 渗透式交流
4. 个人安全
5. 焦点
6. 与专家、用户建立方便的联系
7. 自动化测试、配置管理和经常集成的技术环境
相比于XP、Scrum等，Crystal纪律性较弱，它的主要原则依据团队规模不同会动态变化，所以实际中被应用得并不多。
除了以上5种常见的团队敏捷框架外，还有类似DSM、FDD等团队级别的敏捷实践模型，但目前应用最广的其实主要还是Scrum。
敏捷模型虽然多种多样，实际应用其实也并没有非此即彼的排斥性，因为它们更多还是敏捷思想的落地，我们理解这些模型定义背后的出发点，取长补短应该才是更加务实地去进行敏捷实践的方式。
当然，现代软件的规模其实越来越庞大，仅仅依赖一个小型团队，并不能完成软件产品的系统级研发，这些基于团队级别的敏捷框架，如果应用到大型的软件系统，在组织级别的敏捷，通常并不适用，因此针对这种级别的敏捷，又出现了 大规模敏捷框架， 下一篇我们会继续分享敏捷框架中的这部分框架介绍。
