敏捷團隊的管理其實的確面臨著很多的挑戰(zhàn)。蔡老師分別從敏捷管理的挑戰(zhàn)、接受敏捷、敏捷下面的組織結構、敏捷架構下的溝通、敏捷下的KPI考核、以及機會和發(fā)展幾個方面進行深入的討論。
其實我覺得各個公司施行敏捷的時候都會遇見這次講師所分享的一些問題，基本上都是有共同點的。比如第一點，每個Scrum Team都會有自己的一個基調。每個測試你所跟隨的人不同，跟隨的team也不同，然后所接觸的項目也不同，碰見的問題也不同，甚至作息時間也會有所不同。這樣的情況下，管理其實是最最麻煩的。我自己之前也一直煩惱一個問題就是，在這樣的情況下，我應該如何進行test team這樣一個團隊的橫向分享，比如好的case，好的bug，又或者要push某個process的時候怎么辦。我表示真的很煩惱，如有人有好的解法，還希望在我blog下面留言。
第二個問題點，如何在做好管理的同時，又避免Scrum Master和Test Leader同時給測試發(fā)號施令。這個問題其實也很常見。Master和Leader橫向交流不同，每個人安排任務的切入點也不同，就往往會導致測試們很辛苦。一會兒要處理這個，一會兒要處理那個。最終會導致加班，情緒也不穩(wěn)定。
第三個問題點，一旦敏捷了，就會造成很多的“不規(guī)范”，那么在這種情況下面應該怎么進行KPI的考評呢？
第四個問題點，當你的團隊每個成員都被分派到了各個Scrum Team之后，如何保持test team一個高漲的氛圍，如何去維持一個很好的氣氛，是否能夠一直保證大家一條心呢？
第五個問題點，Scrum Master和Test Leader如何體現(xiàn)自己的KPI。一旦敏捷了之后，作為一個leader的話，我相信很多人會覺得這個職位越來越虛，好像自己離團隊成員以及項目越來越遠，那么怎么樣才能夠體現(xiàn)自己的KPI呢，我相信也是很多人困擾的原因所在。
第六個問題點，測試管理者的出路在哪里，或者說規(guī)劃，或者方向在什么地方？
如何去接受敏捷，這點我相信很多人也能夠體會。如果你作為一個測試經(jīng)理，那么推廣敏捷我相信是非常值得期待的一件事情。但是敏捷并非那么容易被團隊成員以及高層領導所接受，或者說那么快的接受。就測試成員來講，首先他會多了一個“婆婆”，Scrum Master。至少從心理上來講，會有一些抵觸的心理。其次 ，每個測試人員被安排到獨立的Scrum Team中，那么相比以前的團隊合作可能會多出很多的工作量不說，可能相對dev和pm來講更加的弱勢。從企業(yè)高層來講，我個人覺得一般會碰見這樣幾個問題。一種就是覺得現(xiàn)在的模式很好啊，為何要去改變呢？一種就是可能看到敏捷之后，覺得測試team更加偷懶了，沒有doc的輸出，沒有一個團隊的合作。所以綜上所述，接受敏捷需要時間，需要引導。
敏捷模式下面的團隊架構，蔡老師給出了四種架構，我自己其實比較偏向于測試人員上面一定要是測試leader，測試leader上面可以是別的一個職位。為什么呢？一方面來講，測試leader和測試人員最為熟悉也是最貼近的一個角色，無論是工作安排還是溝通都比較好。另外，就如我上一篇寫的文章中提到的，我還是認為能夠理解測試的只有測試，所以無論安排和溝通測試leader能夠更加從測試的角度出發(fā)進行思考，這樣對于測試人員的發(fā)展會非常有利。
這種敏捷的架構中必須盡量要保證產品，項目，測試，開發(fā)等幾個角色互相促進，互相幫助去推動產品，不要有什么勾心斗角。否則結果可能就和敏捷的初衷背道而馳。
敏捷模式下的溝通，這里其實就是兩點，敏捷模式下測試經(jīng)理和Scrum Master的溝通以及和組員的溝通。和Scrum Master的溝通主要是為了讓Scrum Master分配的任務更加符合項目情況，符合測試人員 的水平。和組員的溝通主要是引導大家去接受敏捷，并且不停地指出錯誤糾正，幫助大家和Scrum Master更好的溝通，以免測試人員感覺自己被賣掉了。
測試管理者在該模式下還有一個很重要的溝通對象，就是自己的上級。其實這這點并不難，我更覺得在各個企業(yè)哪怕不敏捷也需要做到這樣幾點。定期的說明自己的想法和建議，包括怎么落實怎么執(zhí)行。花時間好好總結自己團隊完成任務的情況，業(yè)績，讓上級一目了然。最后就是引導上級去接受敏捷。
敏捷下面的KPI考核。這點其實哪怕不敏捷很多公司也很迷茫。敏捷之后，需要進行全方位的考核。1.測試人員所負責模塊的質量。2.case和bug的質量 3.工作的態(tài)度和方法 4.Scrum Mater的反饋。主要要注意的就是作為測試管理者，要對于Scrum Master給出的feedback有所過濾，每個Master都會有自己的性格特征。作為管理者當考核的時候聽取Master的意見的時候需要根據(jù)其不同的性格進行有針對性的過濾，以達到最好最公正的評價效果。 5.對于團隊的服務 6.組內其他成員的反饋
在考核的過程中，測試管理者要像以前一樣的了解自己的組員，而不是放到每個team之后就不理不問。我覺得甚至要比以前更加的了解。同時，考核也是one one的一個過程，在期間需要更多的引導測試人員主動去展現(xiàn)自己的業(yè)績，主動去研究新的技術，主動幫助團隊的成員，提升自己的主觀能動性。這樣敏捷才會越來越好，越來越有效。
敏捷模式下蔡老師還提到了一個補位的概念，顧名思義，就是要了解每個team項目，人員的特征。在一些特殊的，突發(fā)的情況下，測試人員可以進行靈活的補位調整，這樣就不會對于項目、產品造成很大的影響。
敏捷帶來的機會其實很多，就如我自己在創(chuàng)業(yè)團隊中的初期一直是敏捷的一種模式，對于測試人員自身的要求會相應的提高，同時測試人員學到的東西也會更多。測試人員會相比以前的團隊中認識更多的同事，會提升自己的人際交往能力。作為管理者，敏捷也在考驗你的管理能力。就關于敏捷的好處來講，我總結就是作為測試人員，你了解的流程更多了，你了解的產品項目信息更多了，你接觸的技術面更廣了。但有一點，需要大家謹記，就是要不停地和同行溝通，要不停地進行學習。
敏捷是把雙刃劍，要看用的好不好。就如剛在微博上面發(fā)的一樣，大家根據(jù)實際情況進行選擇運用，否則很容易導致測試在企業(yè)中的流程也好，文檔也好，技術也好沒有沉淀和積累。合理運用傳統(tǒng)流程和敏捷才是王道。
本文轉載于51testing 如有版權問題 請找他們 本人只是學習備份而已！