如何减少迭代结束时的停机时间？

在我工作的地方，我们通过3周的迭代练习了Scrum驱动的敏捷。是的，如果迭代次数较短，那将是很好的选择，但目前暂时不能更改它。

在迭代结束时，我通常会发现最后一天进展非常缓慢。实际工作已经完成并被接受。有几次会议（回顾性会议和下一个迭代计划），但除此之外，会议进行得并不多。

我们团队可以使用哪种技术来维持最后一天的动力？我们应该解决缺陷吗？尽早开始下一轮迭代的工作吗？还有吗

我最近一直在为同一个问题苦苦挣扎。我们从下一个迭代开始，但是我觉得这样做消除了对迭代良好的满意。

我正在考虑将其留给开发人员的选择，但要注意“只要目的是使公司受益”。

例子：

• 花一天的时间学习一些东西
• 将其用于创新时间项目
• 将它整理得整整齐齐，使您永远无法进行重构的烦人的代码片段
• 通过UX来很好地运行应用程序（我们似乎从来没有时间来做）

激励程序员的任何因素，都会激励他们按时交付版本。

请了一天假。您完成了本应完成的工作，所以为什么仍在工作？

如果可能进行流程更改，请考虑放弃迭代，持续发布，并保持积压。但是，您不值得停顿一点时间吗？

我注意到了同样的问题（有时我们会使用2周的冲刺，这会使情况更加恶化）。在那几天（冲刺审查日和冲刺计划日），我试图做的是节省一些我知道会做的工作，但不需要大量的计划或团队内部沟通，例如低优先级的错误，完善，或工具改进。有时，这实际上是一种积极的感觉，因为它创造了一个重​​要的时间来从事重要但非性感的工作，否则很难抽出时间来做。

即使我们的用户故事几乎总是在迭代结束时完成，但在最后总是有很长的“精打细算”列表，以及一系列已知的错误。因此，当人们讲完故事后，总是有很多事情要做。

我认为进行回顾性会议是至上的，即使遇到的问题几乎相同，但花一点时间思考迭代的进行方式，学习方式（如果您没有意识到自己的错误）也很重要。一切顺利。

如果所有错误都已解决，那么要完成的工作还包括一长串可以做的更好的事情，以及行动要点，我认为将团队聚集在一个大屏幕前并尝试使用可被建造，以及一些啤酒。它虽然效率不高，但是很高兴谈论已实施的内容以及其实际工作方式。

如果您有时间，那么我将尝试寻找新的东西来学习，并尝试使用它，也许是下一个大问题。但是再说一次，如果有几天，那么积压中可能有一个用户故事要做

我们的迭代将在星期四结束，以便能够在星期五修复所有最新的问题。但是那些星期五（每两周一个星期五）与我们的啤酒星期五相吻合，因此我们尽量保持冷静。修复一些小错误，花一些时间阅读一些东西（书籍，StackExchange，博客等），并在一天结束时喝啤酒放松一下。否则，您不会感觉到完成或关闭，而是感觉就像仓鼠在不停地旋转。

我不确定您是否总是希望准时完成工作。尽早完成工作可以让您考虑未来的故事，功能和特性。做好工作后，它会给您带来一些停顿，这比起早开始工作或致力于撰写更多故事并让工作继续进行更有意义。

肯·施瓦伯（Ken Schwaber）在他的博客中表示：http：//kenschwaber.wordpress.com/2010/06/10/waterfall-leankanban-and-scrum-2/

“上帝帮助我们。人们找到了放松瀑布，休息和发挥创造力的方法。有了精益和看板，那些藏身之处就被清除了。我们现在可以不停地进行逐步的死亡游行。”

在我的项目中，在迭代计划过程中，我们总是选择一些额外的任务，并将其标记为如果迭代中的所有工作都完成了的“额外任务”。实用上，无论如何，这些“额外任务”通常是在下一次迭代中首先要处理的内容，但是从心理上讲，将它们称为“额外任务”的工作要好得多，而总要计划更多的工作然后才能完成。

对于其他事情，例如学习或创新时间，我们只是简单地让每个开发人员每周将多达一天的时间花在该产品上，这是正常的预期结果。它可以是一周中的任何一天（即不必在每个星期的结尾）。

我们团队中的所有开发人员都会在冲刺结束时（假设所有冲刺任务都已完成）将空闲时间用作“ Google时间”。

只要开发人员从公司中受益，这就是每个开发人员从事自己的想法/项目的地方。我强烈建议采用这样的系统，这确实提高了我们团队的工作满意度。

如果您经常提前三天完成任务，那么这向我暗示您没有为冲刺计划足够的故事。

Scrum的目标之一是提高生产力-如果您正在拍摄每个冲刺，则不会这样做。

要解决此问题，请计划比以往更多的故事。仅致力于您以前的速度，但是如果您完成了这些故事，则开始研究其他故事。如果您完成更多操作，则加快下一个冲刺的速度。为了以防万一，请始终计划比您承诺的要多的事情，或者至少安排一些故事。

这是我们改用看板的原因之一。Scrum的所有好处，而无需不断脱离项目。

我喜欢托德休假的答案，但是我要说的是，尝试在早上进行冲刺计划和回顾，并设置挑战性，以使其能够在午餐时间及时完成，然后以团队的形式进行长时间的午餐。午餐时，鼓励讨论有关冲刺的内容，以便您免费获得非正式的回顾。

如果您然后不能放下aftenoon（我的意思是像下午回家一样，下午没有设定自己的目标），那么解决技术债务，因为这是使开发人员比其他任何人都沮丧的一件事（来源） ：我认为），当他们确切地知道如何解决债务并使他们的生活变得更轻松时，他们必须解决技术债务问题。

我个人发现，回顾并不是真正值得花时间的事情，通常有一些常见的重复出现的主题（糟糕的用户故事，错误的估计等），您只是将其视为问题领域并继续前进。我们还尝试解决问题的发生时间，而不是等待追溯（在采用Scrum的早期阶段，我们倾向于这样做）。

现在，每对开发人员不再进行回顾，而是从现有的回顾积压中选择一个出色的项目并进行处理。

我们还保留了一个正在进行的技术债务积压，这是冲刺的奖励项目（如果企业尚未准备好提前从积压中实施某些措施）。

这已经被证明是非常积极的，因为所有那些持续冒泡的小东西都会在每次冲刺中获得一天的关注。

举行白板设计会议，并在即将到来的sprint中分享有趣故事的实现想法。之后，再与计划会议分开进行，在计划会议中，故事仍然根据细节而定，并根据故事点或T恤衫尺寸估算值进行判断。保持会议非正式并鼓励创造力。