与“主要”功能待办事项并行的“一口大小”任务的待办事项？

在高度孤立的“孤狼”开发部门结构中工作了两年多之后，我们采用了敏捷SCRUM。大。我喜欢敏捷；作为一名开发人员，它可以让您专注，忙碌和高效，而无数个利益相关者将项目逐个推销，而他们的期望已于昨天完成。

但是，与我们当前的“模型”相比，转向SCRUM有一个方面，我认为Development以外的人不会丝毫喜欢。这就是他们目前的能力，可以让我们在“等待时”进行一些小的更改。我们开发的很大一部分仅用于内部消费，而且我们几乎都位于同一栋大楼中。因此，多年来，部门负责人或其他部门的经理来找特定应用程序的“代码库所有者”并索要一些小东西（有时不是那么小，但是我们很乐意不承担这三点，周项目基于这些“偷渡者”）。甚至我们的老板有时也会以此方式转达给他的事情。很多时候，如果我们当时正在使用有问题的代码库，我们可以简单地弹出源文件，

使用基本的敏捷SCRUM方法，这些调整将被记录为缺陷（我们不满足先前使用的故事中指定的要求）或新的小故事（我们满足所有陈述的要求，但这些要求不完整，模糊或不正确） ，或者在用户看到新功能后在交付后进行了更改）。无论哪种方式，绝大多数将是一个三分球最多如果不是零和相对较低的优先级（该系统是在其当前状态下使用，但它是如此酷多了，如果......），这使得它们不太可能自上而下地处理积压工作时进入冲刺。

在开发人员会议上提出的这种可能性是其他部门积极反对我们的敏捷过程的根源，他们认为这比我们当前根据要求进行细微调整的能力“敏捷”程度要小。IMO是一个有效的关注点。采购订单背后的利益相关者并不总是就最重要的事情达成共识，因为他们的观点并不完全相同，但是通常只有管理者才能做出最终决定，因此他们的偏见是显示在产品积压中。

然后提出了一个解决方案，该解决方案暂时称为“糖果罐”（另一个抛出的术语是“肉汁船”）。各个部门的“小家伙”要求进行的细微调整（不是现有故事中的缺陷），通过团队内部的共识或鼓掌估计，这些细微调整需要不到开发人员一天的一半，而最终用户认为，对用户体验的即时，重要，积极的影响将与主要待办事项并行列出。它们将被识别为“故事”，但将与“大”故事的主要待办事项隔离开来，但要优先考虑。如果在sprint正常进行期间的任何时间，我们碰巧在系统区域中可以进行这些调整之一的工作，使微调变得微不足道，我们可以将微调带入sprint并在更大的故事中对其进行编码。这样做不得危害更大故事的完成或任何其他承诺的工作。PO也可以访问此列表，如果他们正在处理即将到来的用户故事，涉及涉及该调整的基本功能，则可以将其作为故事的要求折叠起来，然后我们将满足该要求。其他。人们认为，这将使调整的生效时间提早。

这在ScrumMaster培训“ uh-uh”中触发了我们当中的反应。有一个积压。两次积压引入了以下问题：哪个＃1项实际上是最重要的，哪个列表的项决定了真实的速度，以及一个故事实际所属的两个积压中的哪个（大小/复杂性的任何划分都会使某些情况相对下降任意一侧或另一侧）。我们说：“让这个过程起作用”；如果更改对最终用户确实很重要，那么他们将发出足够的声音让部门负责人做出时间/金钱的决定，并且将被积压在开发团队的意识中。

我以为我要提一个问题：您认为，平行列出的“一口大小”的故事是否对使小而有用的，但最终是低优先级的更改更快地做出有价值的决定，或者总体而言是一个更好的决定？将它们折叠成主要待办事项，并让基本过程控制它们是否包含在冲刺中？

我将谈论一些要点，希望它们可以帮助您找到自己的方式：

1. “ SCRUM ”即将变得敏捷。需要常识。如果更改是几分钟的更改，那么我认为您不需要积压。如果超过2个小时，我想您应该再考虑一下。并非所有“轻松取胜”的事情都应该做。在SCRUM中，您按优先级工作。我认为PO必须获得有关您从加法中获得的收益以及所付出的努力的信息。只有这样，PO才能决定它是否重要。转向SCRUM有时会带来很多问题，开发人员通常会说“但是，这只需要几个小时”。所以呢？几个小时就是时间，不是所有短时间都需要包括在内。
2. 我曾经在一个“积压的工程”项目中工作。此积压中包含开发人员建议的用于改进产品的项目。这些项目没有显式的用户值（但具有隐式的用户值）。例如：重构代码中的组件。我们已经描述了变更，工作量和收益（在这种情况下，您什么也看不到。但是，如果这种重构导致更快地开发新功能，那么对于用户来说绝对是收益）。我们的采购订单决定，在版本期间，我们应将每个Sprint（平均）的10％投资于此类项目。在每次冲刺之前，采购总监决定即将进行的冲刺积压工作时，他确保我们有10％的工程积压项目。所以2个版本的待办事项-> 1个sprint的待办事项。
3. 缓冲区 -当开始在SCRUM中工作时，人们通常会忘记，作为软件工程师，我们会陷入不确定的世界。可以将1天的工作时间从6个小时而不是8个小时算起，也就是说，您有15天的冲刺时间，这意味着您有30个小时的时间花在开会，花时间太长的事情上，是的-对于那些小孩子太小而难以记住的事情，但它们却是我们2天工作的一部分。
4. 保持专注 -最后但并非最不重要，在SCRUM中，保持专注很重要。确定要投入多少精力以及优先级是要投资于此类任务，并记住要花时间和精力。不要仅仅因为它们很小就着手处理“小事情”。您有一个PO可以帮助您做出决定，并且具有常识。
5. 保持敏捷 -最后，不要忘记尝试其他方法来解决问题，并问自己是否确实是最好的方法。不断改进。

祝好运 ：）

诸如Agile和SCRUM之类的编程框架旨在将学科和结构应用于开发。但是，纪律和结构似乎是乐趣和创造力的反义词。通常，您需要更加努力地建立和维护纪律。在这些对立的概念之间很难找到平衡。因此，框架倾向于避免该主题。

在我的上一个项目中，我们观察到开发人员每天需要一点时间来刷新或清理头部等。他们被分配了预算的时间（0.5小时/天或2.5小时/周），可以在此时间内做任何事情原因（可能会应用于工作中的事物）。为了保持纪律性，他们被要求记录自己的活动，以便他们对任何成就等功劳都得到认可。在我们的时间表内有一个专门的“糖果罐”预算，可以防止事情失控。

顺便说一句，我们称我们为“项目冷静”，它最终成为该公司许多好主意和改进的源泉。

您应该将这些小故事保留在主订单中。

尽管我没有使用Scrum，但我遇到的问题与您所描述的类似。我看到您面临优先级和效率方面的挑战。

听起来像是在您的“老办法”下，任何人都隐含地被授权将访问开发人员办公室的任务作为当前的“首要任务”。这有一些好处。请求者感觉就像他们正在响应，请求者和开发人员都获得了“快速胜利”。

不利的一面是，频繁插入这些任务往往会减慢或破坏与产品所有者达成一致的头等优先任务。（附带说明，通常每个人都低估了这些“快速”修复所需的时间。）

我的经验是，尝试挤压低优先级的任务会损害优先级的好处。作为开发人员，优先级排序可以向我证明我正在从事产品所有者希望我从事的工作。产品负责人应决定是否要承担额外的工作，并且冒着“很高兴”的要求折叠的风险（无论轻微）。

通常，当我要求利益相关者确定优先顺序时，我会被问到“您能不能挤进去？”。我的隐含愿望是，在不影响当前最高优先级的前提下，神奇地完成新任务。

我经常遇到的是利益相关者要求使用LargeImportantProject和SmallLessImportantTask。困境是，SmallLessImportantTask是否应该等待LargeImportantProject完成（或设置障碍）？需要权衡取舍，而我的经验是产品负责人必须决定。（如果产品负责人没有决定，则开发团队必须猜测。）

Scrum（通常是项目管理）的目标之一是避免为最高优先级任务设置障碍。随着效率的提高，挤占多余空间的空间也就减少了。

效率可能令人恐惧，但是我已经从两个重要的方面看到了收益大于成本。

1. 随着效率的提高，您将提高团队完成有价值的工作的能力，其中包括“很高兴”的要求。
2. 如果一个请求确实是“很高兴”，那么等待请求解决更重要的业务优先级可能是完全合法的。

在我看来; 您的问题是在待办事项中确定任务优先级的方式。例如，“优先级”可以同时考虑重要性和完成速度。不太重要但可以在10分钟内完成的事情比需要花费数周时间才能实施的重要事情具有更高的优先级。

我已经在敏捷领域工作了一段时间。我只能说的是-在某些情况下，坚持一种方法论及其所包含的一切都是绝对错误的。您必须具有敏捷性，并且必须针对IMO调整方法以适应特定情况。

就像上面的Avi所说的那样-“ SCRUM”是关于敏捷。需要常识。如果更改是几分钟的更改，那么我认为您不需要积压。

如果更改需要时间，则意味着并非所有的“无害”都应记录在案。

根据您最初的问题和随后的澄清，这就是我认为您的痛点是

• 不断变化的要求
• 开发人员无法专注于应用程序的其他领域，即 我们是应用程序一部分的英雄，但不热衷于其他方面。
• 采用不同的架构，解决方案和框架方法
• 需求收集过程似乎不起作用

如果最初正确地遵循Scrum，那么应该会解决许多这些问题，更重要的是，将其他问题放在首位应解决。

-不断变化的要求

仅有一份积压的东西，所有东西都被正确地放入了优先级，这意味着在开发过程中团队不应首当其冲地进行需求变更。如果是一个非常动态的环境，则较小的1或2周的冲刺应该确保仍可以在相对较短的时间内促进更改优先级。

-开发人员无法专注于应用程序的其他领域，即 我们是应用程序一部分的英雄，但不热衷于其他方面。

一个Scrum团队可以很好地协作和相互支持，并在团队内部共享知识并寻求在应用程序其他部分上工作所面临的挑战方面具有特定的动力，它将努力确保共享应用程序的知识。诸如结对编程之类的一些实践可以帮助人们克服对编写不熟悉的代码的恐惧，同时还能学习和共享知识。在团队之间分配应用程序知识之前，这可能需要花费一些时间，并且人们可以轻松应对应用程序的任何区域。同样，允许人们承担董事会的任务，即根据自己的工作意愿做出选择，也可以鼓励这一点。

-采用不同的架构，解决方案，框架方法

Scrum促进了更好的沟通，促进了团队合作和更好的决策，并提供了对正在发生的事情的更大可见性。反过来，这应该有助于组织围绕使用框架，体系结构解决方案等进行决策，并且使用Scrum of Scrums机制可能有助于将其灌输到整个组织中。

-需求收集过程

同样，如果您严格遵守规则，并且没有明确规定需求，并且让团队能够理解和估计满足需求所需的条件，则不应将其纳入冲刺。采取另一个高度优先且定义明确的要求...因为这样您便知道您将能够实现！虽然它可能无法立即解决需求收集过程，但会强制进行必要的更改以解决该问题。

要回答您的第一个问题，不，不应有两个单独的积压。在任何时候，开发人员和组织首先致力于最高优先级的项目，这符合每个人的最大利益。优先级应该主要基于业务价值，并且许多小的调整和请求很可能确实会增加业务价值。让产品负责人决定。

我担任Scrum主管已有7年以上，并帮助将Scrum引入许多不同的团队和公司。根据我的拙见和观察，我觉得，如果是第一次将Scrum引入您的组织，请遵循本书。不要偏离。Scrum要求纪律能够坚持实​​践和流程。为适应特定情况而设置例外太容易了，如果过早地进行例外处理，将会导致其带来的利益和价值的侵蚀。做基础，做得好。成为基础知识专家并了解基础知识为何，然后更改流程以更好地适应并推动组织内的持续改进。

有很多非常有效的案例可以说这是“敏捷”的，所以我们必须愿意改变流程，但是一个自我指导，自我组织的团队了解该流程并讨论可以对之进行的更改之间存在很大的差异。这个过程，而不是刚开始走敏捷或Scrum之路的团队。这就像在您不知道要爬网之前尝试运行...