小队pkc++_管理敏捷小队之间依赖性的11种策略

小队pkc++

Agile squads are supposed to be cross-functional, atomic, and capable of delivering a product to the end user completely independently. However, as an organisation scales and the product becomes more complex, it is often necessary for squads to work together to deliver an increment of value.

敏捷小分队应该是跨职能的，原子的，并且能够完全独立地将产品交付给最终用户。 但是，随着组织规模的扩大和产品变得越来越复杂，团队通常需要一起工作以提供增值服务。

Because squads are set up for independence, having them rely on one another can cause friction, which ultimately delays projects. This was a problem the team I work with noticed several months ago. We found that of the sprint goals we missed in the previous 29 weeks, one in three were due to an external dependency.

因为小队是为了独立而设置的，所以让小队相互依赖会引起摩擦，最终会拖延项目。 这是我与之合作的团队几个月前注意到的一个问题。 我们发现在过去29周内未能实现的冲刺目标中，三分之一是由于外部依赖性。

So in the spirit of continuous improvement, we made a commitment to surface known or possible dependencies as soon as possible and formulate strategies to deal with them, should they arise. In the following 13 weeks to date, we have missed zero sprint goals due to external dependencies and are actually completing 35.2% more sprint goals than we previously were. This article details the strategies we used to achieve this.

因此，本着持续改进的精神，我们承诺尽快公开已知或可能的依赖关系，并制定应对策略(如有)。 迄今为止，在接下来的13周中，由于外部依赖性，我们错过了零冲刺目标，实际上比以前增加了35.2％的冲刺目标。 本文详细介绍了我们用于实现此目标的策略。

Feel free to skip ahead and read about the strategies now, or read on to first understand what dependencies are, where you might see them surface in your organisation, and how you should plan in the long term to remove them at their source.

随时跳过并立即阅读有关策略的信息，或者继续阅读以首先了解什么是依赖关系，您可能会在组织中看到它们的存在，以及从长远来看如何计划从源头删除它们。

我们所说的依赖关系是什么？ (What Do We Mean By Dependencies?)

Dependencies are things that need to happen for an Agile squad to complete an increment of value, but that cannot be achieved by the squad alone. Dependencies, if not handled correctly, lead to blockers in task execution.

依赖关系是敏捷团队完成价值增加所需要发生的事情，但仅凭团队无法实现。 依赖关系(如果未正确处理)会导致任务执行受阻。

In scrum, the product backlog is the main planning tool used to inform the direction of the squad. Broadly speaking, the product backlog consists of tasks (often called stories or user stories) with well-defined acceptance criteria. A good user story is scoped and written to follow INVEST (independent, negotiable, valuable, estimable, small, and testable).

在Scrum中，积压的产品是用来通知小队方向的主要计划工具。 从广义上讲，产品积压工作由具有明确定义的接受标准的任务(通常称为故事或用户故事 )组成。 一个好的用户故事的范围和编写要遵循INVEST(独立，可谈判，有价值，可估计，规模小和可测试)。

The concept of independence is key to the idea of managing external dependencies. If a piece of work is completely independent, it has no dependencies whatsoever. While this is something we should strive for, it is not always attainable. There is value in cross-functional, cross-vertical initiatives, and so we must plan for and manage dependencies.

独立性的概念是管理外部依赖项的思想的关键。 如果一件作品是完全独立的，那么它就没有依赖性。 尽管这是我们应该努力争取的，但并非总是可以实现的。 跨职能，跨垂直的计划具有价值，因此我们必须计划和管理依赖项。

依赖类型 (Types of Dependencies)

1. Requirements dependencies — When the squad is unclear on a requirement, and the person with the domain knowledge (the product owner, stakeholder, program manager, etc.) is not immediately available to provide it

   需求依存关系 -当小队对需求不清楚时，并且领域专家(产品所有者，利益相关者，程序经理等)无法立即提供

2. Expertise dependencies — When assistance from a person with specific know-how is needed in order to do something, for example, getting guidance from a database admin on a schema change

   专业知识依存关系 -当需要具有特定专业知识的人的帮助来做某事时，例如，从数据库管理员那里获得关于架构更改的指导

3. Activity dependencies — When progress cannot be made on a piece of work until an external activity is completed, for example, waiting for development environments to be provisioned before work can begin

   活动相关性 -当在完成外部活动之前无法在某项工作上取得进展时，例如，在开始工作之前等待供应开发环境

4. Business process dependencies — When some existing business process affects your squad’s ability to complete its work, such as change review board (CRB) approvals or compliance reviews

   业务流程依存关系 -当某些现有业务流程影响小队完成其工作的能力时，例如变更审查委员会(CRB)批准或合规性审查

5. Technical dependencies — When work requires technical changes in an area of the system that is outside the squad’s control, for example, when you need changes to an API that is managed by another squad. This can be compounded by tight coupling. Let’s say the API is not strictly versioned — now your requested change might require changes to other downstream consumers as well, which means even more dependencies.

   技术依存关系 —当工作需要在班组控制范围之外的系统区域进行技术更改时，例如，当您需要更改由另一班组管理的API时。 紧密耦合会加剧这种情况。 假设该API的版本不严格-现在您请求的更改可能还需要更改其他下游使用者，这意味着更多的依赖关系。

为什么我们要消除依赖关系？ (Why Do We Want to Eliminate Dependencies?)

Simply put, the more dependencies involved in a feature, the less chance it will be completed by the end of the sprint, quarter, etc. This is a problem since you always want to minimise the cycle time of feature development, to deliver for your users as soon as possible. It also affects your ability to react in an agile way to changing market conditions. Increased cycle time and a loss of agility manifest themselves as organisation stress.

简而言之，功能涉及的依赖性越多，在sprint，季度等结束时完成功能的可能性就越小。这是一个问题，因为您始终希望最大程度地缩短功能开发的周期时间，以便为您提供用户尽快。 它还会影响您以敏捷方式对不断变化的市场状况做出React的能力。 周期时间的增加和敏捷性的丧失表现为组织压力。

A natural reaction to this stress is to “divide and conquer”; splitting the organisation up into squads which can deliver the features we know we need today. While this removes the dependencies in the short run, it does not help with tomorrow’s dependencies. Additionally, waiting around for others to complete work or being pressured to complete work for others is harmful to organisational morale. For these reasons, in an ideal world, scrum teams should have no dependencies.

对这种压力的自然React是“分而治之”。 将组织分为几个小组，这些小组可以提供我们今天需要的功能。 虽然这会在短期内消除依赖关系，但对明天的依赖关系没有帮助。 此外，等待他人完成工作或被迫为他人完成工作也对组织士气有害。 由于这些原因，在理想的世界中，Scrum团队应该没有依赖性。

“Cross-functional squads have all competencies needed to accomplish the work without depending on others not part of the team. The squad model in Scrum is designed to optimise flexibility, creativity, and productivity.” — Scrum Guide 2017

“跨职能团队具有完成工作所需的全部能力，而无需依赖团队以外的其他人。 Scrum中的小队模型旨在优化灵活性，创造力和生产力。” — Scrum指南2017

为什么产生依存关系？ (Why Do Dependencies Arise?)

We would like to cut off the dependency problem at the source. There are some common root causes of dependencies between squads:

我们想从源头上解决依赖问题。 小队之间存在一些常见的根本原因：

• Organisational structure — The Android squad, the testing squad, etc. Clearly this is not cross-functional. If the Android squad cannot make a change to API they rely on, they are blocked.

  组织结构 -Android小队，测试小队等。显然，这不是跨职能的。 如果Android小队无法更改其依赖的API，则会被阻止。

• Incomplete cross-functionality — If squads lack one or more skills and must rely on another squad to provide it

  跨职能不完整 -如果班长缺乏一项或多项技能，并且必须依靠另一班提供

• Unreasonably complicated architectures — These inhibit the creation of cross-component and cross-functional squads. A microservice for everything, each owned by a different team, results in an exponential increase in the number of possible dependencies.

  不合理的复杂架构 -这些会阻止创建跨组件和跨功能的团队。 每个事物都有一个微服务，每个微服务都由不同的团队拥有，这导致可能的依赖关系数量呈指数增长。

• Doing big design up front (BDUF) — When plans change (and they will change) you may find your squad is not aligned with the requirements of the project.

  预先进行大型设计(BDUF) —当计划更改(并且将会更改)时，您可能会发现自己的团队与项目要求不符。

• Legacy systems and processes — These often centralise knowledge and inhibit the creation of cross-functional teams.

  旧版系统和流程 -这些通常会集中知识并抑制跨职能团队的创建。

• Regulatory requirements — When only certain squads or squad members have clearance or access to certain data or systems, it creates dependencies.

  法规要求 —当只有某些小队或小队成员具有许可或访问某些数据或系统的权限时，它将创建依赖性。

• Resistance to change — Dependencies often justify the existence of a squad. There is a natural resistance to process or organisational change that threatens this.

  抵制变革 -依赖关系经常证明有一支小队的存在。 对流程或组织变革的天生抵抗会威胁到这一点。

长期计划：消除依赖 (The Long-Term Plan: Eliminating Dependencies)

Agile assumes the squad has everything it needs to deliver an increment of value. In an ideal world, we would have cross-functional squads with all the know-how and permissions to build, test, and deploy a product end-to-end with minimal interactions between them. However, this isn’t always possible, at least not immediately. Regulatory requirements, organisational structures, knowledge silos, and resistance to change often prevent squads from breaking dependencies entirely.

敏捷假设团队拥有交付价值增量所需的一切。 在理想的世界中，我们将拥有跨职能的团队，他们拥有所有的专业知识和权限，可以以最小的交互来端对端构建，测试和部署产品。 但是，这并不总是可能的，至少不是立即可以做到的。 法规要求，组织结构，知识孤岛和对变革的抵制通常会阻止小组完全打破依赖关系。

In the long term, the solution lies in applying Lean Thinking, Kanban, and the Theory of Constraints across squads, to manage the flow of work and realign people and squads around value streams rather than functional areas.

从长远来看，解决方案在于将“精益思想”，“看板”和“约束理论”应用于各个班级，以管理工作流程并围绕价值流而非职能领域调整人员和班级。

In the short term, we can mitigate dependencies by calling them out as soon as they are known and manage them using the strategies below.

在短期内，我们可以通过尽快消除依赖关系来缓解依赖关系，并使用以下策略进行管理。

短期缓解依赖关系的11种策略 (11 Strategies to Mitigate Dependencies in the Short Term)

The strategies can be split into two categories, with most falling into both.

这些策略可以分为两类，大多数都可以分为两类。

• Strategies to mitigate dependencies into the squad:

  战略以减轻依赖进大名单：

• Strategies to mitigate dependencies onto other squads:

  减轻对其他小队的依赖性的策略：

减轻班组依赖性的策略： (Strategies to mitigate dependencies into the squad:)

1. Automation

1.自动化

Where possible, automate repetitive tasks, with appropriate controls in place for safety. Things like continuous integration/deployment (CI/CD) or automating repetitive support tasks would be examples of automation that removes or mitigates dependencies.

在可能的情况下，通过适当的安全控制措施使重复的任务自动化。 诸如持续集成/部署(CI / CD)或自动化重复支持任务之类的事情将是消除或减轻依赖关系的自动化示例。

2. Standardise processes

2.标准化流程

If automation is unfeasible, make processes happen the same way each time to eliminate planning and coordination.

如果自动化不可行，则使过程每次都以相同的方式进行，以消除计划和协调。

减轻对其他小队的依赖性的策略： (Strategies to mitigate dependencies onto other squads:)

3. Gatekeeper strategy

3.网闸策略

Prevent dependencies from affecting the squad’s throughput by blocking stories with dependencies from entering the sprint until you are reasonably sure that dependencies will be resolved in time.

通过阻止具有依赖项的故事进入冲刺，来防止依赖项影响小队的吞吐量，直到您有理由确定可以及时解决依赖项为止。

4. Micromanage

4.微观管理

If your dependency requires significant work to resolve, work proactively with the downstream squad to ensure this work is planned and executed ahead of time.

如果您的依赖性需要大量工作来解决，请主动与下游小队一起工作，以确保提前计划和执行这项工作。

5. Do it yourself

5.自己动手

Where possible, offer to do the needed downstream work yourself, or pair-program with the responsible party in order to drive it to completion.

在可能的情况下，主动提出自己进行所需的下游工作，或与负责方进行配对编程以推动其完成。

6. Remove the dependency from your scope

6.从您的范围中删除依赖项

Unblock yourself by faking it! Set up test stubs or create dummy infrastructure to complete your side of the work. By delivering on your commitment, you have decoupled yourself from the requirement that the dependency is deployed. This works well in conjunction with formal engagement models as long as squads maintain alignment.

通过伪造来解锁自己！ 设置测试存根或创建虚拟基础架构来完成您的工作。 通过兑现承诺，您已与部署依赖项的要求脱钩了。 只要小队保持一致，这与正式的交战模型结合起来效果很好。

缓解小队内外依赖的策略： (Strategies to mitigate dependencies both into and onto squads:)

7. Utilise Agile ceremonies

7. 利用敏捷仪式

• Check-ins — Set up recurring (for the duration of the project) check-in meetings with the teams you depend on or who depend on you, to keep the shared requirements front of mind.

  检查插件 -设置定期(该项目)的持续时间办理入住手续和你依靠或谁的团队会议取决于你，到前车保持头脑的共同要求。

• Stand-ups — Attend their stand-up when it makes sense to, and with their permission. Or have them attend yours. Consider a scrum of scrums.

  站立站立 -在合理的情况下并经他们的允许参加站立站立。 或者让他们参加你的。 考虑一堆混乱。

• Project retrospectives — Critically evaluate what can be improved about your collaborative efforts. This is particularly valuable to facilitate a long-term or recurrent engagement.

  项目回顾 —严格评估可以改进您的协作成果。 这对于促进长期或经常性参与特别有价值。

8. Align on common goals

8.达成共同目标

Invite the relevant squads to design reviews, project planning meetings, check-ins, or retrospectives to give them an insight into the work that you do, why it is important, and how it aligns with the company’s top-level goals. Take an interest and learn about their incentives and concerns.

邀请相关小组进行设计审查，项目计划会议，签到或回顾，以使他们深入了解您所做的工作，为什么重要，以及如何与公司的最高目标保持一致。 引起兴趣并了解他们的动机和关注点。

9. Use virtual teams

9.使用虚拟团队

If the work required is complex or tightly intertwines each squad’s systems, then you should consider the merits of forming a virtual squad for a period of time. You could also second someone or have someone seconded for the duration of the project.

如果所需的工作很复杂或紧密缠绕每个小队的系统，那么您应该考虑在一段时间内组建虚拟小队的好处。 您也可以在项目期间借用某人或让某人借用。

10. Report on flow metrics

10.流量指标报告

Surface burndown and velocity charts which show the impact of dependencies (into and out of the squad). This can be a powerful impetus for change. Consider bringing these results to reviews with stakeholders to resolve dependencies together.

表面燃尽图和速度图，显示依赖关系的影响(进入和离开小队)。 这可能是变革的强大动力。 考虑将这些结果与利益相关者一起审查，以解决依赖关系。

11. Employ formal engagement models

11.采用正式参与模式

Squads should draft engagement models with service level agreements (SLAs) around common request types. Within an organisation of sufficient scale, this will often make sense as the overhead of drafting these models is offset by the frequency of their use.

小队应围绕通用请求类型起草具有服务水平协议(SLA)的参与模型。 在一个规模足够大的组织中，这通常是有意义的，因为起草这些模型的开销被其使用频率所抵消。

Hopefully applying these strategies and surfacing dependencies early will make your life easier when collaborating with other Agile squads to deliver value for your customers.

希望尽早应用这些策略并解决依赖关系将使您与其他敏捷团队合作为您的客户创造价值时的生活更加轻松。

翻译自: https://medium.com/better-programming/11-strategies-for-managing-dependencies-between-agile-squads-aac11e3c1f11

小队pkc++