當軟件開發(fā)組織采用敏捷開發(fā)時，測試團隊通常需要花很長時間來完成轉(zhuǎn)變。在很多公司中，獨立的質(zhì)量保證團隊已經(jīng)根深蒂固。當它們開始適應(yīng)新的敏捷組織時，會遇到難以接受的文化差異。敏捷測試專家Lisa和Janet對此進行了詳細分析，對文化因素在敏捷測試中的影響提出了自己的建議。

　　組織文化通過其價值、標準和設(shè)想來定義。組織文化支配著人們?nèi)绾螠贤、交互和做決定，這可以通過觀察員工的行為很容易地看出來。組織文化可以影響敏捷團隊的成功。敏捷團隊適合于允許獨立思考的組織。例如，如果一個公司是等級結(jié)構(gòu)的，所有的項目都鼓勵指令式管理風(fēng)格，敏捷團隊可能會很吃力。組織以往的經(jīng)歷也可能會影響新的敏捷團隊的成功。如果公司嘗試敏捷，但是結(jié)果糟糕，人們會懷疑再次嘗試的必要性，舉例證明為什么敏捷不起作用。他們甚至可能積極地反對它。

　　當嘗試采用敏捷過程時，組織文化經(jīng)常被遺忘，人們懷疑敏捷為什么不像承諾的那樣有用。改變已有的過程是困難的，尤其是當人們覺得習(xí)慣于現(xiàn)狀時。每個任務(wù)組形成了滿足自己需求的文化和過程。他們習(xí)慣于自己的工作方式？謶值那榫w非常強大，如果不能妥善解決，可能破壞向敏捷的轉(zhuǎn)變。如果團隊成員覺得新的敏捷過程威脅他們的工作，那么會抵制這種變化。

　　以如何定義軟件質(zhì)量的可接受水平的角度思考組織的質(zhì)量哲學(xué)。是否容忍劣質(zhì)的質(zhì)量？是否考慮客戶的質(zhì)量需求，還是只關(guān)心是否可以盡快地將產(chǎn)品交付給客戶？當一個組織缺乏全面的質(zhì)量哲學(xué)和團隊沒有生產(chǎn)高質(zhì)量產(chǎn)品的壓力時，測試人員會感覺到無助。在這種環(huán)境中嘗試使用敏捷開發(fā)的團隊會面臨更大的障礙。

　　如果一個現(xiàn)有的質(zhì)量團隊自封為“質(zhì)量警察”的角色，它的成員通常通過確保完成代碼審查和缺陷嚴謹?shù)赜涗浀饺毕莞櫹到y(tǒng)來保證質(zhì)量。他們跟蹤發(fā)現(xiàn)的缺陷數(shù)，然后負責(zé)終決定是否發(fā)布產(chǎn)品。我們曾經(jīng)接觸過一些測試人員吹噓他們的成，例如越過開發(fā)經(jīng)理直接強制程序員遵循代碼標準。甚至聽說有測試人員浪費時間編寫不符合標準的需求的缺陷。這種態(tài)度并不符合協(xié)作的敏捷團隊，將引起敵對行為！百|(zhì)量警察”角色的另一個風(fēng)險是團隊不認同構(gòu)建質(zhì)量的概念，程序員將測試人員視為安全防護網(wǎng)。團隊通過缺陷跟蹤系統(tǒng)溝通，但這并不是一種高效的交流，所以團隊并不“凝聚成一團”。

　　技能和適應(yīng)能力

　　很多程序員不能適應(yīng)敏捷實踐??但是對于習(xí)慣于根據(jù)需求文檔編寫測試腳本的測試人員，情況如何呢？他們學(xué)會在編寫代碼的時候提出問題了嗎？不能改變測試方式的測試人員與開發(fā)團隊的其他人密切工作的時候會很艱難。習(xí)慣于通過用戶界面手動測試的測試人員可能無法理解敏捷開發(fā)的本質(zhì)??自動化方式。這些測試人員需要很大勇氣來面對變化的角色，因為變化意味著需要發(fā)展其熟悉范圍之外的新技能。

　　輔助因素

　　即使有許多需要考慮的文化因素，但是大部分質(zhì)量保證團隊關(guān)注過程改進，并且敏捷項目通過使用例如回顧總結(jié)等工具來鼓勵不斷改進和適應(yīng)。大多數(shù)質(zhì)量保證專家希望使用他們學(xué)到的知識并改進它。這些人適應(yīng)性強，不僅能適應(yīng)，并且能在敏捷項目中獲得發(fā)展。如果你的組織專注于學(xué)習(xí)，它將鼓勵持續(xù)的過程改進。它將比把更多的精力放在如何應(yīng)對危險而不是改進過程的組織更快地適應(yīng)敏捷。

　　如果你是有效的質(zhì)量哲學(xué)的組織中的一個測試人員，你可能努力使質(zhì)量實踐獲得接受。敏捷方式將提供引入的面向質(zhì)量的實踐的機制。像其他學(xué)習(xí)如何在敏捷項目中工作的每個人一樣，測試人員需要時間和培訓(xùn)。如果管理一個有測試人員的團隊，確保給他們足夠的支持。新項目通常不在一開始引入測試人員，一般讓他們適應(yīng)一個已經(jīng)在一起工作了幾個月的團隊。為了幫助測試人員適應(yīng)，可能需要引入一名有經(jīng)驗的敏捷測試老師。聘用一名以前在敏捷團隊工作過的員工作為老師和教練可以幫助測試人員融入到新的敏捷文化中，不管是進入一個現(xiàn)有的團隊還是加入一個新的敏捷開發(fā)團隊。

　　合適的節(jié)奏

　　傳統(tǒng)的測試團隊習(xí)慣于在項目結(jié)束時快速、激烈地測試，這會導(dǎo)致和夜間的加班。在項目結(jié)尾的測試階段，一些組織通常會讓團隊每周工作五十、六十或者更多小時來應(yīng)付終期限。組織經(jīng)常將加班作為個人貢獻的度量標準。這與敏捷價值沖突，敏捷價值的中心思想是讓大家時刻以好的狀態(tài)工作。

　　在敏捷項目中，鼓勵人們以一個合適的節(jié)奏工作。這意味著團隊以一致的速度工作，團隊可以保持在這個保持高質(zhì)量標準的速度。新的敏捷團隊往往對其能夠完成的工作過分地樂觀，而承諾太多的工作。在一個或兩個迭代之后，會學(xué)會承擔(dān)不需要加班完成的足夠工作。每周四十小時是極限編程團隊通常的合適速度，這是保證人們連續(xù)幾周完成大部分工作并創(chuàng)造優(yōu)質(zhì)產(chǎn)品所能承受的工作強度。

　　團隊可能偶爾需要高強度地工作，但是這是特例，不是一般情況。如果需要短期加班，那么整個團隊都應(yīng)該加班。如果sprint的后某些測試沒有完成，那么整個團隊不僅僅是測試人員都應(yīng)該加班完成測試。在團隊更好地管理負載和節(jié)奏之后，加班才會消失。

　　客戶關(guān)系

　　在傳統(tǒng)的軟件開發(fā)中，開發(fā)團隊和他們的客戶之間的關(guān)系更像是買賣關(guān)系。即使客戶是內(nèi)部的，但是感覺更像是兩個獨立的公司，而不是為了生產(chǎn)業(yè)務(wù)這一目標而共同奮斗的兩個團隊。敏捷開發(fā)依賴于客戶或者至少是客戶代表的緊密參與。敏捷團隊邀請客戶協(xié)作，如果可能，在同一地點工作，并且密切地參與開發(fā)過程。雙方都了解對方的強項和弱點。

　　不管客戶是內(nèi)部的還是外部的，這種關(guān)系的改變需要雙方的認同。開放的關(guān)系對敏捷項目的成功至關(guān)重要，在敏捷項目中，客戶團隊和開發(fā)團隊之間的關(guān)系更像是合作關(guān)系，而不是買賣關(guān)系。擁有一些領(lǐng)域?qū)＜掖，并且持續(xù)地向所有相關(guān)人員報告狀態(tài)，是實現(xiàn)開發(fā)人員和客戶成功協(xié)作的辦法？蛻魧γ艚蓓椖康某晒κ侵陵P(guān)重要的。他們對將要實現(xiàn)的功能確定優(yōu)先級，并對項目的質(zhì)量有終的評判權(quán)。測試人員與客戶緊密合作來理解需求，并定義證明滿足條件已經(jīng)達到的驗收測試。測試活動對于開發(fā)團隊與客戶團隊關(guān)系是很重要的。因此，測試專家是敏捷團隊的關(guān)鍵。

　　組織規(guī)模

　　組織的規(guī)模對項目如何運轉(zhuǎn)及公司如何完善結(jié)構(gòu)有重要的影響。組織越大，結(jié)構(gòu)中的層次可能會越多。當形成自頂向下的交流渠道時，報告結(jié)構(gòu)變得指令化，不適合技術(shù)和業(yè)務(wù)的溝通。