• 之前做咨询那个团队的领导在我们离开之后,在公司内部做了一个演讲,分享了与我们合作的那段经历。听很多人评价过,那是一段非常振奋人心的演讲。

    时隔许久,我终于有机会,看到了这个演讲的PPT。一页页的翻看着这个PPT,回想起当时合作的一幕幕,仿佛就在昨天。站在旁观者的角度,这篇PPT也看得我热血沸腾。合作的时候,我们一直认为这位领导是一位才子。这篇PPT加深这种印象。

    这篇PPT给我留下最深印象的是一条烟斗型的曲线。这条烟斗型曲线是,他们对敏捷认识的心情曲线。

    最初,由于项目存在各种各样的问题,当他们听说了敏捷,一下子就把胃口调了起来,所以,当咨询师来到这里的时候,大家的心情相当的高涨。似乎曙光就在眼前,咨询师的到来很快所有问题都会一扫而光。

    随着与咨询师交流的深入,无情的现实逐渐将这些高涨的情绪打击了下来。咨询师让大家更清楚的认识到了目前的状况。

    真正选择了试点项目组,越来越多的实际问题暴露出来,那些预期很快完成的功能,因为这些问题的暴露,加之一些寻求解决方案,久久不见任何进展。但是,变化在暗流中涌动。站在领导的角度,不见任何交付,可想而知,领导是什么心情。领导试图用原有的方式去指导团队,但团队已经见识到了新的工作方式,不愿意退回到原有的工作方式。

    领导感觉自己对团队失去了控制,甚至暗下决心,等到咨询师离开团队之时,要好好教育一下这个不知天高地厚的团队。对于敏捷,领导的心情到达了谷底。

    就在领导的内心开始放弃敏捷的时候,事情开始出现了转机。随着问题一个个的得到克服,团队逐渐回到了正常开发的轨道上。功能一个又一个的完成,经过测试,发现质量要比之前高了很多。

    原本已经在内心放弃敏捷的领导,在实际的工作成果面前,心情开始逐渐好转。领导开始怀疑自己之前的质疑是否有道理,为了更好的理解所发生的一切,领导开始和咨询师们做起了更加深入的交流。随着交流的深入,领导越发明白了项目组那一段黑暗时期到底发生了什么,原本自己引以为豪的产品质量原来是那么的脆弱,为了修正这些“敏捷”之外的问题,耗去了大家大量的时间。在交流过程中,领导对于敏捷到底意味着什么,也有了一个更加深入的理解。

    当领导越来越认同敏捷,敏捷也就在越来越多的团队实践开来。有了先行者的经验,后来者就可以很容易的将一些现成的方案借鉴过来。不过,客观的现实是,因为没有咨询师的参与,很多方案在应用的过程中,还是有一些走形的。

    随着更多团队开始敏捷实践,曙光逐渐的显露出来。加之后来,咨询师同团队一起协作做了一些更加深入的探索,敏捷实践向深入迈进了。领导看见了进展,对敏捷的信任增强了。同时,也看到了更多的问题,但有了继续前进的勇气。

    这就是“烟斗”的来历,在初始阶段,对敏捷的心情由于迟迟不见结果,而迅速下降,在就要彻底放弃之前,慢慢出现转机,一点一点提升着。虽然用了很长时间,心情才会回到最初的状态,但相对于最初的盲目,后来是脚踏实地。

    任何一个准备实施敏捷的团队,尤其是那些背负着厚重历史的团队,这个“烟斗”是一个需要面对的过程。

  • 2009-07-31

    回头读书

    做程序员这些年里,读了许多书,经常大言不惭的对别人说,某某书,我哪哪年就已经读过了。

    是的,很多书,我许多年前就读过了,不过,随着时间的流逝,这些书留在脑子中似乎只剩下名字。

    回想起来,很多书当时只是把字读了一遍而已,碍于当时的经验,很多观点并不能很好的理解。读过之后,我也承认书是好书,但多大程度上理解了这本书,就需要打上一个大大的问号。现在看来,对于很多内容的理解是非常浅薄的,这也是留在脑子中东西不多的原因之一。

    所以,我打算重读一些好书,以现在的理解,去重新品味这些好书。因为是已经读过的书,我很清楚哪些值得重新翻阅。

    在我看来,对于读书而言,真正能够理解书中内容的状态是,你已经理解这些内容。

    这个说法看起来很奇怪,很多人是希望向书学习。在“无知”的状态下读书,如同走在一个陌生的地方,一路走过去,我们会只关注自己的“目标”,于是,路边的风景就错过了。当我们这个地方有了基本的了解之后,闲暇四顾,也就有机会发现许多曾被我们错过的景色,对这里也就有一个更深的了解。

    重读那些好书,作者似乎不再是高高在上的老师,而变成可亲的朋友,我也得以更加客观的品味他的观点。对于那些不年轻的好书而言,我也可以看见一些时间带来的不足。比如,在《程序员修炼之道》关于源码控制的部份,缺少对分布式版本管理的介绍,对于持续集成的理解也有不正确的地方。基于这样的原因,我对于Dave Thomas今年在Agile China上的发言《程序员修炼之道,十年之后》充满了期待。

    新书旧书都要读,时间成了稀缺资源。

  • 不知道从什么时侯开始,周边的人把我当作一个老手,尽管有些自己不那么情愿,但现实是和我在一起工作的人大多比我工作经验少。

    新手之所以为新手,是因为他们的经验较少,所以,不可避免的会犯一些错误。记得别人还在用新手标准要求我时,有一次出差,到了现场,项目负责人要我去安装我们的程序,可我根本就没把我们的程序带来,结果可想而知,项目负责人劈头盖脸的把我骂了一顿。

    换我扮演老手的角色,我会尽我所能把项目中的一些不确定问题解决掉,然后,让新手们去解决那些确定性问题,通常,他们的能力应对这样问题会游刃有余。最近一年多的项目里面,涉及到了很多探索新技术的工作,我会从项目中挑出一个最简单的情形用新技术实现出来,这个例子可以帮助我弄清楚技术背后的来龙去脉。之后,我就可以把他解释给其他人。我的同事们都很聪明,理解了基础结构,加上一个现成的例子,他们就完全可以继续进行下面的工作了。

    或许单独看起来,我的做法并没有什么特别的地方。刚好最近项目里面有两件点要去探索,我自己做了一个,把另外一个分给另外一个同事。他很快就做完了,而就是这个最简单的例子,我也做了好几天。探索的工作结束,进入到正式的开发工作,其他同事很快就可以接着我的工作继续开展。就是这个最简单的例子,除了了解技术的目的之外,我还写所有相关的脚本,万事俱备,只欠东风。而当我了解另外一个同事的工作时,我发现,他真的只做了一个最简单的例子,了解了一些基本概念。真正把这些内容运用到项目里时,左一个困难,右一个麻烦相继出现,我陪着他一个个克服了这些点,又把脚本预备好,几天之后,才真正进入到可以开发的状态。

    有人曾经问过我,你把有趣的工作都做了,把无聊的工作留给别人是不是合适呢?毕竟每个人都希望在项目中成长。前面说过,我的工作是削除项目中的不确定因素。是的,很多人喜欢的就是解决不确定问题带来的快感。但不确定对每个人来说是不一样的。只要最基础的例子跑通了,这项技术的不确定性对我而言就解决了,但实际上,在具体使用这项技术中还会有一些不确定的问题等待解决,解决这样的问题,同样可以提高。

    谈到成长,每个人都希望自己能够不断的成长,但是,即便是做同样的项目,每个人得到的机会也是不一样的,这样的差异实际上对应着各人不同的表现。和其他人一起工作的过程中,通过观察,我会把不同的工作交给不同的人来做。像前面说的那个同事,我之所以肯把一个探索的机会交给他,是因为他在之前的工作中表现出的态度和能力,虽然他的探索并不完全令人满意,但是,有了之前的信任,我会告诉他,怎么做才会做得更好。

    之所以会想起这个话题,是因为一个同事与我聊起他项目焦头烂额的状态。他在那个项目组中,扮演着和我类似的角色,他感觉自己做得非常累,项目进展也有些问题,于是,我们俩聊起了如何发挥其他人的作用,既让新人感觉自己得到了锻炼,也让自己轻松一些。

  • 2009-06-19

    月度演讲

    RubyConf China,我认识了Robin Lu。我们俩有种一见如故的感觉。我半开玩笑的对他说,有机会请你到我们公司讲点东西。

    回到北京,我向老大汇报RubyConf China情况时,提到了这句话。老大说,我们不妨建立一个Monthly Speaker制度,每个月从外面请一个人到公司来讲些东西。

    Robin Lu有着很强的分享精神,于是,他成了我们的第一个Monthly Speaker。

    今天,我们第一次月度演讲,主题是iPhone开发故事。

    Robin Lu为我们分享了他自己从事iPhone开发的一些经验。从他了解iPhone开发到成为一个iPhone开发者,再到,他将自己的软件放到AppStore上销售。最后,他又分享了自己对于iPhone开发的一些建议。中间很多的故事,只有亲身经历过的人才能讲得出。

    一如既往,Robin Lu的演讲是那样平实,那样吸引人。他不是那种靠技巧取胜的演讲者,但他却很能抓住听众,凭借的就是内容。他留给人的印象是含而不露,没有咄咄逼人的气势,但却可以把问题深入的讨论下去。

    Robin Lu为月度演讲开了一个好头,我开始期待后面的Monthly Speaker。

  • 此刻,我,在上海。

    距离上次离开上海还不到两个月,之所以重返大上海,是为了RubyConf China。

    刚听说RubyConf China要举办的消息时,我就在想,找个怎样的借口才能到上海参会。所以,当我们负责市场同事找到我,说需要一个演讲人的时侯,我毫不犹豫的就接受了任务。

    接受任务是喜悦的,完成任务却是烦恼的。先是gigix和WPC讨论演讲的主题,最终定下分享我们在Ruby项目的一些经验,接下来,就是具体的准备了。每次准备演讲对我来说,都是一个痛苦的过程:一方面,我希望自己的演讲对听众来说,有一些价值,另外一方面,我还要保证思路顺畅,不让人感到突兀。这一次的准备,尤其困难,因为得到确切消息距离大会只有一个星期了,而且我还在项目上。感谢gigix和WPC等人,在他们的帮助之下,我对要讲的内容逐渐有了一个更加清晰的认识,也是因为如此,演讲稿也迟迟达不到可以拿出手的标准。负责联系演讲者的Daniel几次催我提交演讲稿,我何尝不想啊!演讲前夜,我依然在不断修改。

    这次RubyConf China最大的主角,自然是Ruby之父Matz先生。从他进场时那经久不息的掌声中,就可以看得出他到底有多受欢迎。他的演讲《Why Ruby?》介绍了他开发Ruby的一些历史,以及他在设计程序设计语言的一些考虑。很多想法也与我的一些观点不谋而合,听得我频频点头。Ruby原来是一个失业者的产品,时值日本经济不景气,失业在家的Matz利用这段难得的空闲,写出了Ruby。另一个失业者著名产品BT。很多人内心难以接受的失业原来也是一个巨大的资源。Matz说,如今这样一个不景气的光景,说不准就会产生出下一个影响深远的语言。

    借助演讲者的身份,我让会议的组织者引荐我认识了Matz。时间关系,我只和Matz做了一个非常短的交流,介绍了自己在Ruby实现上的一些工作,算是和Matz彼此相识了。最后,我邀请Matz到我们的北京办公室去做客,Matz欣然应允,“只要你们邀请我就好”。

    这次大会的内容还很扎实,robbin的《JavaEye网站架构深度解密》和robinlu的《Ruby and Rails Pitfall》是两个亮点,拳拳到肉。只有真正的经历过这样的问题,才能讲得出这样的话。从演讲技巧上来说,他们两个都算不上优秀,但扎实的内容让人已然忘却了外在,全心全意追随他们的内在。

    koz的《岛根县政府的挑战 - 在日本地区政府和社区当中使用Ruby的案例》是一个介绍,让我们了解Ruby在日本的发展,很开眼。让我惊讶的是,他——一个日本人用中文完成了整个演讲。Ruby的流行程度超乎了我的想像,可以说Ruby教育,从娃娃抓起。原来,岛根县就是Matz居住的地方,岛根县对于Ruby的推动,让我想起了鸟山明,政府为了让他送稿方便,而修了一条高速公路。

    其它几个演讲带给我的冲击相对来说要小得多。至于我自己的演讲,留给别人评价吧!

    最后的Q&A环节,说实话,我更想坐在下面做一个可以提问的听众,而不是一个回答问题的演讲者,因为对于其他人的演讲,我还是希望有更多的交流。在这个环节中,有一个人用日英中三种语言提问,成了大家关注的焦点。

    整体来说,这次RubyConf China还是很成功的,考虑到组织者只用了一个月时间,这样的结果已经让人非常满意了。robbin说,争取下半年在北京在办一次。北京的Ruby开发者们,期待吧!