《敏捷軟件開發 : Scrum實戰指南》—3.4 建立團隊

建立團隊

不管選擇首先建立一個公司范圍內的團隊顧問池，還是在小規模的范圍內嘗試這種模式，組建團隊時首先都要考慮項目需要哪些技能。如果技術能力有欠缺，可以向熟悉該項目的同事求助。在鑒別出需要的技能組合之后，還需要考慮一些軟實力，比如溝通能力、開放的心態以及團隊合作的能力。這些能力常常更難鑒別，但對成功至關重要。這些技能如表3-2第一列所示。

一旦列出技能、能力，就開始挑選合適的人員，把他們映射到你的挑選表中，包含他們的可用性。對每一個人從0星到5星進行打分。記住，這不是一個絕對的量化評估，而只是一個主觀的評價。做這個事情你可能需要幫助，在這個過程中加入第二種觀點。結果如表3-2所示。相比故事中Rebecca匆忙中的涂鴉，這是一個更加正式的版本，可以根據具體人員與需求進行修改。

核心團隊

讓我們假設表3-2 是 Rebecca 在會議后畫的。從表3-2中，一眼就可以看出 John與 Michelle 完全可用，他們共有三項關鍵技能：架構、SQL 與數據建模。另外，他們兩個也被認為具有良好的團隊合作精神。Rebecca 的項目碰巧有大量的 SQL 工作，因此盡管Michelle具有SQL的技能，Rebecca確定她在這個方面需要更多的幫助?？粗渌鸖QL人員，Rebecca在Larry和Scott的名字上畫上了圈，他們在一定程度上可用，很可能可以成為全職的成員。她期望的專職團隊成員包括John、Michelle、Larry與Scott。從圖3-1可以看出，Rebecca的核心團隊并不能覆蓋項目所需的全部技能。

Larry

John

Randy

Scott

Michelle

David

Michael

Stefan

在公司中的角色

開發

開發

測試

測試

開發

開發

架構師

架構師

能力

團隊合作

***

*****

***

*****

*****

*

*

*****

容易溝通

**

*****

*

***

**

**

****

*****

面向客戶

**

*

*****

**

*****

坦然面對沖突

***

**

*

**

**

**

*****

**

開放的心態(愿意學習)

*****

*

***

*****

**

***

**

技能

C#

**

****

*****

**

**

*****

**

SQL

*****

**

*****

*****

*****

**

*****

AJAX

***

****

UI設計

***

**

***

*****

*

***

架構

*

*****

*

**

***

*****

*****

數據建模與ETL

**

*****

***

*

***

可用性

***

*****

*

***

*****

**

***

**

團隊顧問

一旦組成核心團隊，大家就一起開會討論自己的優勢、劣勢以及項目的技能空白。如果發現有技能上的空白，就需要考慮能夠利用哪些團隊顧問。

讓團隊開始接觸團隊顧問池里滿足要求并且能夠和團隊配合的人，如果還沒有一個專門的團隊顧問池，就在公司范圍內尋找。假設?Rebecca?的團隊從?Michael?那里得到了承諾，他可以做?C#的代碼審核，并且結對來幫助團隊完成可能搞不定的?API。團隊還要求David與Stefan分別擔任用戶界面與?Ajax?的團隊顧問。最終的團隊結構圖如圖3-2所示。注意團隊顧問是如何填補團隊技能空白的。

團隊大小

我們都有這樣的成見：小團隊往往工作做得更快。增加人手需要額外的上手時間。布魯克斯(Fred Brooks)在《人月神話》[BROOKS] 中提出了布魯克斯定律：“在已經延遲的項目中增加人手會使項目進一步延遲。”但這是常態嗎？

帕特南和邁耶斯(Lawrence H. Putnam & Ware Myers)在1998年進行了一個關于團隊大小的研究[PUTNAM]。他們的成果發表在1998年的卡特聯盟(Cutter Consortium)上。他們倆研究了491個(新增或修改的)代碼行為35 000～95 000的中等規模的項目，全都是1995年至1998年間完成的管理信息系統項目。

他們確認，由5到7人組成的小團隊交付時間更短(參見圖3-3)，當團隊超過9人以后成本會顯著增加(參見圖3-4)。

如果有團隊顧問，合適的團隊大小應該是4到6個核心成員，這樣一來，即便加入1到3個團隊顧問，仍然可以保持恰當的團隊大小。記住，團隊顧問可以來來往往，但核心團隊要一直保留。

核心團隊與團隊顧問一起工作

一旦建成由核心團隊成員與團隊顧問組成的團隊，就需要建立鼓勵團隊合作的指導方針。不同組織有不同的指導方針，但都應該包括下面幾條。

在整個Sprint期間，核心團隊與團隊顧問共同、平等地對他們的交付承諾負責。團隊顧問要按時上班，盡量參加每日站會，而且在整個 Sprint 里把自己歸為團隊成員。除了在某一領域是專家以外，團隊顧問與團隊核心成員沒有任何差別。在核心團隊成員與團隊顧問之間沒有任何等級關系。如果有任何人或事阻礙了任務，必須在每日站會中提出，并立即解決。

也要記住，不能擁有一個完全由團隊顧問組成的團隊。團隊的絕大多數人應該自始至終都只做這個項目。

團隊顧問與會議

只要經濟和交通上可行，團隊顧問就應該參加相關 Sprint 的所有Sprint 會議。記住，團隊顧問加入團隊是有特定原因的，他們并不是緊急情況下的“備胎”。團隊顧問在 Sprint 中有特定的任務，不管是直接工作，還是幫助其他成員完成工作，或者兩者兼有。因此他們應該在每日站會上報告進度，并在 Sprint 計劃會議與評審會議中提出意見。

l???? 計劃會議：團隊顧問在計劃會議中可以提高團隊的專業水平。如果團隊正在估算并碰到一個他們不如團隊顧問熟悉的用戶故事，團隊顧問的意見就是有參考意義。

l? 每日站會：團隊顧問參加每日站會，可以提高他們對項目的認識，了解項目的進展。

l? Sprint 評審會議與回顧會議：團隊顧問參加評審會議可以讓客戶看見做這個項目的每個人，無論是全職的還是作為顧問。讓他們參加回顧會議也是有益的，因為他們對團隊情況有更好的了解，但記住，他們花在回顧會議的時間也來自于他們總的可用時間。

如果由于預算或者時間的限制而使團隊顧問無法參加 Sprint 會議，團隊就要和產品負責人一起決定如何充分利用團隊顧問的時間。如果團隊顧問在一個 Sprint 中只能有 8 個小時用于項目，而要求他承擔的工作卻需要整整 8 個小時，那么對于團隊與產品負責人來說，團隊顧問完成更多的工作就比參加 Sprint 會議更有價值。另外一方面，團隊與產品負責人也可以選擇減少團隊顧問的任務，使他有時間參加每天日常的 Sprint 活動。對于這些會議，不管決定怎么做，核心團隊、ScrumMaster、團隊顧問以及產品負責人都需要知道核心團隊與團隊顧問之間的安排與承諾。

軟件開發 敏捷開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。