梦想风暴

这是一个全国哀悼的日子，为那些在地震中逝去的生命。

关于地震，我一直想写点什么，又不知从何下手，因为我着实不是一个愿意记录悲伤的人。但我还是决定写一些东西，让思绪飘散一下。

这注定不是一个平静的年景：雪灾，火车相撞，地震。国难让中国人空前的团结起来。

对我而言，今天也是姥姥过世三周年的纪念日。我是姥姥一手带大的，对姥姥有着深厚的感情。所以，我深知亲人离开的痛苦。地震让那么多人失去了亲人，对于活着的人，那是一种折磨，无论你怎样的坚强。

和老妈通电话，她对于地震的记忆要比我深刻，因为75年的海城地震和76年的唐山地震，对于家里都是有影响的。因为曾经离地震很近，所以，她更知道今天的地震意味着什么。

地震时，我以为自己眩晕，后来，才意识到不对，但也并没有往心里去，因为念高中时，学校离矿区很近，矿里放炮的时候，就会感到楼在晃。当我得知地震发生在四川，北京可以感到明显的震动，我知道这会是一场灾难。

其实，最近一段时间，我有意无意在回避关于地震的消息，因为我知道，那些消息会让自己心痛。

有人以为，有些公司或个人捐款是在作秀。如果真是这样，我希望这样的秀越多越好，只要是对灾区有益的。

默哀那一刻，站在办公室里，耳边是响亮的喇叭声和警报声，思绪是混乱的。

自然面前，人很渺小。这是我写在自己饭否上的一句话。渺小的一方，价值何在？在抗震救灾的过程中，一个个感人的故事给了我们答案：人性的光辉。

今天到CSDN参加了一个关于开源的讨论，谈到了自己参加开源项目的感受，也谈到了公司的一些情况。关于自己的部分，前前后后在blog里提到了不少。这里稍微整理一下自己对公司开源情况的一些理解，不见得完全正确，只是基于自己看到的和理解的，如果哪位同事觉得不对或不足，不妨站出来纠正或补充我。

ThoughtWorks是一个咨询公司，这意味着我们有很多机会参与到不同领域的开发之中，也就让我们的经验可以得到不断丰富，更重要的是，我们有机会知道哪些经验是可以复用的。一些可以被复用的知识就在开发过程中被识别出来。ThoughtWorker们是一群愿意不断把事情做得更好的人，于是，就会有一些人把这些可以复用的部分提炼出来，将其开源，把这些知识分享到给社区。据说，CruiseControl、RubyWorks就是诞生自ThoughtWorks的实际项目。

ThoughtWorks最有价值的部分是人。和这样一群人一起工作，只要你把自己的想法抛出来，就会有人愿意与你讨论。相信大家都有类似的经验，很多时候，自己想一个问题很容易走进一个误区，而和别人稍微讨论一下，即便这个人的言论本身并不能给你带来太多的价值，但这个讨论的过程会让自己的思路逐渐清晰起来。ThoughtWorker们是一个巨大的思想来源，这样一群人之间的讨论经常会激荡出各种各样的火花。一个业余的例子是上周五下班之后，一群人玩编故事的游戏，其结果是包括周边的人在内，大家都已经乐得直不起腰了。

开源，需要一个环境。如果周围的人都在做开源，自己就会以为开源是一件理所当然的事情。列在公司开源网站上的项目，其实那只是一些比较知名的项目，也是冰山一角。平时，不经意间和某个人聊天，你就发现，原来身边的这个人正在做一个开源的东西。大家在一起讨论的时候，也经常可以听到这样的话，那就不妨开源一下试试。陶公子最近发起了一个关于Domain Model的讨论，我就对他说了类似的话。

公司内部有一个Innovation Community，也就是说，公司是鼓励大家进行创新的。经常会收到公司内部关于Innovation的邮件，介绍一些最近一段时间有人做的一些事情。其中很重要的一环就是一些ThoughtWorker新近发起的一些开源项目。gigix最近就在一次Innovation Community活动上，介绍了fluorida。

如果一些开源项目能够证明自身的价值，公司也是愿意投入一些精力将它完善。Selenium和CruiseControl就是这样在ThoughtWorks的协助下，得到了快速的成长。当然，不只是公司员工的项目，对于一些其它有价值的项目，公司也会投入一定精力去做，比如Ruby和JRuby。

有了这样的土壤，开源也就变得自然而然。

敏捷软件开发中，与客户的沟通是一项必不可少的内容，因为只有客户才知道他们自己想要的是什么，只有他们才真正了解自己的业务流程。于是，在ThoughtWorks，客户来访是很常见的，这不，我们的客户今天就来了。

一大清早，客户就到了办公室，他们给我们做了一个关于项目的介绍，让我们有机会聆听一下真正使用这个系统的人究竟如何看待这个系统，他们为什么会有这样的业务流程，在他们看来，哪些东西才是最有价值的部分以及他们希望这个系统未来会在他们的工作中起到怎样的作用。虽然在这个项目也工作了一段时间，但我也只是知道有哪些东西，对于为什么是这样，完全没有概念。今天客户的到来算是给我们补上了欠缺的一课。

对于开发者而言，客户到来的作用很直接的体现在某些细节问题的确定上。通常，我们有了问题会问我们的BA（业务分析师），但BA不能给出答案的部分，就只能等待客户的回答了。原本因为时差的关系，一旦涉及到客户，这个过程至少需要一天。而如今客户就在身边，一旦我们有了问题，几乎瞬间就可以得到解决，开发周期大大的缩短。当然，客户不会一直在这里，所以，趁着客户在的这几天，我们要充分发掘他们的作用。

以前也曾经历过客户到来，但这次给我留下的印象却特别深刻。因为，客户让我们近距离的接触到他们的业务。

我们的项目是一个关于宾馆审计的项目，简而言之，有人制定标准，有人按照标准进行检查。虽然听起来很简单，但是系统里面的概念却离我们很远，很难想象究竟是什么样子的。今天，客户就带着我们亲身体验了一下做审计的感觉。

我们去的是客户旗下的一家五星级宾馆，宾馆的总经理带着我们在宾馆内部进行参观，过程之中，还为我们解释了很多真正的检查过程中会出现的问题，在这个过程中，一个个曾经因为写程序而听说过的名词不断的出现在耳边，那个曾经遥不可及的概念，一下子变得异常清晰。上午的讲解和晚上的参观让这个系统变得更加真实了。以前只是住过宾馆，还从来没有从其他角度想过问题。今天的参观，明显是抱着“找茬”的心理。顺便说一下，我们的“审计”还真起到了一定作用，有人在宾馆的游泳池边上的宣传牌上发现了错别字。

客户到来，还有一个很直接的好处，那就是，给了我们一次team building的机会。即便单从这个角度说，我们也总是欢迎客户来访的。^_^

谁是最受程序员欢迎的雇主？

一篇关于最佳雇主的帖子，很高兴在里面看到了ThoughtWorks的名字。

很快，成为ThoughtWorker就要满一年了，这一年时间里，我一直享受着在ThoughtWorks工作的乐趣。确实，它和我之前工作的环境差别很大：开放的工作环境、没大没小的工作关系、不利于保持身材的零食、需要排队的游戏机等等。这段时间一直在考虑一个问题，对我而言，ThoughtWorks到底好在哪里。思来想去，我的答案是人文环境。

依然记得当年，我在当时的部门里发邮件尝试与大家讨论技术，应者寥寥；
依然记得当年，有人劝我放弃所谓新鲜想法，老老实实走在原来的道路上；
依然记得当年，有人对我说，只有做管理才有更大的价值，怎么你对管理一点兴趣都没有；
依然记得当年，我们把“以人为本”作为笑话来听；
……

我也依然记得，当年选择软件开发作为职业是因为热爱；
我也依然记得，当初遇到Darwin点燃了我对技术的热情；
我也依然记得，在本应完成一个功能的时间里完成整个系统重写的快感；
我也依然记得，修改别人留下的bug缠身的程序直至深夜；
……

用了自己职业发展的最初几年，我逐渐清晰了自己在职业发展路上的追求。我会努力走在自己预期的路上，如果环境不能再给予我所需要的，我会寻觅其它的环境。

在这里，我得以继续走在技术的路上；
在这里，身边有一群有想法的人，让讨论可以深入下去；
在这里，总有人能在不同的角度给你一些新鲜的东西，让我不得不偷偷去补各种各样的新知；
在这里，可以和有很多年的工作经验的人一起工作，学习他们解决问题的思路；
在这里，完成功能绝对不是开发的终点，大家总是竭尽所能让程序看上去更清晰；
在这里，关注用户价值会成为程序员也要思考的问题；
在这里，我有机会体验不同的角色；
在这里，我终于弄清楚了leadship和management不是一回事；
……

幸运的是，我坚持了自己的选择；幸运的是，我成为了ThoughtWorker。

又到周末了，由于CodeJam的原因，这已经是我连续第十二天的工作了，有些许疲惫。在这个即将到来的周末，要好好让自己放松一下。

这周开始了一个新的项目，一个Ruby on Rails的项目，一个让我期盼了很久的项目，也是我之前学习Rails的最重要原因。不过，Rails是我最近的blog中出现频率很高的字眼，所以，我并不打算在这里聊Rails的话题。

既然不谈技术，那就不妨聊一些与自己之前做项目不同的体验吧！

在我们这里开发的准确的说是这个项目的第二阶段，也就是这个项目已经有了很多东西，之前这个项目是由美国那边的团队来做，所以，我得到了一个观察国外的ThoughtWorker如何做事的机会。原来参与过的项目里面，更多的是中国这边的ThoughtWorker，所以，我饶有兴致去观察一下二者之间的差异。由于参与这个项目的ThoughtWorker大多是有经验的开发者，所以，很多方面做得成熟许多。

这个项目的自动化程度很高，显然，这些ThoughtWorker在开发之初做了很多工作，把许多可以自动化处理的部分都放到的Rakefile里面。所以，我们得以把更多的精力放在开发本身上，少了很多繁琐的操作。一个简单的例子是，我们提交代码只要简单敲一个命令，首先会到SVN进行更新，然后重做数据库，运行测试，随后，把增加的部分找出来添加到SVN中，最后，它会问我们Pair的人，Story的编号，以及做了哪些工作，以便生成SVN提交的日志。和大多数自动化的工作一样，这些工作本身没有任何技术难度，但有了这些之后，我们可以少敲一些命令，更关注开发本身。其实，之前的几个项目也有一些自动化，比如用Cruise Control做持续集成，但这个项目应该是我经历过的自动化程度最高的项目，差不多常见的重复性工作都自动化了，看看那长长的Rake任务列表便可见一斑。

每天早上，Standup之后，我们会把所有的Dev召集到一起，一起来看一下昨天的工作。我们用SVN diff把代码的差异列出来，大家一起来过。如果恰好是自己做的代码，编写代码的人就会站出来，为大家简单解释一下做了些什么。这样，这样保证大家都会了解到项目的进展。这样做还有另外一个原因，因为我们是一个分布式团队，除了我们在中国这边，还有几个人在美国开发，这样过代码，便可以大致了解到美国那边在我们睡觉的时候干了些什么。

这个项目还有一个做得我觉得不错的地方，就是Story做得很细致。我们在Mingle里面的Story，很多都会有完成这个Story要做哪些步骤的描述。我们只要按照这些步骤一步步做下去就可以了，每完成一个步骤，就做一个简单的标记，这样，几乎不会有遗漏。除了Mingle上的Story，我们还会有专门的文档对这个Story进行比较详细的解释，包括一些验收条件。显然，这个项目的BA做了大量的工作，让我们后续的开发更容易。

这个项目从美国过来了一个BA和两个Dev，而Pair的过程，让我不得不每一天都以英语进行交流。私下里，我经常说，我的英语水平代表了TW的最低水平。当年面试的时候，我自认为表现的最差的就是结对编程，因为一个英国同事高高兴兴搬了把椅子做在我边上，害得我不得不英语解释我在做什么，思路一下子就乱了。不过，少了面试的压力，这时候和人用英语Pair，效果还算可以接受，至少我还可以思考。实在不理解的，就让自己的Pair多解释几次，好在ThoughtWorker们都是很好的人，我的Pair总是不厌其烦的为我解释，直到我确切的直到了我们要干什么。

在这个项目里面，我很高兴的扮演起学生的角色。一方面，我们不是很了解需求，需要向“过来人”学习，另一方面，来这边工作的两个Dev确实都有很长时间的工作经验。和他们在一起工作，我乐得把控制权交到他们手上，自己虚心的观察他们如何思考，如何解决问题。和他们在一起工作，会让人感觉很放心。正如我在《与高手共事》中提到的，他们做的那些工作都很简单，经过一步步简单的工作，一个个Story就完成了。

对我来说，这个项目才开始一个星期，已经学到了不少的好东西，值！