在Scrum與SAFe情境下使用每位團隊成員個人評分的實踐

在本文中，我計劃講述我們在自己的實踐中如何在採用該框架工作的過程中，應用Scrum中每位團隊成員的個人評分。 SAFe

也許很多人都會同意，我們這裡的人（尤其是在俄羅斯）相當經常地盡量少工作（在自己的職能範圍內交付最終產品，或透過獲得新職能來交付）而多拿錢。隨著公司規模的擴大，這樣做的可能性似乎成正比地增長。通常，各種HR相關人員會處理這個問題，他們千方百計地試圖建立正確的激勵體系。OKR之類的也屬於此列。總體而言，這一切似乎都旨在平衡公司內部每個人的負荷，並讓公司所有相關群體/團隊都感到舒適。在本文中，我將分享一個我自己想出來並在團隊中應用的指標。在我看來，它可以補充HR和OKR在平衡某個具體團隊內部負荷方面的努力，或者相應地看出失衡。此外，它完全可以擴展到團隊的團隊，我看不出這有什麼特別的問題。

因此，作為Scrum Master，我有時相當明顯地看到團隊中的負荷並不平衡，有人一個人幹兩個人的活，有人什麼都不做（這些是極端形式，當然是嚴重的問題，但這個指標顯示的不僅僅是極端形式）。我就遇到過這樣的情況，我開始思考什麼指標能鮮明地揭示這個問題。最終，這就演變成了每位團隊成員的個人評分。

在描述這個指標本身之前，我還想指出一個在我看來非常重要的想法。目前我對它絕對確信。

指標應該建立在你們本來就會獲得的那些數據之上。獲取任何指標都不應迫使團隊系統性地花費更多時間，並讓自己的價值交付流程去遷就指標本身。關於這一點，我會在後續文章之一中盡量詳細講述。

那麼，舉一個具體案例。當然，我們使用看板來讓User Stories按狀態從DOR（Definition Of Ready）移動到DOD（Definition Of Done）。我們的看板是虛擬的（即位於網路上，透過連結存取。我們的團隊也是分散式的，站會透過企業Skype進行，正好配合看板共享）。

團隊成員方便把自己設為User Story的參與者，這樣在使用按自己的篩選時，就能快速只留下自己目前參與的那些故事（我們最常在站會上使用這個篩選）。

這裡還想說明一下：這並不意味著該團隊成員不能參與其他故事（例如，如果在站會上某位團隊成員請求幫助，他完全可以成為新故事的參與者；或者相反，如果他覺得不需要自己的參與，也可以不再是某個故事的參與者。

因此，要計算每位團隊成員的評分，我們需要看看每位團隊成員影響了多少SP。在我們的例子中，Arkady影響29 SP（故事1、2、5、6），Tatiana影響33 SP（參與所有故事），Vasily影響23 SP（故事1、3、5、6）。

Arkady已完成（DOD已完成）29 SP中的5 SP，Tatiana已完成32 SP中的6 SP，Vasily已完成23 SP中的5 SP。我在排序上苦惱了很久，最後得出了這樣一個比較兩位團隊成員的公式（team[i] ——一位團隊成員， team[j] ——另一位團隊成員）：

根據這個排序，我們會得到團隊成員當前的評分如下。

• 第1名。Vasily（已完成23中的5）
• 第2名。Arkady（已完成29中的5）
• 第3名。Tatiana（已完成32中的6）

現在讓我們生成整個Sprint的所有數據。假設Sprint持續5個工作日。

• 第1天
  

  

  
  第1名：Vasily（已燃盡23中的0）
  第2名：Arkady（已燃盡29中的0）
  第3名：Tatiana（已燃盡32中的0）
  
• 第2天
  

  

  
  第1名：Vasily（已燃盡23中的0）動態(1->1)
  第2名：Arkady（已燃盡29中的0）動態(2->2)
  第3名：Tatiana（已燃盡32中的0）動態(3->3)
  
• 第3天
  

  

  
  第1名：瓦西里（已燃尽23中的5）动态(1->1->1)
  第2名：阿尔卡季 （已燃尽29中的5）动态(2->2->2)
  第3名：塔季扬娜（已燃尽32中的5） 动态(3->3->3)
  
• 第4天
  

  

  
  第1名：瓦西里（已燃尽23中的8）动态(1->1->1->1)
  第2名：阿尔卡季 （已燃尽29中的8）动态(2->2->2->2)
  第3名：塔季扬娜（已燃尽32中的9） 动态(3->3->3->3)
  
• 第5天
  

  

  
  第1名：瓦西里（已燃尽23中的23）动态(1->1->1->1->1)
  第2名：塔季扬娜 （已燃尽32中的24）动态(3->3->3->3->2)
  第3名：阿尔卡季（已燃尽29中的21） 动态(2->2->2->2->3)
  

因此，使用此指标可以积累 团队每个成员的个人统计数据，并帮助他做出正确的结论。 例如，在这里我们看到瓦西里从一开始就非常合理地规划了自己的时间 （即在冲刺规划时，他与团队商定了工作量，并且 实际完成了该工作量。）但同时，他是否本可以以某种方式帮助团队其他成员？ 也许没有，但在回顾会之前值得思考这个问题。

塔季扬娜和阿尔卡季的问题更为严重。显然，从一开始在冲刺 规划时，他们就与团队商定参与所有故事，但事实上未能 履行承诺。关于原因也值得在回顾会之前思考。也许 应该少为自己规划一些，也许应该扩展能力以便完成所有 计划的事情，也可能有其他解决方案。

因此，我们不仅可以积累整个团队、不仅 一个冲刺的统计数据，还可以积累DEV TEAM具体参与者所有时间的统计数据，并利用这些 信息来持续改进团队。

最后，我想特别提请注意一个事实：在团队中使用此 指标之前，团队大部分成员必须已经具备足够高的信任水平。 此外，我建议重点强调首要之事——没有 加班以及舒适的工作。

我们侧重于正确预测结果，而不是激励 加班以占据第1名。归根结底，此指标旨在提升 团队每个成员单独的规划能力。