作者 Deborah Hartmann譯者 鄭柯 發佈於 2008年4月20日 下午11時10分
敏 捷的“自組織團隊”模式需要團隊成員們具備新的技能——包括他們曾寄希望於項目經理具備的人際交往技能。對於正處於向“自組織”轉變之中的團隊來說，管理 對幫助團隊學習新的溝通和協作方式起到了非常重要的作用。但是要從何處開始呢？在不影響團隊自組織轉變過程的前提下，本文就如何傳授新的技巧給出了一些策 略，並提供了一些相關資源和材料，來幫助大家學習、開發新的技能。“很明顯，這些就是開發軟件的人……而且他們被忽略了。” ——Alistair Cockburn在《敏捷軟件開發》一書中引用Gerald M. Weinberg的話。
敏捷對團隊提出更高要求
對於將程序員視爲難以溝通的一類人這樣錯誤的陳詞濫調，作者Alistair Cockburn提出了質疑，並說道：“程序員只不過是願意就他們喜歡溝通的東西進行溝通，通常是他們正在開發的程序……他們不喜歡就自己不關心的東西閒聊。”而敏捷不同的是，它強調跨職能的團隊構成和面對面的溝通，這會大大擴展與一名開發人員工作效率“相關”的、也是其所關心的範疇。
現在，除了保證所開發程序的優秀之外，開發人員必須要會使用客戶的業務術語，要能理解與他們同處一室的團隊成員的身體語言，還要學着給出建設性的反 饋，並能與多種不同性格的人進行結對編程。敏捷的巨大效用，除了歸功於生產效率的提升之外，還來自於成員在團隊內外處理複雜人際關係的同時，仍能保證工作 富有成效。
無論是比喻方式或者（最好是）真正的矮牆隔間，一旦它被去除，我們就不能再躲藏起來，等待經理、業務分析師，或者是技術寫手來處理“人的因素”了。要想達到高生產率，團隊必須進行自我管理，意味着要把人際交往，即所謂的“軟”技能，逐步融入到團隊的日常工作中。
我們應該訓練誰？
人們很容易認爲這樣的訓練應該讓團隊中更加成熟的成員、以職能更偏向“業務能力”的角色參加。其實不應該是這樣的。在敏捷面前，大家一律平等：所有 成員對團隊產品成果的貢獻相同；同樣地，團隊有可能被任何成員的行爲影響或限制。Scrum實踐者、教練Simon Baker提醒我們：單單編程的行爲也是“一種社會活動，一次對話”，而且它會從人際技能的提升中受益：
對於成功的結對編程來說，高效的軟技能與技術能力同樣重要。進行結對的每個人都要能體察另外一個人的情緒變化，認真傾聽並閱讀他 的身體語言；要能夠表達自己的想法，並以建設性的方式表示不同意見，在不進行道德判斷或倨傲不恭的前提下去說服別人；能夠知道何時提供幫助，在尋求幫助時 也保持謙虛的態度。有許多程序員在這些軟技能上面備受困擾，真是遺憾。
那麼，我們該如何修正我們的團隊？
那麼經理現在是不是應該接過“修正”團隊和團隊成員的重擔呢？是不是每個人都必須把每件事做好？我們是不是應該訓練每個人都可以承擔所有的角色？對 於自組織團隊來說，這樣的干涉反而會影響他們對新範式的採納。要想讓團隊真正高效，教練的姿態也許更加合適：幫助團隊判斷他們應該如何分配工作，讓誰接受 多種職能角色的培訓。目標不是要讓大家的技能水平達成一致，而是爲了提升效率，以及在給定上下文之中如何達到最高效率。對於跨職能培訓，一位程序員這樣寫道：
我不同意改進弱點這樣的論述，我更喜歡加強天分和了解弱點這樣的說法。“瞭解你自己”並不意味着要學習所有的知識並讓自己成爲一把全能的“瑞士軍刀”。
提出 “通才專家（generalising specialist）”一詞的Scott Ambler表示了相同意見：
一個通才專家不只是一個通才（generalist）。通才只不過是個萬事通，但是沒有專長；而通才專家除了萬事通之外，還精通其中一些學問或技能。二者差距很大。
傳統上，培訓計劃隸屬於績效目標的一部分，以拓寬每個團隊成員的知識面。但是實際上這些培訓計劃很少能夠實現，而且管理層也無法提前準確猜測團隊在 未來的一年中需要什麼樣的技能。針對目前現實的情形展開培訓會更加有效——但是一個經理怎樣才能根據一些臨時情況來知道團隊需要什麼樣的資源和幫助呢？下 面就提供了一個起點：讓團隊自己找到自己的短板
幫助團隊尋找問題解決之道
幫助團隊學習他們所需技能的一種方式，是鼓勵他們發現阻礙前進之物，並支持他們尋找解決方案。對改進溝通方式的尋找應被視爲一種實驗，其他團體應用 的流程改進措施也應如此：嘗試，反思，學習，再次嘗試。提供可以加速學習的材料：雜誌、書籍、文章和播客錄音等等。不過不要忘記時間也是資源：爲他們提供 指導、會議、上網的時間，或者讓他們訪問其他團隊以找到解決方法，或者在接下來的迭代中添加一個“學習”任務。在尋找針對阻礙價值產生的問題之解決方案 時，通過實際應用找到的解決之道，團隊可以馬上從學習中受益，這也是讓培訓起作用的極佳方式。
如果真的有效，團隊自己的持續改進活動會產生一些需求，甚至能夠給出一些策略上的建議。Esther Derby和Diana Larson的《Agile Retrospective： Making Good Teams Great》一書可以幫助團隊開發這個很有價值的實踐。
不過要注意：這種反應方式，需要團隊具備發現問題、坦誠交流，以及知道去何處尋求幫助的能力。一個沒有經驗的團隊可能會在一個重要的“人際問題”上 受到羈絆，卻僅將其視爲一般的麻煩，而且無視其提出的警告。而且，在壓力之下，當問題發生時，他們可能無法處於尋找答案的最佳狀態，而是轉而繼續舊有的行 爲習慣。對一些團隊來說，下面這些策略應該會有幫助。
形成解決問題的新方式
剛從隔間走出來的團隊，如何以建設性和協作的方式開會的技能可能是他們最缺乏的。不妨帶入一個外面的推進者，或者在團隊內部找一個有天分的人，把他 們訓練成爲ScrumMaster或是推進者。一個指定的推進者可以將團隊從挫敗感中帶出，並找到解決方案。推進者要不偏不倚，並且不加入到團隊的爭執之 中——他或她可以鼓勵團隊以更客觀的方式來看待自己的人際交往問題，並將其視爲團隊成長過程的一部分。
推進過程可以讓一些困難的交談爲人們所接受，並找出新的方式來進行交互和問題解決過程。例如：新的推進者經常只願意待在不產生衝突的環境中，流連於 團隊內部，而忘記了要與利益相關者和團隊以外的其他人彼此的期望值達成一致。又例如：一個外部的推進者可以幫助一個學徒試着與會議或是項目的發起人面談，並與他們達成協議，保證所有的參與者都能將注意力置於真正的目標之上，並讓團隊以成功爲導向。
團隊成員傾向於從觀察中學習來推進實踐——他們還有可能要求進行培訓。根據團隊和所在環境的穩定性，這種推進可能是一個短期的過程，當團隊逐漸進入 自我推進的過程後，推進者就可以擔負其他責任了。有時，一個新的“推進者”角色會爲整個部門服務，開始訓練其他推進者，或者在出現問題或隔閡時主持回顧活 動，在像惠普和西門子這樣的大型企業中就是這麼做的。敏捷軟件社區中有一些成員，包括Ainsley Nies，Diana Larsen和Esther Derby，他們都有從事類似活動豐富的經驗，可以幫助其他人完成推進過程。
爲何要等到問題出現之時？
在研究過很多成功的團隊之後，Alistair Cockburn發現——暫時忽視人們的弱點——有三樣東西我們可以一直指望：
- 人們通常願意成爲“好公民”，
- 人們喜歡採取主動，而且
- 人們善於四處眺望
即使在問題出現之前，也要讓團隊成員知道人際溝通技能與編程技能同樣重要。接下來，靜靜觀察團隊房間中發生的一切，傾聽回顧會議中傳遞出來的聲音——要記得有些團隊要用稍長的時間來面對麻煩的問題，所以他們不只需要鼓勵，還要有持續的支持。
要注意對小組動態或政治問題敏感的團隊成員。可能有人只要“擡頭觀望”就能知道團隊現在需要什麼，有人像個好公民一樣，承擔提出關於人的問題的風險——這個人可能會讓你感到訝異：“竟然是他！”。
例如：針對團隊房間如何佈置才能讓每個人都全情投入，一個團隊成員表示了他的擔心。此時，經理可以爲這個成員提供一些資源，讓他有機會爲團隊的轉變做出貢獻，而不是經理自己來研究並進行改變。對於這個例子來說，Cockburn的書《敏捷軟件開發》提供了一些關於如何讓團隊房間起作用的理論——還包括應該避免什麼。下面是一種指導的方式：買兩本此書，給那位成員一本，並與他進行幾次會面，討論如何將其中的材料應用到團隊的實際情況中。
通過以提問、指導、建議和提供資源等方式給予協助，經理可爲團隊提供幫助，而且不影響團隊在自我管理方面逐漸增長的自信。
資源來自何方？
想在網上找到“供極客專用的軟技能”是很難的。該使用什麼樣的關鍵字去針對上百萬個沒有相關主題的博客進行搜索呢？哪些解決方案與敏捷的方法可以兼容？在敏捷社區中，針對管理、溝通和推進過程的書籍開始出現，要注意像InfoQ.com/Agile，AgileJournal這些網站上的新聞資源，像ScrumDevelopment、ExtremeProgramming、LeanDevelopment、Agile Management和LeanAgileScrum這樣的敏捷相關的郵件列表資源。這些列表是資深的敏捷實踐者們經常出入之地，而且也是新手們尋找正確的資源和指引的上佳場所。
每年一次的“加速提升你的效率（Accelerating Your Effectiveness，即AYE）”會議， 其目的就在於專門幫助軟件實踐人員和管理層學習更好的人際技能。它是在2000年的時候由一小組諮詢師發起的，其中包括已經爲管理層和軟件開發者提供有價 值的資源長達25年的傑拉德•“傑瑞”•溫伯格（Gerald“Jerry”Weinberg）。（溫伯格已經撰寫了多本書籍，包括1971年的《計算機 編程心理學》——這也許是第一本將編程視爲個人和團隊活動的書籍，1997年的《質量軟件管理，第四卷：預測變化》——專爲關注和擅於處理軟件變更的人士 所準備。）
AYE會議由少數軟件思想家領袖所 主持，在這個與軟技能相關的、一年一度而且豐富多樣的4天會議中，許多資深的實踐者會分享他們這一年職業生涯中的亮點。通過與人實際交流的方式學習這些技 能能夠得到最好的效果。不過如果實在無法派人蔘加，那麼會議的網站也是進行網上研究一個不錯的起點。在網站上的會議內容涵蓋了演講者關於自組織團隊和小組 的經驗，以及他們往年的文章和演示，也包括下列2007年的內容：
- Dale Emery的“重寫抵抗的故事”
- Esther Derby的“點對點的反饋”
- Johanna Rothman的“說服管理層改變團隊上下文不是個好主意”
此外，在敏捷聯盟每年的Agile200x系列會議上， 有許多非常實用的、關於溝通和推進技能的議題。雖然參會要收費，但議題的提案和摘要是免費的，而且這會指導你去尋找這些一些人，他們對於一些話題的思考會 對你的團隊有幫助。這還僅僅是研究的開始：通過找到這些人的博客和發表的文章，你一定能夠發現更多起到幫助作用的作者和教練。
敏捷聯盟的文章庫也是一個很好的地方，有許多關於溝通和推進技能的文章分散在下列分類中：自組織、關於溝通，還有關於人。
嗯，也許當我們有更多時間時，再……
時間總是不夠用的。但時間不是我們唯一可以用來完成更多工作的依靠。Schwartz和McCarthy提醒我們他們所提的“個人能量”是一種可更新的資源：
通過一些略帶欺騙性的簡單儀式，組織可以幫助僱員定期補充他們的能量，讓他們在身體上、感情上和心智上都得到恢復。這些儀式包 括：以特定的間隔讓大家得到短暫的休息；對他人表示欣賞；減少干擾；對於能夠讓人們能夠更好地工作和休息的活動，不妨多花些時間……讓你的僱員們有系統地 復原他們的個人能量，這一定能夠對組織直接產生有益的效果。
他們引用了Wachovia 銀行的例子：參與了“能量復原”計劃的人，相對於對照組來說，他們在借貸上的年收入要多產出13%，而在存款方面的年收入多20%。
Scott Ambler，在談到敏捷單一來源（Agile Single Sourcing）時提醒我們：“在敏捷軟件開發中，要儘量保持輕裝前進，想達到此目的，最佳的方式就是用最好的工件（artifact）來記錄信息。”
有些專家只知道如何使用少數幾種工件來記錄信息，如果團隊由這樣一組專家組成，就很有可能在多個不同的地方得到同樣的信息……如 果人們都是通才專家，他們都有一種或幾種特長，而且還對整個的軟件生命週期有大體的瞭解，他們就可以使用多種工件，從而不會產生在多個地方記錄同樣信息的 不良狀況。
實際上，這已經超出了工件的範疇：通過適時、有效的討論，或者僅僅是與適當的人協商，團隊當前的文檔有多少可以被拋棄？不受人的因素困擾的團隊可以更好地協作，更快做出決策，並減少“浪費”的文檔和溝通。
所以，如果你有很多事情要做……你現在敢於承擔不提升團隊個人能量和溝通效率所帶來的後果麼？如果你真的“沒有時間”，問問你自己是不是在管理一個踏上“死亡之路”的項目，是不是該重新調整一下了。（另一種方案，有人聽傑瑞•溫伯格推薦這樣的策略：向絕望的藉口的守護者——聖猶大祈禱。）
慢慢來
有了這些策略和資源之後，還有非常重要的一點要記得：要允許團隊和個人在需要的時候自己去“拉”來需要的資源，來構建他們的自信；而不是由管理層向他們強制“推”行！最後以隱喻大師——Dale Emery的話作爲結尾：
……“你可以把一匹馬領到水邊，但是你不能強迫它喝”，這意味着“我們這些聰明的變革專家可以告訴人們我們的好主意，但是我們不能強迫他們採納這些主意。”
這常常讓人們覺得很鬱悶，我們這些聰明的變革專家無法讓人們採納我們非凡的主意，這好像是特別令人沮喪的事情。
看看下面的建議：試着把一匹非常口渴的馬領到水邊，看會發生什麼。如果馬很累了，把它領到蔭涼之中，提供一個可以躺下來的柔軟的所在。如果馬餓了，給它乾草和燕麥。如果馬什麼都不需要，那就隨它去吧。
關於作者
Deborah Hartmann是一位能夠說兩種語言 的敏捷實踐者、培訓師和教練，她的工作以多倫多爲基地，並經常在多個國家之間穿梭。Deborah熱心於將工作變得更具業務價值，並讓團隊享受工作帶來的 樂趣。在實踐敏捷的過程中，她擔任教練涉及多個具體項目，業務範疇從大到小，一應俱全。從2006年四月開始，Deborah擔任InfoQ敏捷社區的主 編，並推進了在美國和加拿大舉行關於極限編程的OpenSpace會議和BarCamp社區活動。她還與Naresh Jain一起，作爲聯合創建人，創建了AgileCoachCamp。
InfoQ相關內容
在Joe Rainsberger的文章《不要讓誤解影響你的團隊》一文中，他應用了在AYE會議上學到的知識，來提升人際交往和溝通，並提供了其他一些額外資源。
請移步InfoQ敏捷社區查看更多關於團隊協作、面對面溝通、自組織團隊和領導能力等方面的內容。
注：以上內容來自網絡，本人不承擔任何連帶責任
文章轉自：http://www.infoq.com/cn/articles/agile-people-facilitation-skills