考虑到持续的变化，计划期短短又太短了吗？

变更并不罕见，需求变更，规格变更在工作流程中也是如此。我已经接受了将会发生的变化，但是我想知道：知道即将发生变化，那么规划期有多短呢？（鼓励辩解）

• 迭代（2-4周）？
• 一周？
• 2-3天？
• 一天？
• 一天1/2

假设公司从当前提前“计划” 1 [时间间隔（从上面）]，所以任何计划听起来像：

“[今天早上/今天/本周的/ etc。]你会在工作这和[今天下午/明天/下周的/ etc。]你会工作是。

还假设焦点/方向的变化将持续发生在第二到第三时间间隔。

我是Scrum Practitionner，所以我建议您使用它。

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

有关Scrum的更多详细信息

进行规划通常会使大局在所有细节上迷失方向，而您最终只能旋转轮子。那是巨大的风险。

我更喜欢使用XP（或Scrum），它表示您应该在每次迭代的开始进行一次计划，而当它们的长度为1-2周时，我认为这是最有效的。

话虽这么说，看板中有一些很酷的东西会鼓励计划在需要时进行，尽管我个人认为看板比起从头开始开发更适合维护和支持情况。

我把事情分解成这样：

1. 任何重大的项目/应用程序开发-1周。
2. 将简单的一次性增强功能放入列表中，并进行优先级排序，并且每一个功能都会在半天到整天的时间内得到解决。
3. 错误修复通常会优先处理，并且会与＃2相似，但是有时可以更快地修复。

这里的关键因素是您实际上可以为给定任务做多少计划？创建一个全新的网站来进行yadda，yadda，yadda的开发，除了修正错误外，还有更多的前期计划。谁预先计划错误？部门经理发现他们忘记了某些东西，并且在季度末报告中需要它，因此您必须将其放在一边并继续进行工作。

每周迭代可能需要10个小时，也可能需要50个小时。这完全取决于其他即时任务。我认为，当您询问是否应该搁置一个项目以进行少量补充时，管理人员更容易理解时间矛盾？当他们发现这是不必要的更改时，我感到非常惊喜，我应该继续在yadda-yadda-yadda网站上工作。