在 2025 收官前,看清 Data + AI 的真实走向,点击查看 BUILD 大会精华版 了解详情
写点什么

园中那颗“烂苹果”

  • 2009-01-15
  • 本文字数:1717 字

    阅读完需:约 6 分钟

过去几天,Scrum Development Yahoo 讨论小组有个激烈的讨论,如果团队中某人“表现欠佳”,你该怎么办?针对 Rotten apple in Scrum team这个帖子,回帖多达 130 多篇,讨论也五花八门,从对该问题的建议,到团队士气以及谁来负责的讨论,再到怎样衡量个人这样的经典争论,以及怎样识别一个团队是否是真正的“团队”,当然还有一些其它的内容。

争论是这样引发的,Marko Majkic 说他发觉团队中有一个人“表现欠佳”,并询问大家有什么好的建议(引用自最早的帖子以及稍后的回复):

开发人员平均每人完成 38 个 usp(用户故事点数)。而有个人只贡献了 19 个──只有其他人的一半
……
我并不认为这个家伙懒惰,或者心怀恶意。对我来说,他看上去心不在焉,或者没把精力放在工作上
……
我应该在 Scrum 回顾会议上提出来吗?或者我应该与这个家伙私下里谈谈?要是你会怎么做呢?

这句话引出了很多的话题,其中之一就是讨论 Marko 最早的那个问题,怎样处理那个表现欠佳的人。许多回帖都建议,当前最重要的是做一个全新而客观的评估,看究竟发生了什么。Paul Hudson 总结说道:

正如其他人所说,退一步海阔天空。 根据你的描述,在我看来,你可能认为那个人效率低下,应该责备他,而没有指出隐藏的问题,去帮助他。
……
我(以及其他的几个人)建议你从另外一个角度考虑。根本没有什么灵丹妙药。你需要找出那个人是否有什么问题或顾虑,并跟他一起讨论这些问题。
……
所以 [具体的] 建议包括:
a) 确认这真的是个问题,并且就是你认为的那样
b) 对那个家伙可能遇到的问题多了解一些
c) 在团队中或者私下里提出来并讨论这个问题

如何按照 Paul 列出的建议去做呢,有人给出了进一步的建议,比如:

  • 谨慎选择字眼来描述这个人;就是说,用“烂苹果”来描述这种情况就挺糟糕的,更不用说来描述这个了!(注意 Marko 完全赞成这个观点)
  • Mark Levison 的建议是,用初学者之心 _ 解决这一情况 _ (由 Jean Tabaka 和 David Hussman 提出)
  • 其他一些人(包括 George Dinwiddie)的建议是,花点时间与这个人结对编程
  • 还有其它一些建议,判断时要保持客观,包括从 Linda Rising 那里学习

有趣的是进一步的讨论显示,Marko 并不是特别担心那个人本身干了多少活,他的担心其实是这样的,团队中其他人可能很快对那个人做出一些不好的行动,比如可能在回顾会议上提出这一问题。然而正如期望的那样,很快很多回帖强调说这种结果正是我们期望的,不需要感到害怕。如 Ilja Pruess 所述:

实际上我更为担心的是,如果 * 不 * 说出来会对团队的氛围有什么影响。
……
所以我觉得如果团队中有人对这种“表现不佳的人”心有不满,协调者的责任是 * 鼓励 * 组员讲出来,并帮助他们委婉地解决这个问题。

从这里也引出了对“团队士气”这个话题的讨论。该由谁“负责[保持团队士气] ?”对这一问题的反应尤其值得注意。 Alistair Cockburn Dan Rawsthorne Michael Wollin Paul Hudson ,以及其他一些人进行了辩论,这是不是 Scrum Master 的核心作用?还是项目经理的?产品负责人的?团队自己的?CEO 的?其他人的?或者以上所有人的?讨论中间引用了一篇资料翔实的文章介绍怎样提高士气

受Marko 最初描述的启示,大家对如何衡量一个人的表现也展开了讨论(Marko 用的是“每个人完成的点数”), Ron Jeffries 提醒说如果团队是一个真正的“团队”,就不应该有所谓的“每个人完成的点数”这种说法。相关的讨论也提出,衡量大家的表现(客观地)不一定是错的,但是应该只是你对某个人主观评价的标准之一(比如, Eric Deslauriers 的回帖)。

对这一话题想了解更多,可以查看最近很火的 InfoQ 上关于“业绩评估”的文章, 以及 George Dinwiddie 在博客上发表的 team chemistry judging performance ,当然还有 Mark Levison 的一篇文章

最后请谨记,写作本文时 Scrum Development Yahoo 讨论小组针对该问题有 130 个回帖,所以需要知道 InfoQ 的这篇文章只是对一些关键条目的简要概述。如果想了解全部内容,您可以亲自去查看那个帖子,当然您也可以在那里或者这里发表自己的想法。

查看英文原文 http://www.infoq.com/news/2009/01/handling-your-underperformer “Handling Your Team’s “Rotten Apple””">Handling Your Team’s “Rotten Apple”

2009-01-15 06:271391
用户头像

发布了 37 篇内容, 共 13.6 次阅读, 收获喜欢 5 次。

关注

评论

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

打通数据治理全链路,火山引擎DataLeap数据治理平台公有云版本正式发布

字节跳动数据平台

大数据 数据中台 数据研发 企业号 8 月 PK 榜

软件测试 | 什么时候使用表锁

测吧(北京)科技有限公司

软件测试 | table_cache的设置

测吧(北京)科技有限公司

测试

免费MES系统:助力企业数字化转型的利器

万界星空科技

开源 数字化转型

javascript数组基础

timerring

JavaScript

金蝶管易云 X Hologres:新一代全渠道电商ERP最佳实践

阿里云大数据AI技术

ERP

​加速大规模团队创新,开发安全、可靠、合规的汽车软件

龙智—DevSecOps解决方案

ACT汽车电子与软件技术周 汽车电子与软件技术周

Requests+Etree+BeautifulSoup+Pandas+Path+Pyinstaller应用 | 获取页面指定区域数据存入html、excel文档

Python pandas pyinstaller requests BeautifulSoup

加速数字化转型:龙智专家分享DevSecOps和ITSM工具性能优化策略——2023 DevOps国际峰会现场访谈

龙智—DevSecOps解决方案

DevSecOps devops国际峰会

软件测试 | 源码包安装的性能考虑

测吧(北京)科技有限公司

测试

ShareSDK 国外平台登陆返回参数

MobTech袤博科技

前端 App

柴洪峰院士:大模型赋能金融科技思考与展望

NLP资深玩家

人工智能 金融科技 大模型 WAIC

华为云低代码平台Astro Canvas 搭建汽车展示大屏——实验指导手册

软件开发 低代码 数据可视化 华为云

CCIA数安委等组织发起“个人信息保护影响评估专题工作”,合合信息首批入选试点

合合技术团队

人工智能 信息安全 个人信息保护

人工智能如何应对 DevOps 监控和可观测性挑战

SEAL安全

人工智能 DevOps 运维

小程序开发技术解析:事件系统设计

Onegun

小程序 事件 小程序开发

软件测试 | 升级MySQL

测吧(北京)科技有限公司

测试

SpringCloud Gateway 在微服务架构下的最佳实践

阿里巴巴云原生

阿里云 云原生 Spring Cloud Gateway

git rebase介绍与可视化工具(sourceTree)提效

时常看看太阳

git git rebase sourcetree

小白也能基于OpenAI搭建自己的英语学习工具

派大星

openai

智慧消防大数据监控系统 城市火警智能监测

2D3D前端可视化开发

智慧城市 智慧消防 消防物联网云平台 消防云控平台

软件测试 | 影响MySQL性能的重要参数

测吧(北京)科技有限公司

测试

从国内最早的开放银行浅聊技术创新

FinFish

技术创新 开放银行 小程序化 小程序技术

内网穿透之 ngrok

陈皮

不用再写FlinkSQL了,使用开源XL-LightHouse轻松实现海量数据实时统计

feng

大数据 流式计算 流式大数据统计 流式统计 企业数据化运营

时序数据库 TDengine 被帆软纳入数据源,可视化方案多样化

爱倒腾的程序员

数据库

静态分析全解析:助力高质量软件开发,降低成本风险

龙智—DevSecOps解决方案

静态分析 静态代码分析 静态代码分析工具

低代码平台什么意思

优秀

低代码平台

全链路灰度的挑战、实现思路与解决方案

阿里巴巴云原生

阿里云 云原生 全链路灰度

园中那颗“烂苹果”_研发效能_Mike Bria_InfoQ精选文章