过去十多年中,笔者曾经与上百个开发团队共同合作,这些团队具有一个共同的特点就是:他们通常不会采用结对编程作为软件交付的技术。其中一些团队会讨论结对编程并且认同这种理念,不过由于某种(些)原因,他们目前仍未采用结对编程。那么接下来的问题就是,是什么原因导致他们不采用结对编程呢?在我个人的经验当中,采用结对编程和协作仍有许多障碍。许多团队合作(cooperate)的很好,但实际上并不是协作(collaborate)。因为协作基于信任,它是结对编程的关键环节之一。
结对编程是软件开发过程中所使用的一种技术,两名程序开发人员共享同一台工作站,其中一名开发人员被称为驾驶员(Driver),另一位被称为领航员(Navigator)或观察员(Observer)。两人轮流使用同同一个键盘编写代码和测试案例。两个开发人员轮流使用键盘可以让每个开发人员都有机会思考设计和相应的实现。两人还能够从相互的思想交流中受益,通常能写出更加高效的代码。
结对编程的概念相当简单明了,而且在90 年代后期,极限编程(XP)的早期就已经开始有实际的应用。不过在我个人的经历中,它仍是使用最少的极限编程技术之一。敏捷实践和极限编程的流行让这一问题得以回避。据我的了解,结对编程仍存在许多障碍。
我们首先从组织层级开始分析。许多经理觉得开发者结对编程时,他们付出了两个开发人员的代价却只得到了一个开发人员的生产力。在团队刚刚开始结对编程时的确如此,不过只需经过很短的时间,结对就会以更快的速度交付更多的功能,而且经常只需要更少的代码,而且质量也会有一定的提升。结对编程能够帮助在进行测试之前就解决掉代码中的问题,遗留到生产环境中的会更少。
但组织级的挑战并未到此为止。还有一些关于实际环境方面的考虑。如今,开发人员通常会占据一个受限的工位空间。结对则需要至少6 英尺大的开放式座位空间,以便两人可以并肩坐在一起。有些组织还缺乏适用于结对编程的硬件,例如无线键盘,无线鼠标,以及至少21 寸的显示器。对于显示器来说,则是越大越好。
除了硬件设备之外,组织级的挑战还存在于对开发人员的认可、加薪和晋升的机制。组织对员工进行排名会严重限制开发人员有效地学习结对编程的可能性。许多情况下,开发人员希望被视为超级英雄,以借此提升其在同事之中的级别。另外一个阻碍是绩效评估。很少有公司会将团队合作视为一项有价值的技能,更多的是寻找能够拯救公司于危难之中的“超级英雄”。此外,一直处于在战术层面灭火模式的组织难以体会在结对编程过程中开发人员进行的技术和专业领域知识分享所带来的价值。
如果你的团队在尝试结对编程上仍保持谨慎,好消息是将结对编程融入到企业文化当中已经有一些公开的案例。其中一个例子是 Menlo Innovations 公司,他们要求所有的开发人员每天都要进行结对编程。结对编程是其招募员工的条件之一。虽然这并不一定对所有人都是最优的方案,至少能起到一定的作用。
让开发人员能够结对编程的一个关键因素是较高的安全系数。总的来说,绝大多数开发人员会担心被发现他们其实比他们所表现的要缺乏竞争力。有人将其看做是负担症候群的实例。负担症候群通常会出现如下症状:自己对自己的能力产生怀疑,而又极力说服其他人自己的确拥有这种能力。
一部分人会认为代码审查已经足够并且已经实际运转多年。代码审查的问题在于其发生在代码已经完成,而且常常是已经经过测试并准备发布时。如果发现问题,就会浪费许多编码时间,而且还不得不重新返工并测试这个问题,之后再次经过审查。不幸的是,这在代码审查中时常发生。更有甚者,开发人员会陷入哪一种技术最佳的争辩之中。这种情形下,要么最资深的人强制开发人员做出修改要么房间中最大的声音获胜。这两种情形都会破坏团队之中的信任感。
当要求开发人员尝试结对编程时,他们可能会有颇有微词。譬如:‘如果我自己做速度会更快’或者‘与同事结对编程没有任何意义,因为我不会从他们身上学到什么东西’或者仅仅是‘我已经尝试过了,但并没发现有什么作用’。尽管这些争辩可能是对的,但也可能只是他们感觉在有另一个人在场的情况下编程不安全。
最根本的挑战在于如何创建一个能够让开发人员觉得可以安全地学习、犯错、快速失败、持续提升技能的环境。由于失败会遭受惩罚,一些开发人员会害怕失败。会对失败员工做出惩罚的组织不太可能鼓励员工尝试和成长。
通常,一个团队中的成员会被聚集在一起,而不会作为个体互相了解。如果你的团队还不会在一起分享社交时间,那么这可能是一个最佳起始点。带领团队郊游、午餐、共享欢乐时光或者他们希望一起体验的其他活动。鼓励他们一起在办公室或外出午餐。宴请员工午餐或者郊游可以打消他们对开销的顾虑。向公司申请对此类活动的资助可能需要一点勇气,必要的话,团队领导要做好自己为此买单的准备。
为团队成员学习创造一个安全的环境可能会成为许多组织的挑战。一旦创造了一个适合于结对编程的办公环境,六英尺或更长的桌子和两张舒适的椅子,那么接下来就需要合适的显示器、键盘和鼠标。如果是第一次设置结对编程工作站,可以考虑使用一个只有白板的小的会议室空间。在实际编写代码之前,开发者喜欢在白板上草拟程序的设计和逻辑。现在你已经拥有了一个适用于结对编程的实际空间。
下一个挑战则是为开发人员提供一个便于结对编程的机会。例如,请一名资深开发人员与一名初级开发人员或团队中的新员工结对完成一个故事。在试验当中,每个个体都应该有机会尝试结对编程练习的机会。强制开发人员结对编程通常不会带来预期的收益。
我曾经用过并且有良好效果的另外一个技巧是雇佣一个有良好声誉的顾问作为强力开发人员。合约期限可以很短,两周时间就能够产生显著的影响。让开发人员知晓该顾问可以与他们进行1 对1 的代码会话,并建议他们参加一个小时的时间。可以建议他们用当前所分配的任务进行尝试或者让顾问分享一些练习案例。让团队与备受尊敬的顾问一起工作的另外一个好处是该顾问可能还会鼓励使用其他优良的技术实践,如 TDD 。
当团队就某项新的技术做出尝试时,务必从团队成员处获取匿名反馈,以了解包括结对编程在内的这类尝试效果如何。试着让团队成员自行发现如何才能在与不同的伙伴合作、结对时更加自信。对于新的技术实践,总是需要经过多次尝试之后,团队成员才能够得心应手。
有多种方式可以在工作之余鼓励结对编程,这时团队成员不会对他们在团队中的地位有太多顾虑。代码训练营和代码道场可以提供一个宽松的环境,在这里绝大多数人都是学习者,同时也能够分享他们的经验。敏锐的观察者可以识别出团队中最有可能尝试新技术的成员。与该成员一对一对话,鼓励他们建立自己的专业技能并为他们提供这样的机会。
其目的是让一个或多个开发人员发现结对编程其中的价值。无论结对编程的尝试结果如何,团队领导人/ 经理都应该对团队持支持态度,继续鼓励每个团队成员的个人发展。
对于安全感比较低的团队领导者,更加明智的选择可能是为团队成员播放一段结对编程的视频,或者鼓励他们阅读结对编程有关的书籍。Laurie Williams 与Robert Kessler 合著了《Pair Programming Illuminated》一书。书中分享了几种不同类型的结对编程的案例,包括哪些案例可行哪些不可行。另外一个选择是利用互联网。在互联网上快速检索可以找到大批量的结对编程有关的教程、视频和文章。
如果在鼓励结对编程这方面的尝试不太成功或者正在为团队寻找其他的协作机会,可以考虑在团队中开展Mobbing 会议。 Mob 编程正在获得越来越多的组织的青睐。Mobbing 的其中一个附加好处就是通过轮流在唯一的共享键盘上输入,每个人都能够参与到设计和编码当中。Mob 编程可以帮助在团队中建立更好的共享责任观念并且帮助增进团队成员之间的关系和信任。对于任何一项新的技术,团队都需要经过实践才能够逐渐适应。最后,随着团队成员之间彼此开始逐渐互相信任,他们就会更愿意尝试其他的新技术,这也就能够为他们开创一种更好的合作方式。
一旦团队开始接受结对编程,要不断鼓励他们尝试其他的技术实践。不论成功和失败,都要不吝赞美,因为这都是宝贵的学习机会。
关于作者
Linda Cook,广为人知的技术领袖和敏捷转型专家,致力于帮助组织实现战略目标。作为一名有着超过二十年经验的 IT 执行管理层,Linda 独特地将领导力、创新和愿景融为一体,帮助其解决最复杂的组织级挑战。目前她正在为 Project Cooks 有限责任公司牵头精益 / 敏捷咨询实践。
之前作为 PayPal 的一个敏捷计划的带头人,Linda 管理着该公司最大的 IT 创新,超过 500 名员工,跨越 4 个国家的 57 个团队。在该职位之前,Linda 领导了包括财富 100 强公司在内的多个大型组织的精益 / 敏捷转型,最高将团队的效率提高 250%。此外,她还管理了多个大规模系统开发工作,并带领多个敏捷项目成功通过 ISO 9001-2008 审计和 CMMI 评估。可以通过 linda@projectcooks.com 联系 Linda,或访问 www.projectcooks.com 获取更多信息。
阅读英文原文: Why Won’t They Pair?
评论