体验结对编程

pandapanda 2008-06-06

体验结对编程一周多的时间,遇到诸多问题和大家分享一下。

两名程序员,

一名为编程老手,有丰富的开发经验经常可以提供一些非常好的想法,只是对业务不够熟悉。

另一个是个菜鸟,但进入团队时间较早对业务也相对熟悉。

两人形成互补型结对组。

故事:

由于老手(A)并不熟悉业务,而且时间箱规定时间紧迫,第一周由菜鸟程序员(B)进行主要的开发工作,

AB两人在会议室简单沟通需求和场景后,进入开发阶段。B希望可以一边开发一边让A尽快熟悉业务以及相关API,

B(菜鸟)在开发时遇到一些关键需求时总要停下来和A程序员交流,包括使用到以前定义好的类和业务上下文。

有时两人会因为过去的代码不够简洁而讨论新的方案。

直到周六的下午(时间箱规定周六交付一个可以使用的版本),程序员B突然拍着自己的脑门大叫一声:晕~!!忘了一个需求。而且是关键性需求。

这导致近3天的工作付诸东流。需要重新考虑。

周六下午。程序员B很是郁闷。在会议室里苦苦思索为什么会出现遗漏。。。。。。

原因分析:由于老手A并不熟悉业务上下文,不能参与前期准备。只有程序员B知道下一步应该做什么。而B在开发中经常与A交流关于业务上的事情,导致编程思路不流畅。经常需要分神去解释和讨论,经过一段时间之后又回到自己的代码上。

开发过程由原来的:测试——开发——重构——测试

变成了:测试——开发——讲解——讨论——开发——重构——测试两次开发之间经历了漫长的讨论与讲解。导致菜鸟程序员精力不够,甚至出现致命的遗留问题。

之后两个人在会议室里分析了问题的原因,由于此时已经经过了一周的结对开发,程序员A也对需求渐渐明朗起来。

此时两人都意识到这样的开发过程过于缓慢。原计划2天完成的任务干了3天还遗漏需求。经过商讨决定下周实行新办法:两人一起站在白板前探讨需求,程序员A不明确的地方由B在这个时候进行说明,以及两个人的讨论都在这个时间进行,开发回归测试——开发——重构——测试

相关推荐