iis积压_三个积压？

iis积压

现在，我知道有些人不喜欢积压的工作–队列，等待状态，我们想要完成的工作–我赞成这种说法。 但是Scrum Sprint（迭代）和Product Backlog模型实际上适合许多组织。

也许它是过渡到持续流动，持续价值之前的临时状态，但对于许多组织来说也可能是明智的状态。 产品待办事项是他们想做的事情，但是还没有解决。

虽然我通常接受并教授产品/冲刺积压模型（我们将来可能会做的所有事情/未来两周我们将重点关注的事情），但我一直在想这是错误的。

应该有三个待办事项

1. 机会积压 ：曾经提出过的所有想法都被认为值得记录。 记录这样的想法绝不会使任何人真正地去实践它们。
2. 经过验证的积压 ：来自机会积压的项目已经过检查，研究和讨论，足以被视为未来发展的有效候选人。
3. 迭代/冲刺积压 ：将在当前迭代中尝试的工作。

尽管迭代/冲刺积压与以前一样发挥了作用-设置了下一个迭代的议程-拆分产品积压可以将“好主意”和“经过验证的主意”明确分开。 从前者转向后者的过程包括与利益相关者核对想法，根据总体目标对其进行衡量，考虑市场或组织的利益，并可能进行实验以衡量利益。

这三个积压模型自然地映射到我之前描述的三个计划范围 ，并映射到团队常用的Epic，Story，Task工作分解：

• 机会背景包含大项目，而细目分类很少。 这些可能会在更长的时期内发生，可能会在未来的季度和几年内发生。 它们可能出现在路线图中，或者可能更具投机性。
• 经过验证的积压项目应为故事大小-足够小，可以很快交付，但具有真实的商业价值。 这些项目可能会在下一季度的某个时间开发，因此会出现在季度计划中。
• 迭代积压项目在这里和现在，它们是任务大小的，并且在当前迭代中。

没有必要在任何项目上做更多的工作，直到它移至下一个待办事项列表，再进入下一个计划范围。 在每个阶段，一些物品都会消失，在仔细检查后，它们不会被认为是值得的。

在进行任何工作之前，无需将史诗整体分解。 理想情况下，从任何史诗中脱颖而出的第一个故事都是可以测试技术选择以及更重要的是市场和客户React的实验。

例如，史诗标题为“法语发行版”的第一个故事可能描述了一系列数据收集实验，以评估市场规模和机会。 翻译，付款等可能需要等待，他们可能根本不需要这样做。

至于估计：

• 如果需要，迭代积压中的项目可能需要详细的工作量估算才能得出
• 经过验证的待办事项中的项目可能具有总体估计，而且非常重要的是价值估计（该项目价值多少？）
• 商机积压中的项目可能具有从历史平均值中得出的努力得分（为什么要花时间来估计可能不会发生的事情？），并且只有在进行了价值估算并且判断出该项目相对值得时才可以移至已验证的积压中其他的

三个积压。 你怎么看？ 好主意还是傻？

参考： 积压了三笔？ 来自JCG合作伙伴 Allan Kelly（来自敏捷，精益，模式博客）。

翻译自: https://www.javacodegeeks.com/2013/07/three-backlogs.html

iis积压