体验结对编程

体验结对编程一周多的时间，遇到诸多问题和大家分享一下。
两名程序员，
一名为编程老手，有丰富的开发经验经常可以提供一些非常好的想法，只是对业务不够熟悉。
另一个是个菜鸟，但进入团队时间较早对业务也相对熟悉。

两人形成互补型结对组。
故事：
由于老手（A）并不熟悉业务，而且时间箱规定时间紧迫，第一周由菜鸟程序员（B）进行主要的开发工作，
AB两人在会议室简单沟通需求和场景后，进入开发阶段。B希望可以一边开发一边让A尽快熟悉业务以及相关API，
B（菜鸟）在开发时遇到一些关键需求时总要停下来和A程序员交流，包括使用到以前定义好的类和业务上下文。
有时两人会因为过去的代码不够简洁而讨论新的方案。
直到周六的下午（时间箱规定周六交付一个可以使用的版本），程序员B突然拍着自己的脑门大叫一声：晕~！！忘了一个需求。而且是关键性需求。
这导致近3天的工作付诸东流。需要重新考虑。
周六下午。程序员B很是郁闷。在会议室里苦苦思索为什么会出现遗漏。。。。。。

原因分析：由于老手A并不熟悉业务上下文，不能参与前期准备。只有程序员B知道下一步应该做什么。而B在开发中经常与A交流关于业务上的事情，导致编程思路不流畅。经常需要分神去解释和讨论，经过一段时间之后又回到自己的代码上。
开发过程由原来的：测试——开发——重构——测试   
变成了：测试——开发——讲解——讨论——开发——重构——测试  两次开发之间经历了漫长的讨论与讲解。导致菜鸟程序员精力不够，甚至出现致命的遗留问题。

之后两个人在会议室里分析了问题的原因，由于此时已经经过了一周的结对开发，程序员A也对需求渐渐明朗起来。
此时两人都意识到这样的开发过程过于缓慢。原计划2天完成的任务干了3天还遗漏需求。经过商讨决定下周实行新办法：两人一起站在白板前探讨需求，程序员A不明确的地方由B在这个时候进行说明，以及两个人的讨论都在这个时间进行，开发回归  测试——开发——重构——测试