歡迎您光臨本站 註冊首頁

敏捷團隊的人員分佈

←手機掃碼閱讀     火星人 @ 2014-03-12 , reply:0
  

許多考慮採用敏捷的組織沒有把團隊遷移到開放式環境就嘗試創建項目團隊。敏捷價值和原則中,當團隊成員可以隨時接觸到所有其他團隊成員、易於獲得所有的項目進度圖表、在鼓勵交流的環境中時,團隊可以更好地工作。敏捷測試專家Lisa和Janet分享了敏捷測試團隊的人力資源經驗。

測試人員和客戶與程序員坐在一起可以促進必要的交流。如果實際情況不允許重新遷移位置,那麼團隊可以創造性地解決這問題。

Janet分享了自己的故事:

我曾經在這樣一個團隊工作,空間問題使得所有團隊成員不能坐在一起。程序員有一個可以使他們方便結對編程的區域,但是測試人員和客戶坐在其他的區域。首先,是測試人員走到程序員坐的用戶故事白板區域去參加每日站立會議,當他們有需要問程序員的問題時,也是這樣。基本沒有程序員走到測試人員的區域(大約50英尺的距離)。我開始準備一些招待他們的糖果,並鼓勵開發人員在需要的時候拿一些。但是有一條規矩——如果他們來拿糖果,他們必須問其中一個測試人員一個問題。隨著時間的過去,所有的團隊成員都會相互走到另一個區域了。不是一邊總走向另一邊,交流也更頻繁了。

團隊規模給組織帶來了不同類型的挑戰。小團隊意味著小的區域,所以通常更容易將成員的位置換到一起。大的團隊可能分佈在全球,這時需要虛擬交流工具。調動大團隊的座位通常意味著整修目前的空間,很多組織不願意這麼做。明白你的限制,努力找到團隊遇到的問題的解決方法,而不是僅僅接受現實並“保持現狀”。Janet舉了一個例子:

我工作過的一個團隊一開始在樓層的一角,但是通過三年的擴張,逐漸的佔據了樓層的75%。牆被拆掉了,去掉了辦公室,創建了大的開放區域。團隊在這種開放區域工作地很出色,但是所有的開放空間意味著牆沒有了。窗子變成用戶故事板和白板,白板按順序捲起以便團隊需要時使用。

坐在一起的團隊並不總是存在於完美世界中,分散式團隊有另外的一些挑戰。分散式團隊需要幫助團隊交流和合作的技術。電話會議、視頻會議、網路攝像機和即時消息是一些可以促進在不同位置的團隊實時協作的工具。不管團隊是在一個位置的還是分散式的,通常存在的一個同樣的問題是,敏捷團隊需要什麼資源,如何獲取它們。

新的敏捷團隊成員和他們的經理對於團隊的組成有很多疑問。可以使用在傳統項目中同樣的測試人員嗎,或者是否需要聘用那個不同類型的測試人員?需要多少測試人員?是否需要具有其他專業技能的人?

關於測試人員和開發人員的“正確”比例的問題已經有很多討論。組織使用這個比例來確定項目需要的測試人員的數量,可以根據這個數量來聘用測試人員。在傳統項目中,沒有“正確的”比例,每個項目需要自己估計。需要的測試人員的數量是不同的,依賴於應用的複雜性、測試人員的技能和使用的工具。

Lisa和Janet曾經工作在不同的測試人員——開發人員比例的團隊,從1:20到1:1都有。以Janet來說:

我曾從事一個開發消息處理系統的項目,他們的比例是1:10。GUI很少,我手動測試應用的這一部分,查看可用性和是否符合客戶的期望。程序員做所有的自動化回歸測試,我同他們一起驗證編寫的測試用例的有效性。我把測試的用戶故事,包括某些用戶故事的負載測試,分配到開發人員。

我從來沒覺得沒有足夠的時間做需要的測試,因為開發人員相信質量是整個團隊的責任。

Lisa則分享了自己的故事:

我曾經是一個有20名程序員的團隊的唯一一名專業測試人員,該團隊開發在線商店網站的內容管理系統。當程序員負責手動測試和測試自動化時,團隊才真正有工作效率。一個或兩個程序員在每個迭代的中扮演測試人員,在編碼前編寫面向客戶的測試並執行手動測試。其他的程序員在迭代中承擔起測試自動化的任務。

相反的,我現在的團隊每三或五個程序員有兩個測試人員。我們生產的基於web的財務應用有非常複雜的業務邏輯,有很高的風險,而且密集測試。測試任務通常與編碼任務的時間一樣多。即使是測試人員——開發人員高比例,程序員也會做一些功能測試自動化並部分承擔手動測試任務。專門的測試任務,例如編寫高層次的測試用例和詳細描述面向客戶的測試通常由測試人員完成。

與其關注比例,團隊更應該估計他們需要的測試技能並找到合適的資源。負責測試的團隊可以持續地估計是否有需要的技能和數量。使用回顧總結來確定是否需要聘用更多的測試人員是一個解決方法。

測試人員適合敏捷團隊的工作需要一定的條件。我們不會過多討論聘用什麼類型的測試人員的細節,因為每個團隊的需求是不同的。但是,我們相信態度是一個重要的因素。下面是Lisa的團隊如何聘用一個新的敏捷測試人員的故事:

我們招募另一名測試人員的第一次嘗試並不是很成功。第一個工作招聘公告吸引了很多人,我們面試了三名應徵者,但是沒有找到合適的人選。程序員希望找到“技術人員”,但是我們也需要有同業務人員合作和幫助他們描述實例和需求的技能的人。為了吸引有正確的態度和思想的應聘者,我們努力明確工作招聘公告的內容。

在聽取Janet和敏捷測試社區的其他同事的想法和建議以後,Lisa改變了工作招聘公告,包含如下的條款:

  • 熟悉黑盒和GUI測試用例,設計測試減輕風險,幫助業務專家定義需求。
  • 熟練編寫簡單的SQL查詢和插入/更新語句,掌握Oracle或其他關係型資料庫的基礎知識。
  • 至少使用某種腳本語言或編程語言和/或開源測試工具超過一年。
  • 使用基本Unix命令的能力。
  • 擅長與程序員和業務專家協作。
  • 最好有基於上下文環境的測試、探索性測試或場景測試的經驗。
  • 融入自組織團隊的能力,即與同事協調確定每天的任務,而不是等待分配的工作。

Lisa表示:這些需求帶來了更適合敏捷測試工作的應聘者。我通過小心的篩選,排除了有“質量警察”思想的人。追求職業發展和對敏捷開發顯示出興趣的測試人員更傾向於有正確的思想。團隊需要對測試工具和自動化領域有較強能力的人,所以學習的熱情是極為重要的。這種新穎的招募測試人員的方式是值得的。當時,找到好的“敏捷測試”候選者是不容易的,但是接下來進行得更順利。我們發現把測試職位公告放到不那麼明顯的位置,例如Ruby的郵件列表或者本地敏捷用戶組,可以幫助延伸到更廣闊範圍的合適的候選者。招聘敏捷測試人員教授了我許多關於敏捷測試思想。有良好技能的測試人員對於任何傳統測試團隊都是有價值的,但是因為他們對測試的態度,可能不適于敏捷團隊。



[火星人 ] 敏捷團隊的人員分佈已經有363次圍觀

http://coctec.com/docs/program/show-post-71304.html