Team的一次Code Kata

上周四的中午饭后,我们team坐下来完成了一次Code Kata练习。跟之前的几次邀请PwC team同事过来pair和coach不同,这次是我们组自己内部完成一次练习,题目来自Yuheng之前的一个练习:文曲星上的猜数字游戏。

题目规则很简单:

  1. 游戏开始后,系统会随机给出四个不重复的数字。由用户输入自己猜测的四个数字。
  2. 如果数字猜对而且位置也对,就是1一个A。
  3. 如果数字猜对但位置不对,就是一个B。
  4. 返回结果是如“2A1B”这样的字串。
  5. 猜错6次,游戏提示结束。重来。

开始提出的要求简单:用TDD驱动出实际代码。

大家抽签后开始pair,Yuheng还会一边计时一边催促,pair的气氛基本保持紧张有序。

在我和XuChen pair开始代码后,我们很容易写出第一个测试1,期望返回结果是”4A0B”,最简单的代码实现让测试变绿。

当我们试图写下第二个测试2,试图期望返回结果是“2A1B”时,我们发现不得不面对如何这个游戏规则的最核心算法,但可惜的是,猛然间对这个算法没有头绪。

局面一时僵住,停顿了有两分钟。

直觉和一点经验告诉我们,这时该拆解任务了。很容易想到,如果计算出几个A和几个B是很直白的拆分。

我们可以很容易写出一个测试3,测试猜测的四个数字跟事先给定的四个数字相比,有几个A类数字(循环比较),我们称之为perfect number。

也很容易写出另外一个测试4,测试猜测的四个数字跟事先给定的四个数字相比,有几个B类数字(在上个算法的基础上再循环比较),我们称之为good number。

写完针对测试3和4的实现代码,我们发现我们已经完成了最基本的算法,功能完成了。剩下的是重构代码。

从我们这次的经验看,我有一些收获和心得:

  1. 测试就是代码的设计,你看测试3和4导致的结果就是我们有了对应的两个计算方法。你打算怎么测,你的实现代码就会是怎样的。
  2. 印证了在Wikipedia中那段话,pair programming尤其适合面对一些challenging的任务(至少开始的时候是)。
  3. 分解任务是王道。我们在不同的level拆分任务,从story拆分成task,从大问题拆分成小问题,莫不如是。
  4. 囿于经验,不期望由端到端的测试能逐步甚至一下子推导出完整、完善的代码实现。而这样的练习,恰恰是我们锻造自己经验必不可少的过程。

我们在实现代码时,仍然欠缺的是:

  1. 对于测试方法名的命名,不够清晰直白。
  2. 对于算法代码的实现,简单粗糙,还需要重构。

分布式协作

随着软件需求和实现规模的变大,软件时代已经告别单兵作战、草莽英雄,进入规模化、规范化的快车道,多人、多团队、多部门甚至跨公司的协作起着举足轻重的作用。大到公司的文化、制度和氛围,部门间的利益冲突和博弈,小到团队个人间一个电话、一条消息,无不渗透于协作其中。

加上近年来软件行业对于外包甚至离岸业务需求的旺盛,一个有关“分布式协作”的话题逐渐显现出来。软件公司在面对分布式的协作,遭遇到与以往不同的挑战。

对于成本和效益的权衡,对于沟通有效性的考虑,对于团队成长和业务发展的思考等诸多方面,分布式协作需要领导者等涉众重新思考协作方式的变化带来的冲击和机会。为什么有的企业和团队能够游刃有余、如鱼得水,工作得心应手,业务蓬勃发展?而有的企业和团队却磕磕绊绊、终不得法,最终效率低下,缺失信任,业务萎缩?

这个专题试图回答的问题是:

  • 分布式协作与传统意义上的协作的不同到底在哪?
  • 在你的企业内部,面临的分布式协作的挑战有哪些?
  • 你的企业是如何做出改变来支持分布式协作的?如何消除物理上和心理上\语言上和文化上、技术和业务上存在的隔阂?
  • 分布式团队所引入的隐藏成本在哪里?如何量化这个成本呢?
  • 有哪些工具和方法你认为对于支持高效的沟通和协作最有帮助?
  • 你认为团队的规模和角色的分布对于分布式协作有怎样的影响?
  • 你认为业务的划分是否也会影响到分布式协作?以及会有怎样的影响?
  • 你认为分布式团队之间的协作与面对面的沟通交流是怎样的关系?你的企业有怎样的权衡?

 

我的2011

2011于我而言是变化的一年,在3月份离开工作了四年多的IBM,加入ThoughtWorks中国。对很多程序员而言,这都会是个梦想的工作地方吧,但对于一些如我这样工作有几个 年头的人来说,不是件轻而易举的事情,因为这意味着自己要失去一些东西。

加入前我有过惶恐,担心自己不能适应,这过去的三个季度,我开始慢慢淡定。我越发觉得,TW真是卧虎藏龙的地方,我需要更加不断地审视自己,发觉自己需要提高的地方,这样我才不会太过懈怠,不然落后只是时间的问题。我又觉得遗憾,又觉得欣慰,这是我第三份工作,方才让我有自省的惊醒,工作七年后才有这样的际遇,但七年对于我这样愚钝的人也不算太晚吧。

2011年我在豆瓣上记录自己读过的书,和看过的影视。记录表明,我看了30本书,数量说得过去,但种类芜杂,经典太少,随性跟风阅读居多。我的阅读品味是个问题了,需要纠正。好在我们现在有ThoughtWorker导读了,我可以借助聪明的大脑。跟阅读比起来,娱乐就显得大方许多,我看了40部影片。

2011年,我在ThoughtWorks做完了一个项目(惊异地发现这似乎是我工作以来完整做完的第一个软件项目,由此可见软件行业乃至国内这个环境下,我们的程序员接触的都是什么系统呢?)。我策划发布了ThoughtWorks文集的2012版,也是第三辑。我还和同事贾永娜合译了《Individual and Interaction: An Agile Guide》,今年上半年会出版。在年末的几天,我开发了一个公司内部用来请假的移动小应用,基于jQuery Mobile,简单直接,快速开发。我很喜欢这样规模的应用,我也相信WebApp会在2012年大放异彩。

目标只有可衡量,回顾起来才会有成就感。的确。

从加入ThoughtWorks开始,工作的压力骤增,让我不得不在坚持了几个月后,请辞了InfoQ中文站的原创主编,从琐碎细致的例行任务中解脱开来。作为从InfoQ中文站建站开始就参与的贡献者之一,我对她有深厚的感情。2011年我投入不足,在2012年我会继续投入。已经确认,在2012年春QCon北京我会担任组委会成员之一,负责组织和审核讲师及分享的主题。我还会是“分布式协作”Track的主持人。

在2012年,我会继续策划ThoughtWorks文集的第四辑,我需要的只是邀请合适人来写写文章,这里的人让我很放心,你不知道他们是一群多么乐于分享的工程师们!

我会继续POSA第二卷的翻译,和我的同事们。在2010年,加入ThoughtWorks的兴奋让我贸然接下了两本书的翻译,后来证明我的精力根本不够,所幸的是第一本小册子(上面提到的那本)已经提交出版社编辑。今年只需要关注在POSA这卷经典上了。

2012年,我期望能向九强学习一下摄影,为无聊的自己增添一些生活情趣。我还希望自己能掌握一些Excel的技能技巧,年底跟同事策划内部的Vacation System时才发现,很多事情我们作为程序员都想当然地考虑复杂了,我们即使自己没拿着锤子,也把所有问题都看成钉子了。演讲技能,是任何时候都需要磨练和提高的,幸运的是,现在有擅长此物的同事可以请教,而且知道哪来的天才和10000小时的理论后,所需要的就是不断的练。

如果只是上面这些,对于现在的我不能有一点满足。前几天中午跟Sponsor吃饭,回来进电梯前,他问我:“你觉得你目前最急需解决问题是什么?”我一时语塞。我后来说是Client Facing的能力,毕竟这是我目前收到Feedback谈到最大的问题。我觉得Sponsor和我自己对这个着急的答案都不置可否。

加入ThoughtWorks以来,我越发觉察,我需要的是一次对自己思维和能力的全面革新。

  1. 独立思考的能力。不能说现在没有这样的能力,也不能说看问题不够全面,就是觉得不那么到位。长期遭受信息过载的困扰,不能自拔,而懒惰又拖住自己躺在舒适区,不愿做立下的改变,进而失去培养独立思考和解决问题的能力基础。长期困扰于此,解决办法会是什么?我想是注重阅读和与人沟通学习。心智成长和思维并重。
  2. 计划性和冷热病。我做事情一般缺乏计划性,有了粗略的计划却很难执行好,客观原因是计划的不好,但主观是缺少对计划调优的热情。事情有时计划了,却搁在一边独自娱乐去了。对于目标,没有足够的坚持和热情,很容易开头雷声大,后头雨点小,而且呈周期性,最后连自己都气馁了。这里一个突出的原因就是,我的context的频繁切换导致新鲜劲儿很快过去,计划自然成空了。所以2012年,控制自己context切换是一个重要的目标,远离微博,聚焦注意力。
  3. 承担责任。从我收到的Feedback看,我很容易抓不住一些显而易见的承担责任的机会。这个比较tricky,同事认为是机会是责任,我自己却意识不到,或者意识到了也做不出来,或者不愿意去承担。看来还是嘴皮上动动容易得多,行动起来却不是容易做到的。
  4. 知识体系。ThoughtWorks奉行的是一整套的理论和实践体系,而且这本身还在不停地发展。如果通过实践和学习,将它们沉淀为自己的知识体系,是每个咨询师都要面对的问题。

在ThoughtWorks有一种被“夹持”成长的氛围,enjoy吧!

嗯,2012年,我还要勤奋地Blogging。