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