改变敏捷团队的构成

今年早些时候，InfoQ 在一篇名为建设稳定的团队并处理团队的功能失调的新闻报道中指出，组织机构往往倾向于建立和培养稳定的团队。不过有些时候也会由于某些因素，导致某支团队（或是许多团队）的构成需要发生转变。当这样的转变势在必行时，我们又该如何推动并完成转变的过程呢？

在博客文章团队中，Pawel Brodzinski 探讨了为何团队的形成需要消耗一定的时间，以及当我们试图改变团队的构成时会有什么影响：

Tuckman 提出的团队发展模型（Group Development Model）有时候又被描述为组建、激荡、规范、执行等不同阶段。该模型表明，在我们让团队的表现达到良好的水平之前，需要经历一些痛苦的时期。（……）团队重建总是被视作一项巨大的风险，而且一般来说在这一过程中将会遇到糟糕的表现。

Pawel 给出了两类可以改变团队构成的因素：为团队引入新成员以保持团队的勃勃生机，以及帮助那些表现不佳的团队。Pawel 认为，为了这些因素而改变团队构成时，需要谨慎地操作：

随着每位新成员的加入，团队都会获得一些新鲜血液。而这恰恰是一个借助新人的经验、知识和视角来挑战现有工作方式的机会。（……）这也正是为何我们应该不时为团队引入新人的原因。但是，在为团队大量增加新人之前需要注意的是，如果过分用新人“稀释”团队，我们将回到起点。不管如何，我们可以立刻解散并重组团队。

站在高层次的组织机构视角来看，在短期内保护我们的顶级团队是值得的。然而，从长远角度考虑，将上述文化在团队中传播则是一个更好地选择。但是同样地，在解散自己的明星团队并将成员散布到组织机构各个部分前，请记住这并不是一种能够立刻改变各支团队的魔法，它更像是一种催化剂——或许可以，但也或许不能——帮助在整个公司里传播最佳实践和健康的文化。但是如果谨小慎微地小剂量使用“这服药”，恐怕难以“值回票价”。

在博客文章你的团队中是否有害群之马一文中，Edwin Dando 探讨了某个行止不端的团队成员将如何导致整个团队的功能失调和崩解。他表示，自己是基于 Will Felps、Terence R.Mitchell 和 Eliza Byington 对于负面的团队成员与功能失调的团队的研究得到了这些结论：

如果某个团队中拥有一匹害群之马，那么其他团队成员也会染上他的缺点。当某个团队成员表现出【抑郁的悲观主义者、混蛋或懒鬼】这三种性格之一时，他的队友也会具有相似地行为。当这个坏家伙是个混蛋的时候，其他团队成员也会表现得像个混蛋。当他是个懒鬼的时候，其他人也同样会开始偷懒。

更糟糕的是，团队成员并不仅仅是这样对待他一个人，他们还会这样对待其他所有成员。换句话说，某个人的不良行为拥有一种散射传播效果，会影响整支团队的行为方式。

这是一项极其重要的发现。一颗烂苹果会带坏整车货物，因为他会改变所有人的行为。

基于上述结论，当团队包含这样一位害群之马时，我们必须采取行动：

我们无法忍受这种行为。它会破坏整个团队，而其恶果也会在产品上体现出来。不要再默默忍受了。最终我们只有三条路可走：

1. 什么都不做——随它去。显然这并不是个好的选择。
2. 预防行动——制定团队约定，明确哪些行为可以让我们的团队拥有活力，以及我们哪些行为会带来相反的影响。（……）
3. 为了团队而将其拒之门外。这是否很难？是的，这条路并不好走，但是从没有人说过这是轻而易举的。（……）

针对当我们必须让某人离开或将其赶出团队的情况，Len Lagestee 撰写了一篇题为只给一次机会（处理不良团队成员）的博客文章，给出了若干如何处理的建议：

定义并沟通你们的价值和准则。（……）价值将驱动你们做出决定。

做好准备。让人力资源部门的人，能够了解敏捷环境中工作所采用的文化和协作期望。

制定计划。这一步可以变得很简单，只需要考虑当识别出第一个问题后，打算如何训练某个人。（……）

给他们一次机会。随着价值的建立，以及人力资源和计划的就绪，为他们提供机会进行改变。限定为他们提供的宽限时间，但是要提供给他们每一个改进的机会。

采取行动。一旦限定宽限时光过去而问题依旧，那么就需要做出最后的裁定——因为你的团队正在观察你将如何处理这一状况。

Vin D’Amico 发表了一篇题为不要让你的团队变得自满且是可预见的的文章，在其中给出了一条改变团队构成的原因——引入新团队成员：

在团队中引入新成员，将有助于孵化出新理念并鼓励创新。新人会带来新体验、新视角和新能量。新人不会受到已经建立起的条条框框和历史决策的约束。他们能够随心所欲地就任何事情发问或对任何事说不。

他给出了以下若干有助于改变团队构成的建议：

• 如果你的公司有许多软件开发团队，尝试让开发人员在团队间流动。
• 如果你的公司比较小，尝试让团队成员之间轮换肩负彼此的责任，以提升跨学科技能。
• 从公司外部雇佣同行业、不同背景的新人。
• 在开发团队中引入非技术人员，作为分析师和测试者。
• 让每个人都不时深入现场，以便让他们都能够观察到真实的商业用户是如何工作的。

对于调整团队的构成，你是否也有一些经验想要分享？

查看英文原文： Changing the Composition of Agile Teams