InfoQ

新闻

老资格、尊重、威信和敏捷团队

作者 Vikas Hazrati 译者 郑柯 发布于 2008年5月11日 上午8时11分

社区
Agile
主题
人力资源,
职业生涯,
企业级敏捷

在传统项目团队中工作的资深成员参与到敏捷项目之后,会面临这样的状况:他们会觉得自己的老资格没有得到足够的尊重。在某些特定情况下,他们会发现:这种状况在敏捷团队中很难改变。

在Vikram Dhiman同时发布于Scrum Development讨论组Agile India讨论组的一个帖子中讨论了一个有趣的情形。他讲述了在某公司发生的一个小事故:4个资深的技术人员拒绝加入敏捷团队,因为他们预料到自己无法得到足够的尊重和威信。这些资深成员认为:如果所在团队只以“团队的成功”作为唯一的衡量标准,他们的经验会遭到侮辱。Vikram提到有一个资深成员这样说

我苦哈哈地熬了六年多才达到现在的位置,并不介意与工作经验相对较少的人一起工作,也能从他们身上学到一些东西。可是我发现整整6年的经验根本得不到尊重。如果总是只以“团队的成功”作为衡量标准,我又怎么能知道自己是否成长呢?再次说明,我并非要与团队为敌,只是希望获得一些尊重和威信。

Vikram进一步说道

在老的组织层次结构中,有两种成长路径:技术方向(技术架构师、企业设计师等)和管理方向。我们应该怎么样向敏捷团队中的人们展示这两条路径,从而可以这些有经验的优秀人士留下来呢?

Pankaj Chawla对此争论表示了支持,并指出:在生活的任何层面,威信和力量都会决定生死存亡。他引用了一个动物王国中的例子,力量较小的动物总是会在地位的争夺中落败。他还说,虽然商业的成败有赖于差异化所带来的价值多少,敏捷却倾向于将所有的团队成员处于同一水平线上。

两个讨论组的其他大部分成员都同意:一个人多年的经验并不一定能为他带来威信和尊重。威信和尊重来自于他的行动表现。Ajay Danait补充说 ,真正的领导者不会因为没有赋予权威而退缩,他们会通过建立共识来建立自己的威信。

那是否存在一种方式,可以帮助传统团队中的资深成员获得敏捷团队中的地位呢?

Guido Schoonheim指出“每个人都一样”的团队原则不一定对资深成员适用。在他看来,要想处理类似情况,团队在一开始就应该以正式的形式将彼此的角色和工作标准确定下来。接下来,团队资深成员根据其经验,应该负责项目的质量管控工作以及对其他成员的指导。这会让资深成员的经验发挥最大的作用。

Peter Goldey就认可与成长的话题给出了自己的想法。他认为:虽然团队的成功是最重要的衡量标准,这并不是说不存在对个人表现的衡量标准。根据他的说法,如果结对编程的两人中的一个比另一个表现出色,那么他们会被自然而然地注意到。接下来Scrum Master就要给予这个人相应的奖励了。

那团队应该如何衡量个人的成功,从而不会使他觉得被忽视呢?敏捷团队该如何为资深成员规划职业发展进程呢?

Richard Banks建议使用MVP奖励方式,团队每个成员进行投票,选出最有价值的成员。他还提出要认识到团队中资深人士的经验之价值,对他们的发展规划要根据其贡献以及同事对他们的工作价值的认定来做决定。

David A Barrett认为,随着时代变化,伟大程序员的定义也在经历变化。刚开始时,技术很牛的人可被称为伟大的程序员;此后的伟大程序员要具备社区和业务要求的技能;现在这个称号的定义变得更不一样了。根据他的话,

现在,我认为一个“伟大”的程序员要能够在一个团队中工作。有一整套全新的技能需要学习——比如通过没有权威的方式施加影响,还要有能够带向成功的个人特质。我觉得,Scrum(或者通常意义上的敏捷)的效力会让最后的这种范式转移不可避免。

作为结论,David和Pankaj做出了一些似乎有些离题的评论,这也是他们非说不可的。

Dave Nicolette这样下结论:对于觉得在敏捷团队中受到忽视的人,他认为这是个人问题。他觉得敏捷是一种非常独特的工作方式,不是每个人都喜欢在敏捷团队中工作。关键在于让人摆正心态,为项目的成功做出对团队的贡献。

Pankaj的评论很有意思。他说道:

基本的问题在于:敏捷是由工程师创建的、一种非常工程化的解决方案,其所针对的问题在性质上是工程化的,但实际上是人的问题(生产力、激励、团队等等);而且就像其他针对人相关问题的工程化解决方案一样,当更多人开始接纳敏捷时,它会逐渐显露自己的问题。不过有利的一面在于:敏捷是建立在迭代改进、拥抱变化的基础上的。我想敏捷会根据自己的基本原则来不断修正,并为有了25年技术职业生涯经验的人们找到更好的发展方向。

Scrum Development和Agile India讨论组的成员们一致同意:尊重和威信是要靠自己努力赢得的,而且不会因为一个人的资格老而自动获得。然而,在讨论中有一股小小的暗流,建议敏捷要为资深团队成员们在职业规划和发展上提供一些答案。

查看英文原文:Seniority, Respect, Authority and an Agile Team

敏捷团队首先就应该保证成员的水平 发表人 Justina Chen 发表于 2008年5月12日 上午12时10分
传统到敏捷的转变,首先需要转变的,是你的思想。 发表人 Myhui Zhang 发表于 2008年5月13日 上午12时42分
Re: 传统到敏捷的转变,首先需要转变的,是你的思想。 发表人 sobizz sasumi 发表于 2008年5月13日 下午8时48分
  1. 返回顶部

    敏捷团队首先就应该保证成员的水平

    2008年5月12日 上午12时10分 发表人 Justina Chen

    要让资深人士感觉到加入敏捷团队就是一种资历的证明,而不是让他们去和一些初级人士一起工作。

  2. 返回顶部

    传统到敏捷的转变,首先需要转变的,是你的思想。

    2008年5月13日 上午12时42分 发表人 Myhui Zhang

    从“传统”型项目团队离开,加入到“敏捷”项目团队,首先需要改变的,是思想。只有从根本上理解、认同敏捷团队的核心价值观,才能更顺利的融合,才能更顺利的,将自己的经验和才华,通过团队,带给每个人。 篮球,足球是团队项目,获胜靠整体,但谁也不能否认球星的巨大作用。每个人,依然会尊敬在他们心目中,做的最出色的那个人。 所以,下面的话是非常正确的:

    尊重和威信是要靠自己努力赢得的,而且不会因为一个人的资格老而自动获得

  3. 返回顶部

    Re: 传统到敏捷的转变,首先需要转变的,是你的思想。

    2008年5月13日 下午8时48分 发表人 sobizz sasumi

    但是首先得讓每個人自己有這個概念哦。  讓別人接受這些本身就有好大的難度。 等同于改變一個人的性格

深度内容

和Google互补的搜索引擎Wolfram|Alpha

Wolfram|Alpha与Google究竟是什么关系,Wolfram|Alpha自己是如何定位的?Wolfram|Alaph在多大程度上是语义网搜索呢?InfoQ中文站就等等这些问题采访了Wolfram研究公司中国区商务经理王翔。

SOA契约成熟度模型

本文说明了所推荐的契约版本管理设计策略是如何与SOA成熟度模型发生联系的。文章目的是为实现版本管理和可组合性提供一个路线图。

数据服务简介

Vijay Narayanan在这篇文章中对数据服务的几个方面进行了介绍,它们都是SOA实践者和数据架构师感兴趣的内容。本文对数据服务的几个方面进行了介绍,包括需求定义,基本原理和好处、范围、开发以及消费模式。

分块云计算

在本文中,Jimmy Nilsson描述了一种他在过去数年间观察到的一种正在缓慢成长的架构风格,他把这种风格称为“分块云计算”。

豆瓣网技术架构变迁

罗马不是一天建成的,豆瓣的技术架构也是随着用户规模的增长一直在持续变化中。在本次演讲中,豆瓣的首席架构师洪强宁将与大家一起分享从上线时的单台服务器架构开始一直到现在的豆瓣架构变迁历程。

融合思想:深入探索S#arp架构

Billy McCafferty展示了S#arp架构,它在ASP.NET MVC框架的基础上,荟萃了当今的最佳实践,应用在ASP.NET Web应用程序的架构设计中。

王雷谈开源以及新兴市场计划

中国作为新兴市场中的新兴市场,是Sun在美国之外实施SSE(SUN Startup Essentials)项目重点关注的地区。在QCon Beijing 2009期间,InfoQ中文站有幸对此项目的负责人王雷先生进行了采访,探讨了关于开源、新兴市场、SSE等话题。

使用HTML5构建下一代的Web Form

HTML5 是由 WHATWG发起的,最开始的名称叫做Web Application 1.0,而后这个标准吸纳了Web Forms 2.0的标准,并一同被W3C组织所采用,合并成为下一代的HTML5标准。