建设稳定的团队并处理团队的功能失调

一个脱离项目而存在的、稳定的团队有益于敏捷软件开发。在这样的组织里，可以将工作组织并提供给现有的团队，而不是在每个项目的开始构建新的团队，并在项目结束时解散它们。但若是一个稳定的团队并不能如预期那样运作该怎么办？许多作者都发表了关于建立和培育稳定的团队，以及处理团队的功能失调方面的博文。

在一篇题为“我们想要一支稳定的团队”的博文中，Joe Little 解释了为何他认为拥有稳定的团队是件重要的事情：

（……）要想得到伟大的产品，需要拥有一些独到之处。而我相信，“独到之处”目前更有可能来自一支好的团队。因此，从业务管理的角度来看（这也是关于这件事我们最需要说服的管理者）——我们需要一支稳定的团队。

在 Joe 看来，这样的团队应该拥有业务人员和技术人员，而且在这样的团队中工作应该更有乐趣和满足感。他的建议是，如果已经有了一支很好的团队，那么就让它保持稳定：

[一支伟大的团队] 拥有 5 到 10 倍的提升。（……）这是一支会下金蛋的鹅。（……）如果能够持续为他们提供理想而令人满意的工作，他们或许永远都不需要改变。

稳定的团队要求将方向转移到如何组织需要完成的工作上：

我们不再以项目作为起点而后寻找人手完成项目。我们现在以团队为起点，并寻找适合它的工作。

Everett Zufelt 撰写了一篇题为“构建团队 & 回避功能失调”的博文，文中他着眼于团队的功能失调，以及如何发展团队。这篇博文以他对团队的定义作为开始：

（……）一群为了同一个项目工作的人，与一个为了共同的结果进行工作的团队，二者之间有着明显的区别。团队专注于其共同目标，而且会为了团队表现牺牲自我。

要想发展一支强大的、能够向客户传递更多价值的团队，团队成员们需要互相了解。Everett 解释了为何随着时间的推移，互相了解这件事会变得更容易：因为我们会逐渐了解那些与我们共事的人。

最近我们采纳了“稳定”团队的目标。这并不意味着团队永远不会变化或改变，但它切实意味着我们会关注我们的团队在大小和组成方面的改变。同其他潜在的好处一道，我相信稳定性是构建能够专注于集体成就的团队的重要组成部分。

Roman Pichler 分享了关于如何创建“稳定团队”的建议。首先他阐述了自己看到的对稳定团队的需求：

个体和组织机构都不欢迎对团队的构成进行过于频繁地改变。团队需要稳定性才能有活力。在市场、需求和技术快速变化的敏捷世界中，安全性和持续性来自稳定的团队。

他建议在产品版本间减少团队的改变：

改变团队构成会让团队建设流程从头来过，而这会导致生产力和自我组织受到损害。（……）保证团队主要成员能够持续为某个产品工作，以避免信息流失、缺陷和延迟。

在“稳定团队的价值”中，Kelly Waters 描绘了支持稳定团队的组织的构。她解释了创建这样的架构多么有价值：

一位资深经理能够为任何开发团队做的最有价值的事情之一，是创建支持稳定团队的组织架构。不变的、持久的团队，而不是一个为了项目而召集、在项目之后又遣散以便围绕新项目重组的团队。

Kelly 描述了团队经历的几个阶段：“形成、震荡、规范、执行”。团队需要花些时间才能走过这些阶段：

某些团队的成员能够一拍即合，这样的团队会非常快速地经过以上过程，并且期间只有些许紧张。另一些团队则困在震荡过程中太久，并且需要很长时间以真正开始作为一个团队进入执行阶段。

组织架构如何支持稳定的团队？Kelly 建议以需要交付的产品为出发点：

（……）最好将团队与特定产品或产品组合相结合。这样团队能够共同前进，从一个项目到另一个项目，而无需每次重建团队，而且这样的团队拥有经过优化的关系、流程和速度所能带来的全部好处。这里的理念是将项目分派给已经建立起来的团队，而不是将员工分配到项目并且为了项目每次组建新的团队。

Steve Martin 在题为“失调的敏捷团队成员”的博文中讲述了如何改变团队的构成。首先他描绘了有时候人们想要考虑备选方案——从团队中移出一名成员：

（……）我的许多客户都不希望切换团队——这是神圣不可侵犯的。“哦不，我们不能重新配置团队。这些人就是我们所拥有的。现阶段没有其他的选择。”我说，“不，你可以做出改变。”我不是说直接开除某人（尽管，存在一些例外情况，在这些情况下这是清晰和明显的行动步骤）。而且不，不应该经常将团队成员混合。但是有时候只需要为了团队、利益相关者和客户的利益将团队成员剔除掉。

关于团队成员，Steve 使用了一个能力 - 意愿矩阵用于考虑团队变更：

能力指“技术技能”，例如编写代码的技能、测试的技能、商业分析技能等等，以及敏捷的价值观和原则的 _ 证明 _。意愿指技能组中“人”的部分——他们如何开放地拥抱和相信基础的敏捷价值观和原则，例如协作、响应变更、反馈、作为一个完整团队工作（而不是作为专家）等等。

关于挑选团队成员，首选那些同时具备能力和意愿的人。具有低能力、高意愿特点的团队成员可以通过结对来发展他们的技术技能，从而提升其能力。对于具有高能力、低意愿特点的团队成员，可以进行私人辅导以提高意愿，或是决定让其作为团队顾问而不是成员。对具有低能力、低意愿特点的团队成员，你必须考虑是否希望他们成为团队的一份子：

最后，对那些具有低能力、低意愿特点的成员，需要从一开始就与其进行诚恳的谈话。我甚至曾经在第一次 Sprint 会议上就要求这类人完全离开团队，有时这会从管理的角度带来非常负面的影响。不过这一般会随着时间推移而成为过去，特别是当团队进入执行阶段的时候。”

查看英文原文： Developing Stable Teams, and Dealing with Dysfunctions

感谢杨赛对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。