2、 增量的開發(fā)方式
很多小的產品版本發(fā)布，而不是一個唯一的計劃好的版本發(fā)布。
3、 FIT（Framework for Integrated Test）
FIT允許用戶使用簡單的Word文檔或HTML文檔來定義他們自己的測試。FIT能產生用例子描述業(yè)務的文檔。
這些給我們的提示是：
1、測試工作不僅僅由測試人員擔任，其他項目組成員也承擔了部分的測試工作。那么對測試的質量度量模式可能就要發(fā)生改變了。
2、溝通仍然是項目組不變的主題，但是溝通的方式更多地側重在口頭、面對面方式的交流。那么對溝通的質量度量模式可能就要發(fā)生改變了。
3、迭代、快速發(fā)布、重構等軟件開發(fā)方式對如何進行配置管理的控制提出了新的要求。
何謂敏捷？
敏捷在一定程度上是一種思維方式。它鼓勵個人與團隊的融合，崇尚快速響應變化，拋棄繁雜的文檔。這些從敏捷的宣言可以看出：個體和交互比過程和工具更有價值；能工作的軟件比全面的文檔更有價值；顧客的協作比合同談判更有價值；及時響應變更比遵循計劃更有價值。
敏捷的開發(fā)方式與傳統軟件開發(fā)方式存在很多的不同。例如，比起傳統的開發(fā)模式，敏捷方式更注重人與人之間的溝通和交互；通過區(qū)分優(yōu)先級并專注于盡早發(fā)布來對待進度壓力；要求顧客緊密合作并參與到項目中來。
越來越多的人意識到傳統軟件開發(fā)模式的不足，越來越多的人開始擁抱敏捷。
質量保證在敏捷項目中的角色定位
敏捷把我們的注意力轉移到精簡的項目組、小步快跑、迭代發(fā)布的過程模式中來。那么實施敏捷項目管理的團隊是否意味著不需要文檔、不需要測試、不需要質量保證了呢？
在回答這個問題之前，我們需要考慮質量保證在敏捷項目中的角色定位問題。
抽象的思想與能工作的軟件是不一樣的，因此軟件需求文檔不能代表充分地代表軟件。敏捷方法鼓勵通過合作和面對面的交流來獲得文檔不能替代的信息溝通。那么就意味著我們傳統軟件工程中的對于需求的質量保證工作的方式不再合適了。
在敏捷項目中，軟件測試也需要敏捷。Brian Marick分析并指出了敏捷測試與傳統測試的很多不一樣的地方。敏捷測試拋棄了舊有的關于測試人員溝通方式的觀點。就像需求和設計文檔的不充分一樣，測試計劃和測試報告也是不充分的。敏捷測試要求測試員與開發(fā)人員、用戶充分交流和溝通，面對面的溝通。那么就意味著我們傳統軟件工程中對軟件測試的質量保證工作不能從檢查文檔、評審文檔出發(fā)了。
傳統的軟件測試作為質量保證的控制手段，起到質量把關的作用，測試人員站在顧客的角度來批判產品、檢查產品質量是否達到要求，測試的服務對象是顧客。但是敏捷測試的服務對象有所改變，測試的服務對象是開發(fā)組，幫助開發(fā)人員減少由于產品的不確定性而帶來的損失。也就是說，質量保證的控制手段-軟件測試也有所不同了。
此文章共有4頁 上一頁 1 2 3 4 下一頁
文章來源：中國項目管理資源網
|
Leadge.com首頁 > 知識庫 
