敏捷的历史

　　上上个周四，我在组里做了个内部演讲，题目是“使用Cucumber实现行为驱动开发”。考虑到组内成员并不系统的敏捷背景，我是从历史开始的。

　　扯软件开发的历史是我最喜欢的项目之一，大部分搞软件的读书读到历史基本都跳过去，我却很喜欢看看那些过往的小故事。所以每次跟人聊起来，我都尽量吹他个昏天黑地，反正也没人知道对错。

　　我所介绍的软件开发的历史主线如下：

　　● 1956年，缺陷（Bug）这个概念产生，寻找缺陷的过程包括了测试和调试两部分。

　　● 1979年，测试与调试分离，Glenford J. Myers等推动了这个运动，GM同时也是“软件测试艺术”一书的作者。此运动的直接导致了测试与开发的分离，测试开始有自己的职位招聘与组织结构，研发与测试开始分支，背靠背工作，靠文档进行沟通。

　　● 1990年，轻量级软件测试发展，以减少传统软件测试的浪费为目的。

　　● 1995年，轻量级开发方法登上舞台，Scrum/XP/Lean Development。

　　● 2001年，轻量级开发方法的倡导者走到一起，敏捷宣言诞生。

　　W瀑布模型

　　介绍了历史，我们一起看了下传统软件开发的基石，W模型，并以此为基础，讨论了下其中的浪费：

　　◆ 重复

　　　　● 需求文档（Requirement）与验收性测试用例（Acceptance Test）的重复

　　　　● 功能文档（Function Specification）与系统测试用例（System Test）的重复

　　　　● 设计文档（Design）-即每个模块的功能与模块测试/集成测试（Integration Test）用例重复

　　　　● 文档本身也包含着Bug

　　◆ 始终保持着一个组空闲

　　　　● 在W模型的左边，属于开发周期，研发人员忙碌

　　　　● 在W模型的右边，属于测试周期，测试人员忙碌

　　◆ 文档无用

　　　　● 高质量的代码，可以提供设计模式参考与复用，文档则不行

　　　　● 为了保持文档与代码的同步，需要花很大力气

　　　　● 如，测试用例的文档描述与自动化代码的同步，设计文档与实施代码的同步等

　　◆ 瀑布模型导致修改困难

　　　　● W模型越靠后，修改所带来的代价越高