刚结束了一段不愉快的项目经历，其中掺杂着各种抱怨和愤怒，然并卵，人微言轻，并没有阻碍项目走向灭亡。
现在静下心来，以旁观者的身份重新审视了一下这段经历，颇有心得。正巧收获了一本宝典《解析极限编程：拥抱变化》，在里边看到了我们项目的影子，该书言辞犀利，见解独特，有种相见恨晚的悲哀，给了我很多的心理安慰
极限编程简称XP，主要适用于中小型团队在需求不明确或者迅速变化的情况下进行软件开发的轻量级方法学。我们项目应该也不适用这种开发模式，因为需求极度不明确，项目整体方向都不清楚，所以怎么搞都是废，这完全归功于客户，呵呵。虽然不适用，但其中理论部分是相通的，可以学习一下。
XP流派的主要特征：适应环境变化和需求变化，充分发挥开发人员的主动精神。
软件不能按时交付，也就不能创造价值，这不仅会造成经济损失，而且对当事人本身也有很大的影响。我们需要找一种新的方法来开发软件（非常有必要），我们的项目就是缺少变通，除了加班还是加班，哎。。软件开发的基本问题是其风险，进度延迟、项目取消、系统恶化、缺陷率、业务误解、业务变更、错误特别多、人员调整（半年后，这个项目的所有优秀程序员开发厌恶而离开了）。因为项目需求的极度不确定性，导致开发人员的工作变得极度复杂，做了又改，改了又全部否定，重做后发现还是第一版的好，再改回去。最后导致项目延期，缺陷率太高而发布失败，项目做到这种地步，不全是客户的原因，项目管理者也有责任。
控制项目的共有四个变量--成本、时间、质量和范围。其中，范围的控制最有价值，在这个模型中，软件开发的游戏规则是让外力（客户、管理人员）确定任意三个变量的值，而开发团队确定第四个变量的结果值。很多管理人员和客户认为他们可以确定所有四个变量的值。“你要用这个小组在下个月一号前达到所有这些需求。质量是这儿的首要工作，所以它应该达到通常的标准”，这种情况下，质量总是被抛诸脑后，这是因为在太大的压力下，没有人能做好工作。时间上也可能会失控，最后你得到的是蹩脚的软件。解决的办法是，让这四个变量变得可见。如果每个人-程序员、客户、管理人员-都能看到所有这四个变量，他们就能有意识地选择控制哪些变量。如果不喜欢第四个变量得出的结果，他们可以改变输入，或者选择控制另外三个变量。
每当看到此，我就佩服的五体投地。该死的项目，极度吻合的沿着剧本走，像是别人经历过的一样，我感同身受，我想知道，这些理论真的是凭空思考的么？看了这么多，也挽救不了那糟心的项目了，只能默默记下，警戒自己，不要重蹈覆辙。
项目最重要的就是范围，客户不能告诉我们他们想要什么，而当我们给出他们所说的需要的东西时，他们又不喜欢，软件的开发会改变软件本身的需求。一旦客户见到第一个版本，他们就明白了在第二个版本中他们需要的东西。。。或者他们在第一版本中实际想要什么。要是我们把需求的这种“柔性”看作一个机会，而不是问题，会怎么样呢？那么，我们就可以选择将范围当作四个变量中最容易控制的。我们可以对它进行塑造，如果到发行日期的时间变得紧张，那么总会有一些东西可以延期到下一个版本。通过不去试图完成太多的功能，我们就可以保持能力按时实现满足质量的产品。然而，现实中的客户总是异想天开，要求即保证质量，又不断扩大范围，还要求按时发布版本，换来的就是无尽的加班，先前已提到，这种情况下，质量是最先被忽略的，也就意味着BUG在不断的被生产中，项目将陷入恶性循环。所以理论是美好的，现实是残酷的，但我们还要保持相信的态度，理想还是要有的，万一实现了呢，呵呵。。
项目会经常改变方向，这必须是一个容易包容变化的过程，我们也不想在没人使用的软件上浪费太多，必须将变化的成本保持在合理的范围内。为了避免丢弃重要功能，舍得是很有必要的，首先实现客户最重要的需求，这样如果不得不放弃别的功能，那么这个功能也不能比已经在这个系统的其他功能重要，这需要管理人员深刻地和客户沟通，否则客户就真理了，哎哎哎。。。如果真的确定不了，等待要比现在实现它更好，避免无谓的劳作。
客户和管理人员的责任已经说清楚了，我们再来探讨开发人员应注意的事项。
由于篇幅限制，XP的开发团队将放到下一篇中详述。