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

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

版權(quán)聲明：本文出自 SPASVO澤眾軟件測試網(wǎng)：http://m.xmdc.net/news/html/201579142241.html
原創(chuàng)作品，轉(zhuǎn)載時請務(wù)必以超鏈接形式標(biāo)明本文原始出處、作者信息和本聲明，否則將追究法律責(zé)任。