Questions tagged «sprint»

许多Scrum书籍和文章都说，失败的sprint（当团队无法完成Sprint Backlog的某些功能时）并不是一件坏事，它不时发生，并且如果团队从错误中吸取教训，这实际上很有用。并改善了以下冲刺中的一些功能。并且团队不应因未完成其承诺的工作而受到惩罚。 从开发人员的角度来看，这看起来不错，但是，我们有一家软件公司“ Scrum-Addicts LLC ”为认真的客户（“ Money-Bags Corporation ”）开发一些东西： Scrum-Addicts经理建议为Money-Bags开发一款软件 他们同意功能列表，Money-Bags要求提供发货日期 Scrum-Addicts经理咨询了他们的Scrum团队，该团队表示，将需要3周的冲刺来完成所有功能 Scrum-Addicts经理增加了1周的安全时间，承诺在1个月内发布该软件，并与Money-Bags签订了合同 经过4个冲刺（交付期限）后，Scrum团队只能交付80％的功能（由于新系统的经验不足，需要在生产环境中修复以前的功能中的关键错误等）。 正如Scrum所建议的那样，该产品目前可以交付，但是如合同中所述，Money-Bags需要100％的功能。因此，他们违反了合同，却一无所获。 Scrum-Addicts濒临破产，因为他们没有从Money-Bags获得任何收益，并且投资者对结果感到失望，不愿再为公司提供帮助。 显然，没有哪个软件公司愿意加入Scrum-Addicts的行列。我对敏捷和Scrum的不了解是，他们建议团队如何应对计划和截止日期，以避免上述情况。因此，总而言之，我有两个问题： 谁是罪魁祸首？ 经理，因为做适当的计划是他们的工作 团队，因为他们致力于做更多的工作 其他人 什么是要做？ 经理应将截止日期推迟到原团队的估计值的2倍（或3倍）。 无论如何，都应鼓励团队成员尽心尽力（通过对冲刺失败进行处罚） 团队应放弃Scrum，因为它不符合公司的截止日期政策 我们都应该放弃软件开发并加入修道院 ???

80 agile  scrum  sprint 

我们的Sprint计划会议不仅不好玩，而且简直令人恐惧。 这些会议既乏味又无聊，而且要花很多时间（一天，但感觉要更长一些）。 开发人员对此表示抱怨，并担心即将到来的计划。 我们的例程非常标准（按优先级将用户故事插入到sprint待办事项中>>将故事分解为任务>>按小时数估算任务>>重复），我无法弄清楚我们在做什么错。 我们如何使会议变得更加愉快？ ... 应要求提供更多信息的更多详细信息： 为什么在sprint启动之前未插入待办事项并按优先级排序？ 用户故事确实是优先的；我们不知道他们会花多长时间，直到将他们分解成任务！从这里的（优秀）答案中，我看到也许我们根本不应该估计任务，而应该仅估计用户故事。我们估计任务（而不是故事）的原因是因为我们一直在错误地估计故事，但我想这是一个完全不同的问题。 开发人员为何抱怨？ 会议很长。 会议是单调的。一个接一个的故事，一个接一个的任务，奋斗（是的，奋斗）来估计需要多长时间和涉及什么。 估计任务使用户故事的估计显得毫无意义。 会议时间越长，会议室的焦点就越少。同事注意力越集中，会议花费的时间就越长。递归的仇恨螺旋发展。我们已经考虑将会议分成两天，以使人们集中注意力，但是开发人员对此一无所知。一天的计划已经够糟糕了；现在我们有两个？ 问题的一部分是我们进入了非常小的细节（以便获得更准确的估计）。但是，当我们粗略估算时，我们远远超出了预期！ 总结一下问题： 我们做错了什么？ 还有什么其他方法可以使会议更加愉快？

51 agile  scrum  sprint  meetings  process-improvement 

我使用的代码库超过50万行代码。迫切需要重构。已经确定了重构工作将比正常的两周冲刺花费更长的时间。正如我在本网站上的其他答案所建议的那样，这些不能分解成较小的任务。产品需要在迭代结束时工作，并且部分重构将使系统处于无法使用的状态，因为项目之间的依赖关系非常糟糕。那么解决这一障碍的最佳方法是什么？我再次提到，将其分解成较小的部分不是一个选择，这已经完成了。 更新：人们似乎需要解释为什么这不能适合2周的冲刺。冲刺中涉及的不仅仅是编写代码。我们的政策是没有测试就没有代码。该策略并不总是存在，并且代码库中的很大一部分都没有。另外，我们的某些集成测试仍然是手动测试。问题不在于重构本身如此之大。事实是，小的更改会影响系统的许多部分，因此我们需要确保这些部分仍然可以正常运行。 因为我们有每月的修补程序，所以我们不能推迟或延长冲刺。因此，经过sprint的更改无法停止将其他工作添加到此修补程序中。 重构与重新设计：仅仅因为我们的开发过程效率不足，无法在两周的周期内完成此重构，所以不能保证将其重命名为重新设计。我想相信，随着我们流程的改进，将来我们可以在两周的周期内完成完全相同的任务。这里讨论的代码很长时间都不需要更改，并且相当稳定。现在，随着公司的发展方向变得更加适应变化，我们希望代码库的这一部分与其余部分一样具有适应性。这需要重构。根据这里的答案，很明显，在正常的sprint的时间范围内缺少必要的脚手架来进行此重构。 回答： 我将采用科宾·马奇（Corbin March）首次提出的分支与合并方法，以便我们可以更多地了解这些问题领域以及如何识别缺失的测试。我认为，向前迈进，我们应该采用Buhb建议的方法，确定缺少测试的区域并先实施这些区域，然后再进行重构。这将使我们能够保持正常的两周冲刺周期，就像这里的许多人一直在说的那样，重构应该总是如此。

49 refactoring  sprint 

因此，Scrum冲刺是一个固定的时间段，在此期间应实现一组特定的功能。Scrum团队由致力于提供这些功能的所有人员组成，其中大多数通常是开发人员和测试人员。 建立了这些规则后，您可能会想知道如何在整个冲刺期间让所有这些人都忙。在sprint的开始阶段，没有什么要测试，而在sprint的末尾，通常没有什么东西可以开发/修复。 我已经看到了两种方法可以解决此问题，但是它们似乎都无法正确解决问题。 1）让团队成员决定在任务结束时应该做什么。 缺点： 如果他们的工作没有得到充分的计划（例如，重大的重构，改用新的测试框架），那么他们的工作可能会变得毫无用处，或者被困在中间 另一方面，计划这样的工作可能要花费大量时间，并且客户可能会失望地看到团队浪费时间在无法带来即时价值的事情上 通常无法对这些任务进行彻底的估算，因此，无原则的工作人员很容易花时间看YouTube猫，而不会在Scrum板或其他任何地方反映出来 2）在sprint中留出仅用于开发的空间，并在sprint完成后开始测试（当开发人员开始处理下一个sprint的功能时） 缺点： 在为当前sprint开发功能时，开发人员会通过修正前一个bug来分心，而他们可能无法执行估计在当前sprint期间完成的工作量 需要两个Scrum板：一个用于当前的sprint功能，一个用于以前的sprint错误 所以我的问题是：如何在开发人员和测试人员之间的冲刺期间正确分配工作，以使任何人都不会负担过多的工作，或者在任何时候都没有任务而最终失败？有什么方法可以改善上述方法？还是有更好的方法？

33 agile  scrum  sprint 

假设一个团队成员正在休年假。他不会参加Sprint计划，但他将在迭代/ Sprint中期回来。可以说他有50％的容量，也就是说，如果他可以在下半阶段迭代中使用，我们应该： 他回来后与他进行计划会议。 在他休年假之前，即在进行短跑计划之前，与他进行一次计划会议。 不要安排他执行任何任务，也不要将他分配给非冲刺任务，例如尖刺等 在进行Sprint计划时让他的同伴代表他进行计划，缺席的人可以在他回来时添加任务，如果他不能完成所有工作，可以扩大范围。 让他与另一位开发人员坐在一起，做一段时间的配对编程。 还要别的吗.. 我有兴趣知道你在做什么。 注意：我们正在做（1），感觉不正确。

18 scrum  sprint 

我花了5个小时以上的冲刺计划来进行为期一周的冲刺。似乎太过分了。 由于大多数团队成员都不高级，因此我们将在sprint计划中详细讨论事情。如果我们不这样做，将会在实现过程中导致错误，并在sprint过程中进行重新设计。 我们该如何处理？ 我应该在计划期间讨论多少细节，以使其适合每周冲刺仅2小时的时间？

14 agile  scrum  planning  sprint 

如果我正确理解Scrum，这就是我确定团队在下一个冲刺中可以从事的工作的方式： 我平均了过去几个冲刺的完成点数。 这个量是我们的平均速度。在下一个冲刺中，我们要讲很多故事。 这是一个平均数，因此，如果历史重演，则此冲刺是我们承担的故事点过多的可能性为50％，而我们承担的故事点过多的可能性为50％。 在50％的情况下，我们承担了太多的故事要点，我们可以： 无法完成冲刺。这意味着我们将有一半时间无法实现冲刺承诺。 额外工作以赶上。问题在于，棘轮只有一种方式。我们将完成冲刺，完成的故事点数将反映出这一点。由于我们总是会结束，所以随着时间的流逝，我们的平均水平将趋于上升，直到我们总是完成大量的故事点并熬夜。 我对平均速度和冲刺承诺的理解正确吗？ 如果是这样，对于落后于平均水平的50％的冲刺，我们应该怎么做？ 如果没有，我怎么了？

14 scrum  user-story  sprint  scrum-master 

最近，我已经阅读了很多有关Scrum的文章，并且发现在冲刺期间更改冲刺积压是否可行，这在我看来似乎是相互矛盾的信息。在对Scrum的维基百科的文章说，这是不正常，以及各种其他文章说的这一点。我的软件开发教授也在scrum概述中讲了同样的事情。 但是，我从Trenches中阅读了Scrum和XP，并介绍了任务板上计划外项目的一部分。因此，我查阅了《Scrum指南》，它说在sprint期间“未进行会影响Sprint目标的任何更改”，并且在讨论Sprint目标时“如果工作结果与开发团队的预期不同，然后他们与产品负责人合作，在Sprint中协商Sprint Backlog的范围。” 在Sprint待办事项的讨论中，它继续说： Sprint Backlog是一项计划，其细节足够详细，可以在Daily Scrum中了解进度的变化。开发团队会在整个Sprint中修改Sprint Backlog，并且在Sprint期间会出现Sprint Backlog。在开发团队仔细研究计划并了解有关实现Sprint目标所需工作的更多信息时，就会出现这种情况。 由于需要进行新工作，因此开发团队将其添加到Sprint Backlog中。随着工作的完成或完成，估计的剩余工作将更新。当计划中的要素被视为不必要时，将其删除。只有开发团队可以在Sprint期间更改其Sprint Backlog。Sprint待办事项列表是开发团队计划在Sprint期间完成的工作的高度可见的实时图片，它完全属于开发团队。 因此，在这一点上我完全感到困惑。考虑一下，采用第二种方法对我来说更有意义。在我看来，待办事项中的各个特定项目不是最重要的，而是冲刺目标，因此，不更改冲刺目标，但能够更改待办事项很有意义。例如，如果产品负责人和团队都认为他们在同一个故事页面上，但是随着sprint的进行他们发现存在误解，则似乎有必要相应地更改构成该故事的任务。或者，如果有一些故事或任务被遗忘了，但是达到冲刺目标是必需的，我认为最好在冲刺期间将故事或任务添加到待办事项中。 但是，很多人似乎非常坚决认为对sprint待办事项的任何更改都不可行。我是否会以某种方式误解该职位？那些人对冲刺积压的定义是否有所不同？我对sprint待办事项的理解是，它既包括故事，也包括被分解成的任务。 无论如何，我将非常感谢您对此问题的投入。我试图找出理想的Scrum方法在冲刺期间更改sprint积压是什么，以及成功使用scrum进行开发的人是否允许在冲刺期间更改sprint积压。

14 scrum  sprint  product-backlog 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 6年前关闭。 一些Scrum软件管理工具为您提供此选项，以明确命名您的sprint。 您是使用sprint命名的首选方式还是只使用简单的方案（例如1、2、3，...）？

13 scrum  sprint 

完成分配给冲刺的故事的态度应该是什么？显然，您想优先考虑在sprint中完成它们，但是对我而言，敏捷的全部要点是动态的：您不想故意拖延或使其“错过”在sprint中完成用户故事的机会，但是在当出现意外情况，而那些故事没有完成并被推送到下一个冲刺的同时，您也不希望感觉自己做错了什么。那不应该是令人恐惧或消极的经历，对吗？ 缺少冲刺承诺是否可以接受负面/恐怖经历？当出现必须处理的意外任务（例如生产支持）时，开发人员是否应该对错过的冲刺承诺负责？

12 agile  sprint 

我是一个由4个开发人员组成的项目团队，其中包括我自己。我们一直在讨论如何处理单个工作项中出现的额外工作。 这些额外的工作通常是与任务稍有相关的事情，但并非总是必须达到项目目标（可能是一种观点）。示例包括但不限于： 重构工作项更改的代码 与项目更改的代码相邻的重构代码 重新设计票证周围较大的代码区域。例如，如果某个项目要更改单个功能，那么您意识到现在可以重做整个类以更好地适应此更改。 改进刚修改过的表单上的用户界面 当这笔额外的工作很少时，我们不在乎。问题是，当这项额外的工作导致项目的实质扩展超出了原始特征点估计时。有时，一个5分的物品实际上需要13个时间。在一种情况下，我们得到了13分，回想起来可能是80分或更高。 在我们的讨论中，有两种解决方案。 我们可以在同一个工作项中接受额外的工作，并将其记为错误估计。对此的论点包括： 我们计划在sprint末尾进行“填充”以解决此类问题。 始终使代码保持比发现的状态更好的形状。不要签入半途而废的工作。 如果我们将重构留给以后使用，则很难安排时间，并且可能永远无法完成。 您现在处于最佳的心理“环境”中来处理此工作，因为您已经在代码中深陷其中。最好是现在就解决它，并且比以后再丢失该上下文时更有效。 我们为当前工作项目划了一条线，并说额外的工作进入单独的工单。参数包括： 拥有单独的票证可以进行新的估算，因此我们不必对自己的真实情况撒谎，也不必承认我们所有的估算都是可怕的。 冲刺“填充”用于应对意想不到的技术挑战，这些挑战是完成票证要求的直接障碍。它不适用于仅“精打细算”的附带物品。 如果要安排重构，只需将其放在待办事项列表的顶部即可。 我们没有办法在估算中正确考虑这些内容，因为出现时似乎有些武断。代码检查者可能会说“那些UI控件（您实际上未在此工作项中对其进行修改）有些令人困惑，您也可以解决吗？” 这就像一个小时，但他们可能会说：“好吧，如果此控件现在与其他控件继承自相同的基类，为什么不将所有这些（几百行）代码都移到基类中并重新连接所有这些内容，级联的变化等？” 那需要一个星期。 它通过在票证中添加无关的工作来“污染犯罪现场”，从而使我们的原始特征点估计毫无意义。 在某些情况下，额外的工作会推迟检入，从而导致开发人员之间的阻塞。 我们中有些人现在说，我们应该决定一些截止日期，例如，如果其他物料少于2 FP，则将其放入同一票证中；如果更多，则将其设为新票证。 既然我们只需要几个月就可以使用敏捷，那么这里周围所有经验丰富的敏捷退伍军人对此有何看法？

12 agile  refactoring  estimation  sprint 

如果Scrum中的项目花费的时间比预期的长，我们该怎么办？我之所以这么问，是因为我一直在注意开发人员正在努力完成的项目，因为它比最初想的要困难得多。 在这种情况下，我们应该 将项目从sprint移回产品目录，以便我们可以满足sprint的时间表？ 移至较容易的冲刺项目，并将有问题的冲刺留到时间表结束 在sprint审查中证明为什么在当前sprint中无法向利益相关者完成该项目？ 将来如何避免这种情况？是由于缺乏预先计划，还是我们没有努力将冲刺项目分解为较小的项目？

11 scrum  sprint 

我们是一个由5人组成的小组，即将开始一个新项目。这是我们将全力以赴地进行的第一个项目。 我们正在为如何建立项目基础（框架等）而苦苦挣扎。这些任务不是用户直接受益的任务，因此我们很难弄清楚如何为它编写用户故事。 因此，总的来说，当您从头开始没有框架且没有基础库的项目时，如何使用scrum？

11 scrum  user-story  sprint 

我正在按照Scrum模型松散地进行一个项目。我们正在做两个星期的冲刺。我尚不清楚的东西（也没有书可以参考）正是冲刺之间应该发生的事情：应该有一些“包装”过程，产品在这里生产和交付，但是： 这通常需要多长时间？ 整个团队都应该参与吗？ 在开发人员开始处理下一个冲刺项目之前，它是否必须严格完成？ 进行代码审查和测试时，这是什么？ 一共有三个开发人员，总共约有1个FTE。因此，冲刺确实非常短。

11 agile  scrum  sprint 

我们基本上是根据Scrum进行敏捷软件开发。我们正在尝试进行冲刺审核，但发现很困难。我们的软件正在处理大量数据，而故事往往涉及围绕此更改各种规则。 在没有UI或可见的工作流更改的情况下，有哪些选项可用于演示sprint中发生的更改，但是更改是处理工作的微妙业务规则，可能需要10分钟甚至几小时的时间？

10 agile  scrum  sprint