• 2012年时,我写过一篇blog,谈到了加入项目时,如何了解一个项目。

    当我加入项目时,我要了解什么

    最近在客户现场做咨询,有人跑过来,问了我同样的话题。经过简单沟通,我发现他真正的问题是,为什么我们作为一个外来人可以很快地上手他们的项目,而他们自己的新员工却很长时间才能上手。

    这是一个很有趣的问题。

    正如我在前面那篇文章里写到的,通常我加入一个项目,我首先要获得这个项目的大图景。作为一个ThoughtWorker,我一定会了解这个项目业务价值,它要解决的问题是什么。即便是技术,我也会尝试先从架构入手。等有了大图景,具体到一个问题时,我就知道它在整个项目中,是拼图的哪一块。

    对比而言,客户的很多新人加入一个项目时,常常是试图从一个具体的问题着手,在解决问题的过程中,有太多小障碍了,每次遇到的几乎都是一个全新的问题。所以,几乎就是一路磕磕绊绊。当然,这里不排除我比客户的大多数新人工作经验丰富,所以,对于大部分技术理解能力要比他们好。

    我看到的另外一点大的差别是,我了解项目时,我会按照自己的思路,通过问题,一步步将项目分解开来,也就是从业务到技术,从大框架到小模块。通常,只要与我交流的人对项目足够了解,基本上,我都可以把项目大致梳理出来。

    相较而言,一些新人的接收模式是,等着别人按照他们的思路来介绍。以我和许多客户的合作经历来看,大多数经年累月的项目往往是不足够清晰,甚至是相当混乱的,在这个项目上长时间工作的人也很难把它梳理得很清楚,所以,指望他们把项目介绍清楚只能祈求好运了。前面那篇文章我提到过,许多人是把业务和技术混在一起的,这是我经历过的实际情况。

    除了按照上面所说的方式理解项目,之所以会给人一个很快上手项目的感觉,可能还有一点:使用“行话”,也就是客户他们常用的术语。与人用“行话”交流,往往会更容易建立彼此的信任,也会让人认为你对交流的东西很懂行,这或许算是附赠的技巧吧!

  • 第三次踏上澳大利亚的土地,前前后后在墨尔本和布里斯班两个城市的时间超过了两个月。

    或许是因为设置了正确的时区,澳洲一般都亮天很早,所以,这里适合早睡早起。一般说来,这里的人上班也很早,朝八晚五。

    不过,对于很多人来说,如果不是有什么特别情况,每天上班的第一件事并不是急冲冲地开始工作,而是买上一杯可口的咖啡,三五成群在一起聊聊。就我合作过的一些客户来看,他们对咖啡的喜爱甚至到了让我不能理解的地步,即便办公室的厨房里就有现成的咖啡机,很多人也会选择到楼下的咖啡店里去买一杯新制的咖啡,因为在他们看来,咖啡机里出来的咖啡口感上差太多。当然,一路上聊聊天也是咖啡文化重要的一部分。作为一个中国人,我难免会被问到茶的问题:不,我们中国人喜欢喝茶,但绝对没到你们这个份上。

    澳洲人的工作节奏,在我看来,绝对算不上快,与不少人一起结对写过程序,却极少见出现匆匆赶工的现象,更多的是按部就班地一点点来做。但不得不承认的一点是,虽然节奏不快,但做事的质量却是相当高的,各方各面的细节几乎无一照应不到,而且即便脑子里很快就有一些直接的解决方案,他们也常常会停下来,找找更能体现所用框架、工具、语言味道的实现。所以,几乎在代码里出现的,差不多都算得上这个东西的最佳实践了。

    还有一点,他们对于命令行的熟悉是很令人惊讶的。几乎每一个人,都对命令行操作很熟悉,即便是在Windows开发,也必然会按照一个像Cygwin这样的东西。每每结对,我几乎总能看到一些我之前没有尝试过的一些细节。与他们一起结对,我通常都会全神贯注,充分调动自己的经验,这样会很累,但以这种方式写程序却是一件非常快乐的事情,结对的双方都能在这个过程中从对方身上学到很多东西。

    澳洲有很多人喜欢运动。无论是墨尔本,还是布里斯班,都有一条河穿城而过。清晨,河边就是人们的运动场,跑步或是骑车的人很多。骑车或跑步的人也不在少数,大街上常常见到许多背着背包的人飞驰而过。有上下班运动的,也有选择中午运动的,有人专门中午要出去跑上五公里,再回来继续工作,还有人会组织中午到邻近的草坪踢球,无它,只为锻炼。所以,这里的一些公司专门备有洗浴的地方,提供给那些喜欢运动的人。

    对于很多像我这样的中国人,出到国外,最大的难题恐怕都在英语上。其实,在澳洲,汉字和亚洲面孔还是可以经常看到的。记得有一次和一个来澳洲看孩子的阿姨聊天,虽然不会说英语,但她在这里的一段时间,基本上还是可以很好的生活。单就学习英语而言,我曾经和一个印度同事聊过,他说,其实他们的母语也不是英语,也是要学英语的,只不过在国内的时候,经常有用到,因为不同地区的方言不一样,只能用英语交流。想把英语学好,只能是多说多练。从这一点上来说,还真要感谢ThoughtWorks。加入公司之前,我的英语水平就只能说一些简单的句子,现在可以与人闲聊,如果再写简历的话,我完全可以厚着脸皮写上“口语流利”了。想来,每次出国英语都是一次提高,就是这么一点一点积累的。

    或许,这就是ThoughtWorks给大家提供的平台,让我们不再把自己局限在一亩三分地,而是向世界学习,所以,作为一个ThoughtWorker,我们停不下来。

  • 在ThoughtWorks里面,我经常有机会在不同的项目组间轮换,所以,经常会面对陌生的一切,出去做咨询项目时也是如此。但人们常常会对有经验的人加入项目有所预期,也就需要我能够尽快进入到工作状态中。所以,我也就慢慢摸索出一套适合自己的了解项目的方式。

    业务

    首先,肯定要从业务入手,了解这个系统是做什么的。既然是初始的接触,我并不预期弄清楚所有的细节,只要知道这个系统是做什么的基本上就够了。

    按理说,这通常不应该是什么问题,但这也是常常容易出问题的地方,比如说,有为数不少的人在讲业务的时候,会把技术的内容混在一起讲,这一点对于技术人员尤为明显。个人就曾经经历过让我开始怀疑自己智商的几次介绍。如果5分钟说不清楚,你就别指望半个小时能说清楚。

    技术

    了解了系统的业务,接着就是对技术方面的了解。还是先从宏观方面入手,我期望了解到这个系统是由哪个技术栈实现的,Java、C/C++还是.NET系等等。这样,我就可以系统采用相应的工具与框架有个大概的预期。

    接下来,我期望从架构层面上了解系统。有没有一张或几张图能够把整个系统描绘出来,比如,这个系统需要与几个外部系统集成,自身包括哪些部分等等。一般我不指望有现成的图,多半的情况是,其他人一边说,一边在白板上画出一副这样的图。我接下来会根据自己的理解,把需要的这种图画出来。

    对大面的东西有了了解,我就希望稍微了解一下细节。从集成开始,因为输入输出对一个系统来说是非常重要的,而集成点往往都是系统信息来源。如果有集成,集成方式是什么,比如,Web Service、RMI、MQ,有为数不少的系统用的是FTP,这些集成方式相当于信息的承载,那之上的信息是什么样子,我们还需要搞清楚,比如有的系统用的是MQ,在MQ上传的是XML等等。接下来,就是更具体的协议层面的东西了,我想知道是否有对应的文档,这样,我在需要的时候,就可以查看每个字段具体的含义,不过,这往往不是初期要了解的东西。

    了解了集成,接下来就是系统内部了。这个系统有哪些子系统或模块组成。好的系统往往是由多个进程构成的,这样才不会彼此影响。对于这样的系统,我只要了解每个子系统的作用就可以了。而对于那些只有一个进程的系统,我就需要了解一下这个系统包含哪些模块,各个模块承担着怎样的职责。通常,这会一个很重要的出问题的点,因为很多系统虽然号称有模块的概念,但模块之间的职责往往是不清楚的,经常会出现很严重的依赖问题。对于现代软件系统而言,分层结构往往是不可或缺的,我还希望了解一下这个系统有多少个层,每个层做的事情是什么。这里提及了模块和层次,模块通常是从业务上来分,而层次往往是从技术上看,一个水平一个垂直。

    从设计层面了解完,就是动手的层面了,不过,还不是写代码的事。我会先了解构建脚本。了解一下项目中常用的命令,比如,是否可以一键式跑脚本提交之类的。我期望看到的是一个从版本管理工具里拿出来直接可以构建成功的脚本。但通常情况都不是这样的,要改很多东西、配不少的东西。这也许就是未来要改进的东西。

    熟悉了周边的东西,我们就可以深入到源码层面了。这就是我们程序员最熟悉的东西,比如,源码目录结构、配置文件的位置、模块在源码上的体现之类的等等。但作为最初的接触,我们只要了解基本的东西就够了,因为这是我们后来投入精力最多的地方,以后深入理解的机会多得是。

    团队运作

    除了了解技术层面的东西,我还希望了解团队运作方面的东西,一个方面就是常见活动的时间安排,比如,站会、迭代计划会议、回顾会议等的时间。再有一个方面就是,团队内部是否一些活动安排,比如是否有每天的Code Diff,是否有常规的Session墙。如果团队有外部客户,我们有客户日常的沟通是怎样进行的。

    通过这些问题,我们便不难发现项目运作上的一些问题,比如,很多团队与客户之间根本没有常规的沟通,只是会临时起意去做沟通。有的团队没有Session墙,团队内部分享也就没有常规化。

    通常以上这些东西都不需要很长的时间来了解,快的话,一天就可够了。而通过这些了解,我就可以对团队的基本情况有了一个相对完整的大体认识,接下来的事,就是卷起袖子开始干活了!

  • hopesfish评论《那一点的调用》时,问了一个关于Code Review的问题:

    想请教一下,TW的筒子是如何做code reivew或者鼓励客户做code review的?我在翻阅博主的帖子的时候,似乎对这块没有特别强调,而是更多偏重于TDD,我觉得TDD的问题是一碰到没有责任心的程序猿,就很容易流于形式了

    谈及TDD的好处时,其中之一就是随时随地的Code Review,所以,貌似TDD是不需要Code Review的。但实际上,TDD和Code Review是两个正交的维度,做TDD并不妨碍Code Review。

    这里就来聊聊我所在的项目是如何做Code Review的。我们有两种Code Review:Daily Code Review和Weekly Code Review。之所以有两种Code Review,因为每种Code Review的目的是不同的。

    Daily Code Review

    顾名思义,这是一种每天都做的Code Review。它的目的是让项目组全体成员了解每天的项目进展。

    每天早上,运用git(这里可以替换成你所用的版本控制软件)的diff功能,找出前一天修改。全项目组的人在一起,逐行浏览这些修改。每当过到一处修改,这段代码的修改者就会针对修改,介绍一下这是哪个功能,为什么要做这些修改。项目组的其他人如果对这段代码有异议,都可以提出自己的问题。

    这种Code Review使用的diff功能,了解的基本上只是一个片段,所以,关注点基本上是Clean Code。最经常出现的问题是,这段代码为什么写成这样。对于项目组的新人而言,这种Code Review是一个非常好的学习Clean Code以及了解项目隐含编码约定的机会。

    Daily Code Review结束之后,每个人会针对其他人提出的修改意见对代码进行调整。在开始新一天的工作之前,最大程度地保证了代码库的整洁。

    Weekly Code Review

    诚如之前所述,Daily Code Review只能了解一个片段,人们缺乏对一个功能或一个故事的整体认识。Weekly Code Review弥补了这种缺陷。

    Weekly Code Review更类似于许多企业的传统Code Review方式。由专人(一个人或一对pair)选取一个近期开发比较大的功能(或故事),组织全项目组的人进行Review。

    在这个过程中,组织者会带领所有人浏览针对这个功能的相关代码。我们的主要关注点是让项目组的所有人对这个功能有所了解。这时项目组成员,也会从业务逻辑,以及局部设计的角度对代码进行分析,提出一些改进建议。如果过程中出现了一些难于理解的部分,组织者要负责为大家答疑解惑。

    同样,在Weekly Code Review中发现的问题,也会被修正到代码之中。

    无论是Daily Code Review还是Weekly Code Review,最容易出现的问题都是时间控制。如前所述,不同类型的Code Review有其侧重点,所以,讨论的组织者要负责把握讨论的方向,防止发散,在Code Review的环节中,我们常说的一句话是:“线下讨论”,以此扔掉跑偏的话题。

  • 五年了,真快。

    工作十年,我只工作过两家公司:为我打好基础的东软和为我打开视野的ThoughtWorks,每家五年。这个换工作的速度,在IT行业里,应该算是蜗速了。

    当年进到ThoughtWorks,我最想解惑的是如何做好软件,因为之前的开发经历里,我有太多想不明白为什么的地方,比如,为什么要写文档。选择加入ThoughtWorks,我知道这里有敏捷,貌似是解惑的途径。

    随着自己在ThoughtWorks做过项目的增多,我了解了敏捷,这些曾经的困惑逐渐得以挥去。当有机会尝试咨询,我开始得到从更多角度看待软件开发,我开始相信改变。渐渐地,我知道了我追求的其实不是敏捷,是持续改进。

    去年带了一个项目,在那个项目里,我做了一个尝试。我把项目的目标订在了人才培养,而非传统意义的交付。于是,在这个过程中,我花了大量的精力去教新员工写代码,帮他们设定个人成长目标,教他们做事,带着他们吃好玩好……就是这样一个几乎都是由新ThoughtWorker——甚至大多是毕业生——组成的项目组,后来,这个项目成了Michael Chen口中最接近他心目中全面成功的项目。

    早在做咨询的最初,我就认识到,敏捷实施,管理实践很快上手,但新鲜劲一过,就会发现,收效甚微,而技术实践实施起来,却难上加难。我一度很悲观地认为,这事没法搞,我再厉害,也不可能让他们把我十年的东西在几个月内学会。去年的这个项目实验让我这个问题有了新的思考。

    真正要敏捷起来,我们要做的并不是敏捷实践,而在于提升团队中每个人的能力,而其中的关键在于,营造团队学习氛围。这正是我们在ThoughtWorks西安办公室努力营造的,事实证明,在这样的环境下,整体的成长是很快的,而学习氛围更好的团队其实也是各方面做得更好的团队。

    徐昊对这个问题也有属于他的思考,结合了我们在ThoughtWorks西安办公室所做的各种努力,他提出了LOT(Learning Organiation Transformation,学习型组织转型)。

    从了解如何好软件,到告诉别人如何做好软件,到思考真正提升团队能力,还好,五年的思想工作者,光阴不算虚度。