在 Scrum 团队里,每一名成员都很重要,都在为团队的整体速率做出贡献。而团队成员缺席,不管是否在计划之中,都会影响到团队的速率。 Scrum Development 讨论组上有一则有意思的讨论,众人努力探求着解决缺席问题的途径。
讨论组里大多数人都同意,如果缺席是提前预知的,那么应该相应调低团队的速率估算,Sprint Backlog 中的故事数量也因此要相应减少。然而,如果在 Springt 当中出现意外缺席的情况,而且影响较大的时候,Scrum Master 应当知会产品负责人,并与之商议缩减本次 Sprint 的目标。
讨论中有人提出了一些创造性的办法去处理缺席情况。Kiran Thakkar 提议按照85% 的团队时间做计划,剩下15% 的时间一般足以应付意外事件。Geir Amsjo 的思路也是同一个方向,他建议按照6 小时的工作日来安排团队计划,剩下的时间用于弥补意外情况,比如短时间的病假、正常的休假等等。
Dave Smith 提起他见过一些 XP 团队能有效地吸收一名成员缺席所带来的额外工作量。能做到这一点,是由于工作空间中的干扰也相应减少,因此配对开发的效率更高。他还提到在这样的情形下,剩下的团队成员更努力工作去达到 Sprint 目标,确能补回缺员的损失。不过 Ron Jeffries 回复说,如果这种说法成立,那么很可能这个团队原先就不够投入。他认为团队成员缺席必定会影响团队的速率,除非他们从 Sprint 一开始就对目标估计得过低,否则很难在缺员的情况下仍然完成目标。
Angela Druckman 提议, 为了如实地承诺 Sprint 目标,她会收集每一名团队成员在下一个 Sprint 期间的能提供的工作时数,拿到计划会议上讨论。这样团队可以看到下个 Sprint 期间总的非工作时间有多少,然后集体决定要在 Sprint 中投入多少工作量。但是,如果某些具有特殊技能的成员将在 Sprint 期间缺席,那 么应当通知产品所有人,以便他们相应调整工作的优先次序。
Mike Youngtai 介绍了他的团队中应用“注意力因子(Focus Factor)”概念的情况。注意力因子是完成故事点数与实际工作人时的比值。据他所说,他们在Sprint 计划会议中所用的注意力因子,是经过3 个月跟踪得来的平均值。在计划会议的时候,团队成员计算出可投入的人天,然后以注意力因子为依据确定Backlog。
James S. Fosdick 为应付意外缺席出了一个有意思的主意,他提议
当面对由于生病等原因造成的意外缺席的时候,可以采取处理中途冒出的新任务一样的办法。搞清楚影响会有多大,是否影响到 Sprint Burndown(重大的缺席很可能大大减缓 Sprint Burndown 的下降坡度)。如果有影响,就应该与产品所有人重新商讨目标与承诺。如果没有影响,那就不用管。
查看英文原文: Handling Absence in Scrum Teams
评论