您的位置:知识库 » 软件工程

敏捷开发“松结对编程”实践

作者: 陈勇  发布时间: 2011-09-30 12:55  阅读: 5091 次  推荐: 1   原文链接   [收藏]  

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

  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分钟”。这样既不会让徒弟被卡住,也不会让师傅因为经常被打断而导致无法工作。但师傅可以随时发起交流,因为他们是去帮助徒弟的,聊的也是徒弟的事情,不存在打扰的说法。

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

1
0

软件工程热门文章

    软件工程最新文章

      最新新闻

        热门新闻