学习软件匠艺让我重新思考如何编写代码。作为一位经验丰富的软件团队管理者，我尝试按照相同的方式来重新评估我的管理实践：测试驱动管理和结对管理将会是什么样子呢？在本文中，我分享了将软件匠艺工具和思想转移到管理领域的见解。

我经常听到开发人员抱怨说，他们的主管正在让他们背离敏捷和质量实践，但是他们却没有对其必要性提出质疑。所以，我长久以来一直想知道一个理想的管理者应该是什么样子的。为此，我询问了十多位软件工匠，严格做到了这一点（参见“软件匠艺视角下的管理者角色演变，法文”）。不出所料，他们告诉我，他们首先要寻找的是那些能够向他们传授业务知识的管理者（导师），然后是在组织中推广和捍卫这些实践（倡导者）。

令我感到惊讶的是，对他们中的一些人来说，这还不够，有时甚至完全没有必要：他们唯一要求的是自主权。但是，让我深有触动的是一位开发人员告诉我，她所经历的最好的管理者是同样以匠艺的方式管理软件工匠的人。他们在管理方法上有着相同的质量实践和立场。

我并不是说，你可以把一个领域的做法复制到另一个领域。我想说的是，如果你有相同的动机，那么有些实践就能很好地从软件匠艺移植到管理领域中。

也就说，这不仅仅是理论而已。当我尝试为团队命名时，我有一种为方法命名的相同感觉，我知道自己想出的第一个名字不会是最好的。但是，最有意思的是我尝试改变组织结构的情景，当我试图以大爆炸的方式改变一个 30 人的团队时，发生的情况与我们想以大爆炸的方式替换一个遗留系统一样，结果就是撤销回滚了。该组织非常抵制，以至于把我踢了出去。我现在非常反对大爆炸式的组织变革。

在软件开发中，还有一些适用于管理的通用实践。首先，可以将你的预算编制过程组织成一个 CI/CD 流水线。让预算定义成为很容易重复的事情，并且使其适应你的组织。CI/CD 能够让我们把任务放到一个流水线中，从而避免麻烦的任务。作为经理，我发现预算编制是最繁琐的任务之一。

其次，熟练掌握你的工具。如果在你的组织中，管理者们使用 MS Excel 作为工具的话，那就成为一个 MS Excel 专家。

第三，就像反应式编程一样，让你的决策尽量做到反应式。在做决策时，要保持异步，尽可能减少“提交”阶段，也就是减少那种每个人必须出席，但是只是表达同意意见的会议。对我而言，我觉得保持这种会议也有一定的必要性，在这种会议上，我从不处理事先没有足够时间与大家彻底讨论明白的问题，这种问题可以通过一个简单的异步邮件主题来进行讨论，每个人都有机会发表自己的观点。

除了上文提到的实践之外，我觉得还有两个软件匠艺的实践，它们对管理者非常有用。第一个是代码审查。就像代码在部署至生产环境之前，至少要有两个人进行阅读那样，我尝试与其他人一起审查我的管理决策，可以是同事或老板，最后我发现让自己团队的人来审查是最好的。

但是，在我的公司 Arolla 内部，我们将这种审查推行地更为彻底，也就是实现了结对管理。我们有两个负有相同责任的副总裁。这并不是我们将团队一分为二，而是管理着两倍大的团队，但是一起来进行管理。我们确保一个人说的每句话都会由其他人共担。在实践中，主要有两种情况：要么我的行动与我们共同定义的愿景保持一致（例如，“通过实践小组提高专业知识”），那么我就采取行动去执行；要么与不同的目标产生了冲突（例如，“短期收入”与“长期培训”），那么我就询问其他人的意见。

我发现，在开发中审查代码与在管理中分享和委托责任，归根到底是一回事儿。当我审查一段代码时，它就成为了我的。这就是我如何看待代码审查与管理 3.0 中的委托实践的关系。相应的，管理 3.0 所提出的不同委托级别可以作为一种方式来理解代码审查中的不同力度：你接受把多大权限委托给代码审查者？

我发现第二个真正有用的软件实践是测试驱动开发。作为管理者，我每天都在使用它，并把它翻译成“测试驱动的管理（Test-Driven Management，TDM）”。TDM 是一种保证管理质量的方法，与我使用测试驱动开发保证代码质量的方法如出一辙。它有同样的三个原则：测试优先、使用较小的步骤并产生一个新的设计。

因此，TDM 的第一个原则就是在行动之前阐明你的目标（测试优先）。例如，我把我的目标表述为一个假设，希望我提出的行动能够帮助验证这个假设。这可以非常简单，比如将“让我们实现一项伟大的事业”改成“让我们实现一项伟大的事业，这项事业应该能够让我们定义更小的版本发布”。

这也是我之所以要求我指导的管理者们避免使用表述性语言的原因，根据相同的原则，这是因为在规范中出现并不意味着最终会在软件中出现。例如，不要只是要求团队按时交付，而是与他们一起研究优先级，并确保他们不会因为你是主管就听从你的意见，并想取悦你。

但更实际的做法是，在按照“测试优先”的方式做事情时，你只需要起草一封本应该在任务完成之后才发送的邮件，只不过现在我们在任务开始之前就这样做。这样，你就不会迷失方向，犹如在黑暗中拥有一盏明灯，以准确知道任务何时才算是完成，也就是在电子邮件可以真正发送的时候。这就是为何你必须要写出真正要发送的邮件，而不仅仅是纸上的目标。它必须要进行“编译”，就像单元测试一样，所以很容易就能知道是否达成了自己的目标：你可以点击“发送”按钮吗？如果可以发送的话，那就立即发送它，并马上编写新的“未来邮件”，然后继续下面的任务。

TDM 的第二个原则在于，与 TDD 类似，假定你不会一步到位地达成你的目标（“使用较小的步骤”）。当遇到复杂的问题时，不要试图在全局范围内进行沟通，要对其进行逐个击破。例如，当我们遇到歧视的问题时，我们并没有试图一次性解决这个问题，而是尝试从解决性别歧视的笑话开始，看看系统的反应如何。

TDM 的最后一个原则，与 TDD 类似，就是允许组织的设计逐渐成型。这是最困难的事情，因为我们不可能像在某个方法的职责发生变化时，对其进行重命名那样轻易地去更改一个团队的名称。所以，我发现最有用的一点就是，在试图改变组织之前，先与组织内的人进行协作，然后，让人们选择改变他们所遵循的流程。为了说明这一点，我经常会讨论 UI/UX“设计系统”是如何在一个开发面向用户的应用的组织中出现的。最初，职责被分配到不同的功能团队中，这些团队的前端开发人员独立地构建其 web 组件。很快，责任会由专门的人来承担。最后，在一到两年之后，会由一个特定的团队来维护它，具有特定的流水线和自己的“演示项目”。

绕了一个小弯子，我发现当我与合弄制（holacracy）组织中的人员进行交谈时，他们的“tension”（在合弄制中，tension 指的是现实状况与潜在的愿景中的差异，也可以理解成一种改善的机会，请参见如下两篇文章的介绍，“ Core Concepts, Benefits and Limitations”和“Holacracy® Basics: Understanding Tensions”——译者注）概念似乎非常类似于测试驱动管理中的单元测试。简而言之，tension 是团队成员报告的一个具体事实情况，该情况使他们难以承担自己的责任。这种现实情况阻碍了目标的实现。按照我的说法，在合弄制中“tension 的解决”过程就是重构组织的方式，一点点地解决我们想要解决的具体的小问题，就像我们在 TDD 中使用小的单元测试重构软件一样。

事实上，改变各个团队的职责，同时能够避免重命名的问题，并且每个月以标准化的方式改变流程，这些做法已经在某些类型的组织中以标准化的方式在进行了，这种组织叫做学习型组织。

我并不是说你必须要采用合弄制才能实现质量管理，但我认为在学习型组织中，这要比在更僵化的组织或建立在个人意志和权力上的组织要简单得多。为了给这种管理类型一个名称，我决定将其称为“领导力匠艺”。

借助这个术语，如果重新表述我之前所说的内容，那么将会是这样的，作为领导工匠，需要具备与软件工匠类似的才能（aptitude），比如测试驱动管理、结对、持续预算、工具专家和反应式决策。

但我们也知道，软件匠艺是围绕态度展开的。作为一个领导工匠，应该具有与软件工匠一样的态度，主要是尊重，尊重自己，尊重团队成员，也尊重未来管理他们的管理者，还要尊重团队的前任管理者和他们的遗产。这也关乎节俭，寻找韧性和可扩展性。这就需要谦虚地赋予教学、学习和指导以价值。

回到才能方面，有一种才能是软件工匠们所熟知的，但我还没有谈到过，那就是给予反馈的能力。作为一位开发人员，我们在审查代码时，以及与业务的讨论中（例如，讨论 BDD 中的具体例子）会不断练习该才能。

反馈是一切的核心，作为领导工匠，你也需要反馈。要做到这一点，首先，不要忘记产出（output）和结果（outcome）的差异。更多的权力可能是你的产出，但它不是组织的结果。然后，不要试图像观测 IT 系统那样观测你的团队。团队的反思能力和自我组织性要强得多。团队中的人可以在一定程度上监控自己。

或许，这可以形成一个领导力匠艺宣言，其中会有如下两条首要的原则，即“领导工匠更喜欢对话而不是监督”、“领导工匠更喜欢自我监督而不是外部控制”。如果你有任何想法来对其进行丰富，那么我很高兴和你对此进行讨论。

请记住，上述所有的内容均来自我作为一个开发人员和管理者的感受。为此，我尝试了一个实验，甚至决定更进一步，那就是对组织本身进行编码。目的是看一下精确编码实践是否能够通过代码映射到精确的管理实践中。因此，我决定在 Java 中建立一个简单的组织模型，并使用经典的代码重构方式对其进行重构，比如“内联”、“将方法移至参数”、“抽取方法”、“重命名”等。这种方式很有效：“内联方法”就像在工作现场“去实地看一看”一样；“将方法移至参数”就像把责任移交给别人一样，当责任发生变化时，对角色进行重命名的冲动马上就会出现。在 领导力匠艺 kata 中，有一小部分关于该内容的节选。

然而，当我第一次向一组参与者介绍这个理念时，其中有位参与者 Laurent Bossavit 告诉我，有人已经针对这个问题撰写了论文，这就是 Leon J. Osterweil 在 1987 年的论文。这篇论文是 1987 年发表于 ICSE 的 “软件过程也是软件（Software processes are software too）”，作者探讨了过程在提高软件产品的质量以及我们如何开发和演进它的重要性。另外，1997 年 ICSE 发表了 “软件过程也是软件，修订版（Software processes are software too, REVISITED）”，其目的是澄清对第一篇论文的一些误解，并规划未来的研究方向。

所以我读了他的论文，我发现他最宝贵的建议之一就是，在涉及人的地方，应该把方法留白。Osterweil 总结说，软件不仅仅是代码，它还有过程，还有人类参与的过程。但是，准确来讲，我们不应该试图对保有人类参与的地方进行编码，以避免将人变成机器人。

我认为，这是一个漫长的旅程。我已经开发了 20 多年的软件，管理开发团队超过了 15 年，并在几年前开始辅导管理者。有时候，我很难将管理者所期望的管理方式与我的团队成员所希望的方式进行匹配。这并不是在两个领域进行智力方面的比较，而是如果我们在两个不同的领域做事时感受到类似的东西，请相信我们的感觉。我希望其他的管理者也能在这里找到有用的提示，或者他们觉得自己离经叛道时，能够得到一丝惺惺相惜的安慰。也许有些开发人员也愿意向他们的管理者提供建议。

原文链接：

Craftleadership: Craft Your Leadership as Developers Craft Code(https://www.infoq.com/articles/craftleadership-developers-craft-code/)

相关阅读：

软件架构决策指北：怀疑主义的软件架构设计 (https://www.infoq.cn/article/K7QazDeyGYFS8NWBK54V)

当你的技术栈不能满足每个人需求时，下一步是什么呢？(https://www.infoq.cn/article/7Ps0qyHfQhp59g7YrEvZ)

基于契约的开发：通过明确需求优化软件开发流程 (https://www.infoq.cn/article/g6D7e4ki76V3dRBWkrrK)