如何处理Scrum中的“外部”依赖关系？

如果您为冲刺计划了许多用户故事，而一个候选故事则取决于某个外部提供商向您的团队提供一些东西。例如，在线服务提供商向其系统添加新的API调用，或在其系统上启用您的测试帐户等。

您知道即将来临。

您是否继续将故事添加到sprint中，希望他们能及时提供您完成故事所需的内容，还是等到下一个sprint，当您知道故事已经准备好就可以立即开始就算这意味着不及早开始故事。

如果是前者，您如何处理由于依赖性而失去的“无知的”故事点？部分信用（eek！）或放在下巴上。

最终，这取决于您是否100％确信外部提供商会在需要使用时交付您可以使用的东西。

如果您不确定他们会及时交付，请不要将故事添加到冲刺中。但是，仅由于它们过去一直交付，所以不能保证他们这次将交付。

您应该让客户知道此依赖项存在，并且您将必须等待API（或其他任何东西）可用，然后才能安排工作。

从好的方面来说，您可能会讲故事的某些方面，例如，将其进一步分解，直到您尽可能地隔离依赖关系为止。这可以让您在供应商交付工作之前做一些故事。

您可以做的一件事是在代码和第三方API之间创建一个接口。您可以对界面进行编码，以便项目的其余部分可以继续进行，直到拥有真正的API为止，使用模拟程序返回示例数据。然后，当真正的API到达时，您只需要更改接口后面的代码即可，而这不会影响应用程序的其余部分。仅当您可以同意API的供应商，他们的接口不会改变（至少不会剧烈改变）时，才这样做。

团队是做出承诺的人。在我们的团队中，如果我们觉得自己正在等待（例如）外部开发人员，那么我们学会了说我们不愿意接受这个故事。这个故事不适合接受。

外部资源的延迟交付，意外交付或其他交付很有可能意味着您的估计和优先级可能会发生变化。

在获得所有信息之前，团队不要太天真地认为自己可以完成故事。如果他们说可以，那么就以预期的格式延迟交付，或者根本不交付，他们让所有人失望。

听起来很刺耳，但我想表达我的意思。

在Scrum中，有完成的定义和为用户故事准备的定义。在像您这样的情况下，重要的是要有一个准备就绪的定义，所有利益相关者都应理解并同意。例如，在您的ready定义中有一行似乎很合理，例如：

• 故事需要的所有外部API都必须交付和测试。

如果您需要此API为您的产品增加价值，那么逻辑上的事情就是等待它，直到我们真正拥有此API才能开始工作。同时，我们可以做其他美国产品来增加产品的价值，我真的不喜欢这个美国的模拟实现之类的东西，如果对于客户来说没有真正的价值，那就没有美国，这会浪费时间和资源。 。

如果您正在等待某事，那么即使您百分百确定明天会交付，也不知道该如何计划。为什么？因为如果您不知道它，您甚至无法估计它的复杂性，如果您不能估计它，那么您将无法计划它。

如果您预先定义了一些“接口” /“合同”，外部公司必须遵循，则可以对其进行计划并创建服务模拟。您的开发将使用模拟服务，因此它们将不依赖于外部交付。由于尚未完成针对模拟进行开发和测试的功能，因此应针对将要交付实际服务的sprint计划使用模拟进行静态开发-必须将其与真实服务一起测试才能在sprint结束时视为已完成。

通讯与协议

程序员而不是方法本身将两个系统集成在一起。如果公司决定集成外部系统，则（至少）两个实体之间将签订合同。合同必须确保进行整合。因此，如果公司之间的协议不需要两个部门之间的技术合作，那么问题就不在开发方法上。问题是业务方法论（基本上是合同）。

话虽如此，在计划这些案例时必须考虑到风险，并且考虑到您不了解团队的速度，您将需要宽容那些余地。

项目经理如何管理对外部团队的依赖？

/pm/1400/how-can-a-project-manager-manage-a-dependency-on-an-external-team

如果不依赖您的团队并且您可以执行其他任务，我建议您仅在准备就绪时使用它。即使您有一个样机Web服务，模式，接口和/或契约，它仍可能会崩溃（还记得墨菲定律吗？）。