敏捷开发松结对编程之四日常管理

dollybol 2012-10-05

团队中常见的一种情况计划、估算、设计的时候大家还在一起,但编程的时候就会分开。分开看似是安全的,但是却充满隐患。

2001年,一位招聘考试前三名(一共120员工)的程序员的两个月的成果被彻底放弃重写,原因是里边包含3000多个常数,而且很难修改(码流参数),重写的人座位距离他只有4米,重写也只花费了2周;2002年,一位月薪7000(那时候北京房价才3000多)的程序员编写了一个月的4000多行代码,在一个下午被重写为50多行,座位距离他只有5米的项目经理疑惑加惊讶地问:“你真的没学过c++template?”。

这就是团队的距离,即使是高薪聘请来的程序员也难免犯错。难道我们只能避免下一次问题发生,而不能避免这次问题发生?

-----------------------------------------

前检查点

前检查点就是在做某功能的最初一段时间,师傅与徒弟结对编程,完成最初最重要的设计。

“开始做X功能的时候叫我一声,咱们敲定一下具体怎么做。”这个是师傅的前检查点标准语法。尽管在共同估算的时候大家还是略有共识,但是限于计划会的有限时间,徒弟未必真的知道怎么做。在刚开始的一两个小时里边,师傅带领徒弟一起把基本的结构理清楚,最好写上一些基本代码,让徒弟有一个直观的概念。

在上面提到的2周的重写工作中,重写者和被重写者一起工作了1.5天,重新设计了打包类、递归函数等最难缠的部分;被重写者在剩下的两周里边完成了工作,而且很出色。倘若这一切发生在两个月前该多好。那次事故之后,我们订立了更严格的代码审查制度,所有代码均由部门技术最好的人审查后才进代码库;之后再来的新人,均指派师傅,并由师傅保证其代码质量;将人员划分为需指导的/免于指导的/可指导的/可培训的四级(10年后我在NEC参观交流时发现了几乎完全相同的分级制度)。

前检查点的工作作用是打下设计的基础,保证工作顺利进行。如果一切按照前检查点的设计进行,徒弟可以继续独立工作,如果有偏离,要询问师傅。

前检查点的学习作用是显而易见的,师傅平时工作的精华都展示在徒弟面前。而且这种展示是动态的,在结对编程的状态下,徒弟可以完整地看到师傅是怎样入手工作,怎样思考,怎样解决问题的。

后检查点

后检查点就是某事做完后,师傅检查一下徒弟的结果,保证达到验收标准。

曾经分配给我一个刚毕业半年的组员,刚来没多久就经常看到他上网玩,过去一问,原来工作做完了(真的非常快),惊奇之余赶紧看看结果:功能是有了而且实现得也很好,就是总有点瑕疵:要么按钮不正,要么界面上有错字。后来就改成每次任务完成都赶紧喊我去看看,修正后继续下一个。他后来能力超群,在此公司作为“台柱子”10年,现在还在。

其实多数新人在大学中都形成了“能运行就行”的概念,并不懂商业软件开发的标准。本人也一样,毕业5年还不知道delete内存(C++),每次都是多预留点C盘空间,这样程序就能多运行一段时间,下班之后关机重启就可以了……这样的软件肯定无法在服务器上长期运行的。

在后检查点,师傅可以提出改进要求,也可以当场改动。徒弟在此过程中会发现自己和师傅的差距,并因此而得到改进机会。

后检查点的工作作用是可用来进行代码审查,以确保软件产品的质量,之后会提到。

后检查点的学习作用是帮助新人学习商业软件的开发标准,逐步养成好的习惯。

日常工作

除了在任务前后的时间点外,日常8小时也应该保持良好的沟通。在一次极端的环境中,我们曾经将其发挥到极致。

当时我们以很高的日薪临时聘用了两个不错的程序员。他们技术虽然很好,但是却对业务一无所知,也没有提前看过文档。因为总共也没有多少天,当然不能把任何一分钟花费在熟悉业务上,所以……

1.每天早上(包括第一天)

整个软件被大致分为三类功能区,互相关联。组长(我)也自己编程,负责其中一类功能。

有20分钟的晨会,组长会把一个简单的设计文档的一部分拿出来讲解给两个人,同时指出今天要做的工作要给予其中的哪些内容,他们提问我回答。散会前我们会就每人的工作做一个简单的估算(当年还不会扑克牌估算,太可惜了),确保当日是可以完成的。

晨会会提到技术问题,而不是每日立会中说的只说进度。但技术问题一般只涉及到要求,比如“做分段计价模型的时候,不要在C++里边做For循环,看能不能在SQL里边解决,如果解决不了来找我”“好,我试试。(或)这可能吗?”凡是有问题的就会稍微深入一点;凡是“我试试”的,都放过,但如果试验的结果不通就必须找组长讨论而不能自行解决。

小组加组长只有3个人,所以所有人都参加这个20分钟会,包括肯定不做某任务的人,也听组长和别人的讨论。

2.每天下午1:30点左右

就是吃饱饭犯困的时候,组长会分别和大家在计算机前碰头一下,主要是看当日的工作是否可能在下班前完成(坚持不加班);另外就是看是否和晨会上预想的一样。

其实就算是短短的半天时间,事情就可能有变。有一次其中一个程序员在一上午写了大约4屏幕的代码(一般每天才写这么多),而功能却遥遥无期。原来他不知道有个函数可以快速实现这些功能,正在自己造轮子,他本应该告诉组长所遇到的困难。

程序员很少在这个时候求助,他们总是相信自己能最终解决问题……因此在转型为自组织团队的时候,担心程序员会偷懒的想法整体上是多余的,更需要预防的是蛮干/过于乐观/激进/需求镀金/消息闭塞/无法互相学习等问题。

3.每天下午下班前

当时6点钟有《七龙珠》(工作场所有台电视),两位对此都很着迷,所以我们基本到点就看片,看完后散伙回家。

因为也不能让电视台调整播出时间,基本上下午5点就要开始打扫战场:组长分别找两位,看最终结果是否完成,并做一下修改。同时还要做代码审查(请看下一篇详述)。

由于估算不会太准确,我们专门把所有三不管的小功能梳理出来,谁提前做完了,谁就找其中一个把剩下的闲工夫占上,结果其中一位几乎包揽了全部。

4.晚上

对,组长晚上还要工作。在他们走后组长会在晚上做个集成,把几个人做的功能合成在一起运行。当时也没有持续集成工具,所以只能手工。

在正常项目的正常团队中,这个工作应该在工作时间完成,也就是说或者找专人(或轮流),或者让组长做,或者让自动工具做最好。推荐小组内轮流负责此事,因此可以让大家理解别人的工作、整体的工作,乃至与组外人员的集成工作等内容,为组员成长为组长打下基础。

5.随时

可能已经注意到我们没有“每日立会”,一则当年还不知道Scrum,二则感觉一个3~5人的团队还要靠开会交流实在迂腐。比如在篇首提到的两次事故中,团队都没有少开会,但都因为缺少随时的沟通而导致大错。

其实任何伸伸懒腰的时间都可以进行沟通。不过一般不要“太随时”,应该以师傅的时间为主,也就是如果徒弟遇到了问题,但可以绕过去先走着,就先来一句“我这有问题,有空帮忙看看”+“好,再过15分钟”。这样既不会让徒弟被卡住,也不会让师傅因为经常被打断而导致无法工作。但师傅可以随时发起交流,因为他们是去帮助徒弟的,聊的也是徒弟的事情,不存在打扰的说法。

在多数情况下无论徒弟学得多好,小组的主要产出仍然可能一大半来自师傅。因此不能把师徒团队变成一个简单的学习团队,而要通过保证师傅的时间,来保证其首先是一个工作团队。

这个工作习惯一直保持到后来我管理一个市场/销售/支持团队的时候:我选择坐在开放空间的最中央的一张大桌上(各部门经理也都在中央桌上而非独立办公室里),如果有人有事来找,都会问:“有空么?”答案是有空,或者某个时间之后。尤其是每天有10个以上不同的人会找你的时候,时间管理方法是很关键的。

注:上述部分内容仅限于特定环境中,但思路很多时候都是可取的。

-------------------------------------------------------

前检查点的基本作用是保证后续工作有大致的方向,而且徒弟能从师傅的设计过程中受益。

后检查点的基本作用是保证完成的工作符合要求,而且徒弟能从师傅做出的改进中受益。

在日常工作中,师傅要经常过问徒弟的工作,但以保证自己的产出为前提。不能因为已经进行了共同设计和估算,或开了例会就放弃日常跟踪,问题往往出在小处。

ref:http://blog.csdn.net/cheny_com/article/details/6590360

相关推荐