将剩余的工作列入下一次迭代计划中去，
将本次迭代的结束时间向后延迟，等待任务的完成
前一种办法适合于有很大工作量没有完成的情况，这可能也同时说明计划的制定有问题，在制定下次迭代计划时应该考虑对任务完成时间进行调整。后一种办法适合剩余工作量不是很大的情况。
通常来说，一次迭代完成以后应该有一个产品的新版本可用。这也就意味着：将集成和发布分散到每次迭代中去。借助于一些自动化工具（比如ant），我们甚至可以做到每日构建。
一个迭代周期应该有多长呢？这并没有一个统一的说法，而是应该视目标和可用的 资源而定。但是，迭代周期不宜过长，也不宜过短。迭代周期过长的话，会延缓反馈的时间，可能将许多问题隐藏或是堆积了起来。迭代周期过短，会让人身心疲劳，事情难有大的成效。一般来说，迭代周期应该在2-6周之间。如果安排的迭代周期超过了两个月，你可能就必须审视一下迭代计划的合理性了。
不要认为下一次迭代应该和上次迭代的时间差不多，刻板地把所有迭代规定一个统一的时间是一个很坏的做法。但是你可以把以前迭代周期中的工作效率作为估算下次迭代时间的一个依据。
目标
一次迭代必须有明确的目标：我们希望通过这次迭代达到什么目的。在制定目标时，应该同时考虑另外一个问题：如何检查该目标是否已经达成。这就是所谓的“里程碑”。
迭代计划必须有明确而可行的目标。明确的意思是它应该是可度量的，不能太模糊，因为你很难检查一个模糊的目标是否达成。比如，我们可以说，这次迭代的目标是对xxx方面的需求作进一步细化和评审，完成xxx模块的开发以加入到软件的下一版本中去。这样的目标是明确而且可行的。反过来，如果我们这样说：我们要通过和用户的讨论明确绝大部分愿景，同时要有一个初步的开发。“绝大部分”和“初步”这样的词让人感到困惑：多少是绝大部分呢，在总量尚未明确的前提下，怎么能够知道完成的确是“绝大部分”而不是“一小部分”？“初步的开发”似乎告诉我们这次开发量比较小，但是具体开发哪个部分，或者开发到什么程度，并没有指出一个明确的概念。
由此产生了一个困惑，软件项目是一个不断探索的过程，我们怎么能够明确地对未来的事情作安排呢？譬如在项目初始调查用户愿景时，为了实现“明确”的目标，是否这样定义任务：完成20%的用户愿景调查？
很显然，用户愿景总量到底有多少我们并不知道，所以在这次迭代完成以后如果我们问：是否真的完成了20%而不是15%？很难得到答案。
为了避免出现这种情况，你必须换个角度来看问题，比如我们可以说：对xxx部门和yyy部门的用户做愿景调查。在迭代完成后，可以检查是否这两个部门所有用户的访谈，调查都已经完成，是否这些部门每个人都认为自己表达了全部的意思。
所以，如果你发现很难对制定的目标进行度量，那么换一个角度来看事情吧，你可能就会找到一个合适的表达方式。如果你从所有的角度都看不到事情是可以度量的，那么这可能意味着这件事情可能还没有到应该去实施的地步，这时你应该把它从迭代计划中去掉。对于这种情况，有人可能会说：那我们这次迭代可做的事情就很少了，如果真是这样，那就进行一次小的迭代吧，可能把这次迭代的工作做完了以后就会有更多的工作可以安排了。
有些 项目经理在日程表上，很详细地写着：第一次迭代，某月某日到某月某日，第二次迭代：某月某日到某月某日，第三次迭代。。。这样的做法是不恰当的。因为它假设了后面几次迭代的任务量，但是实际上，在前面的工作完成之前，你很难对以后的工作得到一个明确地概念。而且在这样的计划上，可能并没有用于测量迭代成果的里程碑，这样的迭代最后很可能会演变成为瀑布式的开发。所以，在一次迭代完成之前，不要对急着去计划下次迭代，特别是不要试图精确定义下次迭代的时间，因为你连下次迭代要做什么都还不清楚。
为什么目标的可度量性这么重要呢？在 团队开发中，很多信息因为人与人的交流不畅而无法得到正确地反馈，这让我们没有办法实时地掌握项目的进展情况，退而求其次，我们必须阶段性地了解这些信息。如果目标难以度量，迭代结束后我们很难明确到底有哪些工作没有完成，也就无法看到事情的问题所在。
文章来源于领测软件测试网 https://www.ltesting.net/
