梦想风暴

上周末，Agile China，因为家里有些事，我没有参加。

作为一个ThoughtWorker，错过这次活动的遗憾并不是像之前以为的那么大。首先，这次活动所涉及到的内容，大多是内部讨论或是讲座涉及到的东西，再有，这次活动做得比较好的地方是很快就放出了活动的讲演稿和视频，所以，可以随后弥补一下错过现场的遗憾。

真正值得遗憾的是，错过了一次与人交流的机会。

有时，我会想，公司为什么要举办Agile China这样的活动。在ThoughtWorks的工作这段时间，敏捷已经成为了一种工作习惯，我甚至不觉得它有任何特别的，对我而言，它只不过是一种恰当的工作方法而已。与很多书上介绍的敏捷方法，几乎没有太大的差别。

最近，一个朋友给我写了一封邮件，给我介绍了一些他心目中应该如何做持续集成，这是他读了一些东西加上了一些自己思考的结果。不过，在我看来，所有这些内容和我日常工作中使用的持续集成差别几乎没有。显然，当这些内容还停留在他思考中的时候，我们已经在实践了。显然，他对这方面的了解还是有些不足的。事实上，这位朋友也很愿意提高自己，只是周遭的环境能够给他的帮助太有限了。

和Darwin聊过，ThoughtWorks带给我们的并不是直接技术上的进步，而是为我们打开了一扇窗。与不同的人交流，会让我们拥有更开阔的视野，总有很多新鲜东西在等待我们了解。

还是那句话，敏捷不过是一种恰当的工作方式而已。对比于所谓的传统开发方式，敏捷给人的感觉是很不同，但如果真正在工作中使用它，消除了它的神秘面纱，也不过如此。但真正有多少人能在工作中使用。它这是一个问题。只读几本书，照着几个实践去做，就“敏捷”了吗？未必。看到很多人在抱怨敏捷，不过，很多说法都是想象或是教条的结果。

公司举办的Agile China实际上是一种经验分享，告诉大家，我们在做什么。正如我前面所说，这些东西其实并不是什么新鲜东西，但对于不了解它的人来说，它就是新鲜东西。

闭塞，是阻碍人不断进步的绊脚石。

bug这种东西，只要存在，早晚会暴露出来，即便是深藏25年。不过，我们了解到的bug大多不具备很深的资历。有些不幸的bug会被QA们扼杀在摇篮之中，稍微强壮一点的也许可以生存到系统发布之后。

拜IE6所赐，我们的系统刚刚上线，便有一个bug浮出水面。经过验证，这是IE6处理直接打开附件（如PDF、PPT等）的错误。不过，好在这是一个广泛遇到的问题，使得这个bug连午饭时间都没有坚持到，便被消灭了。

按照对客户的承诺，我和另外一个同事要在办公室支持到晚上10点。上午的时候，我们的QA和客户努力了三个小时，并没有发现其它问题，于是，我们想当然的认为我们可以按“点”下班。就在我们俩准备收拾东西回家睡觉之前，从睡梦中醒来的客户终于发现了bug。于是，我们只好在深夜来临之际，开始了bug征服之旅。

有bug不是什么坏事，发现总是比不发现好。

在客户和PM压力之下修改代码并不是什么愉快的经历，好在bug们都是一些友好的家伙，很容易就定位到。不过，因为客户在线，所以，必须强迫自己把事情做得尽可能按部就班：本机测试、提交到主干、提交到分支、部署到测试环境……

感谢之前大家辛勤努力编写的测试，让我们很容易就知道自己的修改在系统内会造成怎样的影响。通过所有测试的那一刻，心头如释重负。在这个原本很是紧张的时候，多了一份自信。我喜欢这种感觉，虽然忙碌，但依然从容，一切尽在掌握之中。

这个无眠的夜里，身边还有自己的Pair，有专程赶来帮助我们进行验证的项目组的老大哥，当然，还有一直都很辛苦的PM，一个敬业的团队。

一起想一下，程序发布之前的情形。

印象中，这应该是一个手忙脚乱的阶段，一大群人奔前跑后，忙着处理各种各样的问题，尤其是bug。许多人回忆自己经历的时候，往往会很有成就感的说，在某某程序发布之前，忙了一整夜，终于在程序发布之后，回到家里，一觉睡了N个小时，俨然一副历经沧桑的样子。自己经过的，既有有过连续十几天工作十几个小时，为了赶上发布日的经历，也有连续几个熬到后半夜改bug的痛苦。虽然这些都是不错的日后谈资，但当时，那是透支的感觉。

现在，我在等待发布。

是的，等待！

Story的开发工作早就已经完成，bug修改也到了尾声。代码已经冻结，Mingle上可供开发的卡已无踪影，有一种闲暇无聊的感觉。

这已经不是第一次体验发布前的闲暇了。记忆中，最近做过的几个项目，到了最后的几天，都会出现无卡可做的情况。最极端的是有一次，在PM的陪伴之下，打了多半天的游戏。

对比之前的经历，这样的经历显得很特别。原本在我的印象中，越是临近发布，应该越是忙碌，而这种一下子闲下来的感觉，真的是让人有些不适应。

这个时候，PM就成了给大家找事的人。比如，他会组织大家进行一些讨论，看看之前那些做得好，做得不好，以便在后续的工作中进行改进。比如，他会把一些属于下一个阶段的任务拿过来，让大家分析一下，提前热热身，有些手快的家伙，甚至会顺便把一些任务做完。

这样难得的清闲，多半要归功于合理的计划和控制。其实，想想之前的经历，最终期限并不是合理规划出来的。事实上，大多数情况下，对于要做什么，以及这些工作的工作量究竟有多大，并没有很好的估计，所以，往往就是指定一个发布的日期，剩下的就是靠人了，其结果就是为了赶上发布日期，拼命的加班加点，那种透支需要很长一段时间才能恢复过来。

而现在做项目，所要做的一切都是经过大家一起估计出来，包括客户和开发团队，大家对于软件开发的实质认识得比较清楚，所以，不会做一些杀鸡取卵的事情，于是，所有的一切，都会按照预期一步步进行：开发团队也不会为了追赶进度，而损失了软件的内在质量；客户会重新认识他需求的价值所在，做好优先级排序，而不会不明就里的要求全部完成。这是一个合理的开发过程，一种软件开发应有的状态。

准备发布了！

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

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

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

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

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

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

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

又到周末了，由于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就完成了。

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