敏捷測試團隊和管理(1)--糾結篇


太懶了。

直接挪過來吧。在這里開了三年多的地盤,也沒寫啥,真是汗顏!!

 

其實 敏捷這個詞,在中國已經流行很久了。
我也一直沒有認真的去分析它的存在,價值,意義以及有可能帶來的一些負面的影響。
 
直到我換了一份 工作
 
上一家公司,其實也是一種敏捷的團隊。
版本的頻繁發布,開發團隊的不斷自己修繕。然后 測試團隊的人員跟進各個項目,進行業務了解,需求探知,然后測試。
之所以沒有很深刻的感悟。是因為當初的測試團隊和開發團隊物理上是分開的。
 
無論手里接多少個項目,項目之間是否有關聯,所有的測試團隊的成員都在一起。對於因為做不同的業務而產生的可能會有的gap,我設定了一個share meeting來補足。每個人都對於其他人的項目業務,項目的難點,現存的問題以及解決方案都會有些了解。一旦需要項目反轉,人員調動,也不會是全新的手足無措。
 
還有一點,是我以前沒有意識的很清楚的。那個時候跟我合作的開發團隊,是有很深的業務知識的。對於各個業務之間的關聯,對於系統的整體業務邏輯,對於框架基本都是了解的,甚至有的算是十幾年的資深。
所以系統的這種敏捷模式,即便是變化時時有,偶爾也引入一些問題,但是總體上還是好的,可控的。
 
即便如此,因為出了一些新入開發人員對於某些需求的修改,導致其他功能的失效,讓我很是擔心了一回。也因此提出了風險盤整和整體變化控制必須到QA的理念。
而今想來,這些還真算是小case了。
 
新的公司,是國內的開發團隊,模仿的或者說自我心里認同的也是所謂的敏捷開發。
但是對於業務不甚了解,需求不完全知道,架構體系關聯一沒有耐心而沒有時間三沒有精力去了解的,這樣的團隊們也可以自詡為敏捷嗎?
 
他們之所以版本頻發,甚至頻發到跟蹤都難,是因為自己改一次,錯百出。自我卻沒有任何的檢討。認為這就是敏捷。甚至因為UT的“麻煩”和“浪費時間”而輕輕越過。。這也叫敏捷?這叫全無規矩,沒有章法好不好?
我終於了解,什么叫做山寨,也真是納悶了,中國的山寨真是落地生根啊!
 
而且,目前對我來說,最為麻煩的問題不僅僅在於對應這樣的開發團隊。
還因為我的測試團隊被打散了。
 
這邊公司的業務對應很多不同的客戶,每個客戶的需求又會幻化成若干項目。然后每個項目都不大,所以測試人員需求也不多。於是我的測試人員就變成了分散到各個項目的游兵散豆。跟着各個項目拼殺。
 
在人家的一畝三分地上活動,加上又要占用人家項目的budget。對於業務和測試了解並不深入的開發PM們於是就覺得,測試人員自從進入他們的項目的那一刻,就屬於他們的管轄范圍了。於是我很悲催的就失控了。其實我的這種悲催是這個公司從成立以來就是如此的。所以我只能說我很悲催的認識到原來還可以這樣。
 
上周跑到各個項目去做了解,繼續還能悲催的看到分散在各個項目里面的測試人員間或做一些和測試無關的事情。PM們認為,我讓你測試人員入場,就犧牲了其他的resources的人頭預算,所以你幫我一下也是應該的。而追求利益最大化的老大們也認為,多了解一些對於測試人員也是好的嗎。。。
 
於是,我坐在這里寫proposal。從沒有任何一個proposal讓我寫的如此艱難。現狀分析,影響范圍,解決方案。。其實我自己都沒有很好的解決方案。
 
我自問沒有能力真的一下子去了解那么多項目的日常運作和業務。但是不控制的結果是我基本上淪為了一個RM,分人頭。。而這樣的結果不是我如何,而是我的Tester們被置於何地?他們的依靠又在哪里?
但是若是分開,獨立出來,又有若干可恨的客戶,因為安全的因素必須使得某些項目在獨立的開發間。。
 
分開,分離,讓Tester們,開發PM們修正自己的想法,轉換思維。讓開發和測試真正的開始獨立並行,親密合作。。夢想啊,怎么樣才能讓它落到現實呢?
 
*******
后記,在這里也不是向開發人員和團隊抱怨什么。他們也有很多的無奈。因為文化,體制導致的和客戶的不對等或者因為溝通的問題導致的自己沒有轉圜的余地。
Anyway,這些都是我在面對的,和要解決的。
 
曾經我對自己說,如果真的想做,就算用牙咬,我也會撕出一片自己的天空。而今,2012年的我,是否還有當初的勇氣呢?

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM