在大约三年的时间里,我有机会在我职业生涯中遇到过的最有趣的环境中工作。乍一看维护起来可能很复杂,但相信我,事实并非如此。结果不言自明。
结对编程是我们开发团队的默认设置,只有极少数例外,例如有人请病假或担任陪审员时1 。有些人可能认为结对编程很难实现,他们经常会问诸如“谁开车?”、“什么时候切换?”以及“一个人在编码时做什么?”之类的问题。当我向他们提起这件事时。
这些问题是完全正确的,对于不实践测试驱动开发(TDD)的环境,我会犹豫是否回答这些问题。 TDD 与结对编程一样是我们文化的核心。当与结对编程结合使用时,TDD 定义了驱动程序2的边界,明确了工程师何时应该转换角色。一名工程师编写了一个应该失败的测试,另一名工程师编写了使测试通过的代码。一旦测试通过,刚刚实现代码的工程师就会编写下一个测试,然后乒乓球继续进行。最终,每个人都编写了相同数量的代码。
虽然测试驱动开发 (TDD) 有助于通过清晰的契约和接口构建更好、更结构化的代码3 ,但结对编程提供了讨论从架构到代码设计决策的流程的每一步的机会。
在一个由 10 名工程师组成的团队中,无限期地与同一个人合作对我们来说不是一个选择。我们希望所有工程师都有机会在我们的移动应用程序的不同领域(以及前端后端,BFF)相互合作。所以我们实施了配对轮换。两名工程师配对的时间绝不会超过连续一天。例如,如果 Alice 和 Bob 今天配对,那么明天其中一个人会将位置移交给 Carol。如果爱丽丝在第二天将她的位置让给卡罗尔,那么鲍勃将在第三天与戴夫交换。
Day 1: Alice + Bob Day 2: Bob + Carol Day 3: Carol + Dave
重叠对于知识转移至关重要。
这让我想到了另一个话题:工作路线。这些与史诗类似,但更专注于实现完整的功能。车道可以持续几天到几周,并且它们通常是相互独立的。例如,通道可以负责实现照片备份、新的设置菜单或马赛克以制作图片拼贴画。
每个工程师在一条车道上工作了两天,然后才搬到新的车道。这种通道的重叠允许工程师之间进行知识转移。
这种设置的好处是显而易见的。使用 TDD 结对编程可确保工程师交付最佳工作成果,而轮换可确保他们从工程和产品的角度全面了解投入生产的内容。
这种设置促进了一种共享所有权的感觉,每个人都对产品和技术决策负责。不断的轮换也让工程师有机会对前几天做出的技术选择进行调整。尽早纠正方向总是比晚纠正更好,这样可以减少技术债务。
在此设置中不需要正式的代码审查,例如拉取请求。代码审查由处理该功能的人员实时进行,并且提交可以在一天中的任何时间合并到主分支中(在大多数情况下可以多次合并)。
共享所有权简化了团队中的沟通。任何人或任何人都可以随时解决问题。每个工程师都拥有回答产品负责人的问题、向设计师提供反馈或与外部团队互动的知识和背景。这也消除了“这是我的代码,我不想让任何人碰它”的感觉。
最后但并非最不重要的一个重要部分是Pow Wow 。这是一个简单的仪式,工程师可以站起来讨论 5-10 分钟的技术决策。没有任何手续,没有会议室,也不需要发出日历邀请。
因为我们对技术主题的看法一致,所以在计划会议期间很容易确定用户故事的大小。经过近三年的合作,我们有信心完美地调整我们的一周冲刺规模,这简化了我们的待办事项细化会议和计划。这对于我们的产品负责人来说非常有价值,他们能够尽可能保持待办事项的相关性和优先级。
因此,我们拥有了一支快节奏、团结的团队,共享开发过程的各个方面。我们充满信心地交付高质量的代码,每周发布更新,并为产品所有者和设计师提供支持。我们通过实时进行代码审查来消除时间浪费,并通过尽早解决错误的选择来消除技术债务。
当然,这只是故事的一部分。我们还与产品所有者和设计师建立了牢固的合作伙伴关系,但这是另一篇文章的主题。