把团队中某些人投票赶走
敏捷团队是自组织型的团队,充满活力。他们互助互爱,有着高效产出。但是,有的人可能跟这种团队配合不来,影响了团队的生产效率。敏捷社区中讨论了怎样把这种人投票赶出团队。
Joshua Hoover在他的博客上写道,投票驱逐的概念应该深深植入每个敏捷人的心中。因为敏捷团队是自组织型的,所以他们有足够的权利把他们认为不合适的人赶走。只有一点需要注意,那就是这条规则对任何人都适用。所以一定要谨慎行事。Joshua说:
自组织型团队的成员有权利作出谁应该呆在团队里面,谁应该离开团队的选择。发现团队中有人有问题以后,应当先跟他(她)一起帮助他(她)解决问题,要是得不到改进,那就该考虑一下投票把那个人驱逐出境……呃……赶出团队了。
在上文的回帖中,Richard Baldwin补充说,如果一个成员带来的问题比创造的价值还要多,那就没必要为他带来的问题买单。他认为,很多敏捷团队成员都只是对有人无作为的情况保持沉默,而不是主动解决问题。这就把团队带入了困境,降低了生产力。
在Scrum Developement 讨论组中也有类似的讨论,Brent Barton说道:
我们已经习惯了“投票驱逐”。这不算是聘用/解雇,因为他可能只是“不适合”这个团队,也许他能在其他团队中干的超级牛x。这种情况很常见,必须要把不同的缘由分清楚。
Brent认为,一定要正确使用投票驱逐这个概念。有些团队连平等对话的机会都没给对方,也没试过解决冲突,就直接投票了。还有些团队远远没有意识到它的重要性,他们觉得自己没有权利这样做。
在这个讨论中,James S. Fosdick补充说,有人从一个团队中被赶了出之后,他应该进入另一个团队,观察合作效果如何。这可以看出他是不是只在某种特定的团队中让人不爽。他认为,我们应该花一些时间找出问题的根源所在,但如果发现这个团队中的其他人就是不想跟某个人一起工作,那就应该遵守自组织型团队的基本原则,投票把他赶走。
在Implementing Scrum站点上,Michael Vizdos也谈到了类似的话题,其中包括投票驱逐的理由和方式。他提到:
也许这个家伙搞乱了所有人的工作,也许他没兴趣呆在这个团队里,或者表现的跟傻B一样,对什么都不满,嚷嚷着,想让每个人都关注他。团队拥有强大的力量。在一对一的指导过程中,在团队协作的过程中——每日站立会议、完成用户故事、完成任务,或者其他工作 ——这个人一般都可以在组织中找到其他适合他的位置。
Michael还试着从其他视角来看待这个问题。他谈到了自我选择的概念。这个原则的含义是,每个人都有能力做出敏捷方法不适合自己的判断。按照Micheal的意思,如果有人认为自己没法呆在团队里面,他不会马上让这个人离开团队,而是请他继续呆在团队里面,直到迭代结束为止。这样一来,迭代没有遭到破坏,教练也有机会跟这个人一对一的沟通,判断这个人适合在何种环境下工作。
敏捷社区的人都认为投票驱逐是自组织型团队的根本原则。但行使这项权利的时候一定要多加考虑,也许还可以有其他选择,但最后,一旦团队做出了决定,那就需要认真执行。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
· 基于Microsoft.Extensions.AI核心库实现RAG应用
· Linux系列:如何用heaptrack跟踪.NET程序的非托管内存泄露
· TypeScript + Deepseek 打造卜卦网站:技术与玄学的结合
· 阿里巴巴 QwQ-32B真的超越了 DeepSeek R-1吗?
· 【译】Visual Studio 中新的强大生产力特性
· 10年+ .NET Coder 心语 ── 封装的思维:从隐藏、稳定开始理解其本质意义
· 【设计模式】告别冗长if-else语句:使用策略模式优化代码结构