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

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

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

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

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

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

• 在“书评：责任病毒让恐惧削弱了协作的效果”一文中，团队中的英雄主义被看作一种极端情况，会让团队缺少协作，不像个整体，推委责任。
• 在“著名教授批判宏观管理”一文中，英雄主义的领导风格被看成了业界的通病。
• 在“Kent Beck：做真实的自我——创造更多的价值”一文中

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

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

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

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