SteveFreeman写了一篇博客拥抱极限编程（DodoXP）来反驳我的文章。我已经厌倦了与那些坚持认为如果没有极限编程，Scrum就没有价值的人进行无休止的辩论。Scrum运作良好——但前提是实施者从根本上理解其价值和实施原则。您应用Scrum的环境条件决定了您在实施过程中应采取的步骤。例如，在教堂中实施Scrum与在软件开发中实施Scrum有一套不同的实施策略。这两种情况下的实施措施与传统的Scrum不同。XP的支持者经常抱怨Scrum没有为软件行业提供良好的开发原则。但从目前XP被业界采用的进展缓慢来看，真正的罪魁祸首应该是XP缺乏切实可行的措施，造成这种情况的责任应该是XP。从1980年代到90年代，随着开发语言的进步，人们开发和测试的方式发生了变化，变得更适合软件设计。在广泛的面向对象社区中，一些概念被缓慢但广泛地接受。示例包括持续自省、有限责任、测试代码优先(TDD)、持续集成、延迟设计、编码约定和结对编程。所谓极限编程（KentBeck和他的一些同事所做的）就是把所有这些好的实践整合到一个包中，再加上JeffSutherland1993年在Easel实践的Scrum模型。从某种意义上说，这是第一个Scrum抽象概念的具体实现。这些都非常成功。然而，他们实践经验的推广和采用并没有像他们想象的那样进行。也许这是极限编程的错误名称；也许是因为领先的、直言不讳的支持者坚持认为这是唯一的真理；它;也许是因为，归根结底，XP只是另一种开发方法。我不知道。我所知道的是，很少有开发团队声称并承认采用了XP。然而，与此同时，Scrum正在获得动力。不需要很多花哨的理由，但现实是Scrum正在被相当多的团队所接受，并正在使用它来改进我们的软件开发过程。相反，XP现在想要分一杯羹。他们确实饿了。首先，让我把事情说清楚。我非常同意软件开发团队采用一些已知的实用指南来提高代码质量并产生更高级别的软件作品。但为什么这么多人不愿意这样做呢？我不喜欢把一打任务直接打包给团队，也不喜欢提前指定一个他们必须遵循的开发方式。这样做显然违反了“以人为本”和自我管理的原则。在一个好的Scrum实施中，团队成员应该根据自己的情况找到合适的实施策略。只有这样的Scrum应用流程，才能结合实际，才有意义。这就是我追求的进步。一些Scrum团队还没有找到非常满意的开发方法，这说明Scrum实施方法需要改进，而不是告诉团队成员强制执行。我有一个问题要思考：如果XP从未诞生，有多少团队愿意完全接受XP推荐的所有方法？我相信会有很多。相信这些宝贵的开发经验自然会被程序员和团队采纳。对我来说，关注的是体验本身，而不是它们出现的形式。我从来没有“完成过XP”，但我显然可以编写高质量的软件。XP的错误在于什么都硬要接受。这不是XP创始人的初衷，但现在却这样做了。很可能是XP导致了这些好的实践经验没有被接受。很讽刺，不是吗？另一个大问题是XP专着是12年前写的，从那以后诞生了40+种新语言。XP的拥护者是在向人们推荐12年前的经验，现在可能已经过时了——12年相当于整个软件行业年龄的四分之一。惊人的。让人们发现适合自己的开发方式，他们就会总结出最有效的开发经验。这远不是上个世纪末少数有脑子的人能创造出来的。我强烈敦促Scrum倡导者停止与XP争论，我们应该讨论软件艺术。这是我们在这个领域迫切需要的最终目标。幸运的是，现在有一个软件艺术运动，它有自己的宣言，正在获得关注。最终，我们可以通过转向良好的软件艺术实践来重塑我们的领域，而不是修补策略。开发人员：不要做XP。我们要实现一个总体意义上的指导框架，解决困扰我们多年的问题，构建以人为本的核心基础。让我们回到艺术工作。或者从此离开这个行业。英文原文：Don’tdoXP翻译自：http://www.vaikan.com/
