建立高效軟體團隊的五個因素

July 13 13:30~17:18

 

今天介紹一篇刊登在最新一期 IEEE Software 的文章：「Team Performance in Software Development」(軟體開發團隊績效)。文章提到五個影響軟體開發團隊的因素，分別是：

• Team Coordination（團隊協作）
• Goal Orientation（目標導向）
• Team Cohesion（團隊凝聚力）
• Shared Mental Models（共享心智模型）
• Team Learning（團隊學習）

***

Team Coordination

軟體開發包含很多不確定性，開發人員經常面對模糊、定義不清且時常異動的需求。在這種情況下需要依靠團隊成員之間的良好協作來處理問題。「協作」這個字經常聽到，到底是什麼意思？根據文中的定義，協作就是「管理活動之間的相依性」，例如：共用資源（昂貴的測試設備誰要先用）、工作分派、不同工作包之間的關係。

良好的協作需要團隊成員頻繁地互動（interaction）與回饋（feedback），以及在團隊成員之間對於相依性的事物需要達成共識，才不會出現雞同鴨講的現象：

成員甲：你這個工作怎麼做了三天都還沒完成？

成員乙：我根本還沒開始做啊。不是要等你先做好X我才可以開工？

成員甲：這兩件事情沒有一定誰要先作、誰要後做啊！

***

對應到敏捷開發，團隊協作的機制非常多。像是Scrum裡面的各種會議以及短開發週期，XP的pair programming也是一種協作開發方法。看板方法則是透過限制在製品（WIP）數量，以視覺化的方式達到人員協作的目的。

***

Goal Orientation

目標導向也是大家耳熟能詳的 口號 方法。沒有目標，或是目標不明確，會導致大家瞎忙，但卻沒有實質產出，當然會嚴重損害團隊績效。講是這樣講，但讓團隊成員擁有一個清楚且願意共同努力的目標，有時候並不是那麼容易。相信不少人有類似的經驗，老闆為了「激勵士氣」，訂定一個非常有企圖心的目標讓團隊去完成。最後除了達到激怒團隊的效果以外，並沒有實質提升績效。

文中提到團隊領導要引導成員朝向目標邁進，必須要了解軟體開發流程中種種的動態變化，時時關注與評估團隊成員的行為。

對應到敏捷開發，在Scrum中每個sprint都有一個sprint goal，由Product Owner與團隊成員共同決定。團隊成員依據story優先順序施工，這也算是一種落實目標導向的方法。Release plan（產品釋出計畫）可視為更大的目標，以避免只關注sprint goal產生見樹不見林的問題。另外，最小可行性產品（Minimum Viable Product；MVP）也是一種目標導向的做法，只是在MVP的觀念中，這個目標是有待驗證的假設，希望藉由快速上市獲得用戶回饋來修正目標。

***

Team Cohesion

團隊凝聚力就是一群人黏在一起，團結一致以追求目標的傾向。看過電影《魔戒》的人都知道，魔戒遠征隊剛開始凝聚力不高，以至於出發沒多久就只剩下佛羅多和山姆兩個人。凝聚力越高，代表團隊對於完成使用有著較高的承諾（commitment）。

XP的Collective code ownership（又稱為shared code）是一種提升團隊凝聚力的方法。Scrum的自省會議（retrospective meeting）藉由團隊成員持續提出改善建議，（做得好的話）也是一種有效提升凝聚力的手段。

***

Shared Mental Models

共享心智模型聽起來不太像平常會說的話，翻成白話文就是團隊成員對於工作、工作之間的關係、如何協作與互動等概念，有著相同的認知。例如，Scrum、XP或是Kanban這些方法便可視為一種心智模型（如何做事，以及對於某些名詞有共同的定義、理解）。說的再簡單一點，就是團隊成員認同某種做事的方法，這種認同就是共享心智模型。擴大一點來講，可以解釋成「文化」。句有相同文化背景的人，對於如何生活、如何溝通、如何做事以及一些約定俗成的事物，都有著共同理解。

共享心智模型可以增進團隊效能道理也很簡單，試想一個想要導入Scrum的團隊，只有一個人去上過課，其他人都還活在waterfall的世界中，這樣的團隊怎麼可能有效率。所以，要讓敏捷開發產生作用，必須建立起團隊的敏捷思維（agile mindset）或是敏捷文化（agile culture）。

***

Team Learning

最後一點，團隊學習，算是大絕招。不管團隊具備什麼能力，這些能力都可能會「過時」。怎麼辦？有什麼能力可以解決能力過時的問題？想來想去就是「學習力」。只能具備學習力，所以不足的能力都可以獲得，這也就是「學習性組織」的概念。

敏捷開發就是一種持續學習、持續改善的方法，各種會議、回饋機制，都是一次團隊學習的機會。

***

分類人人都會，各有巧妙不同。光是知道這五種高效團隊的特性其實沒什麼用處。鄉民們可以試者將自己熟悉的開發方法，或是目前團隊實際的做法，套到這五個因素中。自己分析看看，這些因素目前自己團隊的實踐方式是什麼？有沒有可以改進之處？具體而言可以採用何種方式來落實？

**

友藏內心獨白：寫好久。