从极限编程说起
实际上这里所说的eXtreme Programming(XP)并不是指某种软件工程方法学，但我们不得不先讨论其意义。
诚然，XP被认为是目前最有成效的敏捷软件开发方法之一，其核心在于将严格定义的规则、流程和相关文档分散成若干小规模过程，并借助动态进化设计实现灵巧的轻量级开发。
表面上，XP的目标是降低用户需求变更所造成的成本增量。这似乎与人们通常所说的“未雨绸缪”有所抵触，也和传统的开发过程之间存在很大出入。然而从社会学的角度来说，XP满足了一种社会变化机制，毕竟历史看起来并不是“照本演绎”的，尽管软件开发存在用户需求，但无论是出于主观原因还是客观原因，这些“需求”并不是一成不变的，XP在面临此类状况时所体现出来的效果，显然要优于其它一些传统的软件开发方法。
现在考虑一个现实中的案例，如果我们的实习期从2009年7月12日正式启动，直到10月下旬，那么摆在面前的就是一个极其复杂的组合调度问题，因为毕竟没有人会幻想剩余最后可怜的两个月能够力挽狂澜。
许多先行者告诉我们执行严格的water-fall方案才有可能到达彼岸，但很明显本案例并不适用这种经典方法。 因而我们需要敏捷，此处敏捷的原因并非需求变化的莫测，而是突发条件的难料，这就迫使我们更加灵巧、轻量地思考这一问题。
但不应忘记，XP方法之所以被称作eXtreme，它期望开发者能够在小规模过程中真正突破eXtreme，并最终实现积流以江、汇江成海。
我并不认为XP缺乏严谨，就如专家定义的XP价值标准:沟通、简单、回馈、勇气和尊重，这些也是我们能最终取得成功的关键因素。
注：一年前的“掩帘向学”仿佛近在咫尺，尽管只持续十多天的思考，却似乎打通了一条向往之路，如今终于步入“关键模块”阶段。鉴于此我不得不逐步减少交流频道的更新，令人惭愧的是一年多来几乎没有一个原创性的连载系列文章能够最终完成，希望将来能有机会继续坐在图书馆里完成它们，这恐怕就是用户当前抽象化的最终需求之一了。