来认识一下海森堡团队，深入了解一下这支优秀的团队。

我很荣幸能向大家介绍我过去三年一直引以为豪的团队。我们一起工作，经历了不少起伏。我们不断优化流程，不仅提高了工作效率，也提升了工作质量。我们学习了哪些事情该做，当然也学习了哪些事情不该做。如果您感兴趣，请坐好，系好安全带，和我一起踏上海森堡团队的征程吧。

我们是谁？

三年前，我们产品和工程部门进行了一次重组，把六个人组成了一个团队。我们来自世界各地——嗯，如果你把我们办公楼的楼层也算作一个世界的话，其实也差不多，因为在软件部门工作本身就是一个世界。总之，我们团队组建之初，大部分成员都已经在公司工作了，但也有些是新来的。

团队成员包括产品负责人 Mike。他一直努力推动开发必要的功能，为我们的产品制定清晰的路线图和愿景，最重要的是，他确保团队里的玩笑少到极致。我们还有 Scrum Master Niels。他不仅教我们如何运用 Scrum 进行敏捷开发，还带领我们进行指导，以提高我们产品的品质，同时也提升团队的整体素质。最后，我们还有四位软件工程师。我们共同努力，确保所有功能都以正确的方式构建，确保一切运行正常，并确保我们的产品负责人能够安心应对我们给他们安排的“过山车”般的挑战。

和所有开发者一样，我们每个人都有自己的怪癖。比如Johan，他总是试图说服所有人我们必须说荷兰语；还有Jo，一个热爱烧烤、武器和烂片的比利时人。这就像你的团队里有Chuck Norris和Jo Bonten的混合体。我们的第三位开发者最初是我们的好朋友Bert，他特别喜欢让我们在每个测试里都加上“arrange”、“act”和“assert”之类的注释，或者让我们删除C#文件中未使用的using语句。即使他两年前就离开了公司，我们仍然把这些注释叫做“Bertjes”。现在，他的位置由我们的巴西朋友Geraldo接替，他那令人惊叹的逻辑思维能力——把任何事情发生的概率简化成50/50——总是让人觉得很实用。最后是我自己，我不想在这里自夸，但如果你有机会来我的团队，我的队友们应该能告诉你很多关于我的奇葩事。我们这群怪咖就是海森堡团队。

你可能会好奇，为什么是海森堡？嗯，组建一支新队伍，最棒的事情莫过于起个名字。我记得我们列了一长串名字，电视剧、童年动画片，还有很多名字里都带“code海森堡”这个词。我们慢慢筛选，最终选定了几个，然后投票决定用这个名字。当然，我们当时想到的不是那位小有名气的德国物理学家维尔纳·卡尔·海森堡……好吧，其实不是，我们只是都喜欢那部电视剧。想想看，进门的时候说“我是敲门的人”，这感觉多棒啊！而且，这个名字还跟传说中的海森堡（Heisenbug）差不多，简直酷毙了，对吧？

全栈及更多

虽然我听说过软件工程师们对团队角色定义各不相同，但我们找到了自己的一套方法。从一开始，我们就达成共识：团队中的每一位工程师都应该能够胜任构建和维护产品所需的一切工作。你可能并非这方面的专家，但你应该了解基础知识并能够运用它们。这些基础知识涵盖了我们的全栈技术，也就是 React 前端和 C# 后端，但我们的工作范围远不止于此。我们每个人都会编写自己的测试，监控正在运行的产品，维护云端基础设施，维护 CI/CD 流水线，进行基本的设计工作，管理数据库，运行数据仓库，以及任何与产品构建相关的工作。去年，我们的 Scrum Master 离职后，我们也开始每周轮换 Scrum Master 的角色。虽然要跟上所有工作的步伐需要付出很多努力，但这种工作方式让我们在用户故事的快速迭代和减少彼此依赖方面拥有巨大的优势。此时，任何三位开发人员都可以去度假，第四位开发人员都能处理好他需要做的一切。

我们如何工作？

我们从团队成立之初就开始采用敏捷 Scrum 方法。这意味着我们会进行所有常规的 Scrum 活动，例如站会、迭代评审、迭代计划会议和回顾会议。我们使用用户故事、产品待办事项列表和迭代周期。但当我们深入探讨如何处理这些用户故事时，事情就变得更有趣了。

我们开始开发用户故事的第一步是进行“设计讨论”。所有工程师都会聚集在一起，讨论具体的实现方式。这通常会产生几个相当详细的任务，有助于我们集中精力推进用户故事的开发。在设计讨论中，我们还会考虑需要添加哪些端到端测试、监控测试和数据验证测试，其他测试则包含在常规任务中。接下来，我们会制定一个叫做“测试计划”的东西。其中一人会绘制思维导图，列出所有需要手动测试的内容，以确保用户故事的功能正常运行。虽然大部分测试都可以通过自动化测试完成，但我们仍然会进行这一步骤，因为尽管自动化测试很棒，但没有什么比手动测试更能让你全面了解一个功能的运行情况。你可以把它比作探索性测试，但手动测试有一些指导。之后，第二个人会审阅这份计划，并在审阅过程中根据需要添加更多步骤。

这就引出了那些总是需要处理两次的任务。一个人领取任务后，会在任务单上签名，完成所有工作（包括编写所有测试）后，勾选确认。然后另一个人领取相同的任务，并审核前者的所有工作。因此，任何任务都必须经过两个人审核才能算完成。

建筑审查

所有任务完成后，包括所有测试，我们还剩最后一项任务，我们称之为“架构评审”。我们会和团队所有开发人员一起，仔细检查代码中所有修改过的部分。我们会特别关注实体的命名方式、放置位置以及它们之间的依赖关系。我们会讨论代码和架构的未来发展方向。通常这意味着我们会做出一些调整，朝着我们期望的方向迈进。这能确保代码架构的健康发展，并让我们定期思考架构问题。

现在我们将代码推送到测试环境，运行自动化测试，并执行测试计划。此时，两位不同的开发人员会使用测试计划，在测试环境中手动执行并验证所有步骤。我们尽力找出至少一个问题，因为一位智者曾告诉我们，只要测试足够完善，就总能找到至少一个错误。而我们确实能找到问题，这种方法往往能发现许多我们原本会忽略的问题。一旦开发人员确认用户故事已完成，我们会向产品负责人演示，如果他签字确认，我们就将所有内容推送到生产环境并删除相应的功能分支。

我们学到的东西

团队合作中，我们会不断调整工作方式，以提高团队的整体素质和绩效。我们尝试了很多方法，有些效果显著，有些则不然。我很乐意详细介绍其中的一些。

蝙蝠侠和罗宾

除了我们的职能之外，团队里还有几个其他角色。你可以担任当周的 Scrum Master，你可以被指定在下次 Sprint 评审会议上做演示，最后，你还可以扮演蝙蝠侠或罗宾……（此处应有蝙蝠侠音乐）

这些角色在我们团队里算是比较新的，但效果非常好。你可能会问，它们到底是什么角色呢？嗯，如果你是蝙蝠侠，黑暗骑士，披风斗士，那么你的任务不仅是保护哥谭市，还要保障团队的正常运作。你需要处理任何可能出现的漏洞或其他突发事件。而且你并非孤军奋战，如果需要帮助，你随时可以依靠你可靠的搭档罗宾。听起来很棒，对吧？确实如此，而且效果显著！

如果你在团队中工作，你可能知道总会有各种各样的干扰。这些干扰可能包括需要报告的 bug、需要处理的导入信息请求，基本上任何不在当前迭代计划内但又不能等到下一个迭代的事情。我们的“蝙蝠侠”会接手这项任务，如果需要帮助，他会向罗宾求助。这样可以确保其他两位开发人员能够保持专注。任务完成后，“蝙蝠侠”就“退休”，罗宾会接替他成为“蝙蝠侠”。然后他会挑选一位新的罗宾，由他/她守护团队直到下一个问题出现。这样一来，任务就分配给了整个团队，大部分成员不会受到干扰，而且你偶尔也能体验一下当个酷炫超级英雄的感觉。

零缺陷政策

和其他团队一样，我们在处理bug方面也遇到过不少难题。你们是否总是优先处理bug而不是开发新功能？你们如何确保bug能够被快速发现和修复？你们可以采取哪些措施来降低bug出现的概率？

对于大多数问题，我们都遵循最佳实践。我们注重质量，编写大量的自动化测试，进行手动测试，并实施监控等等。但是，bug 是不可避免的，而且应该存在。如果你的代码完全没有 bug，那很可能是你把太多时间花在了追求极致的代码质量上。这个观点很有意思，对吧？也许哪天我会专门写篇文章来探讨一下。总之，我们采取的措施之一就是维护我们自己的“零 bug”策略。

大多数零缺陷策略的定义都很简单明了：如果存在已知缺陷，则在开发新功能之前先将其修复。虽然听起来很棒，但在实际应用中，这种做法在实用性方面略有不足。因此，我们制定了自己的零缺陷策略。任何已发现或报告的缺陷都会被调查、评估和讨论。如果缺陷的影响足够大，则会在当前迭代周期中优先处理；如果影响不大，则会将其放入待办事项列表，并在下一个迭代周期中优先处理。这意味着所有缺陷通常都会在一个迭代周期内得到解决，而我们的迭代周期为两周。我们发现，这种方案能够在保证我们预期质量和最大程度减少对新功能开发干扰之间取得最佳平衡。

共同努力

这一点听起来可能很简单，似乎没必要提及，但事实并非如此。团队合作的重要性怎么强调都不为过。在我们团队的方方面面，你都能感受到我们对这一点的重视。我们会进行站会，收集用户故事，还会组织“设计讨论”和“架构评审”等集体讨论活动。而且正如我之前提到的，每个任务都由至少两个人独立完成，这样也能有效地共享大量信息。

除此之外，我们办公室里总是充满欢声笑语。虽然不全是工作相关的话题，但这种畅通的沟通渠道至关重要。因为现在，当有人遇到难题、有疑问或需要任何帮助时，都可以很方便地在办公室里大声提出来。营造这种团队氛围的重要性怎么强调都不为过。当你走进办公室，你应该感受到自己是团队的一份子，而不是团队中的个体。当出现问题时，你应该作为团队共同承担责任。当完成冲刺任务时，你应该作为团队一起庆祝。一起吃午饭，一起做有趣的事情，创造一个让每个人都能畅所欲言、无所顾忌地谈论工作或生活难题的环境。只有这样，你才能真正打造一支优秀的团队。而这正是我们在海森堡团队所建立的。

团队学习活动

我们不仅一起工作，也一起学习。每两周我们会安排一个半小时，预订会议室，观看一段我们感兴趣的视频。看完视频后，我们会进行讨论，看看是否有什么新的方法可以改进我们的工作方式。这样，我们就能不断学习新知识，不断挑战自我，不断发现新的有趣概念。一开始我们看的是鲍勃大叔的视频，但现在我们会把遇到的所有有趣的视频都记下来，然后从中挑选一个来讨论。

群体攻击的开始

大多数开发团队都会时不时地进行结对编程，我们也不例外。但我们还会使用一种我称之为“集体启动”的方法。当我们开始一个新项目时，通常是一些我们还不确定如何实现的大型新概念，我们会预订一个会议室一两天，然后开始集体启动。集体启动基本上和结对编程类似，只是参与人数更多。我们共用一套键盘和鼠标，每10分钟轮换一次。所有操作都在一台连接着电视的电脑上进行，所以每个人都能参与其中。由于团队中的所有开发人员都参与其中，知识可以立即共享，每个人都必须了解正在发生的事情，最终才能找到适合团队的解决方案。这确实是一种快速启动一个你还不确定如何实现的新项目的绝佳方式。

你不是你的产品

这些年来，我还学到了另一件事。我加入过很多团队，见证过它们的兴衰更替，通常一个团队都只专注于一个产品。一旦产品完成，或者需要其他产品方面的帮助，团队就会离开。我逐渐发现，产品和团队之间的联系越来越弱。这让我意识到，与几个人一起开发产品和团队合作之间有着非常重要的区别。一个优秀的团队的优势在于团队协作，而不是专注于某个特定的项目。你可以专注于一个项目吗？当然可以。但这不应该定义你的团队。不要害怕参与其他项目，但要以团队的形式去完成它们。这才是你们发挥最佳水平的时候。

测试很难

这节课比其他课程更偏技术性一些，但正如标题所说，测试很难。难的不仅仅是编写测试，还有思考测试什么、测试适度、是否使用测试驱动开发（TDD）、如何命名测试、如何保持端到端测试的稳定性、如何保持测试的更新。还有一点……编写测试时要确保易于重构，同时又要避免让测试阻碍重构……哦，对了，我刚才也提到了这一点……

我很想说我们已经找到了完美的解决方案，但我认为并不存在。至少没有完美的技术方案。你需要的重要工具是经验、沟通和务实。经验：不断尝试。你可能会做太多测试，也可能做得太少，甚至命名错误。但要坚持尝试，练习越多，你就会做得越好。沟通：与你的团队保持沟通。互相挑战，共同实验，但一定要一起做。务实：不要过度设计。不要花三天时间为一个即使出错也毫无影响的功能编写测试。保持务实。

谢谢

最后，我想向团队表达我的感谢。感谢你们让我成为团队的一份子，感谢你们帮助我成长，感谢你们带给我这段精彩的旅程。

这篇文章也发布在我的个人博客上。