人，就能往Scrumworks上扔任务，也不知道哪些重要哪些不重要，我们自己开发人员看着办，最后剩下几百个小时完不成再扔到下一个Spri
t里面去”
显然，大家的迭代过程很随意，松松散散，没有任何的约束。有的网友说这是公司制度的问题。无疑是在“头痛医头，脚痛医脚”。如果，这时还拿制度说事，明显是在和敏捷精神相悖。敏捷方法，表明看上去管理松散，没有规章制度。其实不然，它有很多的准则，要求每个人能够自觉遵守，养成工作习惯，成为一种职业素质，最终目标是要形成一个自组织的团队。例如，谁可以往Scrumworks上扔任务？这明显是产品主管的职责。就算是开发人员想往上扔任务，也应该和产品主管以及整个团队讨论，明确任务的价值和优先级之后，再决定是否可以把任务放到当前的Scrumworks上。这是最的基本要求，这是每个团队成员默认遵守的原则，甚至可以认为这是一个开发者最起码的职业素质要求。
我们从上面的描述可以再次看出，大家是在对SCRUM有抵触的。如果，到现在，推广者到还不能让大家理解、认可和接受SCRUM方法。那么，引入SCRUM，也绝不可能获得成功，甚至会直接拖垮整个项目。
敏捷方法，需要有一个英明的领导（也许就是ScrumMaster），以身作则，带领着团队向前冲锋，大家齐心协力，以项目的成功作为最高奋斗目标。只有这样，才能发挥敏捷方法的威力，只有这样项目才可能获得成功。
f再回到迭代开发，它能给我们带来什么样的好处呢？一、明确的短期目标。如果让一个团队做半年的详细工作计划，一定非常困难，但如果是2周，那就完全不一样。假设，客户有100个东西要做，但团队在一个迭代（一般是2周左右）中，只能完成20个东西。那么就明确的告诉客户，一个迭代的时间，我们只可以完成20个东西，那么我们先开发其中20个最有价值的东西好吗？二、如何知道团队在一个迭代可以完成多少任务呢？显然，迭代只有两周的时间，相对的计划会很准确，而且前面一个迭代的工作量，是这个迭代最好的参照。如果是第一个迭代，根据团队的经验做好一个合理的2周计划应该不难。三、迭代结束之后，给客户演示工作成果，及早获得用户反馈。同时团队在一个迭代结束之后，也会对整个开发的状况进行思考和反省，举行一个回顾会议，客观的讨论前一段时间的工作，哪些地方做的好，哪些地方做得不够好，对不好的地方，要能讨论出具体可行的解决办法。
敏捷的团队就是用这种迭代的方式，增量的进行工作。小步前进，不停的思考、反省和总结，不停r