写点什么

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

2013 年 5 月 24 日

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

在一篇题为“我们想要一支稳定的团队”的博文中,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 )关注我们,并与我们的编辑和其他读者朋友交流。

2013 年 5 月 24 日 11:241594
用户头像

发布了 256 篇内容, 共 50.5 次阅读, 收获喜欢 4 次。

关注

评论

发布
暂无评论
发现更多内容

Kafka零数据丢失的配置方案

奈学教育

kafka

游戏夜读 | 如何面对前景渺茫?

game1night

读《你的灯还亮着吗》

liu_liu

读书感悟

ARTS WEEK3

紫枫

ARTS 打卡计划

算法基础:排序算法看这一篇就够了

公众号:好奇心森林

排序算法

原创 | TDD工具集:JUnit、AssertJ和Mockito (二十一)编写测试-动态测试

编程道与术

Java 编程 TDD 单元测试 JUnit

Zookeeper 序列化

CoderLi

Java zookeeper 源码分析 后端

如何用日记提升写作能力?

石云升

学习 方法 写作

架构师训练营第一周作业

Benjamin

Libra教程之:Libra协议的关键概念

程序那些事

区块链 libra blockchain 协议

拙见/ 什么是自驱力?

ZoomQuiet大妈

自我提升 大妈 是也乎 IMHO 蟒营®

由一次管理后台定时推送功能引发的对RabbitMQ延迟队列的思考(一)

LSJ

Java RabbitMQ 延迟队列

LeetCode 756. Pyramid Transition Matrix

liu_liu

LeetCode

3年内从负债到买房三套,勤劳不能致富,工资只能温饱

陆陆通通

创业 程序员 赚钱 买房

k8s 上运行我们的 springboot 服务之——自动化测试

柠檬

maven DevOps Unit Test

食堂就餐卡系统架构设计文档

dony.zhang

做产品少走弯路:上帝视角(2)

我是IT民工

产品 方法 路径 知识体系

你不能不掌握的软技能——业务语言

KAMI

方法论 开发 沟通 软技能

公司治理的两个关键要素:存在的基石 + 成长的飞轮

泰稳@极客邦科技

发展 公司管理 增长

SpringMVC中Http请求方式转换(post转换为put/delete等方式)

知春秋

springmvc post post到put方式请求 post到delete方式请求

小师妹学JavaIO之:NIO中那些奇怪的Buffer

程序那些事

io nio Java 25 周年 小师妹 buffer

[翻译]The Go Blog《Go maps in action》

卓丁

go golang hashmap map 哈希表

大中台模式下如何构建复杂业务核心状态机组件

奈学教育

中台

白话说流——什么是流,从批认识流(二)

KAMI

大数据 flink 流计算

大中台模式下如何构建复杂业务核心状态机组件

古月木易

Libra白皮书解读

程序那些事

区块链 facebook 数字货币 libra

[架构师训练营] Week01 - 食堂就餐卡系统设计

谭方敏

学习

《Golang工具go doc使用透析》

卓丁

golang godoc go doc golang如何实现接口 源码阅读

[转载]Go 和 Java的15个主要差异

卓丁

Java golang

如何基于 OAM 编写一个扩展 Trait?

钱王骞

云原生 k8s OAM

互金总结系列(1)--开篇

互金从业者X

演讲经验交流会|ArchSummit 上海站

演讲经验交流会|ArchSummit 上海站

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