ThoughtWorks有什么不同?

仅仅入职两个月时间,就试图看清楚说明白新入职公司的不同,注定是浅陋的。但是这并不妨碍我说出目前我心目中的ThoughtWorks。

昨天和前同事聊天,被问起了ThoughtWorks跟之前公司有哪些不同的地方。我想了想说,你所知道的敏捷的全部,在ThoughtWorks都能找到;没有拖沓碎叨更像是status update的standup; 我看到了自组织的团队,每个人都在团队中承担自己的职责,自信且淡定;扁平的层级文化,没有看不到头的title层次,可以把精力聚焦在项目上和自己感兴趣的事情上;可以向整个公司发邮件,表达自己的担心和困惑,评论社会现实,公司的老大也会加入进来讨论;可以让自己承担起公司主人的角色,为公司的发展做出自己的努力和影响;还有ThoughtWorks对于利用软件和技术改善人类生活的社会责任的担当;ThoughtWorks一直致力于用最先进的技术和方法来帮助客户,这会让做技术的人很high。这些在别的公司都是很难见到的。

我之前的工作经历很有代表性,先是一家国内大型软件企业,然后是一家大型外资企业,这样的经历让我有在不同企业背景和文化下的体验,也让我现在有了相对的参照系,来比较现在所在的环境——ThoughtWorks有什么不同。

如果答案仅仅止步于上面那些不同,我想这是肤浅的。是什么造就了这些以及更多的不同?有一些线索可以帮助理清楚:

在TWI上徐昊提到了Martin Fowler写的一篇博客,讲的就是ThoughtWorks是Roy的社会化实践。Roy希望借这场实践来证明那些认定下面结论的观点是错误的:

  • 你的公司不可能只由能力强的人们组成,必须存在能力差别
  • 能力强的人往往无法合作
  • 大型公司必须有强有力的管理结构,以避免分崩离析
  • 不可能为考虑长远而做事
  • 成为国际化公司是为了利用欠发达国家的人才
  • 不能暴露自己的弱点,尤其对于公司外
  • 不要赋予员工权利,否则会被滥用而伤害公司
  • 文化是次要的,你需要一个优越的商业模型

“社会化实践”,是不是挺震撼的?事实是,ThoughtWorks的确在全球网罗到了一批才能很高的人,在共同致力发展这个公司,守护这样的文化。我们成为了Roy的实验品,但软件这个特殊的行业,工程师这个简单又复杂的职业,这样一群人,的确在印证着Roy的实验趋向成功。

另外还有一篇文章《为什么我要把公司做成扁平型》,作者是37signals的创始人之一,他讲述了公司确实发生过的事情,当试图为一些资深员工创造一个管理职位和职务来发展时,遇到的问题和冲突。经验证明,让团队自己管理自己是效率更高的方式,因为的确有这样的一些人,不介意有那样垂直发展的梯子供自己攀爬。

最后是今天看到的米高写的一篇《全面成功》,这跟我在团队同事那里听到的一样。怎样定义项目的成功,只顺利结项拿到款是肤浅和单薄的。客户满意,项目质量高,团队得到发展,不一而足。ThoughtWorks的文化追求,也导致了全面成功是每个项目组的诉求。在这样的环境下,团队才会是自组织的,个人最后也才是充实和成功的。

Share
 

ThoughtWorks需要怎样的人?

想知道如何才能做好软件的人
想学习最新前沿技术并应用在项目中的人
想在项目中自己做主承担责任的人
想跟大牛成为同事一起工作的人

厌恶大公司繁文缛节的人
厌恶低效无谓加班的人
厌恶没有进步空间的人
厌恶盛气凌人的老板的人

想用上最新版MacBook Pro甚至Air的人
想每天吃到新鲜水果喝可乐的人
想每天可以打PS3和街机的人
想每天都有session听的人

不想把薪水放在第一位的人
不一心追求升职的人
不沽名钓誉的人
不畏惧变化的人

Share
 

Pair时的心态

为什么我们需要pair programming,以及pair有什么好处,不是这篇文章要说的内容,关于这些方面,网上能找到的太多太多。这篇只是想说说对于pair中心态的问题,我在pair时的体会。

对于有过开发经验的人来说,离开几年来一直专属自己的那个格子间,坐到一张开放会议桌边写代码,旁边还坐着自己的pair,度过半天甚至一天的开发旅程,并不见得都是一帆风顺的过程。

每个人有自己的开发经验、背景和知识,成为pair就要为Story的代码质量负责。怎样合力以解决问题产生代码,是需要彼此Open心态,针对问题解决问题,而不是:

  1. 妄自尊大,容纳不下对方的观点
  2. 对对方不闻不问自顾自操作机器
  3. 炫耀自己的知识面而鄙视对方
  4. 甚至出言不逊,伤了对方还浑然不知

这是一个成长的过程,也是一个自我剖析让自己更open的过程。所以我们一般会安排由具有丰富pair经验的老同事带着新同事一块来pair,还会有乒乓和keyboard-mouse方式来控制pair的节奏。在知识传递的同时,逐渐打开每个人闭锁自我的心态,逐步提高pair的效率从而提高team的velocity。

从小处看,这是个人心态改变的过程,从大处看,这是开发文化不同导致的诉求。

Share
 

Automation Training For TW QA

今天作为酱油党之一(徐X语,还有小刀和LeoShi同行)参加了徐X为TW QA开的Automation Training。

对于Ruby小白的我,跟着QA一起学了一把。

  • Ruby的包机制,应用的配置环境
  • Selenium RC的原理,包的四个变种。
  • 在07年就提到过的Page Object

自动化测试具备怎样的特质,才能最大限度的减少QA手工测试的工作量?

  1. Effective
  2. QA manageable

最后,徐X介绍了几个月前他研究出的Data Flow大法。简言之,测试不是要去测试事情本身,而是要测试事情结果的确发生。听着象废话,但那张精美手绘图却惊艳得不行。用以作为切分并归纳测试案例的依据。很受用,争取撺掇一篇文章出来。

Share