最早了解到XP是2001年，在杂志《程序员》上。记得，也是我毕业的年份。那时还没有正式走进程序员行列，在没有企业开发经验时，已经对这种开发方式产生了强烈的好奇，结对编程、迭代计划、单元测试、集成构造，一个个全新的词汇，这对我所学的软件工程完全是一种颠覆。后来，逐渐了解到这是敏捷开发的一种方式，还有类似的Scrum等，这种开发方式真的那么有效吗？为什么我接触的企业却没有使用呢？到底多少企业在使用呢？带着这些问题，我一有机会接触这个行业的朋友就会去咨询探讨，据我了解包括国内一些大型的软件企业，在前2年也基本没有敏捷的团队。导是很多欧美企业，新兴软件小企业在实践的着敏捷，那效果怎么样呢？今天看到了这篇文章，刚好做些思考。
以下为转载内容:
敏捷十年，成效几何？
自从编程界的领袖们发表旨在通过接受需求变更，加强同用户合作，缩短软件提交周期来改善软件开发过程的敏捷软件开发宣言至今已近10年之久了。
敏捷宣言制定2001年2月，当时一群软件开发者聚集在犹他州，他们希望能找到一种可以替代那些由文档驱动的、“重型”的软件开发模式(如当时的被当作金牌标准的瀑布模型方法)的新方法。
尽管早在犹他州会议之前，敏捷开发方法就已经出现，但这次会议却被当作这种方法论推广进程中的一次分水岭事件。十年以来，敏捷开发已被众所周知，很多软件公司采纳了Scrum和XP(极限编程)等敏捷开发实施方案。尽管还存在着不可预知的问题，敏捷方法领域里的专家都认为，总的来说，敏捷方法的实施会给软件开发活动带来益处。
“我说过，我们改变了这个行业，”一位宣言的签署者、目前在Tektronix工作的Ward Cunningham这样说。由于敏捷的出现，关于计算机编程的没落和编程危机的讨论逐渐消失，他说：“我们已经再也听不到人们谈论这个话题了。”
敏捷宣言比实际预期要成功的多，IBM Rational部门的首席敏捷和Lean方法论导师Scott Ambler这样说。
“它对我们整个行业有着重大的影响，”Ambler说。“如今你已经很难找到有不想去试试敏捷方法的人了。跟传统的开发方法相比，人们希望使用敏捷开发和迭代开发来使项目获得成功的愿望要强烈的多。“
但是Kent Beck，同样也是一位宣言的签署者，并且是XP的创始人，在宣言签署的10年后，对敏捷开发所带来的好处去并不是那么认可：“对于这个问题我没有一个几句话的答案。”
“敏捷开发是让人们更加认真仔细的思考如何开发软件，”Beck说。然而，并不是每个人都在敏捷开发上走对了路，他提示说。“仍然有很多人喜欢把读来的一些建议指导应用到他们的项目上，其实那些根本不是所谓的敏捷开发，“Beck说。
敏捷开发的条件
敏捷开发很难学，Cunningham说；”在你能够使用这套方法论前你必须掌握精通各种技巧。“
敏捷开发需要你扎实的技术功底，Cunningham强调道。”有很多人闯进这个领域后发现编程枯燥乏味，不再想学。“Cunningham说:”你要有兴趣做它，想把它做好，这样才有助于你成功。“
“来自企业组织的阻碍会在敏捷方法论的实施过程中显现出来。敏捷开发鼓励更加频繁的交付软件，鼓励把事情分解成小块，而不是把整个项目看成一块。”Skip Angel — 工作于BigVisible Solutions的一位敏捷顾问这样说。”我想这些对于一些企业是个挑战，这些企业的运营方式并不能使他们可以做敏捷的交付。“
项目在一些耗时的过程中很可能会陷入泥潭，Angel补充道，开发人员应该使用持续集成来避免这种瓶颈。
敏捷开发不是银弹，Ian McLeod–做应用软件生命周期管理工具的SmartBear Software公司的执行副总裁这样说。”你需要把事情做对 … 你的敏捷开发可能做的很失败，“ 他说。
Beck回忆起1997年用敏捷开发方法成功的开发出JUnit Java单元测试工具。他们团队使用短周期迭代，大量的单元测试，紧密和客户进行沟通。
”它使我们开发的更快，使我们更好的清楚需要去做的事情，“Wade Weston — 开发标准化交流系统的AttainResponse公司的CEO 这样说。”AttainResponse每周进行开发工作的sprints。我们的sprints周期很短，我们把精力高度的集中于本周要做的工作。“Weston说。
“‘可是让每个人都能上手仍然是个问题，’我的一个兄弟经常对我这样说，他喜欢更详细明确的需求。我一直告诉他，我们之所以开发的这么快，就是因为我们没有明确的需求，”Weston说。等待核心的需求说明基本上是浪费时间。他补充道。
”有些时候，一些开发人员说他们在做敏捷开发，可事实他们根本不是，“Damon Poole — 提供敏捷开发项目管理软件的AccuRev公司的CTO 这样说。“有些开发人员2周都不能把开发的东西(或“故事”)完整的编译集成，”他说。“如果你真的是做敏捷开发，那2周的时间足够把用户故事发布了。”Poole说。
敏捷编程的多种实施方案
Scrum 和 XP 是两个最具有代表性的敏捷方法论。Beck把XP描述为更注重开发的技术方面的方法。“XP说的更多的是告诉程序员应该做什么，相对比，Scrum是一种项目管理方法论”他说。
”XP的与众不同之处在于它是一种体系，而不是一种解决方案。“Cunningham — 一位推动XP发展的贡献者这样说。”它是一种有计划的编程方式。“
Scrum专注于如何管理和交付你的产品，而XP却是考究于如何去做你的工作，Angel说。
Poole指出，”很明显Scrum和XP是目前两种主要的方法论，你经常能看到Scrum团队会采纳XP技巧，而XP团队也会使用Scrum概念。“
另外一种敏捷方法论是Kanban，它起源于制造业生产流程和Lean软件开发概念，Poole说。Kanban里的约束很少，它关注于如何使价值反馈给客户的过程，他解释说。Lean关注于组织效能优化，价值优化，降低浪费，确保正确的好的生产过程，Angel补充说。
RUP(Rational Unified Process)也被人们称作为一种敏捷方法，尽管这种说法有待商榷，McLeod说。RUP的特点是有一大堆的文档，它可能是针对敏捷方法中的各个步骤的，他解释说。RUP可以是一种敏捷方法，Ambler说：”RUP给予我们的是流程上的架构准则。它完全依赖于你是如何制定的。“
Ambler同时提到了DSDM — Dynamic Systems Development Method — 一个敏捷领域里的失败的案例。SDSM有点像RAD [rapid application development]，但在里面增加了一下额外的处理。RAD跟敏捷开发的不同之处在于它只关注开发迭代，而不考虑促进合作，他指出。
McLeod认为各种敏捷方法论和迭代开发过程很相似。”它们之间没有太多的区别，“他说。
“敏捷”这个术语，Cunnigham说，是在犹他州会议上选出的一个词，人们通常把它引用为”轻量级“的方法，他回忆到。但”轻量级“这个词从表面意思上看也承载着一些负面的含义，他说。