组织敏捷性的秘密

你准备好了吗?在所有费用中断依赖性！

当组织内的任何两个离散元素都需要彼此进行全部或部分工作时创建依赖项。在企业级，依赖关系无处不在。他们是由我们决定构建我们的业务以及我们如何设置和执行我们的项目工作的方式创建。亚博vip9通道这使得它们很难识别甚至更难删除。

我相信打破我们对依赖的依赖是个核心挑战e与协调任何可持续的企业敏捷过渡相关。

敏捷转换不会因为Scrum不足而失败。他们不会因为人们没有充分应用正确的XP工程实践而失败。我们的问题不是对敏捷宣言的根本误解，也不是不愿意成为正确的敏捷领导者。

虽然任何给定的组织可能有一些或所有这些问题，但它们不是我们的主要关注点。

潜在的问题是，敏捷项目管理原则、敏捷工程实践和敏捷领导哲学假设您已经做到了已经消除了你的依赖关系! 大多数团队都试图在不验证核心假设的情况下变得敏捷，甚至没有人告诉他们应该尝试！

想想我们是如何描述理想的敏捷实现的……

首先，我们从一个由具有足够技能的跨职能人员组成的小团队开始，这样任何人都可以在系统的任何部分工作。接下来，我们允许这个团队在任何给定的sprint期间只在单个项目上工作。

然后，我们授予该团队一名专门的产品负责人，授权其代表企业做出决策。我们允许他们处理小型独立的功能需求，这些需求可以随时重新确定优先级。亚博vip9通道

我们为团队提供了一个授权人员，负责消除团队可能遇到的任何组织挑战。我们消除了任何流程约束，并允许他们以任何方式完成工作，只要他们交付工作软件。

最后，我们假设它们具有面向对象的架构，可为测试驱动设计，连续集成和恒定的重构而引起。

这种情况完美地描述了一个没有依赖关系的团队。他们有100％的人需要完成工作。

让我们来看看许多团队与尝试采用敏捷...

人们通常是一支专家团队的一部分，这些专家是归类为跨职业项目团队的。因为这些人是专家，所以他们的服务不需要100％的时间。为了最大限度地利用个人，它们被分配给多个项目和任意数量的团队。

产品所有者正在做市场调查，与客户会面，参加贸易展览。团队只剩下一个没有被授权的业务分析师来为业务做决策。亚博vip9通道在现实中，产品负责人只是一群无关的利益相关者的代理人。没有人能接触到真正的客户或市场数据。

许多团队正试图通过使用传统的MRD或PRD来冲刺产品开发。他们没有使用作为系统行为的功能线程编写的需求，这些功能线程可以在sprint的末尾进行全面测试。随着我们对不断发展的系统了解的更多，这些需求不能被重新确定优先级。

许多团队都与传统的项目经理一起工作，他们尽最大努力保持敏捷，但也接受过管理依赖关系并告诉人们该做什么的训练。即使他们想要敏捷，他们通常也不能对项目团队正在处理的真正障碍做任何事情。

团队正在尝试使用紧密耦合的软件架构，测试覆盖不足，遗留代码基础，并且无法进行日常构建。

这完美地描述了在受缺陷的组织假设创建的依赖性的压缩重量下运行的团队。

让我们来看看我们一些常见的假设，导致不必要的依赖关系......

我们假设我们必须针对个人绩效进行优化，因此我们将项目中的团队成员组合在一起。这会在不必存在的项目之间创建依赖关系。我们发现自己在管理谁参与了什么项目，以及他们何时可以参与其他项目。我们在[项目之间]建立了一个依赖关系网络，这限制了我们改变方向的能力。任何变化都会对我们的投资组合产生一系列痛苦的连锁影响。

我们假设我们的解决方案的一部分过于复杂，必须由专家来处理。我们选择将特定人员分配到特定组件。默认情况下，我们在共享相同组件的产品之间创建依赖关系。我们还创建影响同一组件的需求之间的依赖关系。当我们将这些专家分配给专家团队时，我们在团队之间（以及团队成员之间）创建项目依赖关系。

我们假设我们的产品负责人对于团队来说太忙了，所以我们指定其他人代理业务。我们在团队和业务之间建立了依赖关系，导致过度记录和管理合同之间关系的趋势。当使用合同时，我们会在团队和业务之间创建依赖关系，这些依赖关亚博vip9通道系必须得到维护、实施并置于变更管理之下。

我们假设市场需要一次要求所有功能，因此我们不会专注于整个系统架构的小功能切片。为什么要打扰，这一切都必须完成？这一思考导致我们在考虑建立任何东西之前考虑一切。当要求彼此依赖时，无需优先考虑，没有能力改变我们的思想，没有能够从新兴系统中学习。大上前设计文件开始看起来非常合理。

我们假设体系结构不能被解耦，或者测试覆盖率太昂贵。这使得我们在做任何改变的时候都要考虑做每一个改变。批处理变更是在工作软件的环境之外进行的。它们是一次性集成和测试的……可能在项目快结束的时候。通过在代码更改之间创建依赖关系，我们失去了从错误中学习、重构和让团队对结果负责的能力。

依赖关系迫使我们度量工作时间、交付的模块或代码行数，而我们真正想度量的是工作的软件。

为什么这么想？

其中一些依赖性是真实的。许多人可能需要数年才能克服。刚才意识到你接受的每一个依赖关系，你选择离开的每一个依赖性，都会从根本上限制你采用敏捷方法的能力。

每一项都需要权衡，这将降低你的效率和应对变化的能力。

通过首先关注项目管理技术、工程实践，甚至领导哲学……我们失去了目标。我们倾向于从各种各样的策略中挑选适合我们特定组织的策略。我们不会被迫处理基本问题，因此会选择一种毫无意义的敏捷实现方式，这种方式不会提供组织试图提供的基本价值。

通过专注于不懈地追求和消除依赖关系，我们将组织定位为潜在地采用所有敏捷最佳实践。然后我们可以根据我们的价值观和原则进行选择，而不是依赖于我们纠缠不清的依赖组织的约束!

不惜一切代价减少依赖性。这将成为我2009年的座右铭。期待在新的一年里听到更多关于这个话题的内容!