敏捷對QA部門有何益處？
　　傳統(tǒng)方法中，直到產品快要發(fā)布了QA工程師才參與到項目之中。QA工作被理解為項目結尾的工作，這樣明顯會對產品質量產生很大的風險和不穩(wěn)定。傳統(tǒng)方法中，黑盒測試優(yōu)先于用戶界面，且每個測試用例和測試計劃都不得不記錄下來。敏捷框架的引進使工程師收益，因為它們變得更重要了。它們需要一開始主動參與，想出合適的方法確保產品質量�？偠�言之，敏捷中的QA應該：
　　--幫助業(yè)務分析師明確故事以及它們的接受標準，這樣他們可以知道有沒有滿足顧客的要求。
　　--與開發(fā)團隊整合，使用代碼標準并通過重構改進代碼庫。
　　--在編碼前給開發(fā)員提供高質量的測試用例和場景，遵循計劃應對改變。
　　--確保用戶界面上的黑盒測試和白盒測試以了解應用程序內部的工作。
　　--增加自動化測試以增加團隊速度。
　　--將質量控制落實到每次迭代中去。
　　敏捷對管理有何益處？有沒有敏捷經理？
　　敏捷經理
　　負責支持開發(fā)團隊，去除障礙，并保持敏捷流程順利進行。敏捷經理是開發(fā)流程的推動者，他/她的主要任務是大化團隊的效率，而非控制他們如何工作，后者更多地出現(xiàn)在項目經理作為權威人物的傳統(tǒng)項目管理中。敏捷經理確保項目上的都是合適的人，訓練、引導、并激勵每個人實現(xiàn)共同的目標。這項重要任務大大激勵了他們實現(xiàn)他們的目標。

　　那么，敏捷是完美的嗎？
　　當然不是。首先要注意，敏捷并不是完美，它是用有效透明的方式為你的組織和顧客帶去價值。因此，使用敏捷框架時你需要有耐心。執(zhí)行團隊相信敏捷方法這一點很重要。如果這樣，你項目成功的可能性大大增加了。
　　此外，敏捷還有一些缺點。因為它側重于人，如果某些人離開了你們團隊，你很有可能會失去很多團隊的信息和凝聚力。另外，因為團隊是自我管理的，需要所有成員都成熟，通常這很難。后，使用敏捷時有一些會帶來更多不方便的常見錯誤。一個常見錯誤是：試著讓你的組織適應敏捷。敏捷是一個為變得更加高效而提供方法的框架，因此關鍵在于明確敏捷提供的哪些方法適合你個人和團隊的需求。另一個錯誤是：相信敏捷意味著一切隨時可以完成。敏捷是關于靈活度的，但是一個功能的開發(fā)一旦開始，不可能在它完成前改變它。
　　它是適用于軟件環(huán)境嗎？
　　不，它可以用于不同的環(huán)境，比如，想想看我們用敏捷方式寫的這篇文章。我們首先明確了我們想要做的，并開始為期一周的編寫循環(huán)。每次循環(huán)后，我們都需要來自專家和重要利益相關者的反饋。用這種方法，我們提高了我們的文章并繼續(xù)編寫。完成十次循環(huán)后，我們的利益相關者告訴我們它很不錯。很明顯，我們并不是敏捷，因為在它終完成前我們還沒將產品發(fā)布出去。確實，敏捷并不僅僅只適用軟件項目，但是它更適用于小的預算項目，因為每次循環(huán)都修復你的產品或許會產生預料外的花費。此外，敏捷在為了各種理由而需要經常變化的環(huán)境中很高效。
　　結論
　　過去敏捷并不是公司開發(fā)過程的一個方面。它是一個通過團隊合作，透明和不斷的進步經常幫助為終端客戶提供高質量的開發(fā)原理。這些益處表明了敏捷的轉變，這并不是一個輕松的任務。一旦遇到第一個問題，并不完全相信敏捷使用的團隊和公司將會放棄他們對敏捷的使用。
　　一個良好的敏捷團隊了解敏捷的益處并相信它的使用，選擇適合他們的敏捷框架提供的管理和技術方法。這樣的話，敏捷的使用基本成功了。

版權聲明：本文出自 SPASVO澤眾軟件測試網：http://dytjszp.cn/news/html/201579142241.html
原創(chuàng)作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。