基于Scrum敏捷開發的軟件開發人員績效考核

02 Scrum團隊的角色

1、產品負責人/產品經理（Product Owner）。PO是代表客戶或市場需求的角色，他定義產品需求和功能，排列產品開發功能的先后順序，決定產品發布的內容和日期，評審開發團隊的交付，并在需要時根據客戶的反饋調整產品功能和迭代計劃。

2、敏捷負責人（Scrum Master）。SM并非項目經理，他不對開發成功負責，也不直接對開發團隊下達命令，更多的情況下是督促和指導開發團隊按照敏捷開發的原則和方法來工作，排除開發團隊遇到的障礙，幫助團隊回絕PO的不恰當壓力和干預。簡單來說，SM實際上是開發團隊的教練、流程守護者、保護傘和問題清道夫，他的使命是保持開發團隊的高效和緊密合作，并幫助開發團隊解決困難。

03 Scrum開發的流程與績效管理

1、迭代前：產品需求清單梳理

在這個環節需要做的是把產品功能特性進行明確（給客戶的故事），在PO和開發團隊之間達成共識，將之預先拆解為子任務（Scrum里稱之為故事點/故事卡片），并且排定優先級。核心即確認開發需求，并使其具象化。

這一個環節里并不涉及具體的工作任務安排，而是做為敏捷開發與績效管理的起點。

2、計劃：召開迭代計劃會

迭代計劃會將前一階段確認的產品功能和故事點形成具體的任務清單，開發團隊需要明確本次迭代計劃完成的具體故事點，評估工作量，并且分配或認領具體的工作任務，確定每個人的具體工作和協同關系。

這一階段事實上是團隊對PO、團隊成員之間形成承諾：用多少時間完成什么開發工作，實現什么功能。因此，這一階段往往通過會議形式進行，并形成可以供整個迭代期進行跟蹤和追溯、考核的依據。

3、迭代開發：每日站會

迭代開發過程中，要求開發團隊每天要通過短暫的站會來溝通進度，確定問題和問題解決措施。一般的，在每日站會上團隊成員都需要回答如下3個問題：

昨天你完成了什么？

今天你計劃完成什么？

你有哪些需要幫助的地方？

每日站會的結果應該形成整體的燃盡圖，使團隊成員和SM、PO都明確本次迭代開發的整體進度，以及迭代目標實現的可能性和問題所在。這實際上積累了對每一位軟件開發人員的績效考核基礎數據。在這一階段，關鍵的是除非極特殊情況，一般不應改變迭代的計劃。

4、評審：確認、評價迭代成果

開發團隊向PO展示迭代工作成果，由PO代表客戶/市場給出評價和反饋，確認最初計劃的故事點是否能成功交付，本次迭代任務是否完成。個別情況下，也會邀請客戶代表參加。

在這一階段，實際上是由客戶或者PO對整個開發團隊的績效做出評價，因此可以做為團隊績效考核的輸入。

5、復盤：反思和改進

每次迭代結束后，開發團隊內部應該進行復盤，總結在本次迭代中，哪些事情做的好，哪些做得不好，從而得出結論：下一次迭代我們需要開始做什么、堅持做什么、不作什么。

這一階段實際上一方面是對經驗和教訓的總結，一方面是對后續改進和提升的要求，同時也基本明確了每一位開發人員的開發質量和表現。

在整個敏捷開發的過程中，對軟件開發人員的績效考核可以只關注兩個點：工作量和工作質量。工作量依據每一天的站會記錄即可得出，工作質量則可以用評審時對整個團隊和每一模塊的工作質量評價做為基準，結合復盤時討論的結果對每一位軟件開發人員本次迭代內的工作質量做出評價。

這樣的績效考核方式，有機嵌入了日常的軟件開發過程中，不需要管理者投入大量時間和精力用于績效考核，同時也有充足的依據來保障考核的公平性。另一方面，對中小型軟件開發企業來說，也是提高開發效率的一種良好的開發模式。

需要說明的是，這種績效考核方式應當以團隊績效為主，對個人績效考核的結果應用，建議更多用于個人職業發展依據、榮譽授予等方面，而盡量少直接應用于經濟獎罰，以避免團隊的協同和配合出現問題，反而得不償失。

大家有好的想法，歡迎在評論區給我留言

作者/編輯：合易咨詢（heyeehrm）

責任編輯：