在迭代结束时，我们如何减少停机时间？
在迭代结束时，我们如何减少停机时间？
提问于 2011-04-09 15:44:41
在我工作的地方，我们用3周的迭代来练习scrum驱动的敏捷。是的，如果迭代时间更短，那就更好了，但是现在，改变它不是一种选择。
在迭代结束时，我通常会发现最后一天走得非常慢。实际工作已经完成并已被接受。有几次会议(回顾会议和下一次迭代计划)，但除此之外没有什么进展。
作为一个团队，我们可以使用什么样的技术来在最后一天保持势头？我们应该解决缺陷吗？无论如何，提前开始下一次迭代的工作？还有别的吗？
回答 12
Software Engineering用户
回答已采纳
发布于 2011-04-09 15:51:56
最近我一直在为同样的问题而挣扎。我们正在开始下一次迭代，但我觉得这消除了一个出色的迭代所带来的满足感。
我正在考虑由开发商自己决定的选择，但请注意，“只要目的是让公司受益。”
示例：
- 花一天时间学习一些东西
- 把它花在一个创新项目上
- 把它花在整理那些你从来没准备好的烦人的代码上。
- 有一个良好的运行在这个应用程序的一个角度来看UX (我们似乎从来没有时间去做，否则)
不管是什么激励了程序员，都会激励他们按时发布版本。
Software Engineering用户
发布于 2011-04-12 05:28:05
请一天假。你做了你应该做的工作，那你为什么还在工作？
如果过程更改是可能的，请考虑放弃迭代，持续发布，然后继续从待办事项中删除故事。但你不应该花点时间休息吗？
Software Engineering用户
发布于 2011-04-09 21:30:51
我注意到了同样的问题(我们有时使用2周的冲刺，这会使它更加恶化)。我试图为那些日子(冲刺复习日和短跑计划日)节省一些工作，我知道我会做，但不需要很多计划或内部沟通，如低优先级的bug，抛光，或工具的改进。有时，这实际上是一个积极的时刻，因为它创造了一个很好的时间去做重要但不性感的工作，否则很难花时间去做。
页面原文内容由Software Engineering提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://softwareengineering.stackexchange.com/questions/66708
复制相关文章
相似问题
腾讯云开发者
