BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

分布式的敏捷团队需要英雄吗?

| 作者 Amr Elssamadisy 关注 0 他的粉丝 ,译者 金毅 关注 0 他的粉丝 发布于 2009年4月28日. 估计阅读时间: 2 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

在“GDM-Agile悖论:在全球交付模式中运用敏捷的技巧”一文中, Ajay Bhandari和Kumarasivan Veeramuthumoni和我们分享了他们在离岸开发模式中采用敏捷开发的一些经验。他们提出了几个影响成功的关键因素,其中一个是:

第二个关键因素是你得拥有好的人才。我们有被大家成为“银弹”级别的人物,一个无所不能、有着极强设计能力的程序员。显然,不是所有的团队都有幸能拥有这么一个明星程序员,但是有不少办法让你能确保你手下的干将满足项目的要求。

他们具体探讨了为什么一个技术牛人对他们的成功是至关重要的,并且建议我们在没有这种人才的情况下,不要在离岸开发模式中采用敏捷:

根据经验,一个项目如果工程方面的要求越高,使用敏捷开发的难度也越大。为什么呢?工程方面要求高就意味着更加复杂。拿我们的项目来举个例子。在一个网站项目中,我们所计划的很多功能都需要用到尖端的技术,但是大部分技术我们几乎没有经验。很幸运,我们的技术明星很快理解了新技术,尝试着写了一些代码,并且制定出完美的流程使得其他成员能效仿。如果没有他,团队将因为不能理解技术而陷入麻烦,也就根本不能按照敏捷开发鼓励的那样去尽早做出决定。我们目睹了很多项目的失败,原因就在于工程方面的过多要求。在这种情况下,如果你没有经验丰富的架构师,那么请不要使用敏捷。

这个建议来之不易,是源于作者的亲身经验。但是它不符合敏捷界的主流观点。

Beck探讨了如何摆脱一个被他成为“天才/蠢蛋过山车”的模式,这个模式要求我们要么成为工作中的英雄,或者成为蠢蛋,因为我们无法成为英雄。他的建议是:“工作中,你就是你。”

那么分布式的敏捷开发就不一样吗?“英雄”模式是应该被遵循还是避免呢?

查看英文原文:Does a Distributed Agile Team Need Heroes?


译者简介:金毅,小小项目经理。对敏捷思想和实践,软件工程等颇有兴趣,关注Ruby。多年服务于软件外包行业,对软件工程、方法学等在外包业的运用和实施略有感悟。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

颇有同感 by cp true

之前做砸了一个项目就是因为项目成员都没有相关的技术经验,一边做一边学,完全无法控制schedule,在全部推倒重做几次后,项目宣告失败。

牛人的角色 by Zheng Can

我觉得这里所谓的牛人其实在一定程度上可以被理解为架构师。
在敏捷中,由于各项要素的变化都非常快,因此维护项目架构成了非常重要的一环。稳定可靠的架构能够帮助团队成员更好地开发产品。
另外,在软件项目的若干系统性风险中,技术风险相对来说比较容易在前期通过预研的方式进行规避。但如果预研不能架构结合在一起考虑,那么不排除会失去方向。
综上,请砸砖...

敏捷了不意味着就有银弹了 by 曹 云飞

架构师的能力决定了他可以作为英雄,他的作用不会因为团队是敏捷的就不重要了。

同意 by Li Qiang

团队中的技术牛人=项目架构师,软件工程CMMI的技术指标或者是Agile开发的各项敏捷指标都需要该技术牛人来评价,其他人做的话,很难做到合理性。

Re: 牛人的角色 by Lee Raymond

架构师不一定是编程的高手,更有一些编程人员对架构师这个头衔趋之若鹜,经常导致架构师的职责和能力要求不明确,名不副实~

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

5 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT