程序和解决方案积压

计划Backlog是即将发布的特性的保留区域，这些特性旨在满足用户需求，并为单个敏捷发布培训(ART)交付业务收益。它还包含构建架构跑道所需的启用器特性。

解决方案待办事项列表是即将到来的功能和启用程序的保留区域，每个功能和启用程序都可以跨越多种艺术，旨在推进解决方案并构建其体系结构跑道。

产品管理负责计划Backlog，而解决方案管理负责解决方案Backlog。这些积压的项目来自于研究活动和与各种利益相关者的积极合作——客户、业务所有者、产品管理、产品所有者、系统和解决方案架构师/工程等等，这些都是持续探索过程的一部分。

待办事项项通过各自的程序和解决方案看板系统进行管理。工作经过“漏斗”和“分析”的状态，以及经过充分阐述和批准的最高优先级的特性和功能，移动到“backlog”状态。然后，相对于其他待办事项列表，对它们进行优先级排序，等待实现。

使用加权最短作业优先(WSJF)有效地识别、细化、确定优先级和排序待办事项项是解决方案经济成功的关键。由于backlog包含了新的业务功能和扩展架构跑道所必需的支持工作，所以使用“容量分配”来帮助确保快速和长期的价值交付，并保证质量。

细节

程序和解决方案积压是所有影响解决方案行为的即将进行的工作的存储库。产品和解决方案管理分别开发、维护和优先处理计划和解决方案积压。积压是通过各自看板系统并已批准实现的特性和功能的短期存储区域。计划安排项是用故事点来估计的，如图1所示。

图1所示。项目待办事项列表的分解视图，带有对故事点大小的估计

细化积压

敏捷发布培训和解决方案培训运行一个稳定的8-12周的计划增量(PI)节奏，包括计划、执行、演示、检查和调整(I&A)。这种有规律的节奏也是驱动backlog准备工作的心跳。出现在PI前期计划或PI计划中而没有详细的backlog，会给即将到来的PI增加不可接受的风险。

PI计划事件之间的时间是产品和解决方案管理的繁忙时间，因为它们总是在为下一个PI计划细化积压的过程中。使这个过程可见，并为即将到来的PI实现backlog准备就绪，是程序和解决方案看板的主要目的之一。

Backlog改进通常包括:

审查和更新待办事项项定义，制定验收标准和效益假设
与团队合作，建立技术可行性和范围评估
分析将待办事项项分割为增量值的小块的方法
确定支持新特性和功能所需的启用程序，并确定它们的容量分配

优先的积压

对程序和解决方案积压进行优先排序是解决方案的关键经济驱动力。为此，产品和解决方案管理使用WSJF优先级方法进行作业排序。回顾一下，WSJF最终转换为一个简单的公式，如图2所示。

图2。一个计算WSJF的公式

准备PI计划

PI计划的前一两周是一个关键时刻。产品和解决方案管理做最后的backlog准备，更新远景简报，并在活动之前与产品所有者合作进一步社会化backlog。系统和解决方案架构师/工程更新启用器定义和模型，并经常开发用例来说明功能和功能如何协同工作以交付最终用户价值。

通过容量分配优化价值和解决方案的完整性

每一个艺术和解决方案培训面临的一个挑战是如何平衡积压的业务特性和功能需要不断投资于建筑的跑道,为探索提供时间需求和设计未来π和创建原型和模型增强可视性问题区域。为了避免降低速度，并推迟由于技术过时而大规模替换组件的需要，ARTs必须不断投资于实现解决方案的推动者。这增加了工作优先级的难度，因为不同的人可以将团队拉向不同的方向，如图3所示。

图3。业务与启用待办事项项之间的两难境地

为了解决这个问题，ARTs应用了容量分配，在这里，他们决定为即将到来的PI的每种类型的活动可以使用多少总工作量。此外，它们还建立了一个协议来确定如何为每种活动类型执行工作。这也可以包括持续维持的特别储备金以及减少可能累积的任何技术债务。图4和表1给出了结果的示例。

图4。单个PI的容量分配示例

在每一个PI边界上，我们都同意将资源的百分比用于新特性或功能与启用程序之间的比较。

我们同意系统和解决方案架构师/工程有权优先考虑使能工作。

我们同意产品和解决方案管理有权优先处理业务待办事项。

我们同意在经济基础上共同确定工作重点。

我们同意以最大化客户价值的方式在排序工作上进行合作。

表1。管理启用器和特性容量分配的示例策略

虽然商定的策略可以持续一段时间，但分配的容量应该根据上下文定期变化。在艺术的上下文中，这个决策可以作为为每一个PI计划做准备的backlog细化的一部分重新访问，而解决方案管理和解决方案架构师/工程在pre-PI计划之前对整个解决方案做出类似的选择。

关于积压、队列、Little 's Law和等待时间

重要的是，我们应该把时间放在一边，讨论一下积压、等待时间和流程之间的关系。原则#6，可视化和限制WIP，减少批处理大小和管理队列长度，详细解释了这种关系。然而，在这里总结一下这个讨论是很重要的，因为程序和解决方案积压可能对交付时间和吞吐量产生最显著的影响。

这里有一个总结:

Little定律说明，队列中某项的平均等待时间等于队列的平均长度除以队列中某项的平均处理速度。队列越长，等待时间越长，变异性越大。

图5。小定律

想想星巴克的排队情况:如果你前面的十个人每人都点了一杯大杯咖啡，你几分钟内就会离开那里。如果每个人都买了一杯特热的香草拿铁和一个加热的百吉饼，你可能会迟到，而且这不是你能控制的。

排长队都是不好的，导致动机降低、质量差、循环时间更长、变异性更高(想想星巴克)，以及风险[2]增加，如图6所示。

图6。排长队不好

您的程序和解决方案积压不是队列，因为项目可以跳过其他项目以获得更快的交付速度，而且您总是可以选择不为积压中的所有内容提供服务。(注意，这两种方法在星巴克都行不通。)

然而，如果您的backlog中的所有项都提交给涉众，那么您的backlog就像一个队列，队列越长，涉众等待服务的时间就越长。如果他们不得不等太久，他们会找到另一家咖啡店，因为你的店不能满足他们快速变化的市场需求。

因此，团队和艺术必须积极地管理他们的积压，并保持它们简短，以便快速响应。他们还必须限制对长期工作的承诺，因为可能会出现一些比先前的承诺更重要的其他事项。如果一个ART在backlog中有太多固定的和提交的需求，不管它有多高效，它都不能快速响应。

只有当团队和ARTs积极地管理backlog并保持其简短时，它们才能同时可靠和快速。

了解更多

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
[2] Reinertsen, Don. Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

原文：https://www.scaledagileframework.com/program-and-solution-backlogs/

本文：https://pub.intelligentx.net/safeprogram-and-solution-backlogs

讨论：请加入知识星球或者小红圈【首席架构师圈】