统计150天数据发现：人员变动对敏捷团队没有影响？

作者：​巫婆艾 原IBM Advisory Software Engineer，参与并见证IBM敏捷成功转型。原汇丰科技西安有限公司资深项目经理。现任某外企Scrum Master。
擅长基于不同文化形态下的敏捷实践裁剪。相信实践是检验真理的唯一途径。

01丨频繁人员变动的团队—发现问题

故事背景

近期，我的几个敏捷团队中，人员数量在短期内均发生了频繁的波动。虽然整体人数变化不大，但人员频繁地进出，给团队在正常交付工作外带来了额外的压力进行项目交接以及新成员的培训工作。

同时，团队成员在正式以及非正式的情况下，多次提出了团队中慢慢存在的一些问题：比如开始频繁加班，交付压力增大，以及质量变差的苗头等等。

我做为Scrum Master，经过短期对团队的观察，发现了一些坏的味道，并同时思考如何开展一些具体的活动来帮助团队，以更好地实践敏捷宣言的原则之一“团队应定期反思如何变得更有效，然后相应地调整和调整其行为”。

大家坐下来聊聊

于是我召开了全员大会，让大家有啥说啥。目的只有一个：从吐槽问题到解决问题。

为了让吐槽更有效果，我采用了Design Thinking 的方式。邀请了不同角色（Dev, QA, Director, BA等等）的同事来参与。大家积极参与了这个活动。

首先把成员随机组成了3个小组，每个小组5个人。每个小组分配有一个组长，负责给组织小组活动。他并不是本组的发言人，不需要在过程中引导队员的思维方式，但是他需要帮助建立组内安全的氛围，让组员畅所欲言。

团队在想什么

首先每个组分配有一张大的白板纸，并画出四个象限帮助大家理清思路。组员需要针对“团队内部频繁的人员变化”这个情况，写出自己的观点：

• 说什么？
• 做了什么？
• 你想要什么？
• 你的解决方案是什么？

我为大家准备好了Sticker和彩笔。大家拿到Sticker以后首先按照自己的想法写出自己的感受，并贴到相应的象限。限时10分钟。这个过程我们收到了345张Sticker。我们发现有很多是重复的，比如很多人提到加班，焦虑。

那下一个过程，我们花10分钟时间合并同类项。得到以下信息：

通过关键字分析数据的观测，可以看到团队存在较多负面情绪。团队成员同时通过协作，加班，更多的培训最终实现团队价值的交付。

团队士气

最后，我们采用了自由发言的方式来结束这次会议，分析和观察团队士气的状态。我们可以看到总体来说，大家处于负面情绪中，但是通过协作可以做到更好的完成团队任务。

非常遗憾的是我们在过去没有记录到团队士气的情况，所以很难进行历史数据对比分析。未来我们会设计团队士气度量表，在Retro的时候收集团队士气参数，作为长期团队的一项重点衡量指标。

团队诉求

1） 团队处于较低士气状态，负面情绪有一定累计；

2） 交付过程中，产生大量浪费和等待，需要进一步的改进和完善；

3） 团队稳定性的强烈的诉求；

4） 对交付进度以及质量产生一定潜在风险。

02丨频繁人员变动的团队—分析问题

搬除Blocker是Scrum Master责无旁贷的责任和义务。我计划找到相关的Stakeholder提出问题，获得相应的支持，从而尝试帮助团队解决问题。

为了更高效的解决问题，我相应的研究和准备。

团队现状分析

首先我记录了最近8个Sprint的人员变化趋势图。以及人员变化类型的分析。

从下面的图可以看到，从Sprint 70到Sprint 78的8个Sprint中， 团队处于波动状态。整体呈现扬扩张的趋势。

为什么会有成员小数，这是由于团队成员的多样性决定的，在这个团队中，有以下成员类型同时存在：

1） 稳定全职团队成员：成员长期全职稳定在敏捷团队中。具备项目业务以及技术经验。易管理。

2） 稳定共享成员：成员长期兼职在团队，资源配稳定，有保障。管理成本较低，属于易管理型。

3） 不稳定共享成员：成员长期兼职在团队，成员配比处于变化状态。

4） 内部转入新成员：成员通过公司内部协调获得，具备项目相关的技术以及业务能力。

5） 外部加入新成员：成员通过招聘，或者公司内部协调获得，无本项目经验，需要培训获得本相关业务以及技术能力。

反应问题，球回来了

带着团队会的诉求以及现状分析。在一次Leads会议上我提出了稳定团队规模以及降低团队成员多样性的诉求。

1） 更好的团队士气，更少沟通成本；

2） 更少的团队等待，增加工作效率；

3） 更少的项目的浪费，提高交付速度；

4） 更稳定的团队，减少知识的传播损耗；

5） 更成熟的团队， 更高的交付保障。

高层给与了一定程度上的关注，同时也提出了一个问题：团队变动对具体的项目的风险和影响是什么？是否可以高度可视化出来？

从敏捷理论上，知道团队变动肯定对项目有着一定的影响，但真的像我们想的那样吗？

走出困境

抱着老大们提出的问题，我拉出了历史数据形成关键项目KPI，并开始分析项目风险和影响。

Sprint 速率（Velocity）：每个Sprint完成的Story Point的数量。用来观测Sprint的Velocity的变化。

如下图所示：团队的Velocity呈上升趋势。很好理解，因为团队处于持续扩张阶段。Velocity持续上升完全合理的情况。

Sprint 完成率：公式为：(Sprint 完成的Story Point)/ (Sprint 计划的Story Point) 。如果这个值大于1，说明团队超量完成计划；小于1，则反之。

如下图所示：可以看到这个值一直处于1以上，说明大家对于计划的Velocity是可以完成的，没有Carry Over的现象。

Defect Density: 公式为Defects/（团队完成的Story Point）。我们使用他来查看团队的质量。这个值越高，说明质量差。反之亦反。

如下图所示：可以看到Defect Density 处于震荡趋势，并有超过Base Line的情况。但是时间上不能与团队变化的关键时间点完全耦合。经过分析Bug 生产者并非波动成员引起。

人员速率：表示每个人每天能够完成的Story Point。用来描述团队成员的生产率。

如下图所示：可以看到人员速率呈持续上升趋势。说明每个人每天可以完成的Story Point是稳步上升的。

难道持续的人员变动真的对项目没有影响么？分析走入了死胡同。

03丨频繁人员变动的团队—解决问题

过程KPI的选择

难道持续的人员变动真的对项目没有影响么？

在马上要得出这样的结论的时候，我们似乎发现我们走错了方向。以上所有KPI的选择均为结果型KPI。

那么我们需要选取几个过程型KPI来看一下。

于是我们选取以下几个数据进行分析：团队培训时间分布，Grooming时间分布，加班时间分布，Pull Request Reject Rate几个参数进行衡量。

原始数据分析

由于现有数据存在量级差异，看不到明显相关性。对Team Size 参数进行增加5倍处理，对 “Pull Request Reject Rate” 进行增大1000倍处理。

如下图所示：可以看到团队变与各个时间维度貌似没太大关系。但是所有时间走势有趋同的效果。

衍生数据分析

这里需要一些数据分析的技巧了.

我这里引入新参数 TeamSizeChange，使用临近的两个Sprint的Team Size 相减得出。描述Sprint的变化过程。

由于数据存在量级差异，同样对这个数据进行增大5倍处理。

如下图所示。可以看到当TeamSizeChange 有发生波动的时候，各个曲线均有相应耦合的波动。曲线基本同上同下。

也就是说，过程KPI并非收到团队规模影响，而是收到团队规模波动影响。也就是说当相邻Sprint的团队规模有较大变化的时候，过程参数也会相应发生变化。

相关性数据分析

使用Excel的数据相关性分析查看相关性强弱。可以看出，各个KPI均与TeamSizeChange呈正相关性。其中Training Time (hour)为相关性最大，这个也符合现实逻辑。

与高层第二次对决

拿着结果和过程KPI，与高层开展了第二次Review会议。大家非常认可稳定的团队可以减少团队内部消耗，提高团队士气从而实现高质量以及高速率的交付，为Stakeholder 交付更多价值。

但是，另一个问题产生了。一般来说新成员的加入一定会对团队的效率产生 影响的，为什么数据上不能耦合呢？

04丨频繁人员变动的团队—修正KPI

带着老大们的问题，我开始新一轮的思考。为什么呢？

我开始从公式出发：团队平均速率=（每个Sprint实际完成的StoryPoint）/TeamSize/SprintDays

公式中涉及三个参数，其中每个Sprint实际完成的StoryPoint是实际客观值。没有任何问题。

那么TeamSize和SprintDays是如何计算的呢？是否客观真实呢？

Team Size参数分析

首先我分析了每种团队成员在TeamSize参数中的计算方式：

首先我们来讨论一下什么叫做Fully Ramp Up。

在不同的团队以及不同的公司，针对不同的角色对Fully Ramp Up有着不同的定义。在这里我们借鉴了Scrum 中对Dev Team的定义，对Dev Team做到无差别衡量。

本团队采用3个Sprint原则来把控：50%， 70%， 100%。我们用这个比例来假设成员的交付能力。

下面我们来稍微修正一下“团队平均速率”的公式中TeamSize的计算。对外部成员不按照比例处理，按照1计算。下面是处理后的“团队平均速率”展示图：

可以看到在S71的时候Mary加入团队，对团队的速率产生了拉低影响，经过两个Sprint以后团队速率恢复Mary加入前。

在S75，Bob加入导致团队Commit的速率变低，但是比Mary加入的稍高，是因为团队建立了更好的流程帮助Bob成长。

SprintDays参数分析

SprintDays的公式为：Sprint的工作时间*TeamSize-团队休假。例如两周的Sprint的工作时间是10天，团队有5个人，所有人的PTO加起来是13天。那么SprintDays=10*5-13=37天。全部为客观数值。

但是我们没有计算加班时间，由于团队处于长期加班状态，所以这个值不能忽略。

SprintDays的修正公式为：Sprint的工作时间*TeamSize+团队加班天数-团队休假。

修正了SprintDays以后，团队平均速率均有下降。并且当团队有人员借调的时候时候，团队成员会因为知识的传递，更多问题的重复澄清造成一定程度的加班，从而对团队的速率产生一定影响。

后记

经过几轮的团队内部和外部的讨论，可以看到稳定的团队对于交付以及团队内建的重要性。以及如何以高度可视化这种影响。

当我再次拿着修正后的团队的速率图在Leads 会议上review的时候，得到了大家普遍的认可，从而实现了团队稳定性在Leads团队的支持。