軟件測試團隊成功適應敏捷的障礙

　　測試團隊在從傳統開發模式向敏捷模式轉變的過程中存在各種障礙，敏捷測試專家Lisa和Janet從自身經驗出發探討了其中的原因和解決方法。

　　任何變化都面臨成功路上的障礙。組織文化可能是要克服的最大障礙。組織文化一旦建立就很難改變。組織文化的形成需要時間，一旦就緒，員工會忠于該文化，這使得對改變相當的抵制。

　　喪失身份

　　由于很多原因，測試人員堅持獨立的質量保證團隊，但是主要原因是害怕，特別是：

　　害怕喪失質量保證人員的身份

　　害怕如果向開發經理匯報，會喪失支持，程序員會獲得優先權

　　害怕缺乏在敏捷團隊中工作的技能從而丟失工作

　　害怕當分散于開發團隊時，得不到需要的支持

　　害怕他們和經理在新的組織中迷失

　　其他角色

　　按照我們的經驗，新的團隊往往缺少使項目成功的關鍵專家。Lisa的團隊曾經遇到巨大的障礙，唯一能做的事情是停工和詢問：“我們的團隊缺少什么角色導致我們停止不前?我們需要什么?另外一個開發人員、另外一個測試人員，還是一個數據庫設計人員?”我們知道測試是一個寬廣的領域。也許需要一個對敏捷團隊的測試有經驗的人員，或者可能需要一個性能測試專家。需要花時間去分析產品的成功需要什么角色，是否需要從團隊外引入這些角色，這很重要，一定要做。產品團隊中的每一個人都需要理解他們的角色并認識到他們是新的敏捷團隊的一部分，這很重要。但是這需要時間和培訓。

　　缺乏培訓

　　我們曾在Agile 2007大會中一次會議上詢問人們在敏捷團隊中有什么測試相關的問題。其中一個與會者告訴我們，他們根據敏捷資料的建議分拆了測試組織。但是，他們沒有經過任何培訓就把這些測試人員編入開發團隊。在三個月中，所有的測試人員由于沒有理解他們的新角色而離職。這類問題可以通過正確的培訓和指導來避免。

　　當開始在第一個敏捷團隊中工作時，沒有太多的資料能夠幫助我們理解敏捷測試人員應該做什么以及我們應該怎么同團隊一起工作。如今，你可以找到很多能夠幫助培訓測試人員適應敏捷環境及幫助測試團隊進行敏捷轉變的先行者。本地用戶組、會議、研討會、在線介紹和郵件列表都為想學習敏捷的測試人員和經理提供了有用的資料。當你需要幫助時，不要害怕尋求幫助。出色的培訓會為你的投資帶來良好的回報。

　　不理解敏捷概念

　　不是所有的敏捷團隊都是相同的。敏捷開發有許多不同的方式，例如極限編程、Scrum、Crystal、特征驅動開發、領域定義模型、Open UP。我們認為一些自稱為“敏捷”的團隊其實不是使用敏捷。許多團隊只是簡單采用對他們有用的實踐，并不管來自于哪里還是自己的發明。這是允許的，但是如果他們不遵循任何核心敏捷價值和原則，我們會懷疑他們的敏捷身份。按月發布和丟棄文檔并不等同于敏捷開發!

　　如果不同的團隊成員對“敏捷” 的構成有相反的想法，例如，使用什么實踐或者這些實踐應該是怎么樣的，那么將會有麻煩。例如，如果你是推動團隊使用連續迭代的測試人員，但是程序員拒絕使用，那么你就處于麻煩的境地。如果你是不能參與一些實踐的程序員，例如通過面向業務的測試來推動開發，那么，也會引起沖突。

　　團隊必須就如何實現向敏捷的成功轉變而達成一致意見。很多敏捷開發實踐是相互協作的，因此如果單獨使用這些實踐，可能得不到團隊希望的效果。團隊也許可以同意在一定的迭代中試驗某些實踐并評價其效果?？梢詫ふ彝獠康膸椭鷣韰f助他們理解這些實踐并如何將它們協作。多樣化的觀點對團隊是有益的，但是每個人都需要朝同一個方向努力。

　　過去的經驗/觀點

　　很多人經歷過改變，但沒有延續下來。一些開發組織已經有過一連串的“方法”。他們質疑：“我們為什么還要再次做這個?”人們堅持陳舊、失敗的模式。即使當他們試驗新的方法時，也可能在壓力下重復壞的老習慣。下面是一些例子，列舉了人們由于過去的經歷和對事物的誤解而抵制變化：

　　測試人員坐在座位上不與程序員討論存在的問題。抱怨程序員不能理解他想要什么。

　　測試人員無法改變看法：開發人員不知道如何寫出好代碼或如何測試。他完全沒有謙遜的態度，作為測試人員的威信也受到質疑。

　　客戶發現程序員做了其不喜歡的事情時提出抗議，因為程序員總是為所欲為。

　　當面臨到敏捷開發的轉變時，這樣的人經常迅速離開，不給新的過程機會。敏捷開發不適合所有人，但是培訓和實驗的時間可以幫助改變這個態度。讓每個人成為解決方案的一部分，協同工作來發現對其特定情況最適用的過程和實踐。自組織的團隊是一個可以用來保證開發團隊所有成員掌握他們自己的命運的強大工具。

　　角色間的文化差異

　　每個敏捷團隊的新成員都在從不同的角度轉變。程序員經常習慣于編寫產品代碼并使其盡可能快地發布。系統管理員和數據庫專家可能習慣于在他們自己的領域工作， 根據自己的進度執行需求?？蛻艨赡軓膩聿慌c開發團隊成員直接談話。測試人員可能習慣于在項目的末期參與而且不與程序員有太多的交互。

　　毫無疑問，到敏捷的轉變可能引起驚慌。團隊可以通過規則和方針幫助他們交流和順利地協同工作。例如，Lisa曾經加入一個新的敏捷團隊，團隊有一條規則是，如果有人要求和你結對，你必須同意。你可能一開始無法適應，一旦融入進來，你就需要幫助團隊伙伴。

　　識別不同角色的人的需求，并想辦法來提供幫助?？蛻粜枰緩絹慝@得開發進度和了解他們的條件是否會被滿足。開發人員需要知道業務優先級和需求。測試人員需要途徑來獲取實例和將其轉變為測試。所有的團隊成員希望感覺到他們是有價值的，是優秀的團隊成員。每一個團隊成員也需要安全感和可以自由地提出問題，以及嘗試新觀點。了解每個角色的觀點可以幫助團隊完成轉變。

　　對于以上問題，測試團隊應該如何面對呢?Lisa和Janet提供了以下建議：

　　討論恐懼

　　當開始迭代開發時，使用回顧總結來提供討論恐懼和獲得反饋的機會。讓人們知道感覺到恐懼是正常的。保持開放態度，告訴大家感到恐懼和不適應是可以接受的。討論每個恐懼的根源，從討論中學習，作出決定并繼續前進?？謶质菍ψ兓恼７磻?。強迫人們做他們不想做的事情必定會反對變化。

原文轉自：http://www.anti-gravitydesign.com