敏捷开发这个概念已经说了有十几年了，它对开发团队的角色做了划分，并且对各个角色的要求还很高，这实际上是对组织架构的一个颠覆，另外对工作流程，迭代周期都提出了理想定义。很多人觉得这是一种工作方式，照抄了一个模子，但是实际上这远远超出一般人的理解，所以很多公司尝试的时候发现效果并不如意，反而还很折腾，甚至最后搞得研发团队怨声载道，产品也没有做好。

首先敏捷开发是一个舶来品，国外流行的前提是研发人员的自我管理水平较高，敏捷开发要求研发人员具有责任心，能够推动任务前进，解决任务过程中遇到的部分问题。这个基本上就要求团队是一个自治的团队，只要有明确的目标和任务，团队就能往好的方向发展，但是实际上大部分团队都达不到这个要求。另外敏捷开发的主导人一般是公司领导，而大部分团队领导都习惯了自上而下的管理体系，很难将自身角色转变过来，对敏捷的理解也就仅仅停留在形式上。敏捷开发强调了任务为导向的快节奏体系，这要求PO和scrum mater对产品的把控能力很强，能为团队梳理出正确的产品方向，分解出合适的冲刺任务，并且能及时根据需求进行调整。所以主导人对敏捷开发的理解不同，以及团队水平的参差不齐导致了敏捷开发实现的程度不同。

上面说的是人的因素，在流程上，敏捷开发提出了迭代周期（sprint）、迭代会、每日站会、评审会、总结会。比如迭代周期为2-4周，而这个周期并不适合每一个产品，例如To B的产品用户可能会对上线时间提出明确要求，迭代会也极有可能开成群众座谈会。每日站会是一个争议较多的会，这个会能在一定程度保证每个人的方向，但是当车高速开起来之后，能看到车窗外风景的人就很少了，事情是做出来了，但是质量不好，缺少创新。这些又都和团队整体的素质有很大关系。

总之敏捷开发是一个很好的工作框架，但是实施起来难度很大。那么我们应该如何敏捷呢？

因地制宜，循序渐进。首先并不是所有的产品都适合敏捷开发，这个要区分好，不能所有的产品都往上套；其次我们需要逐步敏捷化，现在很多新兴的软件公司都在强调扁平化的松散管理模式，都在强调工程师文化，这就是在充分发掘工程师的主观能动性，我想当团队的人员素质提升的时候，敏捷只是一个发展的结果。

关于我们：[网易轻舟微服务]是围绕应用和微服务打造的一站式平台，以完整、易用的解决方案，解决微服务应用生命周期的所有问题，为业务研发提效。