转:ThoughtWorks University 取经记

ThoughtWorks University 取经记
http://phoenixtoday.blogbus.com/logs/27454013.html

http://phoenixtoday.blogbus.com/logs/28533541.html
四月份我加入了ThoughtWorks公司,由于是应届毕业生的缘故,紧接着就被派到印度班加罗尔分公司进行了六周的公司培训。六周的生活是紧张、繁忙而又非常开心的,不但与敏捷开发方法进行了亲密接触也结识了许多聪明、勤奋富有激情的外国同事。在这六周的生活中,前两周主要是进行公司文化和敏捷开发思想的培训,后三周就主要进行技能的培训,最后一周是给所有培训的ThoughtWorker一个项目,来评估整体培训的结果。培训这些内容的主要目的是让新员工尽快的融入到公司文化中,成为公司的一份子;还有就是理解敏捷软件开发的原理并亲身体验真正的敏捷软件开发方法,从而体会到这种开发方式的种种好处;最后的一个目的当然就是增强新员工的技术水平。本文会分为两部分,第一部分介绍ThoughtWorks对公司文化和敏捷开发思想的培训,第二部分介绍 ThoughtWorks针对具体的团队开发技能是如何进行培训的,全文中会穿插一些真实有趣的小故事以及我对相应培训的一些感想。

公司文化的传承

对ThoughtWorks有所了解的人都知道,公司的文化都是围绕人与人之间的平等、尊重和加强沟通这几个方面的。作为一个新员工,给你带来的最大感受就是公司自由平等的氛围和人与人之间和谐友好的关系。

这些平等、自由的思想当然会渗透在培训课程的点点滴滴之中。第一天的课程中,我们就做了很多的游戏,其中有两个很有趣的游戏,第一个游戏是老师们给每个人发了一份表格,上面写了二十多条内容,每一条内容会对应一位老师或学员,例如会有这样的内容“有一个人拥有iPhone”,“有一个人的体重小于50公斤 ”,或者“有一个人要坐超过二十小时的飞机才能来到班加罗尔”等等,这些问题每一个都是特别设计的,而你的任务就是要在五分钟之内将所有的内容与人对号入座。游戏开始的时候,大家跑得跑,叫得叫,笑得笑,整个大厅沸腾了,好不热闹,最终有一两个学员将所有人对号入座,然后大家就集体将所有匹配的结果大声朗读了出来。其实到底谁赢了游戏,并不重要,真正重要的是在这个过程中,大家增进了了解,进行了有效地沟通,如果你都不了解你的团队,那如何进行软件开发呢?从这一个简单的游戏,我们所有学员和老师,就从陌生人向朋友迈进了一大步。第二个游戏叫做“人人都会犯错误”,传达的人人平等的理念更加强烈一些。游戏规则类似于中国饭桌上经常玩的报数字(遇到含七的数字和七的倍数要说Pass),只不过我们加了一条,就是在你犯了错误后,要大声地说“YES”,同时手脚并用的摆一个姿势,然后站到圈的末尾。结果在游戏的过程中一位印度裔的老师Reshema经常出错,长相可爱的老师Reshema再加上大声吼叫的 YES以及怪异的手脚并用姿势,把所有人逗的前俯后仰。这个游戏使我们明白了,犯错误是很正常的事情,你没有理由去责怪别人,ThoughtWorks也是允许你犯错误的,关键是犯了错误你从中能学到什么,以及帮助别人怎么从错误中进步。

其实公司的第一堂课根本与敏捷软件开发和技术无关,可能大家根本无发猜出是讲什么的,连所有的学员都很惊讶公司培训的第一堂课,竟然是告诉我们什么是公司认为的歧视和不平等,在这一堂课中,老师会提出一些问题来让学员投票,让我们分辨什么是歧视和不平等,然后再给出公司的答案,如果大家有疑问可以充分的表达自己的意见,然后再投票。从这第一堂课的内容就可以看到ThoughtWorks是何等的重视人与人之间的平等和尊重了。注重人与人的沟通也体现在公司文化的各个方面,最简单的一个例子就是宿舍的安排,我本想着可能是不同分公司的员工会住在一起,没想到刚下飞机就得知自己会和一个澳大利亚的同事还有一个印度的同事住在一间公寓里,这对于英语不是母语的中国人来说,也真的是捏了一把汗。但是仔细想想,这样的住宿方式,不但会加强不同学员之间的交流,而且可以更好的了解不同区域的文化,了解你将来可能一起工作的同事,了解他们的想法和行为方式,这样才可能达到真正的尊重和平等。

了解ThoughtWorks的人可能都知道,平等和尊重在公司的极致体现不能不说是那些公司的领导层了,每一期学员培训,Roy(不要说你不知道Roy是谁啊)都会单独做一次演讲,其中的主要内容包括创建ThoughtWorks的原因和历史,公司经历过哪些困难以及他本人的一些传奇经历。Roy的演讲是很有趣的,不过学员们提的问题更加有趣,我和我的舍友就提了一个“假如你被绑架了,你会怎么办?”的离奇问题。结果Roy的回答让人瞠目“其实我是被绑架过的!”然后他就娓娓道来那一次班加罗尔分公司的ThoughtWorker是如何乔装成绑匪,然后在飞机场对Roy实行了一次“绑架”,之后Roy又爆料出许多被ThoughtWorkers戏弄的故事。从这些Roy的小故事中,你可以发现公司的头头脑脑们,喜欢和员工打成一片,有的时候他们会上来拍你的肩膀然后叫你的新外号,有的时候他们会跟你谈论他们最近的尴尬经历,甚至吃饭的时候他们也会被员工灌醉。可见平等和尊重的理念已经深深的植入 ThoughtWorks的文化精神之中。

ThoughtWorks公司的平等和尊重还体现在公司的管理很透明,甚至包括财务收益、开销等信息都会公开的呈现在新员工的面前。印象中
关于
管理很透明有两个小故事很深刻,其中之一就是第一周一门课程的内容就是将公司这几年的收益和开销完完整整的展现在所有员工的面前,包括总共有多少收入,总共有多少支出,这些支出用在培训、新建分公司、股东收益等等方面的具体支出数目,并且在课程的最后每个学员还要扮演公司财务部门的角色,模拟体验一下公司财务部门是如何进行资金运转和保证现金流的。第二个故事就是Roy在他的演讲中提起了2001-2003年公司曾经裁员的事情,原因就是当时IT产业大萧条,公司处于窘境,Roy说那时是他最为困难的时期,直到现在都很内疚,仔细想想在绝大多数的公司中,这些内幕消息哪是一个刚进公司还不到十天的人可以接触到的,但是ThoughtWorks确毫无保留的给我们展现在眼前。其实管理的透明在回国后,也时时刻刻都可以体验到,ThoughtWorks 北京分公司每月都会做一次月报,让全公司的同事都知道这个月我们分公司的经营状况。对于我们这些新员工,在短期内就对公司的各种状况有了一个整体的了解,从而很快的建立起了一种强烈的主人翁精神。

敏捷软件开发思想的传承


对于前两周敏捷开发思想的培训是非常有趣的,几乎每节课都有互动的过程,每节课都会有生动的实例让你体验到什么是真正的敏捷软件开发,为什么要使用敏捷软件开发。

在介绍整体培训的过程之前,首先介绍一下ThoughtWorks敏捷软件开发团队的构成。一般一个开发团队主要有以下几种角色:PM,Project Manager项目经理;BA,Business Analyst业务分析;DEV,Developer 开发人员;QA,Quality Analyst测试人员。PM对项目进行全局掌控(有的时候,还会有IM,Iteration Manager对具体的迭代开发进行掌控);BA,主要与客户进行沟通和业务分析,与开发人员进行交流,与测试人员对整体功能进行讨论等等;DEV,主要就是开发应用程序,但同时也要协助业务分析员和测试人员进行工作;QA,主要对开发人员开发出的系统,进行全方位的测试,包括功能测试、性能测试等等。对于团队整体的开发流程,是一个有序、小步、渐进的过程。ThoughtWorks对敏捷软件开发思想的培训也主要针对如何了解用户需求,团队共享代码,迭代开发,总结与回顾。

在软件开发的过程中,能够准确的理解用户的需求,将用户的需求转变为开发团队理解的用例,是一件紧迫而重要的事情。但是,如何才算好的理解用户的需求呢?如何能让我们这些从没与客户打过交道的毕业生尽快的学会与客户沟通的方法呢?这就是我个人非常喜欢ThoughtWorks University的一个方面,在敏捷软件开发的所有课程,包括对需求理解的课程,设计的非常精妙,不但能够让这些观念深深地扎根人心,而且能让你体会到真正的软件开发其实就是应当这样做得。我们上过一堂用橡皮泥做电话的课程,老师们把大家分成许多小组,每个小组由3-4个学员和一位扮演客户的老师组成,老师们扮演的客户是非常的苛刻的,我们的任务就是要做出让客户满意的电话来,每一次开发的过程只有十五分中,分三次开发完成一部完整的电话。在整个开发的流程中,我们体会到客户的需求是随时改变的,当他们看到了原型系统,甚至可能推翻之前的所有需求,这时候作为一个开发人员或者业务分析人员,在你了解客户的需求过程中,不但要求你具有能够充分理解客户需求的技巧,更需要你能启发客户思考一些它们没有想到的方面,从而少走一些弯路。在制造电话的过程中,我们几个小组在第一个开发周期的行动,几乎都是闷头造电话,完全忘记了我们有一位客户坐在我们的桌字旁,当我们有疑问的时候,为什么不去直接找客户进行沟通呢?老师向我们提出了这样的问题后,我们在后面两次的迭代中,和客户进行了频繁的沟通,最终做出了让客户满意的电话系统。下图就是我们做出的橡皮泥电话系统之一,你看Reshema老师拿着电话,多么高兴。

不得不提起的回馈信息

加入ThoughtWorks以来,发现回馈信息是公司非常注重的一个方面。在TWU的生活中,不但学员之间两周会互相给一次书面的回馈信息,每周需要对这一周发生的小到食物好吃与否大到老师的培训方式等都要提供回馈信息,平时课堂上即使给出的回馈信息更是数不胜数了。由于我们中国学员的母语不是英语,因此在前两周培训的过程中,我们有的时候跟不上老师们的语速。结果在第一周五的回顾课程中,不光中国学员,还有许多我们新认识的朋友帮我们提出了这个问题,讨论的结果就是我们不但在墙上挂起了“说慢点!”的大幅标语,还发明了一个手势用于提醒老师讲话慢点。回馈信息其实确保了大家都在尽自己最大的努力去做好每一个方面,同时也培养出一种公正公开的气氛,让我们都朝着自己所树立的目标前进。

总结

现在想想,公司的一系列生动的培训课程,不但让我们了解公司文化的本质,更重要的是让敏捷软件开发思想深深的扎在了我们心中,我们看到了原来软件开发的过程可以这样的丰富多彩。TWU的洗礼其实只是带我们入门,不过这些课程在我们真正进入项目后,才会逐渐发挥出一步步深远的作用,例如我现在从事的项目,就时常让我想起TWU的课程中老师说的方方面面,再结合当前的亲身体验,可谓是获益匪浅。希望本篇的内容也能够对读者有所启迪。



在有些人的眼中,ThoughtWorks是一群拿着卡片到处贴,到处走的奇怪人群组成的软件咨询公司。其实为什么使用卡片作为理解用户需求的主要机载体,在我去TWU之前也很疑惑。后来,在一堂介绍如何使用卡片理解需求的课程中,终于了解到原来其中包含了这么多奥妙。首先卡片很小,这就迫使业务分析员不能将太多的内容放在同一张卡中,由于一个迭代周期通常是两到三周,需要给用户展示一些能用的系统功能出来,这样就会引起整个团队思考许多有价值的问题,什么是最紧要的?什么是系统的核心?我们要用多长时间来完成这些卡片上的内容?第一个迭代周期能完成多少卡片?我们的团队开发速度是多少?等等。其次,卡片在卡片墙上是可移动的,因此它很灵活,就如下图所示,可以将卡片放置在不同的队列中,通常我们用“在分析中”、“在开发中”、“在测试中”、“结束”等一些状态表示卡片所处的不同状态。这样,当所有团对人员,需要了解当前项目的进度状况时,只要站到卡片墙前,就可以一目了然,如果处理不同卡片的小组需要彼此沟通,在卡片墙上,可以用最快的速度找到相应的人员,甚至,当你有疑惑的时候,卡片可以拿下来仔细研究,只要记得最后放回去就好。卡片的最后一个优点就是对当前项目进行评估,举一个简单的例子,当一个团队的开发状态是绝大多数的卡片都集中在“在开发”的队列中,就表示当前开发团队处于业务分析员和测试人员无事可干,但是开发人员又过于繁忙的不健康状态。什么原因导致的呢?可能是开发速度过慢或者是业务分析员写的卡片粒度过大,导致开发人员无法及时的完成。由此,当我们站到一个团队的卡片墙之前,我们看到的不仅仅是一些简单的卡片,更是整个开发团队的开发状态的展示。一张张小小的卡片却包含了如此多的内容,这真的是我们始料不及的。当然卡片并不是完美无缺的,对分布式团队开发就是卡片墙的致命弱点,但这些问题在ThoughtWorks的Mingle软件中都得到了很好的解决,卡片对我们来说更是一种以用户为中心,以团队沟通为中心的开发思想,而不仅仅是一种开发方法。
针对眼前的需求,小步前进,不做过多的设计,也是敏捷软件开发的核心思想之一。ThoughtWorks University通过一个早上的摆积木课程(Lego Game)让我们充分的理解了过多设计的弊病。这次课程的整体任务是创造未来物种,类似于造电话课程,同样分为三个迭代周期,有一位老师作为客户伴随着我们进行开发。这一次,老师们一下给了我们许多点数不同的需求,每个需求对应一张卡,每张卡上有不同的分数表示这张卡的难度,每次迭代有五分钟的讨论,需要确定这次迭代都要完成哪些功能,有十分钟的设计,还有十五分钟的开发过程,每次迭代后大家要讨论哪些做得好,哪些做得不好的地方。第一次的迭代往往是犯错误最多的地方,我所在的小组向客户许诺了总共加起来十分的卡片,在设计过程中又做了许多不必要的假想,过多的专注于给未来的需求留下余地,而将自己开发的过程束缚住。最后仅仅搭起来了动物的头和身体,可是客户要求的是一个完整的动物,所以第一次迭代我们只有零分,客户非常的失望。ThoughtWorks 就是这样,通过学员的犯错误,让我们自己体会,然后通过讨论,让我们自己总结出具体的方法,老师们则是在旁边指引,这样的感受怎么能不深刻呢?经过讨论,我们制订了自己的方针:少许诺,少设计,好好做核心模块。就这样,最后我们创造出了未来的一个物种(还有它的孩子)。

迭代的过程也是ThoughtWorks进行敏捷过程培训的一个重要方面。还是继续我们的游戏旅程吧:这一次老师让我们分成三个小组,分别从培训大厅的一端将气球搬运到另一端,每一组有两个人负责装运,两个人负责撑袋子,一个人负责搬运,哪一组能在最短的时间内,将最多的气球从一个口袋中运到另一侧的口袋中就算胜利,如果过程中任何气球掉在路途中,则不可拾取。第一次的规则是只能运一次,整个过程给人的感觉就是搬运的人花了很多的时间,承担了过多的责任,而其他的四名队员起不到任何的作用,只能边喊边焦心的等待。第二次的规则几乎与第一次一样,但搬运人可以多次的运输。结果第二次,我们不但出色的运输了所有的气球,而且还比第一次所花的时间更少。玩完游戏的讨论过程中,我们逐渐的明白了,第一次运输就好比传统的瀑布式开发,开发人员承担了许多的压力,缺少沟通和其他人员必要的帮助,闭门造车造出来的东西,往往并不是客户心目中想要的东西;而第二次运输就好比多次迭代的开发过程,开发人员得到更多的信息回馈以及业务分析员和测试人员的帮助,因此能够开发出更好的软件产品。就这样,我们不但理解了迭代开发的原理,更通过亲身的体验明白了这样做是行之有效的。

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章