敏捷的開發(fā)方式與傳統(tǒng)軟件開發(fā)方式存在很多的不同。例如，比起傳統(tǒng)的開發(fā)模式，敏捷方式更注重人與人之間的溝通和交互;通過區(qū)分優(yōu)先級并專注于盡早發(fā)布來對待進度壓力;要求顧客緊密合作并參與到項目中來。敏捷在一定程度上是一種思維方式。它鼓勵個人與團隊的融合，崇尚快速響應(yīng)變化，拋棄繁雜的文檔。這些從敏捷的宣言可以看出：個體和交互比過程和工具更有價值;能工作的軟件比全面的文檔更有價值;顧客的協(xié)作比合同談判更有價值;及時響應(yīng)變更比遵循計劃更有價值。
越來越多的人意識到傳統(tǒng)軟件開發(fā)模式的不足，越來越多的人開始擁抱敏捷。
一、質(zhì)量保證在敏捷項目中的角色定位
敏捷把我們的注意力轉(zhuǎn)移到精簡的項目組、小步快跑、迭代發(fā)布的過程模式中來。那么實施敏捷項目管理的團隊是否意味著不需要文檔、不需要測試、不需要質(zhì)量保證了呢?
在回答這個問題之前，我們需要考慮質(zhì)量保證在敏捷項目中的角色定位問題。抽象的思想與能工作的軟件是不一樣的，因此軟件需求文檔不能代表充分地代表軟 件。敏捷方法鼓勵通過合作和面對面的交流來獲得文檔不能替代的信息溝通。那么就意味著我們傳統(tǒng)軟件工程中的對于需求的質(zhì)量保證工作的方式不再合適了。
在敏捷項目中，軟件測試也需要敏捷。Brian Marick分析并指出了敏捷測試與 傳統(tǒng)測試的很多不一樣的地方。敏捷測試拋棄了舊有的關(guān)于測試人員溝通方式的觀點。就像需求和設(shè)計文檔的不充分一樣，測試計劃和測試報告也是不充分的。敏捷 測試要求測試員與開發(fā)人員、用戶充分交流和溝通，面對面的溝通。那么就意味著我們傳統(tǒng)軟件工程中對軟件測試的質(zhì)量保證工作不能從檢查文檔、評審文檔出發(fā) 了。
傳統(tǒng)的軟件測試作為質(zhì)量保證的控制手段，起到質(zhì)量把關(guān)的作用，測試人員站在顧客的角度來批判產(chǎn)品、檢查產(chǎn)品質(zhì)量是否達到要求，測試 的服務(wù)對象是顧客。但是敏捷測試的服務(wù)對象有所改變，測試的服務(wù)對象是開發(fā)組，幫助開發(fā)人員減少由于產(chǎn)品的不確定性而帶來的損失。也就是說，質(zhì)量保證的控 制手段-軟件測試也有所不同了。
因此質(zhì)量保證工作在敏捷項目組中的角色定位可能要發(fā)生一些改變，我們也許不再是抱著一堆文檔在評審，追著開發(fā)人員要文檔的QA;我們也許不再是指責產(chǎn)品不過關(guān)，要求返工的QA;我們也許不再是要求項目組拿出與顧客充分溝通的證據(jù)來的QA。
二、敏捷對質(zhì)量保證的提示
目前，雖然敏捷項目管理方式逐漸興起，但是觀望的、淺嘗即止的人多于實踐的人，尤其是關(guān)于如何在敏捷項目中開展質(zhì)量保證工作的實踐還比較少。因此很難準確說明敏捷項目中的質(zhì)量保證工作會有哪些改變，但是我們能夠從敏捷的原則和開發(fā)方式中得到幾個有用的提示。
1、程序員開始被測試所感染。
感謝Beck、Gamma和JUnit單元測試工具，現(xiàn)在，測試驅(qū)動開發(fā)被大部分的開發(fā)環(huán)境所支持。敏捷項目中的程序員更具單元測試意識。
2、增量的開發(fā)方式
很多小的產(chǎn)品版本發(fā)布，而不是一個唯一的計劃好的版本發(fā)布。
3、FIT(Framework for Integrated Test)
FIT允許用戶使用簡單的Word文檔或HTML文檔來定義他們自己的測試。FIT能產(chǎn)生用例子描述業(yè)務(wù)的文檔。
這些給我們的提示是：