与大师面对面

昨天，CSDN举办了一个程序员沙龙，我一般是少有参加这样的活动的，不过昨天却是例外，因为昨天请来的，正是敏捷开发的创始人之一，Martin Fowler。
不知道他身份的话，远远望去，也不过是一个很普通的老外，络腮胡子，秃顶的脑门（这使我想到了C++创始人那同样秃顶的脑门 ，是不是每个聪明的人都回绝顶啊）。现在就不客观的回顾一下昨天的演讲，为什么叫不客观呢，因为我不能忠实的记录大师的每一句话，我在听的过程中也一直在思考，所以，我想，我的记录恐怕夹杂了很多我自己的想法和臆测吧。如果各位想要看看完全真实的记录话，我还是建议去CSDN的网站咯。

    首先是ThoughtWorks公司的中国区总裁Mr. Pinney，Fowler现在的身份应该是ThoughtWorks公司的首席科学家，专门指导敏捷开发的。ThoughtWorks是一家什么样的公司呢，就我的理解应该是一家IT Service的公司，自从蓝色巨人开始向IT服务转变后，我才发现，美国的软件行业早已经全面的向IT服务转变了，列的出名字的除了刚才说的ThoughtWorks还有 Ivar Jocobson International, EDS,挨森哲等等。大体来讲这样的公司业务都分为两块，一块是软件定制，一块是软件开发咨询。而ThoughtWorks的特色就是不管是自己开发行业软件还是对其他企业进行软件开发咨询，都采取敏捷的开发方式，并且取得了巨大的成功。呵呵，扯远了，详细地内容敬请期待我的下篇blog《IT服务的时代》

    言归正传，随着Martin Fowler的登场，我们来聊聊他的演讲。首先，Fowler先生把我们传统的开发方式称为plan driven的开发方式，也就是计划驱动。不同于敏捷方法所采用的测试驱动，计划驱动的开发方式是以预测性味基础，以过程为核心的开发方式。这种开发方式，往往强调设计的重要性，希望在正式构建之前（所谓构建，也就是我们常说的coding过程），能够把一个软件的方方面面都能想到，并用文档的方式和图的形式得以保留，这也是UML产生的初衷——为了更好的描述设计，Martin Fowler作为UML的专家，豪不隐讳自己曾经也使用传统的开发方式很多年的事实。正式多年的传统方法的开发方式，使他发现了以下三种情况是plan driven的开发方式所恨难避免也很难解决的。
    其一，如果把软件工程跟其他的工程领域来比较，其他的工程领域设计阶段只占用整个生产周期的10%左右的时间，而软件工程却占用了40%到50%的时间，问题出在哪里？是这个类比不恰当？还是我们所谓的“设计”划分的时间点不正确？
    其二，与建筑商的设计不同，软件设计在纸上是很容易完成的，而拿到实际开发中却发现有这样或者那样的问题，作为资深的软件开发专家，Fowler先生也很诚实的承认，无法在设计阶段把所有可能的问题都考虑得周全
    其三，需求总是在不断的变化的，不像建筑工程那样是建立在静态需求之上。
    这样的三个问题，直接就导致了敏捷开发的产生。敏捷开发是以适应性为基础，以人为核心的开发方式，目的就是解决以上三条plan driven无法避免的问题。说到以人为核心我又要插两句话了，最近国内所谓的“软件工程”是很火的了，软件学院每年不知道培养了多少“软件工程师”和“软件蓝领”，很多人都要学习所谓的印度模式，想要把中国变成一个巨大的软件加工厂，而这种思想所代表的正是 plan driven的开发方式所提倡的过程管理：以过程为核心，人就像零件一样是可以替换的。对于Fowler先生的观点来看，这种思想是不可理喻，无法实现的乌托邦式的思想。为什么敏捷开发如此强调人的作用？对于此Fowler先生给预了专门的阐述。首先，根据调查（IBM的某位牛人的调查，应该是艾克.卡文），“大凡成功的项目，基本上没有什么可以重复的经验（process）可以用来参照，唯一的一点，就是有一个好的开发团队”。项目管理，说白了，就是管理项目开发的主体——人，人在项目开发中起着绝对主导的作用，绝不是像零件那样可以随意替换的。这里Fowler先生做了一系列的对比：基于plan driven的开发，把程序员当作了computer，甚至有人还提出软件开发本身也可以被编程。而对于敏捷开发来说，不同于机器零件，人没有持续性的也不可重复，人的优势和机器的优势并不一样，人应该是第一位的，凌驾于过程（Process）之上的。“人与人之间的交往互动比方法和工具更重要”（《敏捷宣言》）。方法应该用来适应人，在一个好的开发团队中，人应该能选择方法。过程是不一样的，对于敏捷开发的每一次迭代，都必须总结改进开发的过程。
    在演讲的最后，Martin Fowler先生也指出了，敏捷开发不是万能药，本身也还是在一个不断的探索阶段。而且，及时在美国，也不是一个普及的开发方式，不过他对敏捷开发的未来还是很有信心的。

    接着就是嘉宾的圆桌会议，主要也就是敏捷开发这个领域结合各自的开发世纪和中国的实情进行了一些讨论。讨论本身我就不再记录了，不过导是抽出了一些观点。
    一个就是，关于程序员素质的问题（我觉得那位大哥想说的应该是程序员的经验），Fowler先生认为开发经验的不足并不是敏捷开发不能实现的理由，恰恰相反，敏捷开发可以快速的帮助程序员成长。但这里面有一个默认条件，那就是需要教练，呵呵，是这么翻译的，不过我觉得翻译成师傅也很恰当（取义自《软件工匠》），一个敏捷的团队最好有一个经验丰富的灵魂人物作为指导，才能够比较快速的成长，尤其是当一个团队的经验不丰富的时候。
    二个就是，不同于工程学的比喻，软件开发更像一个律师和客户那种基于协议，协商的一种工作，笔者把它比作咨询式开发，或者我们以后可以叫做软件咨询学。另外一种情况就是，软件工程所类比的工程学也是N多年以前的工程学了，现代传统工程学越来越注重需求的变化，淡化设计和构建的分界，对此，正是软件工程学所需要好好反思的。
    三个就是，虽然自上而下或者自下而上的推广敏捷开发都可以，但是就目前国内成功的案例来说一般还是自上而下的推广，才能成功，而这，正是国内推广敏捷开发的巨大阻力。
    四个就是，现场客户对于敏捷开发（我觉得对于所有的开发都是这样）的成功，是十分重要的。殊途同归，软件开发的核心就是紧紧抓住客户的需求。

    在活动的最后，我眼疾手快，以最敏捷的方式举手示意，终于得到了一次提问的机会，呵呵，而且一问就是三个（哎呀这三个问题，差点让我没有得到CSDN神仙姐姐送的纪念品）。那么我这里就比较详细的记录了Fowler先生的回答。（个人认为我的问题还是比较尖锐和有针对性地）

Q1:既然敏捷开发如此的强调人的作用，那么怎样避免在开发过程中出现个人英雄主义，也就是过分依赖于团队中某些人的技术，而当这些人离职后会导致开发的中断甚至瘫痪。
A: 就我们的开发事实来说，这样的“个人英雄”走了，团队的开发反而变得容易了，敏捷开发强调人的作用，强调的是团队的合作而不是个人英雄主义

Q2:国内很多公司都在试图通过CMMI的认证，您认为如何把敏捷方法引入到CMMI的体系中。
A: 嗯，在CMMI中溶入敏捷其实事件很困难的事情。CMMI的提出，本来是为了帮助个人进步的一种机制，首先，它的产生背景，源自一个plan driven的开发方式相当普遍的时代，所以比较强调过程的管理。但是并不是说CMMI中引入敏捷是不可能的，事实上CMMI对敏捷也是非常友善的。但是对于CMMI来说最可怕的是证书的兴起（说的好，这就是一个政治的问题而非一个技术的问题了），它破坏了CMMI的初衷。

Q3: 对于传统的非面向对象的语言，比如说VB是否可以引入敏捷开发
A: 敏捷开发本身是语言无关的，XP也不是敏捷的全部，不过VB不支持创建自动化测试确实也是个问题，但还是有实施的可能，特别是.Net平台以后，这一切都变的非常容易了（俺这么问自然是因为我在开发中确实没有办法自己选择开发语言嘛，要是能用.Net，我也就没有这个疑惑了，5555）

以上就是我写的特别报道，感谢CSDN提供了这次交流的机会，同时感谢Microsoft和CSDN提供的blog空间......（此处省略N多字）。最后的问题是，我写了这么长，不知道会不会有人来看啊