在Jumbo，我们实施了一种敏捷的工作方式，向我们周围的公司借了很多东西，而这些公司的工作时间比我们更长。
因为每个组织都不同，并且实施组织模型与组织的成熟度紧密相关，所以我们并不会盲目地关注周围所有出色的孩子所做的事情。 在Jumbo，我们还没有立即准备好所有这些东西。 其他一些事情根本不适用于我们。 简而言之：我们做了适合自己的事情，而不是盲目关注互联网上的某人。
在此10,000英尺的概览中，我们保留了KISS（这表示保持标准，在这种情况下很愚蠢 ）：
- 我们工作着广泛接受的多学科团队 ，其中包含被视为团队目标核心的所有角色和技能，例如前端和后端开发人员，测试人员和业务分析师。
- 我们使用精益实践进行工作：从软件开发价值流中消除浪费，创建短周期的反馈流，并采用“拉动式”交付方式。
- 我们使用标准的Scrum实践和流程来完成工作。 这意味着我们会执行所有Scrum仪式，并具有产品负责人和Scrum主角色。
- 我们根据著名的Spotify模型为敏捷组织改编了各章和行会的概念，以适应我们的特定需求。
因此， tl; dr是：我们并没有重新发明轮子，而是依靠（双关语意）敏捷和Scrum，并在适用的情况下从Spotify模型中借用了。
我们之所以敏捷，有几个不同且非常简单的原因：
- 团队自治，在地方一级优化独立性。 我们希望组织有效，简单和清晰。 任何其他影响生产力的因素，因为大型组织中的团队协调都是梦pipe以求的事情。
- 流程，确保团队完成少量工作，并具有封闭且快速的反馈周期，并且流程不受中断，不受团队外部瓶颈的影响。
- 简便性：我们希望每个人都能理解一个简单的模型。 反过来，这简化了入职流程，有助于向组织外部的人员解释我们的工作方式，等等。 使用现有框架中的一组简单且众所周知的原理可以简化解释。
通过这三个基本前提，我们以以下方式进行了组织。 作为食品零售商，我们喜欢使用食品参考来解释事物。
我们敏捷组织的“基石”是Cherry ，这是一个小型组织单元，与技术领域保持一致。 首先，我们有紧密联系的产品负责人和团队负责人。 他们与固定数量（两个，有时三个）的开发团队协同工作。 技术上相邻的团队组成部落，共同解决相似的问题，以将纹波效应减小到较小，较不复杂的规模。
每个团队都有一个团队负责人，一个经验丰富的开发人员，负责其团队成员的人力资源工作。 负责人以“方法”帮助团队，指导他们的个人发展，是团队的全面升级点。
每个团队都有一个产品负责人，负责“什么”。 PO不是团队的一部分，而是我们有时仍称为“业务”的一部分，但是“业务”和“ IT”之间的区别正在迅速消失。 他们并不完全负责“他们的”团队所做的所有工作； 团队也可以执行产品负责人规定的工作。
我们试图了解Conway定律，并围绕我们希望软件的交付方式来规划我们的团队。 我们以几种不同的方式组织团队：
- 技术领域，系统或挑战。 例如“应用团队”或“电子商务核心团队”。 这些团队拥有技术领域的所有权，并独立开发并投入生产。 他们负责其所有方面，例如“技术故事”，一些架构工作，并越来越多地负责其提供的软件的Ops。
- 业务成果。 一个例子是“购物篮”或“内容团队”。 这些团队负责客户旅程的不同部分。
我们尽量避免使用诸如“ HR”，“ Sales”之类的业务职能团队。 这些正是我们正在努力消除的组织孤岛的类型。
如您所见，我们尝试避免使用业务职能团队，例如“ IT运营”，“ HR”，“销售”等。 相反，我们已经将这些部门提供的许多服务由内而外转向了，并试图将它们集成到团队中。
对于与团队工作密切相关的许多业务职能，这很好。 例如，将团队负责人整合到团队中可以使人力资源工作与团队紧密结合，使其成为团队中不可或缺的一部分。
对于IT运营，这也很好。 我们正在努力缩小开发与运营之间的传统差异，并将整个电子商务堆栈的运营转移到开发团队中。 将来，这些团队将负责他们正在研究的技术领域的所有方面和阶段，而不仅仅是软件开发方面。
这些团队不再依赖周围的孤岛业务部门，而是变得更加敏捷和敏捷。 他们能够独立决定其技术领域的越来越多的方面。
换句话说，我们赋予部落，小组和小队自由的决定权，这些决定权通常由中央IT部门（例如基础架构，身份和访问管理以及运营管理工具（监控，部署，测试等）。 我们正在停止强制使用这些中央IT资源，而是由团队自行选择。
总而言之，我们的目标是完全将传统的筒仓IT部门下放为行会，以管理连接的简单性（也称为“体系结构”）的端到端集合。 我们将来自该IT部门的角色和知识整合到每个团队中。
这具有一些主要优势：规模小且摩擦少的基础架构消耗，可以更好，更快地集成到其部署管道中。 他们选择的服务往往是自助服务，即用型，即付即用的服务，最重要的是：没有传统的集中式IT服务所具有的众多依赖关系。 公司内部没有大型，昂贵的公司基础架构，因为这是一项资本密集型的投资。 取而代之的是，团队拥有较小的独立预算，可以购买较小的独立服务。
团队完全控制着他们交付软件功能并在生产中进行操作所需的每种服务的购买与构建决策。 这样可以防止大量定制现成的软件产品。
开拓者引领潮流
不可避免的弊端是不同的团队选择不同。 为了使这个问题易于管理，我们引入了pathfinder的角色。 探路者与Spotify模型中的章节负责人密切相关。 他们是各自领域的专家，主要专注于较难的技能（与团队负责人相反，后者专注于较软的技能）。
探路者带领所有Scrum团队努力工作，例如领导工会和分会，部落中的团队成员也扮演类似的角色。 例如，设计探路者将与所有前端开发人员举行会议，而质量保证探路者将与测试人员和业务分析师举行会议。
在许多方面，出于许多相同的原因，我们执行章节和行会：维护非功能性和定性方面。 探路者还可以帮助跨越各个单元和部落的工作，例如架构，重大计划和成本优化。
在Jumbo，探路者拥有更定性的视角。 他们使用例如《编码指南》，《设计手册》，即用型云服务和微服务支架来建立和实施工作方式原则。 他们定义了技术的标准用法，并帮助团队在团队之间实施这些技术。
我们讨论了组织的许多不同领域。 这只是高层概述。 因为发生了很多事情，所以我们将在以后的博客文章中分别介绍这些不同的方面。 现在，我将在巨型技术园区中为您构建敏捷组织的以下12个方面：
