你們是完整團隊嗎？
譯/金毅
如果你的團隊使用敏捷方法開發軟件，那么采用完整團隊方法（Whole-team approach）對于發揮敏捷實踐的功效極為重要。
完整團隊這一敏捷實踐強調以整個團隊為單位工作，把專人專責簡化為職責均擔，從而開發出高質量的軟件——可以說它是一種“膠水型”實踐：它將很多其它敏捷實踐組織在一起。例如，在Lisa Crispin和Janet Gregory所列舉的敏捷測試的“關鍵成功因素”中，完整團隊位居榜首。
和其它實踐一起協作，完整團隊能發揮巨大價值，如降低交付風險、改善速率/發布周期、得到更優方案以及減少缺陷和其它浪費。然而完整團隊和其它敏捷實踐一樣需要紀律性和勤奮。在此有四個“臭味”可能預示著你還沒有發揮完整團隊的功效——同時我也建議了一些解決方法，或許能幫你順利過關。
臭味 #1: 強調頭銜
我記得有個團隊剛剛開始實施敏捷時，某個團隊成員拿著組織結構圖，義正言辭地跳出來指正：在程序員完成故事編碼之前應該禁止測試人員介入。其實沒必要把頭銜搞得跟完整團隊勢不兩立。但如果某個重要成員一意孤行，或者團隊因為角色不同而不敢質疑技術主管，再或者團隊期望“測試人員”完成所有測試，那我們就該擔心自己實施完整團隊的效果了。
解決方法: 打破角色和職責界限
如果你把工作簡單地看作是一些待完成的活動的集合，那么你就可以打破角色和職責的界限，允許隊員在多重領域創造價值。比如，解放程序員，讓他們探索測試。類似地，當測試人員發現一個他們能修復的缺陷時，放手讓他們去修復吧。
臭味 #2: 英雄主義
我們都見過這樣的人：某個團隊成員為了順利發布，打算今天加班到很晚，或者周末加班。他上次就是這么干的，這次也將這么干。問題在于：英雄主義對項目有百害而無一利，它降低了團隊的人員風險承受能力（也就是說，團隊中有幾個人離開，但還能保證項目正常運行），而且往往還會阻礙信息共享（當然不全是故意的）。學習和進步的瓶頸就在于此。引申出來的另外一些臭味是：是否任何人都能在任何時候休假呢？某人能輕而易舉地離開項目嗎？
解決方法: 擺脫依賴
如果你是團隊中唯一更新白板或修復有問題的構建的人，去休個假，試試如果沒有你會發生什么。
在每日站立會議中，如果你發現某位團隊成員只是向你而不是所有成員陳述他的見解（假設你是主管），那么你只要避開他的目光，他就會自然而然地轉向其他人，和團隊一起達成一致，也會慢慢形成會議的主人翁精神。最好的團隊領導者是信息共享者而不是信息囤積者(hoarder)。
臭味 #3: 大家每天固定位子就坐（一個蘿卜一個坑）
大家是不是每天上班都坐同一個位子呢？選哪個電腦有什么影響嗎？是不是每臺電腦都有你需要的全部工具，同時配置完善足夠你完成所有任務呢？如果不是，證明你們不經常結對，也不常交換結對伙伴。
解決方法: （真正地）結對編程
結對編程并且經常輪換結對伙伴是需要紀律性的。如果你沒做，只能說明你不相信這有用。為了共享知識和技能，在看板系統中你可以安排學習和一些緩沖時間。你可能需要拒絕一些客戶的要求，但短暫的損失將帶來長期的收益：你整裝待發，開始一起協作的極限編程之旅。而正是由于掃清了知識方面的瓶頸，你將會快速前進。試試結對吧。
臭味 #4: “編外”隊員
在你的團隊中，你有沒有一個隊員被排除在關鍵會議之外呢？這可能發生，比如技能存在很大差異時，團隊中有兼職或共享成員時，或者團隊主管認為不需要所有人都參加會議。
解決方法: 三駕馬車
敏捷團隊可以通過三駕馬車來匯聚知識和意見。如果規定關鍵會議必須有測試人員、程序員和業務代表參加，將有助于團隊分享對需求的理解，減少溝通隔閡，并且盡可能擺脫個人技能和見解的限制。Janet Gregory稱之為三駕馬車，而George Dinwiddie則引用電影“神勇三蛟龍”（Three Amigos）來命名它。不論你叫它什么，它都是完整團隊的一個基礎部分。
那么下次你參加回顧會議時，考慮考慮怎樣在下一個迭代改進吧，或者想想你是不是那個唯一知道如何修復構建的人呢？你也可以去思考一下完整團隊里那些臭味以及解決方法。抑或停下你思索的腳步，和其他隊員討論討論這個話題。
關于作者
Matthew Philip以前是Asynchrony Solutions的敏捷教練，但他更喜歡說他是“敏捷團隊隊員”。想了解更多信息，請訪問他的博客。
關于這個話題的一些參考信息:
- 敏捷測試 (Crispin and Gregory)
- Ron Jeffries談完整團隊實踐
- George Dinwiddie的《神勇三蛟龍》
- Ralph Waldo Emerson的《美國學者》
- 哥玩的是足球，不是橄欖球：如何通過關注活動而不是角色來培養完整團隊
查看英文原文：Are You a Whole Team?
留言列表
