InfoQ

InfoQ

新闻

我的书签

登录注册 以永久保存书签。

该内容已经被标记书签!

标记书签错误,请重试!

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

作者 Vikas Hazrati 译者 郑柯 发布于 2008年5月11日

领域
架构 & 设计,
企业架构,
过程 & 实践
主题
企业级敏捷 ,
职业生涯 ,
敏捷 ,
人力资源

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

在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

译者 郑柯 InfoQ中文站总编。做过开发,当过PM,干过销售,搞过市场,最终还是回到媒体。实用的理想主义者,相信:每天改变一点点,这个世界会更好。

敏捷团队首先就应该保证成员的水平 发表人 Chen Renart 发表于
传统到敏捷的转变,首先需要转变的,是你的思想。 发表人 Zhang Myhui 发表于
Re: 传统到敏捷的转变,首先需要转变的,是你的思想。 发表人 sasumi sobizz 发表于
  1. 返回顶部

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

    发表人 Chen Renart

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

  2. 返回顶部

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

    发表人 Zhang Myhui

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

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

  3. 返回顶部

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

    发表人 sasumi sobizz

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

深度内容

应用云平台的可用性——从新浪SAE看云平台设计

云计算平台的可用性,相比传统互联网服务而言,更加复杂和困难,也更具有挑战性。本文借助新浪SAE云平台为读者讲述了云平台可用性的定义、如何打造高可用的平台,以及对云计算的用户提出了建议。

JVM定制改进 @ 淘宝

淘宝高度重视Java平台的健康发展,组建了一个团队专注于Java平台的底层部分的性能、功能与稳定性改进;工作主要基于OpenJDK中的HotSpot VM开展,其中一些通用的功能随后也会逐渐反馈给OpenJDK社区。希望能与使用Java平台开发应用的大家交流经验。
本次演讲视频录制于QCon杭州2011

"伤得起"的云计算应用——对云端应用之架构的思考

2011年4月21日至22日是值得云计算从业者纪念的日子。Amazon的IaaS服务出现故障,导致许多商业网站的服务中断,影响非常严重。作为云计算用户,我们需要思考的是,如何保证即便在云服务不可用的情况,我们的应用架构仍然能够屹立不倒?本文正是站在云计算用户的角度试图探讨这一问题。

让交付的速度跟上思考的速度

12人的技术团队,4组刀片服务器,每月20亿的访问量,每日1次准时部署,99.9%的可用性。这可能吗?当然。想知道如何做的吗?百姓网将与您分享他们在DevOps实践过程中的经验和技巧。
本次演讲视频录制于QCon杭州2011

架构之路——穿行在产品和业务之间

篱笆作为一家起源于社区的电子商务公司,反映到技术层面就是同时要面对产品和业务,以及经营战略的变化调整。如何在产品和业务的夹缝之间完成技术架构的抽象与平衡,寻找更有效的价值定位,这当中有些经验教训和个人感悟愿与众人分享。
本次演讲视频录制于QCon杭州2011

特性注入:成功三部曲

本文将对特性注入以及相关方法做一个扫盲性的介绍。我们会解释这个框架的关键要素,并附上实例来证实它们。为了让文章保持相对较短,我们不会深入到某个工具或方法中,而是会给出一些参考资料,以便大家做进一步的研究。

解析JDK 7的动态类型语言支持

随着JDK 7的发布,字节码指令集终于迎来了第一位新成员——invokedynamic指令。这条新增加的指令是JDK 7实现“动态类型语言(Dynamically Typed Language)”支持而进行的改进之一,也是为JDK 8可以顺利实现Lambda表达式做技术准备。在这篇文章中,我们将去了解JDK 7这项新特性的出现前因后果和它的意义。

Java Remoting远程服务(下)

随着互联网应用的发展,Java分布式远程服务技术受到越来越多的关注,本文将对各种相关实现以示例的形式逐一介绍,并总结其中的优缺点,使读者能够在技术选型时有所准备。这是文章的下篇。