今天在公司参加了关于淘宝是不是敏捷流程的辩论，有了很多感触，也有了很多的思考，感触是整个测试部门甚至研发部门已经开始如此深入关注敏捷模型了，因为敏捷模型的确有其优势，能够给整个研发工作带来一定的好处；思考是因为淘宝现在是敏捷流程吗，如果不是，那么敏捷流程适合淘宝吗？

　　首先谈谈感触，敏捷模型在上个世纪的最后一年就已经被几个业界泰斗给提出来了，到目前为止已经在业界推崇了十几年，而且保持长盛不衰，成为了瀑布模型的强有力的竞争者。敏捷模型首先是在美国流行，后来传入国内，这几年来，无数的软件公司和互联网公司都在学习实践这个模型，说明这个模型一定有很多地方是值得我们学习的，而我们现在研究这个模型尝试这个模型，取其精华，弃其糟粕，相信对提高整个研发效率，完善整个研发体系都是极其有帮助的。

　　再谈谈思考。

　　首先我们要搞清楚敏捷模型的定义，什么是敏捷，我们要明确一点，敏捷模型和瀑布模型一样，关注的是过程，而非结果，高质量的软件发布，客户满意度的迅速提高都是结果，都是采用一种模型实践过后的结果，因此度量一个项目团队是不是在采用敏捷模型，并不是看这个公司软件上线的结果，而应该具体考量，为了让软件上线，项目团队做了哪些具体的工作。因此敏捷开发是一种以人为核心的、迭代的、循序渐进的开发方法和过程。

　　其次我们再看看敏捷的几个要素：

　　1.    人员沟通

　　敏捷模型中对沟通的要求很明确，就是沟通要简单、高效、明确，因为简单、高效、明确的沟通可以带来问题的快速解决，小黑屋式的沟通的确很快速很高效，但是各个项目情况不同，不是所有项目都可以达到这个水平，但是我们可以通过各种渠道建立良好的沟通，人员沟通关键在于人的主观能动性和理解力，而非渠道。

　　2.    流程迭代

　　什么叫迭代，迭代本身是一个完整的流程，而很多个迭代加起来就是一个螺旋上升的过程，而螺旋上升到达顶点，就意味着敏捷流程结束，软件成功发布。而一个迭代本身则相当于一个完整的瀑布模型，覆盖了从需求到设计到编码到部署到测试等一些列动作，而每个迭代结束就应该发布一个可以运行的版本，当然这个版本不一定是完整的，但是随着螺旋上升，以后的版本会越来越完整。这个就是迭代的核心所在，也正是因为这种迭代式研发，需求的变更才会受到欢迎。

　　3.    客户参与

　　客户的需求就是软件项目存在的价值，如果软件发布以后满足不了客户的需求，甚至于客户的需求背道而驰，那么就算这个软件做得再好，技术再先进，也不会有市场，那么这个软件项目的价值也就不复存在了，在敏捷模型强调的其中一个要素就是客户或者客户代表参与，每个迭代结束，客户或者客户代表需要对这个迭代进行验收测试，以确保每个迭代结束的成果是符合客户需求的，这样一直到螺旋上升的顶点，最终发布出来的软件也是满足客户需求的。因此这种持续的客户参与的过程也可以最大程度得保证项目的最终质量。

　　4.    可运行的软件

　　什么叫可运行的软件？就是可部署，可运行，能够让客户触摸到的软件，这样的软件才能叫可运行的软件，可能有人会说，我是做底层的，不可能让用户在页面上点，这是典型的不知道客户是谁的表现，其实现在的软件都是模块化的，分层的架构，任何模块或者任何层面都会有一个调用方，那么这个调用方就是这个模块的客户，这个模块就应该在每个迭代的结束，都发布一个可运行的代码供客户运行，这样在迭代结束才会有明确的产出。借用KentBeck的一句话：再多的文档都不及一个可运行的软件。换句话说：可运行的代码就是最好的文档。

　　因此对于任何软件项目来说，敏捷不可能适应所有项目，因此需要因项目而采用不同流程，淘宝也是一样，流程没有最好的，只有最合适的。