与“主要”功能待办事项并行的“一口大小”任务的待办事项？
在高度孤立的“孤狼”开发部门结构中工作了两年多之后，我们采用了敏捷SCRUM。大。我喜欢敏捷；作为一名开发人员，它可以让您专注，忙碌和高效，而无数个利益相关者将项目逐个推销，而他们的期望已于昨天完成。 但是，与我们当前的“模型”相比，转向SCRUM有一个方面，我认为Development以外的人不会丝毫喜欢。这就是他们目前的能力，可以让我们在“等待时”进行一些小的更改。我们开发的很大一部分仅用于内部消费，而且我们几乎都位于同一栋大楼中。因此，多年来，部门负责人或其他部门的经理来找特定应用程序的“代码库所有者”并索要一些小东西（有时不是那么小，但是我们很乐意不承担这三点，周项目基于这些“偷渡者”）。甚至我们的老板有时也会以此方式转达给他的事情。很多时候，如果我们当时正在使用有问题的代码库，我们可以简单地弹出源文件， 使用基本的敏捷SCRUM方法，这些调整将被记录为缺陷（我们不满足先前使用的故事中指定的要求）或新的小故事（我们满足所有陈述的要求，但这些要求不完整，模糊或不正确） ，或者在用户看到新功能后在交付后进行了更改）。无论哪种方式，绝大多数将是一个三分球最多如果不是零和相对较低的优先级（该系统是在其当前状态下使用，但它是如此酷多了，如果......），这使得它们不太可能自上而下地处理积压工作时进入冲刺。 在开发人员会议上提出的这种可能性是其他部门积极反对我们的敏捷过程的根源，他们认为这比我们当前根据要求进行细微调整的能力“敏捷”程度要小。IMO是一个有效的关注点。采购订单背后的利益相关者并不总是就最重要的事情达成共识，因为他们的观点并不完全相同，但是通常只有管理者才能做出最终决定，因此他们的偏见是显示在产品积压中。 然后提出了一个解决方案，该解决方案暂时称为“糖果罐”（另一个抛出的术语是“肉汁船”）。各个部门的“小家伙”要求进行的细微调整（不是现有故事中的缺陷），通过团队内部的共识或鼓掌估计，这些细微调整需要不到开发人员一天的一半，而最终用户认为，对用户体验的即时，重要，积极的影响将与主要待办事项并行列出。它们将被识别为“故事”，但将与“大”故事的主要待办事项隔离开来，但要优先考虑。如果在sprint正常进行期间的任何时间，我们碰巧在系统区域中可以进行这些调整之一的工作，使微调变得微不足道，我们可以将微调带入sprint并在更大的故事中对其进行编码。这样做不得危害更大故事的完成或任何其他承诺的工作。PO也可以访问此列表，如果他们正在处理即将到来的用户故事，涉及涉及该调整的基本功能，则可以将其作为故事的要求折叠起来，然后我们将满足该要求。其他。人们认为，这将使调整的生效时间提早。 这在ScrumMaster培训“ uh-uh”中触发了我们当中的反应。有一个积压。两次积压引入了以下问题：哪个＃1项实际上是最重要的，哪个列表的项决定了真实的速度，以及一个故事实际所属的两个积压中的哪个（大小/复杂性的任何划分都会使某些情况相对下降任意一侧或另一侧）。我们说：“让这个过程起作用”；如果更改对最终用户确实很重要，那么他们将发出足够的声音让部门负责人做出时间/金钱的决定，并且将被积压在开发团队的意识中。 我以为我要提一个问题：您认为，平行列出的“一口大小”的故事是否对使小而有用的，但最终是低优先级的更改更快地做出有价值的决定，或者总体而言是一个更好的决定？将它们折叠成主要待办事项，并让基本过程控制它们是否包含在冲刺中？