技术债务管理团队的斗争

在现实世界中，没有技术债务管理团队，一个致力于解决和解决技术债务的团队。没有人想成为这样的团队。这是一个正在清理其他开发人员的混乱的团队。谁喜欢这件事？

但是，我们确实有更多专业的团队，例如，基础设施团队，建筑团队，核心团队等 - 一目了然，迷人的名字。该团队负责在下面的图中的核心协调器/依赖项组的示例中执行使用的应用程序的核心主体。

注意：您可以找到更深层次的潜水，为什么本文中软件（移动）开发的可扩展性所必需的。

如果我们思考一天的发展之一，就没有任何核心团队，因为只有一切都是一切的团队。然而，随着时间的推移，团队成长。我们现在需要更好地分区工作，其中一些团队负责功能传递，部分团队负责公共代码，如下所示。

然后，拥有公共代码的团队是负责探索要重构，改进，更好地对齐的特征团队的代码，以便可维护性和可扩展性。这项工作基本上就像管理技术债务一样。因此，呼吁该组织技术债务管理组织并不是一个错误的人。

无论如何，本文的重点不是定义组的名称 - 您可以命名IT核心，基础架构或架构 - 但要制定这样一个团体的斗争，并探索帮助它的方法。

以下在本文中，我将互换地使用名称核心组，基础架构组和架构组来描述此类组的斗争。

对于一些组织，没有边界。建筑团队拥有一切。他们授权特征团队的所有活动：它们代码的方式，他们实现的类等。这使得它非常一致并对齐。

但它使特征团队非常不灵活。他们只能使与架构团队提供的内容完全对齐的事情。如果他们想做建筑团队定义的东西，他们将需要咨询架构组。建筑团队成为瓶颈。

鉴于上述情况并不理想，也许核心组应该只负责所有现有的公共代码。但普通代码的定义非常模糊。也许它只是一些常见的数据层和实用程序功能。如果我们将公共代码定义为所有要素组使用的代码，则只能是代码的非常小部分。

这样的结构很大，因为它为每个特征团队提供了自由，以便在不被核心组被阻止的情况下工作。缺点是（如上图中的不同颜色所示），每个功能团队工作的方式都会大大偏离。常见使用的潜在模式，函数和数据可能已经以各种方式跨越功能团队重复，而无需探索如何为常用方式抽象，因此工作的可扩展性受到损害。

寻找核心组应该拥有的正确边界是考虑的棘手部分。它还取决于核心组内的团队能力以及他们可以采取多少。

形成核心团队时的初始阶段很难。我建议开始小并定义焦点区域核心团队可以拥有为特征组带来的价值。也许它可以是一些实用功能等。

随着时间的推移，它可以长大地咀嚼，因为它更有能力。它可以讨论跨特征团队的普遍性的抽象组件，并从那里扩展。

有时，组织的任务是使架构组定义所有其他团队的标准或规则符合。这个想法回到了工业化的时代，在工厂生产地板上的对齐将提高可扩展性并减少浪费。

即使是对面向对象的编程，在其早期的时期倡导，通过具有定义基类的能力来符合符合性。基类由核心团队拥有，而功能团队则只需实现基类。

这种方法存在好处，其中特征团队可以在没有必要自己实施它的情况下获得所有普通代码福利。根据上面所示的非常简化的图，依赖关系1,2和3都注入基类，因此该特征类将免费提供。

为了完全符合，不应该创建自己的基类。每个新课程都必须通过建筑团队。原因是，这将避免跨特征团队的意外复制。如果另一个功能团队想要一些新的东西，他们将必须与架构团队联系，看看是否已经提供了。如果没有，架构团队将为他们制作该基类。

从上面来看，它是一个专制的开发方法，我们可以看到它不会缩放。瓶颈将在建筑团队中。此外，无论建筑团队提供什么可能无法满足每个团队的需求。该架构团队将忙于架构每个团队所需的变体，或者将提供特征团队不充分利用的通用类。无论哪种方式，它都不是理想的。

相反，我们可以走到另一个极端：核心团队没有任何授权。它们只提供常见的实用程序，这取决于要考虑使用它们的特征团队。

正如最近的首选编程方法一样，“优先于继承中的组成”，如下所示。

功能团队没有义务符合基础团队提供的任何内容。他们可以使用所需的内容甚至不使用基团的任何东西。特征团队在实现他们喜欢的内容方面具有充分的灵活性。

这极端也有缺点。没有一定程度的授权，就什么是常见的做法，而不对齐，团队可以多样化。潜在的浪费和重新工程可以在不同的团队中发生。

我们必须在符合要求所需的内容之间进行平衡，很好的是有“有用的支持公用事业”以及在那两个之间的事情。

为了完全符合，一个非常好的例子是分析要求，在那里我们需要所有功能，以符合它需要触发的方式。

至于“有用的实用程序”，这些可能是团队可以轻松采用的常见UI组件，而不会创建新的组件。 （可以说，一些设计师可能会说明这需要完全符合，以确保团队中的一致设计。）

对于其中的事情，这可以是一种颜色集，其中某些颜色需要一致，而其他颜色需要一致，功能团队可以灵活地选择一系列预定义的颜色。

不是每个人都会同意我的例子，但你得到了这个想法。核心团队需要与所有团队合作，以定义什么＆＃39; sensite和什么＆＃39; s flexible。这不是一个简单的过程。

好的，所以我们想要形成一个核心/建筑/基础设施团队。我们应该考虑谁搬到谁？也许我们选择一个专家开发商和一个初级开发人员的通常构成（假设我们没有许多人挑选的奢侈品）。

特征团队怎么样？也许他们与核心团队有相同的构图。然后每个团队都有一致的团队成员组成，相当分布。

虽然这听起来合理，但这种组成可能存在一些挑战。我们必须认识到以下内容。

核心团队成员正在实施全部使用的通用组件或形成与所有组交互的公共抽象。这不是所有初级开发人员准备好的东西。与此同时，我们不能依赖于一个专家开发人员来定义一切。

核心集团的主要“客户”是特征小组，是一组开发人员，其中一些专家。同样，初级开发人员将有限的能力与更有经验的“客户”联络，以形成稳固和有意义的东西。依赖于核心组中的一个专家开发人员来处理所有组将不会扩展。

鉴于这样的情景，也许我们需要在核心组中拥有所有专家开发人员。这是更好的，因为我们处理与特征组合作的可扩展性的挑战。但是，在团队中拥有所有专家将有挑战定义团队的方向。也许我们可以通过专家领导来定义方向。

其他挑战是核心组支持的许多功能团队。如果他们中有太多，我们如何扩展核心组以提供最佳的互动和支持？

在我看来，如果我们想建立一个坚实的核心组，它肯定需要在更多高级开发人员中拥有一个拥有经验的团队中的构成。该团队定义并开发了大部分核心，或者也许是所有的架构，从而需要其工作需要在技术上牢固和声音。

最重要的是，如果允许的话，在每个相应的特征团队中将核心团队（图中的特征群中的彩色绿色彩色绿色彩色绿色）有价值。组织地，他们可以成为特征团队的一部分，但他们积极参与决策，并成为核心团队产品发展的一部分。

他们在特征团队中的存在也让他们作为监督者，以确保在功能开发中的必要方向，并继续识别核心团队可以扩展的领域。这位大使再次，还需要成为具有适当技术经验的人，以便处于如此作用。

因此，核心组的领导需要成为可以管理一组专家开发人员的人，而不仅仅是在核心组内，而且是在特征群体中作为其大使。

对于产品，通常我们有一个产品经理来监督特征上所需的增强功能。他们与利益相关者联络，不断与客户群互动，以了解下一个最佳工作的感觉。

该功能的开发人员从产品管理器中获取一个输入的单个输入，并在下一步做什么的方向和优先级。开发人员不需要尽可能多地处理利益攸关方。重点是工作。

核心组不再在外部使用的功能中使用。他们不面对外部客户。没有真正的“产品”，而且没有必要是该组的“产品”经理。

但核心团队确实有利益相关者。他们是特色团队。核心团队需要与一群开发的开发人员联络，他们正在开发和提供对所有功能有意义的工作。

在特色小组中与同伴开发人员联络的过程，讨论需要的是需要的，并在需要优先顺序等方面来妥协，需要特定的产品和利益相关者管理技能。

通常，开发人员无法配备此类技能。如果没有适当的产品和利益相关者管理，本集团将无法识别其方向和重点，因为每个功能组的需求都可以明确多样化。

在一个理想的世界中，这样的团队将有一名技术产品经理，技术和利益相关者管理技术和利益相关者管理。持有这篇文章的人也可以是该集团提供指导的小组的技术领导者。必须提供充足的时间才能与特色团队合作和联络，并且一个人必须牺牲一个人的时间专注于刚才技术工作。这是一个艰难的作用，因为一个仍然需要及时了解其技术能力。

或者其他选择是拥有监督核心团队的主要开发人员或建筑师，并影响特征团队的影响。在这样的位置可以设定焦点和方向，以确保在整个产品的高水平下工作的优先级。核心团队成员（有一定程度的专业知识）可以与特征团队合作，以制定更详细的工作水平。

无论如何，利益相关者管理是一种不同的技能，以确保核心团队的成功，除了技术知识之外。

我记得如何在软件功能上工作时，看到发货的功能是如此的快乐。我工作的软件是公众使用的。所以当我看到我的朋友使用软件时，我可以告诉他们我开发了这一点 - 有什么履行感。

或者当有人问我以谋生为生，它真的很容易告诉他们，让他们明白我通过向产品展示我的所作所为。当释放新版本的软件功能时，我可以告诉他们查看它。对于每个这样的释放，我们通常用蛋糕庆祝。

但是，当一个人在基础设施团队中工作时，外部用户没有容易看到有形的功能。完成的工作可以只是现有服务的额外API或新属性 - 对于大公告来说太轻，因为这可以惹恼公告的收件人。如果没有公告，所做的工作就会受到忽视。

当核心开发人员改善核心库时，还还将有时，使代码更加可维护，或产生一些轻微的性能改进（例如，记忆力减少）。没有接口改变。那些使用核心库的人甚至没有觉得它。没有人通知或欣赏它。

有时，当释放新版本的核心库时，当宣布时，它就像另一个正常公告一样。如果改善对它们没有大量价值，该特征团队可能不会欣赏它。相反，功能团队可能会讨厌如此公告和变化，因为它们必须执行工作要进入新库或进行更改以满足新的接口。

相反，如果核心团队成员编码了对核心库的质量的回归或影响特征团队的东西，那么它可能会被使用它的人迅速注意到。不快乐的“客户”可能会“升级”这个问题。

在这样的环境中，对于良好的工作来说，对于所做的良好工作而言，对于所犯的错误，核心组内的开发人员很快就会变得更加不道德，而且没有人想在这样的团队中工作。该团队现在实际上是技术债务管理团队：高风险，低收益。没有人想在这样的团队中。

也许核心团队还应该像特色团队那样对待他们的工作。每次迭代都有可以达到里程碑。在此计划中有什么在计划中，应该在未来之外地了解，因此，应了解它们的价值或整个产品），因此存在新版本的预期。

谁领导核心团队需要在与特征团队协商中制定的高级别计划。人们也追踪团队的所有过去成就。需要庆祝所取得的所有主要里程碑。团队的良好工作需要广泛传播和共享。

至关重要的是，核心团队成员认为他们的工作是看待和赞赏的。毕竟，我们都不仅仅是为了金钱而且为成就感。

学术上，有很多关于衡量产品成功的研究。分析用于探讨使用软件功能的方式以及如何转换为组织的底线。

该功能的开发人员成功的一部分是及时向公众及其质量提供特征（例如，崩溃率，资源利用，性能）。

但是，对于核心组，人们如何衡量其成功？没有有形的客户面向输出产品。当然，我们可以说我们提供这个库和那个API服务等，但是这样做的含义是什么？核心团队如何在链接到其底线方面的组织的基本成功呢？

查看核心团队的一种方法是它就像IT部门为本公司提供所有所需的计算机和基础设施。它就像一个部门，贡献了支出。

在通常情况下，管理层希望优化该组的成本，除非该集团可以展示其贡献以提高生产力的贡献。

因此，如果我们有一种方法来测量特征组所获得的生产力或开发的可扩展性，那将是具有很大的价值。也许一个简单的方法是特征团队使用的API。这是一个超薄的例子。没有直接公式，而且比完成更容易。

也许第一个测量是特征团队的情绪，就核心团队如何支持它们。如果所有功能团队都感受到核心团队的价值，至少它是一个很好的开始。

沿着这些线路，有几个行业示例显示了这种核心或基础设施团队的巨大成功。一个是AWS，它的服务器最初在亚马逊内部服务，现在它已成为亚马逊最大的业务组。

另一个例子是Airbnb和Square等公司，他们为其他开发人员开发了核心图书馆，这些产品用于使用的其他开发人员，这对开发人员社区的组织的声誉显着贡献。没有直接的收入增益，但它使他们更容易招聘。

软件开发是更改最快的行业之一，如果不是最快的行业。每年，介绍了新的东西。一些变化是渐进的，一些革命性。

通常，核心基础架构团队或建筑团队是定义特征团队应采用的技术框架的团队来确保符合性。

这也意味着通过不断变化的软件技术，核心团队的感受义务在曲线之上，能够正确识别最好的下一个技术，然后朝着它努力。

这也是我推荐的最早的原因之一，即核心团队应由一支精心知识和遵循技术趋势的专家组组成。

虽然是核心组可以推动这一前进的理想选择，但它不是可扩展的解决方案，因为核心团队仅包括产品的开发人员的一小部分。

应对最新的技术介绍和探索，不应该是核心团队的唯一责任。来自每个群体的开发人员应该对新的东西充满热情。此外，如果我们不允许他们是一个先行者来探索一些新技术，我们对其他群体的开发人员做了不喜欢。

虽然核心集团有责任最终将最新技术部署到所有人，但每个团队（包括特征团队）都应该有自由来试验新的并提出建议。

这种自由很棒，因为它可以在团队中实现可扩展的探索。并非所有新的技术都应该被采用。从功能团队中汲取的经验教训可以帮助过滤不适合的技术。那些伟大的人可以向核心团队建议考虑使它由其他群体所采用。

当然，当有矛盾的技术时，核心团队是仲裁者的重要性，决定将优先考虑。