在传统模式下也通用的敏捷实践

敏捷的实践有很多种，有些具有相关性，有些可以独立实施。对于刚刚涉及敏捷的人来说，可能需要一本“攻略”。虽然敏捷社区并没有这么一本攻略，而且也不推荐每个人按照攻略去实施敏捷，我想还是有一些基本的实践可以在多数情况下适用。

第一步：Daily build + Smoke Test

每日构建加上冒烟测试一方面可以作为初步的检验，保证软件的基本功能不出错。也可以为测试人员尽早提供所需的Build。Smoke Test本身只要包括基础和核心功能就可以了。执行时间最好短一些 （手工不超过20分钟，自动不超过5分钟）。

第二步：快速修复Bug

这一步的原则是，一旦发现严重Bug，先修复再写新代码。一旦Smoke Test发现Bug，必须立刻修复。如果能够做到Smoke Test失败的时候，不check in 代码会更加好。如果是其他情况下发现严重bug，也必须优先予以修复。这样就可以确保不在错误的基础上构建功能。能够做到这一步，基本上，软件的质量就不会非常差。刚开始的时候，每日构建可能经常会失败。或者是发现了bug，也没有及时修复。这样就失去了每日构建的积极作用。但是如果能够坚持实施一段时间，会看到明显的质量改善。

第三步：测试和开发人员协同工作

这一步其实越早开始就越好，并非一定要等到第三步。所谓协同，最好是两种人员在一个Team里面，坐在一起工作。如果做不到，也可以由一个测试人员固定搭配若干开发人员，互相配合工作。这样的好处是提高沟通效率，也使测试工作能够尽早展开。

第四步：自动化测试

自动化测试可以按照单元测试-集成（功能模块）测试（非UI）-系统测试（UI）这个顺序。如果单元测试的覆盖率够高，集成和系统自动化测试可以简略甚至暂时不做。

以上四个步骤在任何一种开发模式下，都具备实施的条件，互相之间并不存在依赖关系以及实施的前后顺序。我经历过瀑布模式下，实施了这四个步骤中的三个，最后也能够开发出高质量的软件。