敏捷，我的故事

一个流行的概念，往往大部分人都不懂

对于敏捷的定义，维基百科上如下说也：

敏捷软件开发（英语：Agile software development），又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。

敏捷宣言如下：

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

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

客户合作高于 合同谈判

响应变化高于 遵循计划

上面的定义和宣言，相比传统的瀑布，核心思想是响应变化、小步构建、不断验证以快速寻求反馈，做出高价值产物。一切都是为了提高软件的可视性，从而让客户能更早的审视产品价值，从而快速调整，所以我觉得寻求反馈是敏捷的核心思想。

我的敏捷之路

在没有加入ThoughtWorks之前，我大概听到过敏捷，但是当时觉的Pair很邪乎，老板怎么能让两个人干一份活呢。4年前，有幸加入ThoughtWorks，开始了对于敏捷的“守、破、离”。

守

刚加入公司，我还是一个开发，在北京的一个项目上，和团队一起Iteration Plan Meeting、站会、Kick Off、Pair编码、Sign Off、Showcase、Retrospective。

给我最深震撼的是Retrospective和Pair。在Retrospective过程中，团队的所有人一起说团队哪些做的好，哪些做的不好，哪些可以改善。对于做的不好的和待改善的点，通过大家一起讨论从而产出若干Action，以便让项目的各个方面都朝好的方面发展。

在Pair过程中，两人一起澄清问题、思考解决方案、编码，整个过程思维高度集中，且“三个猪皮将顶一个诸葛亮”，往往思路更广，写出来的代码精致且bug少。

这个阶段，我就是不断的熟悉敏捷各种活动的套路，一招一式，此谓守。

破

在熟悉了各种敏捷活动之后，就开始思考这些活动到底为什么会给项目、团队带来好处，以及在具体实施的时候，有没有可以改善的点。

比如Sign Off应该由谁drive，之前团队是由QA，是不是让开发drive更合适，能让开发有更好的责任心呢？Retrospective是一定每个迭代完成才需要，是不是团队觉得有问题的时候，就可以来一场呢？不是每个Story都要Pair，简单的Story是不是可以不用呢？Code Review的标准和目的到底是什么？应该不止检查语法、逻辑错误，更多的是交流设计和想法。估点为什么花那么长时间，结果估的还不准确？

除过反思每一个活动，有考虑他们背后到底是为了干什么？IPM，Kick Off都是为了让团队正确的理解业务，Sign Off，Showcase是为了让团队对产出的结果进行对齐，确保做的东西是正确的，客户想要的。Pair是为了保证质量，同时共享知识。

这些活动背后的理念，了解到敏捷并不确保快速产出，敏捷用这么多实践来确保工作方向的正确性和质量。

离

敏捷，以核心的理念为支柱，若干原则为指导，并用敏捷活动来实现，以期用正确的方式，做正确的事。

敏捷也是为了做出更好的产出为目标的，如果做的事情，需求变动不多，需要自上而下的方式，则也不要迷信敏捷。比如：火箭驱动系统用瀑布开发更加适合。

对于具体项目，用敏捷还是瀑布？若用敏捷的话，具体用哪些敏捷活动，具体怎么用？不要所有的活动都生搬硬套，要针对项目具体情况，人员情况，具体定制。还是那句老话，具体问题具体分析。

敏捷，就是拥抱变化，快速迭代，寻求反馈，且过程中不断持续改进。