在传统项目团队中工作的资深成员参与到敏捷项目之后,会面临这样的状况:他们会觉得自己的老资格没有得到足够的尊重。在某些特定情况下,他们会发现:这种状况在敏捷团队中很难改变。
在 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 讨论组的成员们一致同意:尊重和威信是要靠自己努力赢得的,而且不会因为一个人的资格老而自动获得。然而,在讨论中有一股小小的暗流,建议敏捷要为资深团队成员们在职业规划和发展上提供一些答案。
评论