导读：本文中介绍了像瀑布方法这样的传统软件开发方法能否利用敏捷价值观和原则，这样的企业是否是敏捷的。笔者根据自己的经验给出了中肯的建议。他认为持续改进是所有软件团队都应该追求的目标。

　　关键词：敏捷方法；瀑布方法；软件开发；探测性测试；

　　您觉得一个团队是否可能遵循敏捷价值观的同时，使用传统方法，像瀑布方法，这样这个团队还是敏捷的吗？

　　我个人更喜欢Elisabeth Hendrickson对于敏捷定义的解释，我觉得这是最精确的。敏捷开发意味着频繁交付业务价值，以一种可接受的步伐，至少每季度一次。

　　我有点不爽的是“瀑布”已经成为“完全不正常的软件开发”的同义词。瀑布是软件开发中一套定义清晰的阶段，每个阶段之间都有一个“gate”来确定项目是否能够进入下一个阶段。

　　九十年代初期，我在一家企业工作，用的就是瀑布流程。然而，我们的文化强调质量。所有的角色，包括程序员、测试员、分析员、产品经理、培训专家和技术作家都参与到整个产品生命周期中。程序员进行代码复查，用接近100%的覆盖范围进行自动化单元测试。测试人员自动化GUI级别的回归测试。我们有足够的时间进行探测性测试。我们在测试中用到了很多今天敏捷团队所用的实践，像持续集成和自动化部署。偶尔，我们会在周六工作（上至副总裁的所有管理者都参与），但是我们从来都不是一只“死亡军队”。

　　最终，我们发布的产品代码只有少量瑕疵，我们的客户很满意。然而，我们一年中只发布一次或者两次产品。尽管人们在协作中角色不同，我们还是会关注自己的工作。我不是说我们要采取一种真正的全团队方法来保证质量。然而，在产业环境中，我们所做的确实奏效了，我们不需要做敏捷，但是我们也很敏捷。

　　当我为一家软件开发组织工作的时候，却有了不同的体验，他们想要敏捷，每两个周就发布一次产品。没有自动化的单元测试，没有可持续步调；程序员每周例行公事地工作60到80个小时。

　　我的测试团队有效地利用敏捷价值观和原则，在探测性测试和自动化GUI回归测试上取得了不错的成果，此外，在编写面向客户的测试时，程序员对于驱动开发很有帮助。然而，我们不能在代码内测试质量。软件照例失败了，“个人英雄主义”成为主流，哪个幸运的程序员发现了BUG，推动了产品进展，就会得到奖励。最好的程序员精疲力竭，安装时的技术债务拖累了开发团队，企业最终彻底失败。没有质量和可持续步调的频繁发布不等于敏捷。

　　如果你在一个传统的phased-and-gated的开发环境中工作，别担心什么是否符合敏捷定义，但是要让敏捷价值观和原则来指导，在合适的地方使用敏捷实践。用不同的方式实验来改善你们的工作，减少技术负债。持续改进是所有软件团队都应该追求的目标。