敏捷在一定程度上是一种思维方式。它鼓励个人与团队的融合，崇尚快速响应变化，抛弃繁杂的文档。这些从敏捷的宣言可以看出：个体和交互比过程和工具更有价值;能工作的软件比全面的文档更有价值;顾客的协作比合同谈判更有价值;及时响应变更比遵循计划更有价值。

　　敏捷的开发方式与传统软件开发方式存在很多的不同。例如，比起传统的开发模式，敏捷方式更注重人与人之间的沟通和交互;通过区分优先级并专注于尽早发布来对待进度压力;要求顾客紧密合作并参与到项目中来。

　　越来越多的人意识到传统软件开发模式的不足，越来越多的人开始拥抱敏捷。

　　质量保证在敏捷项目中的角色定位

　　敏捷把我们的注意力转移到精简的项目组、小步快跑、迭代发布的过程模式中来。那么实施敏捷项目管理的团队是否意味着不需要文档、不需要测试、不需要质量保证了呢?

　　在回答这个问题之前，我们需要考虑质量保证在敏捷项目中的角色定位问题。抽象的思想与能工作的软件是不一样的，因此软件需求文档不能代表充分地代表软 件。敏捷方法鼓励通过合作和面对面的交流来获得文档不能替代的信息沟通。那么就意味着我们传统软件工程中的对于需求的质量保证工作的方式不再合适了。

　　在敏捷项目中，软件测试也需要敏捷。Brian Marick分析并指出了敏捷测试与 传统测试的很多不一样的地方。敏捷测试抛弃了旧有的关于测试人员沟通方式的观点。就像需求和设计文档的不充分一样，测试计划和测试报告也是不充分的。敏捷 测试要求测试员与开发人员、用户充分交流和沟通，面对面的沟通。那么就意味着我们传统软件工程中对软件测试的质量保证工作不能从检查文档、评审文档出发 了。

　　传统的软件测试作为质量保证的控制手段，起到质量把关的作用，测试人员站在顾客的角度来批判产品、检查产品质量是否达到要求，测试 的服务对象是顾客。但是敏捷测试的服务对象有所改变，测试的服务对象是开发组，帮助开发人员减少由于产品的不确定性而带来的损失。也就是说，质量保证的控 制手段-软件测试也有所不同了。

　　因此质量保证工作在敏捷项目组中的角色定位可能要发生一些改变，我们也许不再是抱着一堆文档在评审，追着开发人员要文档的QA;我们也许不再是指责产品不过关，要求返工的QA;我们也许不再是要求项目组拿出与顾客充分沟通的证据来的QA。

　　敏捷对质量保证的提示

　　目前，虽然敏捷项目管理方式逐渐兴起，但是观望的、浅尝即止的人多于实践的人，尤其是关于如何在敏捷项目中开展质量保证工作的实践还比较少。因此很难准确说明敏捷项目中的质量保证工作会有哪些改变，但是我们能够从敏捷的原则和开发方式中得到几个有用的提示。

　　1、程序员开始被测试所感染。

　　感谢Beck、Gamma和JUnit单元测试工具，现在，测试驱动开发被大部分的开发环境所支持。敏捷项目中的程序员更具单元测试意识。

　　2、增量的开发方式

　　很多小的产品版本发布，而不是一个唯一的计划好的版本发布。

　　3、FIT(Framework for Integrated Test)

　　FIT允许用户使用简单的Word文档或HTML文档来定义他们自己的测试。FIT能产生用例子描述业务的文档。

　　这些给我们的提示是：

　　1、测试工作不仅仅由测试人员担任，其他项目组成员也承担了部分的测试工作。那么对测试的质量度量模式可能就要发生改变了。

　　2、沟通仍然是项目组不变的主题，但是沟通的方式更多地侧重在口头、面对面方式的交流。那么对沟通的质量度量模式可能就要发生改变了。

　　3、迭代、快速发布、重构等软件开发方式对如何进行配置管理的控制提出了新的要求。

　　总结

　　敏捷项目管理代表了一种软件开发思想的回归，软件的本质是为用户提供价值，为用户解决问题。所有软件工程的活动都是围绕这个核心思想来进行的。极限编程、测试驱动、SCRUM等等，都只是为了突现软件活动中的某方面的重要性而提出的，但其核心都一样。

　　个体和交互、能工作的软件、顾客合作、快速响应变化，这些原则毫无疑问会使传统的质量保证工作方式发生改变。很多质量保证的手段和方式可能要发生剧烈的改变，但是至少有一样东西是不变的：质量保证的目的仍然是确保交付产品的质量。