敏捷开发
在国内大家对敏捷开发已经不算陌生了，在与很多产品和技术的聊天中大家都认为自己所使用的方法就是敏捷开发，而多数人对敏捷开发的理解就是「小步快跑」，两周一个版本。如果我们要扣字眼的话，这些都不是敏捷开发，只不过是敏捷开发的一个表面现象。不过我吃惊的不是很多人对敏捷开发不了解，而是仅仅对于敏捷开发的理解仅仅停留在两周一个版本，很少人去思考为什么是两周一个版本，一周不行吗？无论是产品经理还是开发人员，如果有认真思考过这个问题，那么对敏捷开发的理解也就不会这么表面了。
根据 Wikipedia 的描述，敏捷开发「是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于『非敏捷』，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。」
敏捷开发不是一种软件开发流程，而是一种框架，正如同你不能说 Javascript 是一个软件一样。作为一套框架，敏捷开发的目的是减少浪费。对于浪费，我们可以理解为做了一堆没有人用的功能，或者有人用但是有很多缺陷的功能，这样的产品和功能极大的浪费了开发人员的劳动，让他们的付出变得没有价值。浪费，即是「价值」的反义词，也就是说，敏捷开发的目的是为了追求产品的价值。
但是对于价值的追求实际上过于宏观，就如同没有人能够知道怎样才能获得成功一样，但是反过来思考，如果不造成浪费，那么就可以被认为是在创造价值了。正如前面所说，对于软件开发来说，浪费可能出现在两个地方，一个是开发的功能没有人使用（需求分析），另外一个就是有很多人用但是软件经常性崩溃导致用户无法使用（代码质量）。对于第一个问题，我们需要关注如何理解用户需求；对于第二个问题，我们则关注如何提升软件的代码质量。
我们前面说过，敏捷开发是一种框架，在这种框架下有需要不同的方法，例如 Scrum，Kanban，Xp 等，这些方法通过不同的途径来解决上面这两个问题。虽然方法不同，但其理念却是相同的，我们透过敏捷开发宣言我们可以了解到这种理念：
我们一直在实践中探寻更好的软件开发方法，
身体力行的同时也帮助他人。由此我们建立了如下价值观：个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划也就是说，尽管右项有其价值，
我们更重视左项的价值。
—— 敏捷软件开发宣言
个体和互动
个体和互动是敏捷团队的基础，也就是说并不是随时随地的都可以实践敏捷开发，敏捷开发对于其团队成员有一定的要求。一个敏捷团队中只需要少量的开发人员，通常是 7 个人左右，最多不会超过 14 人，因为随着人数的上升，所带来的沟通成本实际上会大于所带来的开发能力。同时敏捷开发对开发人员的能力有一定的要求，通常是比较高级的开发人员，能力对等也是降低沟通成本的一种方式，但也不进如此。
而最关键的是个体的互动，这种互动是在敏捷团队内部，要求所有团队成员之间要经常沟通，所谓「三个臭皮匠胜于诸葛亮」，团队内部的沟通能够让每个人对需求和目标的理解更加一致，从而减少因为需求理解不一致导致的重复性工作。在一些方法论中的「结对编程」就是对这个宣言的一种实践。
软件与文档
第二个宣言是很多反对敏捷的人经常拿来说事的，反对者认为敏捷开发不使用文档会影响后期产品的更新迭代生产，我们在实践中也遇到过类似的问题。但是敏捷开发并不反对使用文档，而是在传统的开发流程中，文档也是一种多余的存在。我看过很多产品经理的 PRD，每个小功能都写成一个 PRD，一个小小的产品竟然出现几十份 PRD，那么在未来如果需要对产品进行重构，那么是透过着几十份 PRD 整理出当前产品的逻辑简单，还是让开发之间阅读一份代码简单就是一个问题了。而且很多开发人员在开发过程是并不阅读 PRD，那么也就导致了 PRD 实际上并不能真实的反映产品现有的逻辑，更不用说很多时候文档之间还会出现相互矛盾的地方。
既然文档无法反映产品最真实的逻辑，那么只有代码本身可以说明清楚了，那么为什么我们需要一堆年久失修，没有人维护的文档，何不直接使用代码作为文档，在开发过程中保持代码的整洁，让其他人也能够清楚的理解当中的逻辑。
文档并不是没有价值，而是及时更新的文档才有价值，那些年久失修，开发也不愿意去看的文档自然是没有价值的。在我们的实践中，有些文档是在开发之后作为补充才写的，有些文档则是设计过程中与开发一起讨论的结果，无论是何时写，怎么写，文档都需要可以清晰且准确的反映软件的逻辑。
客户合作
很多敏捷开发的方法中并没有太多的涉及到客户合作，反而是设计过程中开始越来越多的注重与客户的沟通，在一些敏捷设计的方法中，有一种称之为 Co-Design 的方式，就是让客户直接参与到软件的设计当中，由客户来书写用户故事，这样才能够真实的反映客户的诉求。
很多时候客户的诉求并不能一次全部提出来，在与客户的不断沟通中这些诉求回一个个的出现，这些过程都需要我们持续的与客户沟通，从而避免开发出没有人使用的功能。
相应变化
开发人员经常会讨厌需求的变动，希望可以有一个不变的需求，但实际上这几乎是不可能的。在当今的互联网环境中，新技术不断的涌现，人们的个性化需求也不断的变化着，想要让产品更加贴合目标用户，就需要去快速应对用户需求的这种变化。而实际上，这个世界本来就是在不断变化的，以前人们因为信息流通的问题，无法快速感知遥远地区发生的种种变革，而如今通讯极度发达，任何地区的小小变革都可能会影响整个世界。
那么既然这种变化是不可避免的，那么我们为什么要去抵制呢，何不寻求一种可以快速响应变化的方法来帮助我们更好的应付变化。这也是敏捷开发所追求，前文我们提到敏捷开发是为了避免浪费，如果我们已经知道了浪费就是没有人用的功能，但是这个设定就如同薛定谔的猫一样，如果你不上线这个功能，你怎么知道这个功能有没有人用呢？既然我们要上线才能知道结果，那么为了避免浪费，那么我们就需要使用最小的成本来开发，万一上线之后真的没有人使用，那么我们浪费的成本也是最小的。
软件开发有时候就像是摸着石头过河，因为没有人可以预知未来，没有人在软件发布之前就可以保证这个软件和大卖或者无人问津，一切都需要发布之后才能揭晓，如果成功，那么人们会继续投入精力在这个产品上；如果失败，就需要作出改变调整方向。所以我们可以理解为敏捷开发实际上就是在以小博大，以最小的成本以求获得最大的收益。通过小成本的对未来的不断试探，来找到产品适合的方向。
从另一个角度来看，敏捷开发就是在不断的「规避风险」，如果真的遇上风险，那就将风险降至最低。因为没有人知道怎样才能成功，但是人人都知道怎样才会失败，那么我们在软件开发的过程中尽可能的避免自己不失败，也就算是一个成功了。