首頁 > 創業投資 > 查看文章

產品負責人必看:如何確定Scrum團隊的最佳規模?

    發表時間:2019-09-11 17:13

無論你在小型創業公司工作還是在大公司的新產品線工作,當團隊人數越來越多時總會達到一個臨界點。盡早識別這個臨界點可以讓您的團隊避免進入低效階段。

無論你在小型創業公司工作還是在大公司的新產品線工作,當團隊人數越來越多時總會達到一個臨界點。盡早識別這個臨界點可以讓您的團隊避免進入低效階段。

每個產品都是不同的,團隊合作也是如此。因此,拆分團隊也需要做一些反映團隊情況的決定。

在做決定時有以下幾點需要考慮:

開始考慮團隊拆分或增加新團隊最明顯的跡象就是團隊的預算增加,這可能發生在創業公司的新一輪投資或企業產品的新目標中。

如果預算增加較多你的團隊規模會增長3倍甚至更多,這個時候你就不得不拆分現有的團隊以延續原有的技術知識。

然而,當預算增加呈遞增式時,你的決定就變得沒有那么明確,最終的結果就是在名冊上增加一些新人。

如果說,你計劃將自己的團隊由7個人增加到11個人,需要做拆分嗎?敏捷提倡小團隊,但也同樣提倡個體和互動高于流程和工具,擁有兩個或以上的團隊必可避免的要創建更多流程以便能夠同步工作。

專家怎么說?

亞馬遜創始人貝索斯曾將兩個披薩原則用在會議和團隊中,那就意味著無論是會議還是團隊應該只有兩個披薩可以喂飽午餐的人數。

Scrum指南建議有3到9名成員實際執行sprint backlog,這就意味著總數中不可能包含PO或者Scrum Master,除非他們他們當中有人在執行sprint backlog項。

這些數字看起來更有直觀意義,但他們背后也有數學原理。如果將團隊中的每個人都看做一個節點,并將他們鏈接到其他節點。這就是隊友之間的人際關系。

他們之間可以是友好的、競爭的、惡意的或者關懷的,無論兩人之間的關系是什么,都需要每個人有一定的心理承受能力。

隨著團隊人數的增長,這些鏈接之間的數字不會呈線性增長。節點之間的鏈接公式,如下圖的鏈接增長圖所示:

圖表從數學角度清楚的說明了為什么當團隊規模不是特別大的時候能實現運營效率的最大化。

如果我們遵從Scrum指南的建議采用3到9人的團隊規模人數,最終的鏈接值為3到36。如果把團隊人數增加到15人,鏈接值將超過100。

這種規模的團隊只有在團隊中每個人的責任定義都非常明確且很少重疊或者一些非官方的小組才能有效運營。基于敏捷原則工作時既非案例也非期望。

團隊變大的信號 1. 每日Scrum

每日Scrum是整個團隊的聚會,用于闡述sprint進展和遇到的困難,有時候也被稱為每日站會。

Scrum指南建議每日站會要在15分鐘內完成,這個時間限制對團隊規模來說是很好的試金石。如果你注意到自己的團隊開始超過15分鐘線,那么可以表明兩件事:

你還應該注意到團隊中的一些人,正在逐漸失去興趣因為一個人可以接收的信息量是有限制的。如果太多人提供更新,那么跟蹤每個人的進度并了解團隊的狀態就會變得很難。

這使得人們只會向內看,只看到自己的進步而不是尋找機會去幫助他人。

2. 梳理和Sprint規劃

梳理和迭代規劃都是與分解用戶故事和預估交付時間或規模大小有關的活動。

雖然有更多的人可以幫團隊做出更好的決策,同樣的擁有太多人也容易讓團隊陷入僵局。

同一任務可以由不同的方法來完成,并且每一邊的論點數量都會隨著人員數量的增加而增加。與站會一樣,不要把低效的計劃談話與團隊規模過大混淆。

最終,讓scrum儀式變得更高效且有效是scrum master的工作。

3. 回顧

在回顧會議期間,團隊成員可以解決任何爭論或沖突并提出改善其工作流程的方法。回顧會議教會我們妥協的藝術,因為它讓我們在不同團體直接尋求共同點。團隊也因為它的成員愿意在他們的分歧上適當妥協而變得強大。

然而,和sprint規劃一樣,團隊成員過多那么鏈接點也會很多,所有這些鏈接點都是潛在沖突。

如果你在回顧會議時發現大家的共同點越來越少的時候你就應該開始注意,這很有可能是由于團隊規模過大,團隊拆分是最佳選擇。

如何拆分團隊?

表明上看,拆分團隊是一個相對簡單的任務。將團隊成員分成兩組,確保每組中都有相似經歷的成員,明確新團隊的目標。

然而,在拆分團隊時還有很多因素需要考慮進去,以免影響團隊以后的成功。

1. 團隊士氣

需要時刻牢記的最重要的事情之一就是團隊士氣。一天結束時,團隊中的成員將不得不在新的組織架構中工作。

如果團隊在敏捷原則方面是成熟的,那么他們應該能夠自己分裂。這是最理想的結果,因為團隊成員最了解他們的內部關系——誰與誰關系最好以及誰能從分離的組織中收益。

2. 跨職能團隊

Scrum推動跨職能團隊“擁有創建產品增量所需的所有技能”,擴展到兩個甚至更多團隊時也是如此。

對于很多開發者尤其是一些敏捷新手來說,自然趨勢是與技術線路一起思考的。

例如,團隊經常想將拆分成前端和后端。這在某些罕見的情況下可能會有意義,但作為產品經理,你應該在大多數時間提出反對意見。

一個全是前端開發者的團隊無法自行提供產品增量,并且自然地就開始思考技術能力也就是將他們團結起來的原因。相反,他們更應該關注的是客戶以及如何滿足他們的需求。

另一個有趣的考慮因素是團隊中的非開發角色。在各種情況下,一個團隊可能包括一個設計師、業務分析師和QA專家。一旦你拆分了一個團隊,尤其是如果你沒有雇更多的新人,那么在處理這些角色的問題上就會陷入兩難的境地。

他們應該分配自己的時間到不同的團隊嗎?你應該雇傭只服務于一個團隊的新人嗎?他們應該跟開發團隊一起工作呢還是成為產品團隊的一員?

對此并沒有絕對的好建議因為每個產品都是不同的。這些決定最好與團隊一起做出,同時記得需要一直不斷修正。

3. 團隊之間應該有獨立的Backlog嗎?

如果一個團隊被拆分,那么接下來的問題自然就是他們應該用同一個backlog工作還是再獨立一個backlog出來?

[email protected]是由Scrum指南的創建者開發的一種方法,[email protected]不是很規范,但它確實指出了兩點:

所以,本質上來講,[email protected]描繪了新團隊與他們各自的PO和backlog緊密配合的場景,只是添加了一些額外的結構來協調團隊之間的工作。

[email protected]適合數個、數十個或數百個團隊,但即使你們只有兩個團隊一起工作它也能提供一些有價值的見解。

大規模scrum(LeSS):

LeSS提供了一種有趣的產品backlog方法。在LeSS中,一個PO與2到8個團隊一起工作。一個PO能跟那么多團隊一起工作看起來有點不太可能。

LeSS的理念是PO在抽象層面上工作,并將產品backlog項細化的職責委托給團隊。這種情況下,跨職能開發團隊還應該包括業務領域知識以便交付產品增量。

在LeSS中,只有一個backlog。

大規模scrum(LeSS):

LeSS提供了一種有趣的產品backlog方法。在LeSS中,一個PO與2到8個團隊一起工作。一個PO能跟那么多團隊一起工作看起來有點不太可能。

LeSS的理念是PO在抽象層面上工作,并將產品backlog項細化的職責委托給團隊。這種情況下,跨職能開發團隊還應該包括業務領域知識以便交付產品增量。

在LeSS中,只有一個backlog。

對于一個產品經理來說,多團隊意味著更多的工作追蹤和響應查詢。

1. 優先級會議

如果你曾參加單個團隊的每日站會,那么現在你可能會發現繼續這個習慣很可能是徒勞的。

將每日站會作為一個讓他們了解團隊動力并提醒他們可以進行討論的機會,你參加sprint規劃會議與否取決于你團隊的成熟度。

如果團隊中有很多新面孔或者他們已經很長時間沒有用敏捷的方式工作了,那么你的指導就非常必要。

即使你有信心讓團隊在沒有你參與的情況下進行規劃,如果出現問題請務必要在規劃期間與團隊進行交流或語音聊天。Sprint review必須始終是你的首要任務,所有人都應該參加。

Sprint review是一個能讓你從所有在場的利益相關者和團隊本身獲得第一手反饋的機會。這是一個驗證假設的時間,不應該錯過。

2. 與Scrum Master多互動

你可能會減少某些scrum儀式的參與,但應該增加與scrum master間的合作。

團隊拆分后,肯定不止一個scrum master,這種情況下,你需要與他們所有人密切合作。確保你可以信任他們,以便真實了解團隊的進展及sprint期間出現的任何問題。

這種關系可以幫助你了解最新進展并且無需參加所有的scrum儀式。

scrum of scrums 介紹:

時候也稱為元scrum,scrum of scrums是一個新的儀式,通常作為scrum流程規模引入。

它是更高級別的站會的復制品,每個團隊都指派一名大使,所有大使每天都在S0S會議上碰面溝通進展和阻礙。

這個會議還用于突出可能需要解決的任何跨團隊技術問題。

scrum of scrums 介紹:

時候也稱為元scrum,scrum of scrums是一個新的儀式,通常作為scrum流程規模引入。

它是更高級別的站會的復制品,每個團隊都指派一名大使,所有大使每天都在S0S會議上碰面溝通進展和阻礙。

這個會議還用于突出可能需要解決的任何跨團隊技術問題。

如果你的團隊設置要求產品經理積極參與到團隊中,那么請考慮在產品方面再添加一些人員。有幾種方法可以解決這個問題:

隨著團隊的發展,你可能會開始注意到一些它變得太大的跡象,尤其是在:

  • 站會。 如果你們的每日站會超過15分鐘的時間界限并且注意到人們開始逐漸失去興趣;
  • sprint規劃 。如果你們在Sprint規劃期間越來越頻繁的陷入僵局;
  • 回顧 。如果你開始注意到在回顧期間大家的意見越來越難達成一致。

所有這些跡象都表明你可能需要拆分團隊,拆分團隊看起來是一項簡單的任務但也會帶來持續的后果。如果真的要這么做,每個產品經理都要考慮以下幾個問題:

如果需要跟蹤兩個或以上團隊則需要確定優先級順序。高效率的產品經理應該計劃如何與新團隊保持同步:

  • 優先級會議 。思考哪些敏捷儀式是值得你花費時間參與的而哪些是可以被忽略的;
  • 與scrum master互動 。讓scrum master作為你的團隊代理人,通過他們獲取團隊信息;
  • 擴充產品團隊 。在產品團隊中添加一些成員和你一起工作,讓他們幫你完成一些日常重復性任務或進行用戶調研和市場分析。

希望通過以上幾點建議,你能有一個相對比較清晰的團隊拆分思路。

原文作者:Stephanie Ockerman

翻譯/校對:吳倩倩

本文由 @吳倩倩 翻譯發布于人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基于CC0協議

責任編輯:

电子游艺行业