如今，许多从事软件开发工作的人都听说过结对编程的实践，但它在行业中的应用仍然参差不齐。它被接受程度不同的一个原因是，它的好处并不是立竿见影的，它更多地体现在中长期。而且它也不仅仅是“两个人共用一台电脑”，所以当它让人感到不舒服时，很多人会很快放弃它。然而，根据我们的经验，结对编程对于团队协作和高质量软件至关重要。

远程办公与集中办公之间并没有简单的二分法，相反，团队的分布模式有多种，每种模式都有不同的权衡和适合的有效技术。虽然不可能确定结论性的证据，但我的感觉是，大多数团队以集中办公的方式工作效率更高。但是，您可以通过使用分布式工作模式来打造更高效的团队，因为它可以让您接触到更广泛的人才库。

现代源代码控制系统提供了强大的工具，可以轻松地在源代码中创建分支。但最终这些分支必须合并回来，许多团队花费了过多的时间来应对他们错综复杂的分支。有几种模式可以让团队有效地使用分支，集中于整合多个开发人员的工作，并组织通往生产发布的路径。首要的主题是，应该经常整合分支，并将精力集中在一条健康的主线上，这条主线可以以最小的努力部署到生产环境中。

提交/展示/询问是一种分支策略，它结合了拉取请求的功能和保持提交更改的能力。更改分为提交（无需审查即可合并到主线）、展示（打开拉取请求以供审查，但立即合并到主线）或询问（在合并之前打开拉取请求以供讨论）。

平台团队特别依赖于其他团队来确保其平台的采用 - 将代码更改纳入其他团队的代码库对其成功至关重要。这种跨团队协作有多种模式，选择正确的模式取决于平台采用的阶段以及团队和代码库接受外部影响的能力。

如果您使用回顾，或者任何类型的会议，人们应该在会议上讨论和学习，您会不时地经历效率较低的会议。这并不奇怪，大多数人都会遇到这种情况。本文描述并提供了三种不幸情况的解决方案：跳过生成见解、迷失在您无法改变的事情中，以及被一个夸夸其谈的人所支配。

好的技术设计决策非常依赖于上下文。定期为共同目标一起工作的团队能够定期沟通并快速协商变更。这些团队表现出强大的协作力，并且可以做出技术和设计决策来利用这种强大的力量。当我们放大到一个更大的组织时，在独立工作且协作频率较低的团队和部门之间存在着越来越弱的力量。认识到这些强弱力量的差异，我们就可以为每个级别做出更好的决策，并提供更好的指导，从而使团队能够更快地行动。

技术正在变得越来越智能、越来越强大。我经常观察到，随着这些技术的引入，组织的生产力非但没有提高，反而降低了。这是因为该技术增加了开发人员的复杂性和认知负担，降低了他们的效率。在本文（系列文章的第一篇）中，我将介绍一个最大化开发人员效率的框架。通过研究，我确定了关键的开发人员反馈循环，包括开发人员每天执行 200 次的微反馈循环。应该对这些反馈循环进行优化，使其对开发人员来说快速、简单且有效。我将研究一些组织如何利用这些反馈循环来提高整体效率和生产力。

启动是在项目开始时进行的一项活动，目的是将相关人员召集在一起，为正在进行的工作设定共同的方向和工作方式。精益启动是一种重点突出的启动形式，可以在一周内完成。在此期间，我们将了解产品的关键功能和客户，并构建一个画布来制定最小可行产品的特征。

加速意味着更快地行动，获得速度。有效地处理数据对于任何希望在现代世界中蓬勃发展的组织来说都是关键，数据网格正在向组织展示如何大规模地从其数据中实现价值。数据网格加速研讨会通过了解团队和组织的当前状态并探索下一步的工作内容，帮助他们加速数据网格转型。

传统的文科学位提供了与产品经理高度相关的技能

获得良好的音频，使用图库视图，不说话时静音，并欢迎猫咪的到来。

我们和我们的同事经常被要求为客户执行架构评估。当我们这样做时，参与这些系统的架构师会谈论这些系统的性能、它们对故障的弹性，以及它们是如何设计成易于发展以支持新功能的。然而，很少被提及的是，不同的系统如何为业务价值做出贡献，以及这种价值如何与其他架构属性相互作用。

结对编程的好处已被广泛接受，但围绕结对轮换的建议仍然存在争议。团队成员应该何时以及多久轮换一次配对？以及……如果我们每天轮换配对会怎么样？我们与三个团队一起进行了一项每日结对轮换的练习。我们开发了一种轻量级的方法，帮助团队反思结对的好处和挑战，以及如何解决这些挑战。最初的恐惧被克服了，团队发现了频繁轮换配对的好处。我们了解到，频繁交换配对可以大大增强配对的好处。在这里，我们分享了我们开发的方法、我们的观察结果，以及参与团队成员分享的一些常见恐惧和见解。

不久前，我正在和一位即将走上学术道路的博士后聊天。他问我关于研究课题的问题，希望我能给出一些意见，因为他觉得我能告诉他哪些研究具有实用价值。我并没有帮上什么忙，但我确实提到，最好的方法是在行业中待一段时间，感受一下软件开发在现实世界中的运作方式，以及哪些问题可以通过一些研究工作来解决。他对这个想法的回答非常令人不安。

一致性地图是组织信息辐射器，有助于可视化正在进行的工作与业务成果的一致性。这项工作可以是常规功能添加，也可以是技术工作，例如重新架构或偿还技术债务，或者改进构建和部署管道。团队成员使用一致性地图来了解他们的日常工作旨在改进哪些业务成果。业务和 IT 负责人使用它们来了解正在进行的工作与其关心的业务成果之间的关系。

当人们使用“软件架构师”一词时，他们是在借用建筑施工中的比喻来帮助人们理解架构师的角色。讽刺的是，在这样做的时候，他们误解了建筑师的实际角色。

随着人们对数据分析和可视化的兴趣日益浓厚，我们看到人们正在投入更多精力来开发有趣的可视化，让人们能够从组织中流动的数据中获得洞察力。大多数此类仪表盘都面向个人使用，但越来越多地倾向于将它们用于更公共的目的。

关于敏捷方法，有一个常见的误解。它集中在用户故事的创建方式以及它们在开发活动中的流动方式。这种误解是，产品负责人（或业务分析师）创建用户故事，然后将它们交给开发人员去实现。这种想法认为这是一种从产品负责人到开发人员的流程，产品负责人负责确定需要做什么，而开发人员负责如何做。

敏捷软件开发打破了需求分析、测试和开发之间的一些壁垒。部署、运营和维护是其他一些活动，它们与软件开发过程的其他部分也存在类似的分离。DevOps 运动旨在消除这些壁垒，并鼓励开发和运营之间的协作。

在会议或研讨会期间，不时地对一些事情进行投票，以便对它们进行排名或选择一个子集，这是一件好事。点投票是一种快速而有效的方法。

开放空间是一种帮助你组织自组织会议的方法。我第一次接触到它是在 1997 年，由 Norm Kerth 介绍给我的，从那以后，我多次看到它被使用，我自己也使用过很多次。它似乎在小规模（十几人或二十人的小组）和大规模（一两百人）中都能很好地工作。我见过它持续一到三天。我将描述我所见过的各种变化：Crested Butte 是一个每年举办一次的小型研讨会，大约有 20 人参加，2002 年敏捷大会 在一个采用开放空间的轨道上有大约 100 人参加（从那以后，他们一直在这样做，但我一直没能去那里），Foo Camp 则有几百人参加。这项技术是由 Harrison Owen 开发的，在他的书中有很好的描述。

结对编程是一种软件开发实践，它要求开发人员两人一组地工作。所有重要的代码都是由两名程序员编写的，他们通常并排坐在一台显示器前，通常使用同一个键盘。在添加代码时，他们会一起讨论每一步。

关于 结对编程 的一些常见误解。

通信技术的进步导致越来越多的团队以 远程优先 的方式工作，这一趋势因新冠肺炎疫情的强制隔离而得到加强。但是，远程工作的团队仍然可以从面对面的聚会中获益，并且应该每隔几个月就进行一次。

所有敏捷方法都强调系统开发人员与最终受益的客户之间直接互动的重要性。敏捷宣言指出“业务人员和开发人员必须在整个项目中每天都在一起工作”，这强调了互动的高频率。极限编程通过其 现场客户 的实践来强调这一点。

当人们想到代码审查时，他们通常会想到开发团队工作流程中的一个明确步骤。如今，在 拉取请求 上执行的集成前审查是最常见的代码审查机制，以至于许多人天真地认为不使用拉取请求就完全没有机会进行代码审查。这种狭隘的代码审查观点不仅忽略了许多明确的审查机制，更重要的是，它忽略了可能是最强大的代码审查技术——由整个团队进行的持续精炼。

项目时间线是在 项目回顾 期间生成的一件很有价值的东西。时间线应该显示项目期间发生的各种事件，以及它们如何影响项目。

你在敏捷项目中经常会发现，开发团队坐在一个开放式的团队房间里。这在极限编程的早期就被提倡，并在第二版中被列为主要实践之一。敏捷主义者喜欢开放式的团队房间，因为它可以促进团队成员之间大量非正式和深入的沟通。

如果你正在使用 XP 风格的计划，你需要从开发人员那里快速获得一致的估算。抛出估算可以让你快速判断开发人员对估算的看法是否相似（这样你就可以记下来并继续进行），或者是否存在分歧（当你需要更详细地讨论 用户故事 时）。