我有这样的一个经验，当你拿着你的proposal去和你的客户洽谈，希望通过超强的技术拿下这个项目时，往往不能如你所愿。诚然，当你炒出一大堆概念，例如面向对象设计、设计模式、AOP、敏捷或者SOA，客户的谈判代表往往会为你口若悬河的一番谈吐而佩服得五体投地，甚至于晕晕乎乎，但客户总能把握自己最后的底线，“咬定青山不松口”。终究说来，要去洽谈项目，除了要看公司的实力、项目经验以及业务人员的关系之外，客户最关注的还是你的WBS和报价，以及项目或产品的交付时间。
所以谈方法，可以让客户佩服你，却不能让客户认同你。
那么在项目开发过程中呢？不管是什么项目，项目要取得最后的成功，判断标准是客户。因而，在项目开发过程中，与客户的交流就显得至为关键。甚至可以这么说，客户的参与程度直接制约了项目的成败。敏捷软件开发正是将客户放到第一位置，重视与客户的交流，通过与现场客户或者ProductOwner的讨论，排定用户故事（Product Backlog或者特征Feature），以及它们的优先级。然后通过迭代（Sprint）的方式，定期交付可以工作的产品，供客户使用，以期判断出开发人员的实现是否符合客户的需求。无疑，这是敏捷软件开发取得成功的要素之一。
然而，在真实项目中，我们很难找到方法中提到的理想客户。如果客户是领域专家，我们或许要省去很多事情，然而这种事情固然是可遇而不可求，除此之外，很难排除领域专家会对项目开发的横加干涉。我们无法保护自己的项目成员，不会受到这样强势的客户的干扰。如果客户仅仅熟悉传统领域的业务需求，那么很不幸，我们还要担负引导客户的责任。最重要的，我们要制定一套双方都认可的交流标准，这样才可以降低歧义的大面积产生。如果一个项目存在多个客户时，那么，你将面对的不再是问题，而是毁天灭地的灾难！在客户都没有能够统一自己的需求时，又哪里能够谈得上软件开发呢？项目经理会淹没在客户方的文山会海中的。何况，还有无穷无尽的需求变更在等着你。
最为普遍的是，我们的客户往往并不了解软件技术。此时，你愿意不厌其烦地和他们大谈特谈方法吗？反过来，客户又愿意耐下心来聆听你的布道吗？
错！错！错！客户并不希望经历一次项目之后就能成为软件专家，也不希望一大堆苍白无力，毫无意义的名词堆砌在自己的脑海里。什么敏捷，什么领域驱动模式，什么架构设计，统统见鬼去吧！我们需要的是看得见，摸得着的产品！是那种通过鼠标操作就能够看到结果的Windwos界面，那才是神奇的魔术。对于客户，就是这么简单。
Ron Jeffries在一个关于敏捷的讨论小组中提到：我们的客户不应该在意敏捷开发。我们的客户只对业务负责任，但并不仅仅只限于软件开发。他们应该感兴趣的是：
-- 得到真正需要的软件；
-- 能可靠工作的软件；
-- 尽快交付的软件；
-- 对他们的影响尽可能地小;
-- 软件以其最容易最自然的方式运行。
其实与客户进行交流，就是技术与技术之间的碰撞。领域技术是开发人员所不具备的，但却是我们必须关注的。我曾经为一家生产液晶显示器的企业开发过CIMS系统，对于与生产线相关的一大堆概念畏之如虎。我们强烈需要那些精通领域知识的开发人员，在这个项目中，我们幸而拥有，因此项目取得成功。然而在大多数项目中，我们无法拥有这种幸运。
为什么要采用敏捷？不是因为我们可以敏捷，而是客户要求我们敏捷。很难想象，一个项目在闭关数月的时间里，客户还能够忍耐那些案牍文档。我经历过这样闭门造车的项目，结果失败了。其实，并非敏捷比其他项目开发方法要好，而是我们必须把握敏捷的精神，在于我们重视与客户的交流，在于我们的团队是自组织的，在于我们能够在定期时间内交付可以工作的产品。
客户希望看到的不正是这样吗？然而，我们一定要切忌收住那张夸谈技术的嘴巴。客户不希望听到什么方法，什么技术。项目是否采用敏捷与他无关，即使采用瀑布式软件开发，只要成功，客户也会认可。因此，不管是何种方法，只要能够定期高质量的交付产品，就是好的方法。唯一不同的是，成功实施敏捷或许能够有助于消除客户的误解，增加客户的信心。
我的外婆常常教导我：“不要做说话的巨人，行动的矮子！”诚哉斯言！