hehe，这个不是我说的。是昨天听Larman的讲座的时候，他这么告诉我的。
Craig Larman，提出过GRASP模式和PV原则，著书Applying UML and Patterns（UML和模式应用，中文版已出）；Agile&Interative Development-a manager's guide。这次讲座的的内容主要是关于迭代式开发和敏捷方法的。
中间提问的时候，我问到了前一段开发产品时实践XP的最大的疑惑，怎么样增加客户的参与度？因为我们的客户（其实就是老总了）很忙，一个月出现一次就很不容易了，而且每次的时间也难以保证。我始终认为这是项目的最大风险，却苦于不知道怎么解决它。
Don't use XP！这就是他回答我的第一句话。因为显然，我没有现场客户，那么就不可能实施这个实践。而只有所有的关键实践结合在一起（至少要有现场客户、代码公有、结对编程、测试驱动、计划游戏、持续集成）才能叫做XP。因此，我们所实施的并不是XP。敏捷开发方法并不只有XP一种，可以选择其他的对需求有更多过程支持的方法。
听到这样的回答，第一个感觉是有点不能接受，实话实说，我首先想到的是Larman是不是更加“亲”RUP，以至于要打压XP来显示敏捷UP的更广的适应性。其实他说的这些我都明白，也看到Beck在自己的书中明确的这些写着，而且，我自己很清楚项目还远远没有达到XP的标准，只是尝试XP。
但是，我的第一感觉还是难以接受。开始，我认为是因为我误认为他的建议是完全抛弃XP的实践，如TDD。但后来，我明白了，是我过于热爱XP，不是某个实践或因为它的有效性，而是因为它的概念上的完整统一和其中所包含的人文信念对我的吸引。尽管，我知道团队还没有到XP，但是我却渴望着它可以在某个将来成为一个XP团队。所以，在明确的知道了条件的局限已经不能适应方法的使用限定时，我仍然固执的坚持不增加合理的过程，而只是盼望着从天上掉下来一个现场客户。因为我无法对自己说：“Dont't use XP”，而这正是问题所在，我对自身的利益要求压倒了对客户的利益要求，结果是为了应用一个很酷的过程去作软件而不是为了满足客户的需求。原来在技术层面犯过的错误，这次又在过程层面再犯了。忽然明白了《敏捷软件开发》中一句略显夸张的话“作为程序员，你必须明白，XP不是你唯一的选择”。
回头再说说讲座，Larman的讲座非常的好，从内容的广度到现场的气氛，都非常的不错（特别是今天在公司里讲了TDD后，发现演讲真是一门需要磨炼的技巧）。比较可惜的是，似乎是组织方（IT之源）宣传的原因，到会的人相当少。而现场的翻译，好像是因为省成本的原因，是由组织方的人客串的。倒不是他的英语水平差，事实上是相当不错的。但是，口译也是一门需要专门训练的技能，最后的结果就是整场的翻译基本上就是白描式的。
在开始的时候，组织方专门说明了因为成本的原因，他们是通过反复谈判最终争取到Larman来义务讲座（当然我们不是免费，他们还是需要搞点场地费路费的） 。但是这样的一个组织水平，我认为不会促进开展更好更频繁的交流。
这次的收获有：比较系统的了解了迭代开发的理论历史和关键方法；比较广的知道了敏捷方法族；对敏捷建模有了一个粗略但是比较明确的了解。可惜的是一天的时间有些短，有些方面如果能够展开就更好了。
哦，对了，还有一大收获是去上海的车上认识了一个漂亮mm,
