在“ GDM-Agile 悖论：在全球交付模式中运用敏捷的技巧”一文中， Ajay Bhandari 和 Kumarasivan Veeramuthumoni 和我们分享了他们在离岸开发模式中采用敏捷开发的一些经验。他们提出了几个影响成功的关键因素，其中一个是：
第二个关键因素是你得拥有好的人才。我们有被大家成为“银弹”级别的人物，一个无所不能、有着极强设计能力的程序员。显然，不是所有的团队都有幸能拥有这么一个明星程序员，但是有不少办法让你能确保你手下的干将满足项目的要求。
他们具体探讨了为什么一个技术牛人对他们的成功是至关重要的，并且建议我们在没有这种人才的情况下，不要在离岸开发模式中采用敏捷:
根据经验，一个项目如果工程方面的要求越高，使用敏捷开发的难度也越大。为什么呢？工程方面要求高就意味着更加复杂。拿我们的项目来举个例子。在一个网站项目中，我们所计划的很多功能都需要用到尖端的技术，但是大部分技术我们几乎没有经验。很幸运，我们的技术明星很快理解了新技术，尝试着写了一些代码，并且制定出完美的流程使得其他成员能效仿。如果没有他，团队将因为不能理解技术而陷入麻烦，也就根本不能按照敏捷开发鼓励的那样去尽早做出决定。我们目睹了很多项目的失败，原因就在于工程方面的过多要求。在这种情况下，如果你没有经验丰富的架构师，那么请不要使用敏捷。
这个建议来之不易，是源于作者的亲身经验。但是它不符合敏捷界的主流观点。
- 在“书评：责任病毒让恐惧削弱了协作的效果”一文中，团队中的英雄主义被看作一种极端情况，会让团队缺少协作，不像个整体，推委责任。
- 在“著名教授批判宏观管理”一文中，英雄主义的领导风格被看成了业界的通病。
- 在“ Kent Beck：做真实的自我——创造更多的价值”一文中
Beck 探讨了如何摆脱一个被他成为“天才 / 蠢蛋过山车”的模式，这个模式要求我们要么成为工作中的英雄，或者成为蠢蛋，因为我们无法成为英雄。他的建议是：“工作中，你就是你。”
那么分布式的敏捷开发就不一样吗？“英雄”模式是应该被遵循还是避免呢？
查看英文原文： Does a Distributed Agile Team Need Heroes?
译者简介：金毅，小小项目经理。对敏捷思想和实践，软件工程等颇有兴趣，关注 Ruby。多年服务于软件外包行业，对软件工程、方法学等在外包业的运用和实施略有感悟。
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论