什么是交付计划？
随着开发组织的发展，他们需要重新组织为可高效管理划分为部分的工作单元的小型团队。 这些团队通常有自己的工作计划、版块和其他流程，来满足其在组织更大目标这一背景下的独特需求。 随着时间的推移，组织可能会发现通过围绕一致的框架来整合其流程，可以获得网络好处。
交付计划是对一个或多个工作计划的可视化。 它旨在让团队和管理人员大致了解每个团队计划生成的内容和生成时间。 这样，作出的决策可以优化组织中的投资。
团队必须定期审查其交付计划，以确保其工作计划与其他团队的计划保持一致。 这些审查应解决以下问题：
- 我们确定能交付当前计划中承诺的内容吗？
- 我们是否确信我们所依赖的团队会按当前计划提供我们所需的内容？
- 我们的计划中是否有可用于工作的间歇？
- 团队内部或团队之间的依赖关系是否存在问题？
交付计划可在项目的生命周期中的任何时间点添加价值。 它们基于团队积压工作 (backlog) 动态生成，因此始终是最新的，并提供最新的见解。
让我们来看看 Tailspin Web 团队的讨论。
Andy：我刚和工程管理人员进行了富有成效的会议。 我演示了我们使用 Azure Boards 进行的工作，他们对让其他团队加入的前景深表乐观。
Mara：太棒了！ 他们什么时候开始？
Andy：这是最好的结果。 他们已经实现了！ 昨晚，游戏引擎项目主管创建了一个团队和一些冲刺 (sprint)，开始添加工作项。 今天早上我快速了解了一下，发现正在顺利成形。 让我向你展示一下他们的进展。
Andy 导航到游戏引擎的当前冲刺 (sprint) 板。 他和 Mara 很有兴趣地查看工作项。
Andy：嗯...我刚发现他们不打算在这个冲刺 (sprint) 结束前部署 beta 版本。 我们不是要在下一个冲刺 (sprint) 期间将排行榜与 beta 版本数据库集成吗？ 如果不先提供 beta 版本，我们就无法做到这一点。
Mara：说得对。 我们依赖该团队生成该可交付结果，以便我们生成我们自己的可交付结果。
Andy：这将会对下一个冲刺 (sprint) 的生产力造成负面影响。 我会给他们打个电话了解情况。
遗憾的是，较复杂的团队结构可能会导致沟通隔阂或滞后。 当一个团队的工作遭遇阻力时，他们可能无法生成其他团队所依赖的内容。 这对于小型团队（所有相关人员每天召开会议）而言可能不是大问题。 但是，随着团队规模和位置不断扩展，每个人不可能知道任何地点发生的任何事情。 正是在这一点上，组织需要从纯“推送”模型（如亲自或电子邮件公告）转换为“拉取”模型（团队可以查看和跟踪彼此的计划）。
Andy：好的，我刚和开发主管联系过。 她告诉我，在艺术团队从 Cliffchella 返回前，他们的团队都无法交付 beta 版本。
Mara：那个山顶音乐节吗？
Andy：是的，很明显这在设计界是一件大事，他们整个团队只需要一整周的时间进行准备，方可参加。 游戏引擎团队士气低落，因为这将他们的计划延期了三周。 如果事前知道事情会这样，他们会确保提前获取所需的项目。 他们还为没有早一点告诉我们而道歉。 他们之前不知道我们等着使用他们的 beta 版本来交付我们的部分。
Mara：至少值得欣慰的是游戏引擎团队正在发布他们的冲刺 (sprint) 计划。 它帮助我们尽早发现了此依赖关系问题，以便我们调整计划。
Andy：我希望能有一种方法可以更轻松地了解潜在的风险。 我们的团队在公司有许多依赖关系，因此我们不可能参加每个会议，并订阅每个通讯组。
Mara：我们应该创建一个交付计划，这样我们可以同时查看团队冲刺 (sprint)。 这将有助于两个团队更轻松地确定我们的计划如何相互影响。
用于管理多个敏捷团队的建议
敏捷方法以及 Azure DevOps 可显著提高项目透明度和可预测性。 不过，项目可能仍会遇到传统挑战，这些挑战通常与人员或信息误传相关。 在缩放敏捷工作时，需要考虑以下事项。
在用户和流程中建立信任
敏捷实现的早期恶意批评者通常怀疑其提高团队绩效的能力。 组织内的思想领导者需要通过演示工具和流程如何生成结果来建立信任，这一点很重要。 有时，这些结果是工作效率提高，这很容易量化。 但是，请不要忘记强调规避潜在问题（如可避免的计划延期或质量问题）所带来的团队获益。 当人们开始将权益与实现它们的流程关联时，你将发现他们更积极。
将组织提升到团队（和个人）之上
当有新的流程或策略提出时，某些团队和个人会较抗拒。 强调新透明度如何在组织中为每个人的期望提供依据，而不是将新策略描述为对特定团队或个人的绩效带来负面影响。 如果任何人都能在同一个位置跟踪其工作与组织完成其目标的关系，这将使人易于理解他们对该流程的承诺的重要性。
促进透明度文化
遗憾的是，“透明度”一词并不那么招人喜欢。 如果一切进展顺利，没有人会要求提高透明度。 如果团队遇上麻烦，则通常会归咎于透明度（或缺少透明度）。 即使敏捷团队拥有所有透明度机会，结果仍然受到个人和团队的诚信度影响。 请强调实现透明度的原因之一是能够尽早识别并解决可能出现的问题。 大家都知道，人们有时会遇到妨碍他们符合计划截止时间的情况。 但是如果他们直到最后一秒钟才不得不报告令人失望的消息，则可能产生破坏性高得多的影响。 如果要构建舒适级别的透明度，可以首先就相关人员尽早报告预期的延迟表示感谢。