大规模发布计划

我在不同的公司用过不同的技术。在我目前的雇主那里，我们正在使用史诗来组织一组用户故事，使之成为连贯的面向客户的交付产品。
史诗定义了一个目标版本，并且有一个技术主管或一个项目经理负责与前端/后端团队中的各个产品负责人交谈，并确保他们的优先级和冲刺计划考虑到总体目标和发布计划。
使用JIRA(我们选择的工具)，您可以使用各种史诗报告来跟踪相同的内容。

我们放弃了跨团队的单个积压(或并行积压)的想法，因为管理这些积压变得太有挑战性了。

当然，我可以讲得更详细一点——这取决于你想讲多远。

独立的前端和后端团队通常需要协调他们的发布计划，以便交付具有商业价值的特性。因此，您可以通过重新组织到特性团队来减少所需的发布计划的数量。这将使发布计划更容易围绕业务需求而不是技术需求进行调整。

特性团队带来的挑战往往比他们解决的要多。当您同时进行许多小项目时，它们就不能很好地工作，并且它们不能促进对特定组件或工程驱动的改进的深入了解。

在一些组织中，它们确实有效，但这并不是发布计划问题的最终答案。

发布计划中的第一个考虑是消除开发团队的约束。焦点必须直接放在每个版本给产品负责人带来的价值上。对于核心Scrum来说，功能团队并不是必不可少的，但它们是一种很好的实践，因此在大规模实施Scrum时，会特别考虑它们的优点。

没有按照特性发布进行组织的开发团队更有可能增加发布计划开销，包括实现发布所需要的沟通，以及在任何一个特性的价值被证明之前必须解决多个集成点。因此，在优化发布计划安排时首先考虑这个问题是很重要的。

从理论上讲，这都是正确的。实际上，由于我在之前的回复中提到的原因，特性团队是有成本的。

此外，开发人员不会只致力于一个产品或功能。他们还支持初级团队成员，处理客户升级，对组件进行维护，部署旧项目等。所有这些都需要组件所有者之间的日常交互，而特性团队违背了这一点。

但它们绝对值得考虑。从个人经验来看，我尝试过几次功能团队——每一次的表现都不如模块化团队。

特性团队可能会违背组织关于价值以及如何最好地交付的假设。这些假设通常反映在组织的配置中，例如按层、按地理位置或按组件。

企业敏捷性需要深入而普遍的变化，以及在组织运行过程中实现这种变化的支持。在实现特性团队时，生产率下降是可以预料的，尽管这是短期的。这在缩放专业Scrum框架中得到了认可。然而，我个人认为，除非有合适的赞助，否则开始实施功能团队是不明智的。