模板
教程
環境
性能
功能
管理
敏捷測試中的管理層適應過程
對于成功的敏捷實踐，管理層的支持是至關重要的。敏捷測試專家Lisa和Janet詳細分析了管理層的文化變化和適應過程。在階段性項目中，管理層定期得到更新信息，簽署表示每個階段結束的文檔。高層經理可能不知道如何度量敏捷項目的進度。他們可能害怕失去控制或缺少“過程”。
而在敏捷項目中，期望改變了。在Janet以前從事瀑布項目時，每個星期總是聽到類似于“功能已經完成90%了”。這種度量在敏捷項目中是沒有意義的。沒有“完成標志”來表明階段的結束，項目的“完成”不是通過條件衡量的。每個項目團隊決定其有意義的度量標準。在Scrum中，sprint和發布燃燒圖跟蹤用戶故事的完成，能夠讓經理們衡量進度，但是沒有固定的“日期”用來通知客戶。測試標準可以用來有效地跟蹤測試覆蓋率，但是不提供收尾文檔。讓很多經理不能理解的另一個改變是讓團隊決定他們自己的技術和管理他們自己的工作量。不再由經理決定哪些已經完成了。團隊(包含客戶)決定交付成功應用需要的質量水平。敏捷團隊在比傳統團隊更少的時間期限內評估和工作。為了保證技術問題不會增加，團隊需要規劃足夠的時間來實現良好的設計和執行，而不是偶然形成的。敏捷團隊的經理關注于清除障礙，讓團隊成員更出色地工作，而不是糟糕地管理團隊的活動。
Janet舉例說：
我請副總裁負責一個大的敏捷項目，他從管理的角度發現這在新的敏捷環境下是最困難的部分。他說，在傳統的瀑布模型項目中，在最末期，報告都顯示事情根據計劃進展順利，然后所有事情都處于驚慌狀態并“都不工作”。
在敏捷項目中，每天都有需要解決的問題。敏捷項目更是在一致的基礎上工作，至少獲得真實的報告。項目的結尾當然是沒有疑問的。
業務相關人員不喜歡驚奇。如果可以說服他們給團隊足夠的時間和資源來進行轉變，他們將發現敏捷開發使計劃更精確并達到穩步增長的業務目標。
有時確實是管理層驅動開始敏捷開發的決定。Lisa公司的業務主管選擇嘗試敏捷開發來解決他們的軟件危險。為了起作用，他們需要有不同的管理層期望。需要對做出巨大改變的困難非常敏感，特別是在運行不正常的組織中。在所有時候，轉變到高性能的敏捷團隊可能是一個很長的時期，經理需要許多耐心。確保提供必需的資源是他們的工作，確保每一個人都學到如何高效率地工作。
作者講了一個測試經理轉變的故事：
Tae Chang在DoubleClick管理一個執行端到端的測試來確保所有集成點(從上到下所有變化)都被覆蓋的團隊。當他們使用Scrum時，開發團隊重組成為許多應用團隊。交流問題導致了缺少依賴，所以Tae的團隊開始幫助確保問題被盡早發現。
Tae告訴我們：“我相信敏捷開發顯著地放大了跨團隊交流的重要性和協作的端到端的測試工作。找到一個非擴散的(即適合目前的sprint結構的)集成測試過程是很困難的。實際上，我們依舊在嘗試，但是測試工作的整體益處很顯然。”他們的團隊開始進入“小型瀑布”的陷阱。“在回顧總結中，”Tae解釋說，“我們認識到這樣做的一個原因是我們在內化敏捷實踐前開始了敏捷過程。”
DoubleClick的團隊知道測試自動化和持續集成是關鍵，就提出了新的想法，例如專門的構建和自動化團隊來幫助開發團隊應付這些問題。他們引入專家培訓來幫助團隊學習測試驅動開發和結對編程。開始采取步驟來解決遺留系統中的技術問題。
Tae的團隊參與了所有的sprint計劃和評估會議，使用正式和非正式的交流來達到跨功能的溝通和協作測試及發布。他發現這有助于保持會議簡短和內容相關。他也支持所有人坐在一個開發的區域并反對分隔斷的格子。
Tae給轉變到敏捷的測試人員提出了如下建議：“敏捷開發通常一開始會使測試人員感到挫敗，因為他們不能獲得完整的需求文檔或者確定的測試階段。我認為敏捷開發中，無論何時，測試人員將從事來自傳統開發過程中多個階段的任務。測試人員可以在設計會議中和工程師及產品管理層(她這時需要記錄并開始思考建議的代碼改變可能會影響的有風險的區域)一起工作，同時對提議的變化進行自動化和運行測試用例。這時在思想上的改變，一些人可能比其他人更快地接受。”
Tae的經歷反映出我們和曾經交談過的許多其他團隊的情況。
Lisa特別強調要使用經理的語言：什么是業務經理最容易明白的?是底線---ROI(投資回報率)。為了從經理那獲得需要的支持，把需要放入他們可以理解的上下文環境中。團隊的效率轉化為新功能，獲得更多的收益。如果需要時間和資金學習和使用自動化工具，向管理層解釋自動化的回歸測試將使團隊更快，每個迭代交付更多的功能。
Lisa舉例說：
我的團隊需要很多時間來做危險的重構，例如嘗試將代碼分成多個模塊使其可以獨立構建。也需要時間將現有工具升級到最新版本，或者嘗試新的工具。所有這些任務很難在為期兩周的sprint中實現，因為我們還要努力向業務交付用戶故事。
我們向管理層解釋如果這些“項目”任務推遲太長時間，技術債務將會積累，速度將會放慢。每個迭代交付的用戶故事的數量將減少，并且新的用戶故事將使用更長的時間來編碼。業務方面將會用更長的時間獲得為了吸引客戶所需的新特性。
業務人員很難同意讓我們每六個月投入一個兩周的迭代來做管理技術債務的內部工作，但是隨著時間發展，他們將會在我們的速度中看到結果。最近，其中一個經理實際上問我們是否需要更頻繁的“優化sprint”。產品和團隊都在成長，業務人員也希望確保我們同時在基礎設施和工具方面進步。
