梦想风暴

我们很忙

dreamhead — Sun, 08 Nov 2009 23:52:32 +0800

软件开发似乎就应该是忙碌的，加班似乎也应该是常态。我听到最为痛心的一个说法是，每天都在加班，忙得连洗衣服的时间都没有。也是因为忙，忙得有没有时间学习、没有时间思考。所有一切都是因为忙。

但是，我们都是怎么忙的呢？不妨看一些细节。

软件开发中，最重要的过程应该是编码，但真正的编码有多长时间呢？在一个采用传统开发方式的团队中，会有一个最后集成阶段。因为前期做的验证不够充分，所以，要给后面留下很长的时间，用来做集成和测试，更有甚者，这个时间要比“开发”时间还长。这里的“开发”阶段只是在纯粹的编码。就这样，在计划中，很大的一段时间被砍掉了。

即便是在“开发”阶段，就真正能坐在那里好好写代码吗？未必。在大企业里面，最浪费时间的是什么？开会。人多，沟通不畅，开会成了“自然”的选择，而且，往往是人越多，会就越多。事实上，很多企业的会都是非常低效，一开会就发散，通常一个会一两个小时就进去了。在《做好一件事》中还提到矩阵式管理也会让人无法好好写代码。就这样，在团队开发中，又有一段时间被消耗掉了。

即便真正开始写代码，又是怎么做的呢？对于历史悠久的产品而言，程序员需要面对大量的遗留代码，编译一次代码，都要用很长时间，这意味着，消除编译错误这样原本应该很简单的事情都要消耗大量的时间。于是，经常可以看到一个个程序员面无表情的在那里等待编译。遗留代码，通常也意味着欠了一屁股的技术债务，也就是说，为一个功能要遍地开花的改许多代码，这也很耗时。对于不编写单元测试的程序员，常用的验证手段就是调试器，因为人的参与，这个过程不能自动化，很是缓慢。好容易到了该提交代码了，因为文件很大，出现冲突的几率也增加了，处理冲突也是耗时的事。在个人开发中，时间就在不知不觉中流逝。

我们很忙，因为忙而认为一切都是理所当然的。正如上面所列，很多时间实际上是在一环扣一环的低效中无谓消耗了，所以，每天不得不加班，让自己看上去很忙，以此换回内心的“安宁”。

我们真的很忙吗？

博客大巴，你的个人传媒早班车

2009 Away Day

dreamhead — Sat, 31 Oct 2009 22:43:12 +0800

这是一篇欠帐，因为Away Day是上个周末的事情了。

我很喜欢Away Day，因为：

Away Day是放松，我们可以逃离办公室
Away Day是学习，有各种各样的session等着大家
Away Day是聚会，外国同事千里甚至万里迢迢来参加，出差在外的同事也会回来
Away Day是交流，不同人不同思想在一起碰撞
Away Day是……

遗憾的是，去年因为经济的原因，Away Day取消了，一年之后，当Away Day再次有机会重现江湖的时候，我充满了期待。不同于两年前在办公室里“Away”，这次我们真正意义上的Away。

Away Day中一个重要的安排当然是一大堆的session，这是一个非常好的学习机会。我的immersion同学Ola Bini这次来到中国，参加Away Day，他的session是关于下一代JVM，也就是JDK 7的一些发展和变化。对于经常关注业界新闻的人来说，语言层面上的东西没有太多新鲜的内容，倒是Ola对低层实现方面的一些讨论，让人可以更系统的了解JVM的发展。徐X一个关于Scala的session居然听不出和Scala有什么关系，实在是有些过份。徐X借着这次机会，表达了一些他对几种程序设计语言的喜爱，比如Smalltalk，Haskell等等。倒是结束之后，我和我们CTO麦罗聊了一会Scala，我建议他弄个Scala的项目，让大家感受一下。

这次个人感觉收获最大的一个sesion来自我们的老大郭晓，他的主题是关于认知偏见的。我开玩笑的把这个session总结为，如何防止被忽悠以及忽悠别人。自从开始成为咨询师，我就开始对心理学感兴趣，这个session中所讲的东西，我可以很好的映射到我的咨询工作之中，所以，内心会产生出极大的共鸣。事实证明，这不是个别现像，我们后来玩杀人游戏的时候，这些内容左一次右一次的出现在我们面前，于是，杀人游戏又变成了这个session的延续。

好久没有见到我们创始人Roy了，不过，一般情况下，Away Day他都会出现的，这次也不例外。更大的惊喜是，他的老母亲也出现在北京。我们几个同事在交流咨询经验的时候，Roy走了过来，加入了我们。我们把自己之前的一些工作告诉给他，饶有兴致的听完我们的介绍，他认为我们的工作很有趣，建议我们写一本书，把这些经验介绍出来，同时，也建议我们写一个介绍，发给其它办公室的ThoughtWorker，让有兴趣的人也加入到中国这边的咨询工作中来。

Away Day的狂欢出现在我们盛大的Party。这些平时已经很能出彩的家伙还是能玩出更多花样。恶搞了很多人“专业”视频；一群新ThoughtWorker表演《唐伯虎点秋香》；把最喜闻乐见的pair拿出来展现反模式；让Sponsor和Sponsee体验默契；用十分钟创作一个小节目……

Away Day总是让人快乐的！

博客大巴，你的个人传媒早班车

管理问题？技术问题？

dreamhead — Wed, 21 Oct 2009 23:48:19 +0800

产品做大了，人多了，就要分组，有了分，自然还要有合。这是一个产品的两个团队，他们原有的工作习惯是，一旦有工作涉及到二者的接口，两边独立开发，等到完全开发完毕，双方“一起”把代码合入代码库。或许，单看两个团队，问题还不是特别明显。在整个产品中，开发团队有很多，类似的情况在底层团队和几乎所有其它团队之间都存在，而且每个团队都有自己的开发进度，由此，你可以想见，采用这种开发模式，协调各组之间的开发计划到底是一件多困难的事情了。

为什么不能把接口部份先合入代码库，然后，两边一起分别完成各自的工作。经过调研发现，接口中有个双方共用的结构体，在这个结构体中添加一个新的字段，从上层调用者来说，没有任何问题，问题出现在底层。在实现中，会对比这个结构体的长度和从数据库读出内容的长度，在底层还没有实现这个功能时，数据库内容的长度和结构体的长度肯定是不一样的，而这个不一致会导致整个系统启动失败。这是双方不能独立工作的真正原因。

上面的原因看上去很合理，但放到一起，却给人感觉那么奇怪。因为添加一个字段，导致系统无法启动，所以，两个组要把代码攒到最后一次性提交，所以，计划很难协调。

为什么双方要依赖于同一个结构体呢？从直观的想法来看，两个部份用到是同样的结构，使用同一个结构体就无可厚非。但结果告诉我们，这样的做法是有问题的。一个改进方案是，上层代码做一层封装，把底层代码隔离开来，这样，上层团队就可以单独开发，不再依赖于底层团队的开发进度，之后，当二者都完成开发时，只要把这一层封装稍做修改，二者的工作己可以连接到一起。

这是一个常见的手法。比如，Java项目经常会用到一些开源库，我们并不会让程序的所有部份都直接依赖于这个库，而是要做一层封装，这样，哪天我们打算换掉这个库的时候，只要改掉这层封装就可以了，其它部份完全不需要修改。

设计的一个作用就是解耦。解耦一个表现就是要区分出内外。或许，在整个产品的范围内看来，他们都是“内部”，但是由于跨越了不同的团队，实际上，他们并不是“自己人”。所以，彼此分离才是一个正确的选择。这样一个设计上的改进，解开的不仅仅是代码之间的耦合，也是两个团队开发进度之间的耦合，二者不再需要等待对方，只要把自己的工作做好。唯一需要协调的点，就是最终的集成，但这个点并不影响团队的开发进度。

初看起来，这是一个管理问题，但真正的问题其实是设计，而这只是一个例子。

博客大巴，你的个人传媒早班车

捏软柿子

dreamhead — Wed, 14 Oct 2009 22:08:52 +0800

或许你不知道，那些在项目组里面耀武扬威的家伙，可能是客户眼中的软柿子。

有一个很大的项目，负责与客户接口的有三个人，大多数需求都是从一个人那里进来的，因为这个人是最好说话的。结果是，本来可以顺畅运行的项目，由于需求的暴增，导致不得不加班，一个原本运转正常的项目，怨声载道。
一个计划20个点的迭代，迭代结束后，待开发的点居然超过30个。这些需求都是从这个项目负责人那里直接走到待开发的状态，因为每个提需求的人告诉项目负责人的都是这个需求是很重要、很紧急的。结果是，项目组的进度并没有因需求的增加而加快，反而士气受到了打击。
有一个人很好的PM，总是把满足客户需求看作很重要的事，所以，他倾向于接受客户的所有要求。结果是，组内其他有经验的人据理力争，顶住了PM接受客户需求的倾向，项目组一直顺利运转。

这些都是真真切切发生在我的身边，或是我亲历，或是对周边项目的所见所闻。

客户是上帝，让客户高兴很重要。但让客户高兴，并不等于一味的接受客户所有的要求。事实上，你真的这么做了，客户不会领你的情。他会认为你接受他的要求是一件天经地义的事，所以，他会变本加厉的提出更多的东西。一旦成了客户眼中的软柿子，他就会不断的“欺负”。在第一个例子里面，其他两个人不那么好说话，于是，第三个人成了突破口。人都愿意做容易的事，所以，捏软柿子也就再正常不过了。

或许很多人并不承认自己是“软柿子”，但当他们听到“紧急”、“重要”、“有价值”这样的词汇时，他们便迷失了方向，就像第二个例子里面那个负责人一样。但是客户为了强调重要性时，他肯定会这么说。只有剥离这些形容词，才能淘尽黄沙始见金。

团队中的“软柿子”真正伤害的是团队。一般能够和客户打交道的，在团队中都会扮演比较重要的角色。因为他是团队和客户的接口，他在团队内部受到的置疑相对会少一些，所以，他一旦接受客户的要求，多半就意味团队接受了客户的要求。像上面最后一个例子中那样的情况，其实并不多见，这需要团队中有经验更丰富的人。

如果你所在团队有个“软柿子”，你的生活肯定不好受。

博客大巴，你的个人传媒早班车

十一读书行

dreamhead — Fri, 09 Oct 2009 22:53:02 +0800

八天，最长的一次公共假期。回了趟家，幸好飞机上有书做伴，旅程才不显得那么漫长。

书，是很沉的东西，所以，随身带的书轻薄为好。这次陪我回家的是《卓有成效的管理者》。

这本书的英文名字是《The Effective Executive》。把Executvie译成“管理者”，虽不是错，却阻碍了我对这本书的接近，因为我从来不是管理者。其实，这本书是讲如何做事的。对我而言，Executive译成“执行者”或许更贴切一些。

看一下这本书的目录：了解自己的时间用在哪里，考虑自己对外界的贡献，善于利用人的长处，懂得要事优先。这些内容对于非管理者，也是相当有价值的。对于许多自命不凡，却因为得不到赏识而郁闷的程序员来说，这本书会告诉你“到底差啥”。

这本书很薄，一共不到200页，值得从头到尾读一下。如果没时间，抛开第六、七两章关于如何做决策的部份。如果还没时间，就读读第一章和最后一章，因为它们概括了书中的内容。如果还没时间，那真是活该忙死。

回程的路上，在机场遇到了李开复的自传《世界因你不同》，买了一本，继续高空阅读。李开复的文章和书，我是读过好多，在我心目中，他一直是一个良师的形像，所以，很有兴趣了解一下他是如何成长的。

从这本自传，我读到了，一个人的高度，很大程度上决定于他遇到了怎样的人。李开复之所以是现在的李开复，因为他一路上遇到了好多境界很高的人，包括他的父母、导师、在苹果、SGI、微软、Google的各位老板，甚至是帮他打官司的律师。想成长的更好，就要接触更多比自己优秀的人，不只是认识，而是真正的深入接触，比如一起工作。实在没有机会，就读读这些人写的东西吧！

这个十一长假是真正意义上的不虚此“行”。

博客大巴，你的个人传媒早班车

没有困难，制造困难

dreamhead — Wed, 30 Sep 2009 21:45:23 +0800

有困难要上，没有困难制造困难也要上。相声中的段子在软件开发团队中真实的上演着！

改进持续集成

要敏捷，要做持续集成。于是，有人想，如果能够把一些常见的操作（比如编译）替大家做好，省去了每个项目组配置的工作量，那该多好啊！于是，投人投时间，就着CruiseControl改出来一个新版本。

事实是，得到了一个看上去很美的可配置环境，而很多使用这个环境的项目组压根没有一键式脚本，直接把代码提交到进去，交给服务器来处理，顺便说一下，这个持续集成环境几个小时才运行一次，也就是说，写一行代码，也许几个小时以后才知道是不是能够编译通过。持续集成完全起不到应有的作用。

其实，只要把一键式脚本写好，配置持续集成很简单。

编写自动化测试工具

自动化测试很重要。于是，有人想，应该有一个自动化测试工具用来编写自动化测试。于是，投人投时间，编写了一个强大的自动化工具，甚至拥有一个漂亮的IDE。

事实是，这个工具运行起来，基本上需要占据2G内存，而很多开发人员开发人员的机器只有512M内存；编写测试的语言算是一种DSL，很特定于领域，没有人知道怎么用好它；这个为编写测试而生的工具，居然没有常规的Assert，没有setUp和tearDown；开发人员很少愿意用这个工具。

其实，如果用脚本语言封装一下，很多现成的工具和框架都很可以使用。

打造开发框架

重用很重要。于是，有人想，应该构建一个统一的平台，让所有团队采用同样的机制去编写代码，减少开发和维护的工作量。于是，投人投时间，做出了一个开发框架，号称开发团队只要编写少量的代码就可以完成功能。

事实是，一些很适合用B/S结构的应用因为这个框架变成了C/S结构；这个框架采用二进制的格式作为通信协议，让通信过程变得神秘无比；放着许多现成稳定的服务端应用不用，自己编写了一个。

其实，就Web应用而言，太多现成的东西可用了。

博客大巴，你的个人传媒早班车

别急着敏捷

dreamhead — Sun, 27 Sep 2009 23:01:33 +0800

在敏捷中国2009上，有人问了这样一个问题，我们公司实行的是CMMI，我们在这个框架下敏捷呢？

我们怎么敏捷呢？这是许多人曾经问过的问题。很多人之所以问出这个问题，多半是听说了敏捷的诸多好处，然后，心向往之，却不知从何入手。从愿望上讲，这是件好事，追求一些业界好的东西，但你真打算敏捷吗？

大多数想做敏捷的人，都是因为对现状不满。但恐怕他们并没有仔细想过，现有开发过程中存在的问题是靠敏捷就能解决的吗？

市场部门只是扔给开发团队一大堆需求和一个不切实际的deadline，不改变，敏捷也没辙。
进度压力大，团队成员没有时间和精力去学习和思考，不改变，敏捷也没辙。
只关注业务，忽略软件开发技能，不改变，敏捷也没辙。
只关注显式成本（比如硬件投入），忽视隐式成本（比如漫长的编译时间），不改变，敏捷也没辙。
只给开发团队压活，不给开发团队解忧，不改变，敏捷也没辙。
……

你看到了，前面我用了很多“变”。想真正敏捷起来，就要面临改变。

许多团队团队并没有意识到敏捷到底意味着什么，他们指望一成不变，添加几个敏捷实践，就把所有问题都解决了。越是积淀深厚的团队，这几乎就越是一件不可能的事情。

采用一些敏捷实践，也许会让某些团队有一些进步，但我也了解过不少“敏捷”团队，因“敏捷”而痛苦万分，唯一让他们欣慰的是，抛弃了繁重的文档。目前关于敏捷，很多人看到都只是鼓舞人心的一面，也许敏捷的“烟斗”才是最真实的一面。

如果你认为你的团队一切正常，如果你没有准备好承受敏捷带来的改变，别急着敏捷！

博客大巴，你的个人传媒早班车

Hello，Noop

dreamhead — Sun, 20 Sep 2009 21:54:40 +0800

Noop是一门新的程序设计语言，更准确的说，它是一个实验，准备把一些优秀的工程实践集成到语言中，比如依赖注入、测试、代码可读性等等。不过，Noop实在太新了，新到很多东西还没有成型，也不要指望现在就用它来做些什么。但是，翻看一下Noop，还是发现一些有趣的东西。

Noop采用构建系统是Buildr，你可以把它理解成Ant或是Maven。Buildr是Apache的第一个Ruby项目，当然，它主要还是为Java系统服务。对很多项目而言，构建脚本会随着系统的发展逐渐增大，里面逐渐也会出现很多逻辑，换句话说，构建脚本也是程序。这个理念的实践者，对于Ruby项目，自然就是Rake，而C/C++项目，可以选择SCons，现在Java项目有了Buildr。Buildr内置的许多task，在项目不复杂的情况下，只要遵循约定，简单几行代码就可以把构建过程实现出来，充分体现了“易者易为，难者可为”的理念。它甚至还支持生成Eclipse和IntelliJ IDEA的工程文件，省去了自己手工配置的烦恼。

Noop的主要开发语言是Scala。Scala近来的名头越来越响，Java之父James Gosling把它选做Java之外的第一选择，Twitter用Scala改写了一些后端服务，Groovy的创造者James Strachan甚至认为如果Scala早点可用，他就不会去写Groovy。在编译器方面，Scala支持Parser Combinator，为人们提供了从零开始手工编写和用工具（像ANTLR和yacc）编写解析器之外的又一种选择。不过，Noop里面并没有运用Scala的这个方面能力，它用了ANTLR，这也让我们有机会见识Scala的另一优秀之处，在Java类里直接使用Scala类。

具体看一下Ｎoop。打开src/main，里面有三个目录：

antlr，ANTLR的语法文件
noop，用noop实现的标准库
scala，Noop语言的实现

再来看看语言实现，scala/noop目录有几个包：

grammer，调用ANTLR生成的类实现的解析器
interpreter，实现了一个基本的解析器
model，语言的基本模型
types，一些基本类型，可以理解为Noop的运行时。

从现有的目录和代码，我们可以看到Noop还是非常简单的，它甚至不包含生成JVM字节码的部份，而且类型也是最基本的几个。

最后，让我们实际运行一段Noop程序，在此之前，你需要安装Mercurial（也就是hg）和Buildr，对于Ubuntu而言：
    sudo apt-get install hg
    sudo env JAVA_HOME=$JAVA_HOME gem install buildr

获得Noop的代码
    hg clone https://noop.googlecode.com/hg/ noop

clone成功之后，进入到noop目录，构建整个noop
    buildr

如果是第一次运行，可能它会用一段时间下载所需JAR文件，然后，才会执行编译，运行测试等任务。

打包的命令是这样的：
    buildr package

有了生成的JAR包，我们可以运行Noop程序了，这里我们用了Noop提供了一个HelloWorld的例子程序，它位于examples/noop/helloworld/HelloWorld.noop。
    java -jar target/noop-0.1.0-SNAPSHOT.jar HelloWorld examples/noop/helloworld src/main/noop/stdlib

还是那句话，Noop实在太新了，包括目前的命令行都是那么粗糙，它甚至不能加载自己的标准库，需要指定对应的路径。

Ｎoop刚刚起步，对于希望了解语言实现的人，它可以当作一个起步的阶梯。

博客大巴，你的个人传媒早班车

做好一件事

dreamhead — Fri, 18 Sep 2009 23:43:12 +0800

Write programs that do one thing and do it well.

这是Unix的哲学，这个理念同样也可以当作我们日常工作的方式，因为软件开发是一项需要集中精力的工作，我们需要专注。

在一个“矩阵式”管理的企业里面，我们很有可能身属两条线，一方面，在一个项目组里面，另一方面，还归属于一个资源组，这样，做完这个项目之后，作为资源会被调度到其它项目中。在我们为项目组战天斗地的时侯，资源组的领导突然给你安排一个活，请放心，他绝对会告诉你这是一件“很重要很紧急”的事，让你马上处理。要知道，考评的生杀大权可是掌握在资源组主管的手里，除了老老实实完成他交代的任务，我们还有什么更好的选择呢！但是，别忘了，我们还在项目组里面，项目组的活也是要做的。欲哭无泪的我们只能是打碎了牙咽到肚子里，加班完成本该上班时间完成的工作。

这是一个例子。在真实项目里面，我们会被各种各样的因素所打扰，想安静的坐在那里写程序实属不易。对于项目而言，这就是一种伤害。

在这种情况下，项目负责人就需要站出来，扮演过滤器的角色，与各种各样的干扰做斗争，为自己的项目组成员创造一个良好的工作环境，否则，这位负责人就没资格抱怨自己项目进度缓慢。事实上，只要有人站起来，很多情况下，那些所谓“很重要很紧急”的事其实也没那么重要和紧急，也不是非要这个人来做。

屏蔽了外部的干扰，有时侯，我们还不得不面临内部的干扰。内部干扰，自己人给自己人捣乱？不会吧！

遗憾的是，会。比如，在很多传统开发方法的公司里面，任务是靠分配的，也就是在开发的最初，人就知道自己要做什么。有的负责人就会一次性的把多个任务分配给一个人，这样的话，这个人实际上在同时做几件事，很难注意力集中到一点上。在敏捷软件开发中，我们使用Story管理需求，采用主动认领而非指定专人的方式，这样，每个人在做自己当前任务的时侯，都可以非常专注，不必去考虑所谓“下一件事”。

再比如，讨论需求的时侯，做估计的时侯，有人突然若有所得一般，高喊，这个Story应该下一个迭代做吧！这时候就应该有人站出来，告诉他，我们在做估计而非计划。讨论发散可能是我们经常面临的情况吧！如果没有人扮演打断的角色，恐怕除了浪费时间，找不到更合适的形容方式了吧！

相比于外部干扰，内部的消耗可能更不容易注意到，需要我们有更敏锐的观察力。

专注的做好一件事，不容易！

博客大巴，你的个人传媒早班车

敏捷中国2009

dreamhead — Mon, 14 Sep 2009 23:03:12 +0800

当Kent Beck、Dave Thomas和Fred George确定参会，我就对这次大会充满了期待，有机会聆听这些世界级的程序员对软件开发的理解，本身就是一件很难得的事情，更何况，还可以做一些面对面的交流。

Kent Beck这次演讲的题目是《实效的理想主义》。客观的说，单从演讲技巧而言，Kent Beck并不是特别好，而且这次演讲的内容确实有些太哲学化。在听演讲的过程中，不断听到有人在小声的问，他到底要讲什么。对于他演讲内容，我的理解是，一方面，作为软件开发者，我们应该是一个理想主义者，有了一个目标，我们才能不断的提高和进步，另一方面，现实的情况可能会让我们无法一步到位到达理想状态，我们就要以具有实效的工作方式，向理想逐渐靠近。

我早就说过我很期待Dave Thomas的《程序员修炼之道，十年之后》。原本我期望得到的是十年之后的新东西，可大部分篇幅都是在讲十年之后依然适用的部份，比如破窗户、自动化等等。真正提到的新东西非常少，只有动态语言、分布式版本控制和云计算，而且几乎是一笔带过。Dave是一个性情中人，演讲的时候，脱了鞋子站在了讲台之上，他是一个爱家之人，让全场为他老婆高呼“生日快乐”。

Fred George曾经也是ThoughtWoker，所以，对我而言，他也显得格外亲切。在这个到处喊“敏捷”的年代，Fred关于超人的话题把思绪牵回到对人的关注上。很多公司都在努力改造过程，却忽略了对人的关注，Fred告诉我们，想做好软件，人是最大的可挖掘潜力。这是个让我心潮澎湃的演讲。当我以咨询师身份出现时候，客户们都试图了解敏捷“如何做”。这个演讲让我终于彻底想明白，不注重人，再好的方法都收效甚微。所以，敏捷宣言把人放在了第一条。

参加这种大会，很重要的一点就是交流，这也是让我觉得收获极大的原因。遗憾的是，Kent Beck第一天早上讲完，中午就离开了，幸好还有Dave Thomas和Fred George。通过他们的话语，我们可以清楚看到他们对于软件开发的那种热爱，以及对于软件开发技能的重视。第一天晚上的交流活动，我在台下听着他们回答别人的问题是一个很过瘾的环节，对于那些问题，我会有自己的答案，听他们的回答，对比自己的想法，是一个很好的学习思考的过程。

私下里的交流也很有趣，我问了二位同一个问题，《程序员修炼之道》建议我们每年学一门新语言，他们的新语言是什么。Dave的答案是Clojure，我问起他Scala，他说也许是下一门，不过，他说不知道为什么，他并不喜欢Scala的语法。至于Fred，他说自己是个鸽子，会追随Kent Beck、Dave Thomas和Martin Fowler这样的人物，表现得像个十足的追星族。Fred在我眼里，就是个老顽童的形像，可惜，他已经离开了ThoughtWorks，否则，和他结对一定会很有趣。

除了几个主题演讲，能引起我极大兴趣的不多。因为很多演讲是在讲自己如何实施敏捷，我不大需要他们告诉我敏捷是什么，以及如何来做，我甚至可以透过他们的说法发现一些他们在实际操作中存在的问题。不过，我想明白一点，这次大会更多的传达一个信号，越来越多的企业已经开始敏捷了，而且已经有了不错的成效。至于敏捷到什么程度，并不重要，敏捷本来就是为了不断向好的方向前进。

有一个演讲在我看来是最特别的，就是夏洁的《新成员如何快速融入敏捷团队》。这是我第一次听到关于软件开发中“软”技能的演讲。软件开发这个圈子太过注重“硬”功夫，却忽视了软技能。这二者犹如智商和情商的关系，仅仅有高智商并不能带人到达很高的程度。其实，这也是我今年开始逐渐关注的一个话题，因为做咨询的关系，对于“软”技能要求一下子就提高了。曾经和夏洁聊过很多次“软”技能的话题，所以，在我看来，曾经身为ThoughtWorks中国区HR Manager的她是非常合适来讲这样一个话题的。

从大会的内容来看，很多是我以为的常识。不过，当Dave讲那些已经记载《程序员修炼之道》上的内容，有些人如获至宝，当Fred讲起一个函数平均应该只有几行，一片惊叹。我知道，我高估了许多人。

敏捷之路，还很漫长！

博客大巴，你的个人传媒早班车