我们先从微信的案例来看一下，其敏捷实现之道。
早在2006年接手 QQ 邮箱业务，按步照班一年过去，QQ 邮箱差点死掉。触到了底，团队开始反思，到底是哪儿错了。看起来似乎那都没错，但这恰恰是最大的错，用张小龙的话讲：“一个非常平庸的团队用了一些非常平庸的方法去做出来一个非常平庸的产品”，而且是不知不觉的，这样下去很危险。
当时QQ邮箱团队负责人的做法是拉出去了一个十个人的“敏捷小队”，有负责后台的，前端的，设计的，产品的，大家就都坐在一起。有什么想法、改进立马去实现，往往大家讨论的需求，可能夜里或第二天一早就出来了。正是这种敏捷的方法，让 QQ 邮箱触底反弹，起死回生。
作为中国最早的一批知名程序员，早在加入腾讯以前，张小龙就知道“小快灵”对技术研发意味着什么。要知道， Foxmail 的第一个版本就是他一个人写出来的。
张小龙团队对敏捷的实践，就这么一直延续。
为了给产品决策者提供最大的自由度，敏捷原则成为整个微信开发流程的指导原则。对微信来说，在发布前的十分钟，也是允许产品决策者提出变更的。不断修改，不断试错，这已经成了微信的特色。对有着海量用户、单一的功能每天可能会承受上百亿访问的微信来说，这种产品变动是相当大的挑战，但微信做到了。可想而知，微信的研发承担了多大的压力。
如果要说敏捷的最大局限性，可能就在于对技术人员的高要求。程序员出身的张小龙对研发人员的要求就是“没有技术实现不了的”，如果实现不了，就再来一次，两次，三次。研发团队的支持，给了产品决策最大的自由，这也是微信胜出的关键之一。
那么，什么是敏捷?
敏捷软件开发(Agile Software Development)从1990年开始逐渐引起广泛关注，与传统的瀑布开发模式相比较，敏捷开发更快、更轻、更灵活，是一种应对快速变化的需求的一种软件开发能力。敏捷(Agile)这个词起源于17位技术高手在2001年发起的敏捷联盟，并确立了敏捷软件开发宣言。
敏捷软件开发宣言：
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。
由此我们建立了如下价值观：
个体和互动高于流程和工具
工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。
Tripwire 前创始人及 CTO Gene Kim 在他的白皮书《The Top 11 Things You Need to Know about DevOps》里写道：“相对于瀑布开发模式，敏捷开发过程的一个基本原则就是以更快的频率交付最小化可用的软件。在敏捷的目标里，最明显的是在每个 Sprint 的迭代周期末尾，都具备可以交付的功能。”
敏捷强调团队之间的紧密协作、面对面的沟通，是一种以人为本、迭代、循环渐进的开发方法。在互联网时代，敏捷作为一种快速迭代，迅速试错，小步快跑的开发方式，逐渐成为互联网公司角逐竞争的有力砝码。
快速迭代、小步快跑
敏捷不光是快，还是灵活，实际中强调对需求的快速响应和适应。敏捷开发要求最小可行化验证(也就是精益创业里的 MVP 法则)，及时调整，增量迭代。也就是说，在敏捷开发里，快速试错是允许的，产品快速迭代，迅速收集反馈，并不断优化完善，这是一个健康的产品研发流程。
在互联网时代，不试错，不敢犯错的技术团队是可悲的，这只是意味着在用平庸的方法来做事。事实上，敏捷的产品开发，会利用一切可实现的方式来规避风险，比如微信的所有产品功能迭代会通过灰度发布和A/B测试的方法先小流量测试，通过了再全量发布，将风险降到最低，也获取了迭代反馈。海量用户和迭代风险绝不是拒绝拥抱敏捷的理由，从某些意义上讲，拥抱敏捷是拥抱变化和适应互联网发展节奏的表现。
敏捷带来一个最好的心理感受是什么呢?我们今天可以想一些与众不同的点子，然后我们可以很快就看到效果，因为我们可以很快把它上线了，然后可以去验证，如果不对就下线，如果还有改进余地，下个星期再去改它。如果改了还不行，那继续下线，如果改了行，它一定很好……这是一个能够持续实现你的想法的过程。最后，我们来看看敏捷宣言遵循的原则，体会敏捷之美。
我们遵循以下原则：
我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
欣然面对需求变化，即使在开发后期也一样。
为了客户的竞争优势，敏捷过程掌控变化。
经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
业务人员和开发人员必须相互合作，项目中的每一天都不例外。
激发个体的斗志，以他们为核心搭建项目。
提供所需的环境和支援，辅以信任，从而达成目标。
不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
可工作的软件是进度的首要度量标准。
敏捷过程倡导可持续开发。
责任人、开发人员和用户要能够共同维持其步调稳定延续。
坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
以简洁为本，它是极力减少不必要工作量的艺术。
最好的架构、需求和设计出自自组织团队。
团队定期地反思如何能提高成效，并依此调整自身的举止表现。
