问考虑到持续的变化，规划周期有多短？

EN

我是一个，所以我建议你使用它。

1. 定义迭代的持续时间。我喜欢在初创公司进行两周的迭代，在大型企业项目中进行一个月的迭代。
2. 在迭代开始时，从您将从产品待办事项中开发的特性中选择。没有人有权改变迭代计划，甚至连产品经理也没有。
3. 更改发生在产品计划中，而不是迭代计划中。因此，你在工作中永远不会受到影响。

关于Scrum的更多详细信息

计划往往会使更大的图景迷失在所有的细节中，而你最终只会旋转你的车轮。这是一个巨大的风险。

我更喜欢使用XP (或Scrum)，它说您应该在每次迭代开始时计划一次，当每次迭代的时间为1-2周时，我发现这是最有效的。

尽管如此，在看板中有一些非常酷的东西鼓励在需要时进行计划，尽管我个人认为看板更适合于维护和支持情况，而不是从头开始开发。

我把事情分解成这样：

1. 任何重大项目/应用程序开发-1周。
2. 简单的一次性增强会被抛到一个列表中，按优先级排列，每一个都会在半天到全天的时间内得到解决。
3. Bug修复通常优先进行，并经历与#2类似的过程，但有时修复速度要快得多。

这里的关键因素是，对于给定的任务，您实际可以做多少计划？启动一个全新的网站，做yadda，有更多的前期计划，而不是修复一个bug。谁事先计划好了bug？部门经理发现他们忘了一些东西，并需要在季度末的报告，你必须把事情放在一边，并进行工作。

每周迭代可能有10个小时，也可能有50个小时。这一切都取决于有多少其他东西是即时的。我认为管理层更容易理解时间的限制，当你问，如果你应该把一个项目放在一边做一个小的补充？当他们认为这个小小的改变是没有必要的，我会继续在yadda网站上工作，这让我很惊讶。