完成本部分后，你将更好地了解 InnerSource 如何加快产品开发；我们还将介绍其与敏捷开发最佳实践的关系。
为了实现敏捷性，组织努力建立自治团队。然而，在一个复杂、相互关联的世界中，某些依赖性是不可避免的。 InnerSource 提供了一种替代 "等待"、"建立变通办法 "和 "升级 "的方法： 需要修改依赖关系的团队可以伸出援手。 InnerSource 促进了跨团队协作。它注重书面交流，即使在远程模式下也非常适合。
在本节中，你将了解到敏捷开发和 InnerSource 使用类似的术语甚至技术，但在细节上却有很大不同。了解两者在文化和工具使用目的上的差异，将使你受益匪浅，而不是陷入常见的误解。
你将了解 InnerSource 对能力规划的影响。此外，InnerSource 没有免费的午餐——托管团队需要时间来指导贡献者。我们还将探讨 InnerSource 带来的额外谈判可能性——保持 "投入与收益 "之间的平衡。
让我们从一个简单的例子开始。想象一下，你正在开发一款新的可爱风音乐APP。为了了解用户与APP的交互情况，你开始收集一些交互日志。随着时间的推移，你在分析这些日志时会进行更深入的挖掘，并将学到的知识反馈到开发过程。现在，想象一下另一个将内容引入你的APP的团队也有一些需求——他们可能希望根据内容创作者接触到的用户数量来奖励他们。因此，他们也开始使用你收集的日志。但他们需要一些额外的分析步骤，而这是你一开始所没有想到的。他们现在面临着一个挑战：是建立一个变通办法，还是通过你的积压工作来优先处理他们的请求。有了 InnerSource，他们就有了第三种选择： 在你的帮助下自己进行更改。当然，这可能会比你自己修改要慢，但这仍然比等待你进行修改要快。</p>
在理想的 InnerSource 组织中，你可以进一步扩大规模： 还记得上次必须在整个平台上进行横向关注点修改吗？如果采用“将其放入每个团队的Backlog”的方式，往往会感觉时间拖得很长；另一方面，它实质上是为这些团队提供一个实现修改的补丁，这会大大加快速度。在这种方法中，修改的复杂程度取决于组织的成熟度和代码的可维护性/模块化程度。