前言

敏捷(Agile)到底是什么(是Scrum，是XP-Extreme Programing还是Lean或是其它)？在软件行业中”敏捷”已成为软件工程的一个专业术语。我相信现在没有哪个企业会承认自己还在使用瀑布模式(Water Fall)，但是没有遵循瀑布流程就是敏捷了吗？反过来我们用了某些敏捷的流程或工具我们就能标榜自己是敏捷吗？

敏捷是什么

敏捷的流行已经促成了一个全新产业的形成，新的名词和方法论不断的推陈出新，我们在追逐“新事物”时却开始迷失我们的初衷- 为什么做敏捷。当然这里因素有很多，产业扩张的浮躁，互联网时代知识焦虑的迎合，很多培训在大肆宣扬方法和流程的同时在不停地淡化本质(因为人们变得不愿意思考，希望拿到的就是能解开所有问题的万能钥匙)。所以回到一开始的问题，我相信你会得到很多类似scrum是敏捷（以偏概全），敏捷是拥抱变化，不停地迭代（只是敏捷的特点之一）等答案。敏捷是什么很难通过几句话解释清楚，事实上敏捷也没有标准的官方定义。

很多具体方法的出现源于具体问题，而问题的产生都有时代的背景，敏捷也是如此。我们总是拿瀑布和敏捷作比较，可是敏捷的出现并不是解决瀑布的问题，事实上瀑布和敏捷都开始于20世纪的70年代，只是瀑布模型更适合解决当时的问题，从而得到发展，但是随着时间的推移，在这个完全由软件定义的时代，瀑布模型不再适合现在开发面临的挑战，所以敏捷再次被大家关注和扩展。敏捷关注的是以人为本和对变化的适应性，2001年发布的敏捷宣言本质上也在强调这两点。

以下是敏捷的4个价值和12条准则：

个体和互动 高于 流程和工具

工作的软件 高于 详尽的文档

客户合作 高于 合同谈判

响应变化 高于 遵循计划

1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。

2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。

3. 经常地交付可工作的软件,相隔几星期或一两个月，倾向于采取较短的周期。

4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。

5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

7. 可工作的软件是进度的首要度量标准。

8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

10. 以简洁为本，它是极力减少不必要工作量的艺术。

11. 最好的架构、需求和设计出自自组织团队。

12. 团队定期地反思如何能提高成效，并依此调整自身的举止表现。

请真正体会以上内容，你会发现我们无论是现在的Scrum，XP还是CI/CD（持续集成持续部署）都是在利用一些具体的方法和工具让我们朝着4个价值和12条准则努力。

Scrum vs XP

敏捷宣言并没有定义敏捷的具体方法，它只是定义了敏捷应该具备的理想愿景。无论是Scrum、XP或者(精益)Lean都是具体的方法，让我们更接近敏捷，团队是否敏捷，并不是你使用了这些方法，而是你是否结合自身的条件并落实到位。敏捷其实是多维度的，敏捷既然以人为本，那么它必然涉及人的管理；敏捷既然关注交付，那么它也会涉及项目管理；Lean和Scrum在这两个维度总结了很多方法。如果你是在使用Scrum那么你会发现日常的会议变多了(daily, planning, grooming, retrospective meeting等)。会议的意义是让整个团队能更有效的交流并达成一致，让信息更透明更有效的传递给每一个人。但是就像我在优秀团队中提到的，会议是把双刃剑，组织一个会议的成本很高，无效的会议会使团队变得低效，所以在使用Scrum的之前请确保团队已经了解每个会议的意义以及目的。Scrum很强调团队的自主性，这点我持保留意见，优秀的团队我应该充分的赋予他们自主权，但并不是所有团队都知道自己应该怎么做(尤其是一些年轻的团队)，他们需要一定的指导或者方法告诉他们如何做正确的事。否则过度“信任”团队的自主性反而会导致最终结果的不一致。

敏捷很强调迭代的周期，尤其作为面向项目管理的Scrum更是如此，我们的项目进度是一目了然了，我们需求实现的反馈更快了，但这大部分是解决了管理上的痛点，那作为程序员的我们的痛点谁来解决？代码的质量，复杂的依赖，以及功能集成等这些和技术相关的问题如何保证敏捷。只有项目管理层面的敏捷就像中国快速增长的GDP后面拖着一个房地产，它有可持续性吗？现在市面上很多Scrum培训都在强调项目管理，如何让开发变得更敏捷则一笔带过，很多讲师甚至都没有开发经验？敏捷是多维度的！敏捷方法不等于敏捷，不要只使用一种方法，否则你会发现你正在背离敏捷宣言的价值观。作为一个程序员，我希望大家应该了解下XP(尤其阅读下KentBeck写的《Extreme Programming Explained》)虽然现在感觉听到XP的声音越来越少，但是我相信在我们的日常工作中已经或多或少的在应用一些它提到方法，XP更多的是站在程序员（KentBeck就是程序员出生）的角度提出了敏捷的实践方式，比如TDD，结对编程，重构，YAGNI等，它从另一个维度来解释敏捷。

没有哪种敏捷方法绝对的好，找到适合自己的方法，才是真正的敏捷，在使用任何敏捷方法前，请务必确认你已深刻理解敏捷宣言（很多团队天天在说自己在做敏捷，很多培训师天天在讲敏捷，并为敏捷创造了很多专业名称和所谓的方法论，但是他们往往忽略了做敏捷真正的初心是什么）。

敏捷的误区

我们做的是敏捷吗？敏捷并没有给我们带来太多的改变？敏捷只是管理层压榨我们的又一种方式(世界到处充满了阴谋论)。网络上到处都能看到这些言论，是敏捷错了吗？还是我们错了？如果回到之前的敏捷宣言，你觉得敏捷有问题吗—好像很难找到哪里有明显问题。那为什么我们做的都是敏捷，最后的感觉和效果却千差万别呢？

1. 形式教条大于意图：很多时候我们总是拿着某些条条框框告诉团队，敏捷要我们开这些会那些会，敏捷要我们两周一个迭代等等，没错，开会的目的是让我们有效的沟通，让我们一起反思如何提高团队的效率，如果开会没有达到这样的效果，我们还需要这样的会议吗？如果团队两周都没有一个可交付的输出，那么我们还要硬性的将两周作为迭代的周期吗？缩短迭代周期的目的是为了及时得获取产品需求和质量上的反馈，如果两周没有一个可交付的输出，我们需要的是停下来，找原因。千万不要认为我们有daily meeting, planning meeting, grooming meeting, retrospective meeting我们就是在做Scrum，不是遵循Scrum的框架我们就是敏捷。如果只是机械的照搬流程，那效果可想而知。敏捷应该是一个名词（可惜英文是个形容词），它是我们期望的目标，使用的某些方法或流程只是让我们尽可能达到期望的目标，他们既不是充分条件也不是必要条件。

2. 敏捷做成了小瀑布：在很多次Retrospective meeting(反思会)上，总是能听到一些人抱怨需求老在变化。敏捷不是拥抱变化吗？很多团队在做敏捷时，仍然在机械的将瀑布的方式拆分到每一个迭代周期中。开发依然只关心写代码，测试依然等着开发的功能，产品经理依旧独自的思考需求方案。敏捷是大家一起参与到每个环节，需求大家可以一起讨论，产品经理可以从客户角度，开发可以从技术角度，测试可以从质量角度一起讨论出一个合适的方案。开发过程中，测试可以先写测试用例，而不是等待功能，开发可以通过持续集成，少量多次的提交阶段性成果给测试或产品经理，获取反馈，并及时调整。其次敏捷不仅仅关注项目，还关注每个人的个体，这不是简简单单的模式流程，它需要每个人要深入的认识到敏捷到底是什么。

3. 敏捷方法不是银弹：每个角色对敏捷的理解和期望是不同的，管理者关注的是项目的进度和团队的产出；员工关注的是自身的发展和回报；客户关心的是需求是否得到满足。某些敏捷方法可以解决部分问题，但是它解决不了所有问题，就像软件工程没有银弹一样，敏捷的具体方法也不是。不要期望用了敏捷的某种流程或方法，员工的效率就可以提高，产品质量就能得到保证，客户需求可以得到满足。敏捷带给你的是思路，只有通过结合自身不断的实践试错找到真正适合自己的方法。敏捷路上没有终点，它是我们持续进步的过程。不要把希望寄托在某个敏捷方法上，敏捷方法不等于敏捷，敏捷本身没有问题，问题在最后的执行和落实。不要崇尚任何一种敏捷方法：

4. 不愿改变的组织架构：当一个组织希望引入敏捷时，说明公司原有的体制和架构有些问题，敏捷很强调变化，而第一个要变的就是组织架构。敏捷要不把组织架构拍平，要不就把组织架构拍碎，否则所有的方法都只能流于形式。设想一个组织测试和开发隶属不同的职能部门，那么出现问题时你就会发现，原本应该紧密合作的事情最后变成了踢皮球。公司层级越多，沟通效率就越低，官僚作风就越严重。任何好的方法都有适合自己的土壤(橘生于淮南则为橘生于淮北则为枳)。扁平的组织架构是敏捷的基础，既然已经决定要做敏捷了，那就拥抱变化吧，这里的变化不仅仅是需求的变化，还包括组织结构，管理，技术等。你做好了开始敏捷的准备了吗？

后记

一生二二生三三生万物，千千万万的方法，不如原始的本真。敏捷也是如此，让我们放下所有的敏捷方法，问问自己，我想要的是什么？敏捷宣言中的价值观和准则是你想要的吗？如果是，那么请你在执行任何方法时，提醒自己我这样做的目的是否和我的初衷一致。