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

3 条回复

回复

敏捷团队首先就应该保证成员的水平 发表人 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

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

独家内容

程立谈架构、敏捷和SOA实践

支付宝首席架构师程立在本文分享了支付宝技术架构的发展,对架构的认识,成功架构的特点,如何避免架构设计的失败,以及在敏捷和SOA方面的实践等。

Emmanuel Bernard谈Bean验证规范

InfoQ有幸采访到了Emmanuel Bernard,向其了解Bean验证框架及专家组正在寻求的社区参与的更多相关信息。

通过索引器简化C#类型信息访问

作为一个有别于Java、Ruby等语言的一个特性,C#可以用索引器(Indexer)将类型本身以对象数组的形式供外部使用。同时,把索引器和LINQ结合使用倒是一个非常不错的组合,索引器做接口、LINQ完成内部检索逻辑,客户程序在无需记住具体方法名称的前提下,按照键值检索即可,索引器内部则依托LINQ to系列的基础,提供对各种异构数据源的访问。

产品负责人成功之道

Scrum中,产品负责人这个角色具有很大的影响力,能够带来很高的价值。但要想运用得当,可没那么轻而易举。如果做得好,就可以在客户和开发者之间建立更为融洽的关系,并能够增加组织的竞争优势。

硝烟中的Scrum和XP

在本书中,作者Henrik Kniberg讲述了他在一年的时间里,带领40人的团队实施Scrum的过程。他们试过了多种团队尺寸(3~12人)、sprint长度(2~6星期),定义“完成”的不同方式,不同的backlog格式,各种测试策略,在多个Scrum团队之间进行同步的多种方式。他们还尝试过XP实践——持续集成、结对编程、测试驱动开发等等,还试过了把XP跟Scrum组合。

软件开发中的准时化生产

准时化生产(Just In Time)是精益生产(Lean Production)和丰田生产系统(Toyota Production System)中的概念,敏捷开发与准时化生产中的很多观点和实践是一致的,精益思想作为精益生产背后的指导思想也正在积极地影响着软件开发领域,向其中不断注入创新与活力。

Tapestry for Nonbelievers

I. Drobiazko和R. Zubairov合作撰写了一篇文章,详细介绍Apache Tapestry 版本5——一个面向组件web框架。文章向读者展示了创建组件方法,并谈到了Tapestry中的IoC以及Ajax的相关特性。

ESB拓扑方案

在本文中,Adrien Louis讨论了两种基于ESB的SOA拓扑方案的优缺点:单个公司级ESB vs. 彼此互联的“部门级”ESB系统。Adrien讨论了每种方案对管理、业务监测、治理、可靠性和编配等问题的影响。