在过去的几个月里，我一直在撰写关于个人可以采用的微小、渐进的行为，以取得更大成功的文章。本月，我想重点介绍我认为对于在工作中取得小成功至关重要的团队行为。我花了一些时间与红帽公司的 AtomicOpenShift (AOS) 团队之一——Cockpit 项目团队相处。
虽然我花了大量时间与 AOS 团队相处，但我很少有机会直接与 Cockpit 团队合作。我很幸运有机会在今年早些时候我们都在布尔诺的时候与他们坐在一起交流了一段时间。从局外人的角度来看，这个团队在技术话题和个人话题上都能够轻松地相互交谈，这让人印象深刻。事实上，你可能会认为他们都在同一个办公室工作。然而，团队中的所有五位工程师和设计师都分布在欧洲和美国各地。
我很高兴在本月初与 Andreas Nilsson、Dominik Perpeet、Lars Uebernickel、Marius Vollmer、Peter Volpe 和 Stef Walter 进行了交谈。我们谈论了很多事情，但在采访过程中形成了三个中心主题
- 理解你的目标
- 使用反馈循环
- 致力于开放和透明的沟通
在接下来的三个月里，我的专栏将重点关注这些主题，以及你可以与你的团队一起做些什么来逐步改进。本月，我邀请你花时间与 Cockpit 项目团队一起工作，并了解他们正在做什么让他们能够成功地合作。
Cockpit 团队拥有广泛的持续集成/持续部署 (CI/CD) 系统。它如何帮助你们协同工作？
Dominik Perpeet (DP)： 首先，它让我们能够更专注于“有趣的事情”——开发新的和令人兴奋的功能。当所有东西在合并之前都经过测试时，如果可以将错误与特定更改联系起来，则审查某些内容会容易得多。老实说：如果没有自动化，我们根本无法以现在的速度交付。此外，告诉其他人，“嘿，我们刚刚合并了你的东西。你会在下周在 Fedora 上看到它——以及其他人！”，这非常令人鼓舞。
Stef Walter (SW)： 根据你的计算方式，Cockpit 项目采用了多达 100 个不同的系统 API，并将它们集成到一个连贯的体验中。这些 API 中的每一个都在不断变化，集成至关重要。如果没有持续的自动化集成，这将是团队中每个人的唯一工作。这是项目的关键部分。需要考虑的另一点是，定期和快速交付是开源和敏捷的关键组成部分。它将贡献者纳入其中。集成测试使这一切成为可能。
AtomicOpenShift 中的许多团队都参与了经过大幅修改的 Scrum 版本。你们在很大程度上避免了这个过程，但现在你们正在考虑将部分内容纳入你们的工作流程。是什么引发了这种变化？
SW： 最近，我们采用了 sprint 计划，但没有采用 scrum 的所有方面。主要目标是缩短我们自身开发过程的反馈循环。我们希望能够回顾我们在给定 sprint 期间从事的任务，有一个清晰的划界点来进行计划、回顾和迭代。
Andreas Nilsson (AN)： 我一直遇到的一个问题是，我从各种地方收到了很多不同的任务，但没有一个好的方法来确定这些任务的优先级。sprint 帮助我专注于重要的事情，并提供更好的估算方法。如果另一个东西想要加入，那么优先级列表中就需要移除一些东西。
Stef 经常谈到 设计驱动开发。它如何帮助你们实现目标？
DP： 当我们花时间“从顶层”（设计角度）考虑问题时，我们总体上浪费的时间更少，从团队中的其他人那里获得的好处最多，并且整个开发过程感觉不那么混乱。
AN： 它使我们能够在整个开发过程中更好地就我们正在构建的内容以及为谁构建达成一致，从写下我们正在构建的内容以及为谁构建开始，基于这些需求创建临时的角色，并基于这些角色的工作流程制作线框图。与在代码中浪费时间进行昂贵的迭代相比，它使我们能够更快地进行实验和迭代。
SW： 它还有助于我们跨项目进行协调。当首先拥有设计和故事时，它使与其他项目合作以实现给定目标变得容易。目标非常明确。没有它，在没有目标的情况下讨论实现细节通常是徒劳和令人沮丧的。
请告诉我更多关于你们的跨社区工作——Cockpit Origin 的信息。是什么让这项工作对你们有效？
DP： 就目标进行公开沟通——无论是我们的目标、他们的目标还是共同目标——以及如果工作毫无进展或存在其他缺陷，则愿意放弃工作。我认为在几乎所有跨社区工作中，各方都有所改进。我们不是孤立的——恰恰相反——因此，每次与他人的互动都意味着对内部和外部观点的更多校准。
SW： 设计驱动开发、用户故事和线框图带来了巨大的改变。当目标是明确的用户故事时，其他社区更愿意参与进来，他们可以就该故事提供反馈和迭代。
沟通如何影响团队的工作？
DP： 沟通是我们工作中非常重要的一部分。我们彼此之间都是远程的，因此沟通感觉更加自觉和有针对性。我们使用任何可用的模式，并且适用于我们想要实现的目标——面对面，无论是亲自还是通过视频聊天，当我们想见到彼此时；语音聊天，用于集思广益；IRC，如果我们需要公开讨论；电子邮件，用于保留记录和异步沟通；GitHub，用于设计或代码讨论。我认为所有这些也取决于心情和参与者。
时区是一个挑战，但可以管理。它们还会导致安静的工作时段，这也没什么不好。但是，我相信如果我们没有亲自见过面，我们就不会作为一个团队运作得如此出色。
SW： 开源工作本质上是分布式的。每当实施分布式工具或系统时，都会产生非零的开销。代码、微服务或开源都是如此。然而，那里的关键目标是分布式可以横向扩展，但我也同意 Dominik 的观点，我们对此很务实，有时在大多数人不在的时候，讨论会在 IRC 上进行。聚在一起讨论整体 项目目标 帮助我们建立了对我们想要完成的目标的基本理解，并使我们保持同步。
并非一切都尽善尽美。你们团队目前面临哪些挑战？
Marius Vollmer (MV)： 我们开始专业化，这增加了上下文切换成本以及在不熟悉的代码部分工作时破坏事物的风险。我们获得了更多反馈，这很棒，但也许我们没有做好充分的反应。
SW： 让开源社区进一步参与进来。我们确实收到了团队外部的贡献，但尝试帮助其增长是一个挑战。
AN： 在我们的东西最终会出现在其中的不同产品之间确定优先级。我还觉得我们缺少客户反馈循环。一旦事情得到实施，我们是否以一种对我们的最终用户有效的好方法解决了这些确切的需求以及确切地为谁解决了这些需求？
如果让你为任何从头开始的人提供建议，你会提供什么建议？
SW： 永远不要把集成测试留到以后。如果 Marius 没有尽早开始这项工作，那么将其作为未来的目标是很诱人的，那将是该项目的末日。此外，从一开始就尽早发布、经常发布并在任何地方发布。我们等待太久才分发 Debian 和 Ubuntu 软件包，这阻碍了项目的采用。
AN： 从第一天开始就启动设计工作流程。否则，你的竞争对手会一直让你绕圈子。
DP： 始终拥有清晰的长期目标，但永远不要害怕出于正当理由而改变它们。
评论已关闭。