基于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）

责任编辑：