依赖管理-好的，坏的，丑陋的

你的团队是否在努力完成任务?他们是否因为等待另一个团队或另一个人而经历了大量的溢出到下一个周期?在等待其他团队或人员完成工作时，项目是否处于阻塞状态并老化?

依赖是软件开发中的一种流行病。原因可能有很多——也许你的组织已经采用了敏捷框架，但你还没有构建起来支持可持续的团队。当你开始你的敏捷之旅时，你可能非常依赖供应商或专家。而且，一些大规模的系统更改需要某种程度的依赖关系。事实是，依赖关系不会消失。当你扩展敏捷工作时，依赖关系也会扩展。好消息是，您可以使用一些策略将您的团队从管理依赖转移到减轻依赖。

Scrum指南说的是:

“跨职能团队拥有完成工作所需的所有能力，而不依赖于团队以外的其他人。Scrum中的团队模型旨在优化灵活性、创造力和生产力。”- K.施瓦伯和J.萨瑟兰，Scrum指南,2013

对于刚接触Scrum的团队或刚接触敏捷的组织来说，这通常不是现实。虽然跨职能团队是敏捷的基石，但您的组织可能需要很长时间才能演进。如果你想充分认识到Scrum的好处，不要仅仅管理依赖关系，而要无情地减轻它们。继续往下读，学习如何做到。

我们听到(或说)的事情:

• 组织设计:我的团队主要是后端;我们依赖于另一个团队的<…>(填充任何软件组件-前端增强，数据库层，集成，API)
• 不成熟的敏捷性:我的团队正在使用Scrum，但与我们合作的许多其他团队正在使用更传统的方法，如瀑布
• 不跨职能:我的团队使用来处理一项专业技能，而且他们位于完全不同的时区
• 复杂的架构:我们使用了太多不同的系统、工具和技术，以至于不可能真正实现跨功能和松散耦合
• 你的“理由”是什么?

好，坏，丑

就像所有的敏捷一样，没有什么灵丹妙药，没有万能的解决方案。但是，我们可以做一些事情来减轻依赖关系。有些是权宜之计，有些则需要更长期、更复杂的解决方案。无情地减轻依赖关系的解决方案在于赋予人们权力并启用心流。

有难看的依赖关系?让我们谈谈如何变好。

从短期来看，沟通和积极的计划是关键。对于更长期、更有授权的状态，可以考虑交叉培训、开放权限、组织设计更改，甚至是招聘和团队组建策略。每个人都需要努力才能看到大范围的成功。

短期:Scrum中的Scrum

当您在整个组织中扩展敏捷时，减轻依赖关系的常用方法是使用一种称为Scrum的Scrum的扩展模式。在Scrum的Scrum中，来自每个团队的代表会面以协调工作和依赖关系。一个有价值的实践是将依赖关系可视化，并根据工作的价值和影响坦率地划分优先级。不允许宠物项目或副业——所有的依赖关系都必须是可见的，并根据其他需求进行评估。另一个常见的做法是确保决策者参与其中，以便快速解决障碍，并且团队专注于解决方案。

如果您的团队处于依赖关系的接收端，这是缓解参加多个团队会议需求的良好的第一步。但这只是你减少依赖的旅程中的一步——你可以做的还有很多。

长期:开启心流，赋予人们力量

Scrum Master或技术经理

总的来说，保持好奇心，并对每个依赖项提出有力的问题。不要接受现状——缓解依赖是一个复杂的问题，没有明确的解决方案。与Scrum团队、领导者、甚至是涉众展开对话，从不同的角度审视你的工作。

• 让工作“完成”。如果你还没有完成，首先，分析一下可能导致问题的原因:项目太大了吗?是否在工作执行期间而不是之前识别依赖关系?如果项目太大，无法在时间范围内完成和完全测试，您可能需要将指导和培训工作集中在垂直切片的小工作项目上——强调小。如果问题确实是依赖于其他团队或不属于您团队的专家，请与您的团队、产品负责人和业务领导讨论一些解决方案，以便他们致力于将项目独立于其他团队而达到可发布状态所需的行为更改。
• 让整个团队都参与进来。如果你的团队的工作流程出现了问题，可能表现为高溢出率，大量正在进行的工作的启动和停止，或者老化的项目，考虑一下如何解决问题。当涉及到使用技术解决问题时，没有人比开发团队更了解可能性的艺术。他们也是最接近工作的人，他们会很好地洞察由权限、控制和只有少数人掌握的专业知识引起的瓶颈。

产品负责人或业务负责人

沟通和准备是关键。说“不”也一样。产品负责人或业务负责人能做的最好的事情之一是积极主动地规划依赖关系、排序工作和协商范围。在敏捷中，领导者的角色是保持团队的领先地位，并每天做出艰难的决定，这对团队的成功至关重要。(阅读我的作为产品负责人的情绪情商的5个技巧。）

• 提前计划至少2-3个周期，以便开发人员可以帮助尽早识别依赖关系。这将允许您与任何其他团队合作，了解他们的待办事项，并确保请求的价值得到传达。考虑使用敏捷中的各种计划周期，让你的团队有三个“触摸”来分解工作，从愿景和路线图，到发布计划，再到细化。
• 传达价值，而不是优先级或截止日期。当团队必须平衡多个利益相关者与相互竞争的请求时，我们希望将对话集中在业务价值上，而不是截止日期上。为自己和他人澄清:如果在我们要求时没有解决这个依赖关系，业务影响将是什么?如果根本解决不了怎么办?这种依赖关系对于交付有价值的东西真的是至关重要的，还是只是可取的?
• 团队不应该开始带有外部依赖项的工作项，除非其他团队在计划会议上做出承诺，或者除非依赖项在工作开始之前得到解决。愿意对需要依赖第三方的工作进行排序，这样你的团队就可以建立自己的学习和技能来支持更多依赖他人的工作，减少对他人的依赖。

开发团队:

当涉及到依赖性缓解时，开发团队是第一道防线。

• t型技能:随时随地开始交叉培训，这样团队中更多的人可以做更多的工作。当需要专家时，可以考虑让这个人加入你的团队几周，分享知识和专业知识。
• 问责制:确保任何细化活动都是在代码中，在数据库中进行的。在改进过程中，要找出哪些地方需要依赖其他方面，而不是依赖他人。
• 敏捷工程:考虑技术如何提供帮助，例如自动化、微服务或持续集成以尽可能频繁地发布。重构代码，使您的团队可以独立于其他团队工作。要求减少权限或控制，而不是接受老化约束。

敏捷领导:

开启心流，赋予人们力量。经理和领导的角色需要演变，组织结构也需要演变，以支持跨职能、自组织团队的转变。当似乎所有的目光都集中在发展上时，这一因素的重要性可以被忽视。但是，没有人比他更有能力在整个系统范围内进行改革，释放资源，消除限制。

• 启用流程:执行精益分析，如价值流映射，以识别浪费和延迟。您的目标应该是将您的组织发展为合理的价值流和可持续的团队，并计划减少对价值流之外的依赖。
• 授权给人们:创造一种授权的文化——在你的组织中是否存在单点失败?是否有多个级别的审查?这是一种集中式决策的文化，还是一种去中心化的、自治驱动的决策，导致了瓶颈和依赖?

使能和授权之间的区别在于，使能侧重于协助行为，而授权则是向个人或团体授予权力。

授权产品负责人和业务负责人说“不”有助于他们限制正在进行的工作，将工作重点重新集中在最高、最有价值的项目上，并消除协调复杂、依赖的工作的浪费。赋予Scrum管理员和团队经理更多的权限和更少的审查，可以促进信息和数据的流动。授权团队说“是”，并做得更多，有助于整个组织认识到统一和积极的员工的全部力量和有效性。

您的团队如何找到结束依赖关系的方法?

Julee Everett和Kim Andrikaitis

磨练你的手艺;说出你的真相;表达你的感谢