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

　　賦予團隊權力

　　一個關鍵的成功因素是團隊是否有權決定自己的方式。如果得到正確的幫助，人們將會改變他們的觀點和感覺。Lisa曾經觀察Mike Cohn在團隊中作為教練的情況。作為一個自組織的團隊，團隊需要確定并解決他們自己的問題。Mike確保他們有時間和資源來實驗和改進。他確保業務人員理解質量比數量和速度更重要。每個團隊，即使是自組織的團隊都需要一個可以有效的與組織的管理層溝通的領導。

　　慶祝成功

　　變化需要時間并且會遇到挫折，所以，一定要慶祝你的團隊獲得的所有成功。當達到在迭代的第四天為所有用戶故事寫出高層次的測試用例這個目標時，你應該慶幸。 當成功完成一個迭代，讓團隊一起做小游戲或者吃午飯。認可成果對于變化的鞏固很重要。

　　在讓測試人員繼續向質量保證經理匯報的同時，融入開發團隊是幫助轉變到敏捷開發的好辦法。測試人員可以發現從對程序員的敵對關系轉變到協作關系的方式?？梢哉故舅麄內绾螏椭鷪F隊理解客戶需求并交付滿意的業 務價值?？梢耘e辦令人愉快的活動來建立良好的團隊交互。給團隊成員準備餅干和巧克力是讓他們走近你的一種好的方式。耐心和幽默是巨大的優勢。

　　但是，Lisa和Janet也提醒測試團隊——改變并不容易。

　　敏捷開發可能更快速，但是變化可以是緩慢的。采用敏捷的新團隊將會較慢地掌握承諾使用的一些實踐。我們曾遇到很多沮喪的測試人員，他們的“敏捷”開發周期實際上是小型瀑布周期。這些測試人員仍然在受壓榨，只是頻率更多。迭代在用戶故事可以被測試前結束。 程序員拒絕或者不能適應關鍵實踐，例如測試驅動開發或者結對。團隊把質量的責任交給了測試人員，但是測試人員沒有權力改變過程。

　　沒有魔法使你的團隊做出有益的變化，但是我們為想讓團隊以有益的方式改變的測試人員提供了一些技巧。

　　耐心

　　新的技術，如測試驅動開發是很難的。找到讓你的團隊有時間去掌握他們的方法。在你等待的時候找到可以獨立做出的改變。例如，當程序員學習編寫單元測試時，以最小的幫助實現一個你可以使用的GUI測試工具。幫助團隊成長。記住，當人們恐慌時，他們會變回舊的習慣，即使這些習慣沒有作用。關注微小的有益增長。

　　讓他們感覺到痛苦

　　有時不得不看到火車失事。如果改進的建議被回絕了，團隊失敗了，再次提出你的建議并請團隊考慮試用幾個迭代。人們最希望在他們感覺到最痛苦的領域改變。

　　建立你的誠信

　　你可能現在同以前沒有與測試人員親密工作的程序員一起工作。向他們展示你如何幫助團隊。告訴他們你發現的問題而不是開出缺陷報告。請他們在提交代碼前和你一起檢查代碼。當他們意識到你提供了真正的價值，他們將會更聽從你的想法。

　　從事你自己專長的開發

　　閱讀書籍和文章，參加用戶組會議和討論，學習新的工具和腳本語言。開始學習你的應用編碼使用的語言，如果可以同程序員結對或者他們會輔導你，那么就請教他們。同事會注意到你渴望增長自己的技能。如果本地用戶組希望聽你對于敏捷測試的演講，或者軟件通訊發表了你的自動化文章，團隊伙伴可能會注意到你有很多值得考慮的想法。

　　警惕質量警察思想

　　做一個合作者，而不是強制實施者。如果程序員不遵循編碼標準可能會影響你，但是確保他們遵循編碼標準不是你的工作。向團隊提出你的問題并請求他們的幫助。如果他們忽略了一個至關重要的確實會傷害團隊的問題，可能需要請求你的教練或經理的幫助。但是用“請幫我找個解決方案”的語氣，而不是“讓這些人這么做”的語氣。如果你發現一個問題，其他人很可能也發現了。

　　用離開表示拒絕

　　你已經耐心了。你已經嘗試了能想到的所有方法，但是管理層不理解敏捷開發。程序員已經導致很多缺陷和不可以測試的代碼，并且代碼被發布了，盡管你已經盡最大努力了，包括每天工作14個小時。沒有人關心質量，感覺到努力被忽略。這可能是時候尋找一個更好的團隊了。一些團隊滿足他們的方式，并不感覺到足夠需要改變的痛苦。Lisa曾在一個越來越混亂的團隊中工作，因為有很多機會來解決為什么服務器會宕機并成為英雄。盡管采用了敏捷實踐而且項目成功了，但是他們又回到了舊習慣，Lisa最終放棄改變他們。

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