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

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

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

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

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

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

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

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