请问在scrum开发中所谓迭代的处理需求变更怎么理解？

[pptding]

scrum的描述是可以通过每一次冲刺后提供给客户可使用和评审的产品，以得到反馈和需求的变化，然后在后面的冲刺中进行实现。
于是问题来了，如果我在项目初期就已经定义好了每个冲刺所要进行的内容，例如冲刺1实现用户权限，冲刺2实现业务数据查询，如果在冲刺1以后，发布的产品用户提出了修改意见和反馈，那么冲刺2中是否要安排项目中的人员进行对冲刺1需求反馈的处理？如果是这样的话，分散了团队的力量去解决遗留问题，岂不是会导致整个项目计划出现问题？

请有过scrum项目经验的高手给予解惑，谢谢！！

[以专业开发人员为伍]

你这种担心说明根本没有敏捷起来，而是乱糟糟地。 你会提前发布产品吗？如果不会，请你出门下楼梯回家。 你会带着bug（没有确定修改测试的情况下）进行随后的开发吗？如果会，那么直接晕倒吧。 实际上，敏捷方法并不是让你变得紧张兮兮地！你不应该比没有使用敏捷开发之前更紧张。而仅仅是，你应该在同样的时间里感觉到很有成就感、少走了许多弯路，这就是敏捷。

[以专业开发人员为伍]

把敏捷开发当作垃圾约束，恐怕只有那些行政经理（而不是开发经理）才会想出这种馊主意。 敏捷是一种设计技术，而不是用来“压迫”员工的。所以不要用很庸俗的行政视角来看敏捷开发，应该用这个办法来保证“创意、修改、发布更加自由”，用触觉就能把握好时间调整节奏，而用不着压迫别人加班修改bug。

[pptding]

LS的意思是要根据自己的经验和感觉，来灵活的应对发生的情况？那我可不可以这样理解，在scrum开发初期完全不用（或者说大概）的定义一个冲刺计划，然后根据自己团队的开发情况和实际的进展来安排何时该进行下一阶段冲刺、何时该对用户提出的变化进行实现。而一个有经验的scrum团队，对这些时间的安排总是合理的，所以完全不用对敏捷开发所带来的约束而担心？

[对酒当歌今夕何夕]

每个迭代期 我们都会安排 预留10% 的时间解决遗留问题 ，或者在3到5个迭代后会一个半周期个缓冲迭代 专门处理遗留 架构 产品线 的问题 敏捷 是并行的，不是瀑布，一个完了才能做下一个 敏捷就是接受反馈 快速反应 不然你还敏捷干嘛，不能变更一般都是说在一个迭代周期内的东西要相对固定

[以专业开发人员为伍]

引用 3 楼 pptding 的回复:

LS的意思是要根据自己的经验和感觉，来灵活的应对发生的情况？那我可不可以这样理解，在scrum开发初期完全不用（或者说大概）的定义一个冲刺计划，然后根据自己团队的开发情况和实际的进展来安排何时该进行下一阶段冲刺、何时该对用户提出的变化进行实现。而一个有经验的scrum团队，对这些时间的安排总是合理的，所以完全不用对敏捷开发所带来的约束而担心？

首先，你不能什么都白手起家地让一帮水平最低的成员用最低级的开发方法来开发。你应该培训员工采用比较高级的平台开发方法，提高开发人员水平。 一旦进行敏捷开发，你的人员的要求就提高了，而不是降低了。 这个时候，当你从高层次的“设计、工程、进度”把我预计工作流程的前后调整规律时，才会游刃有余。 这就是敏捷式开发与“无头苍蝇”式的开发的区别。 如果我感觉一个“无头苍蝇”式开发团队，只是想用敏捷开发来凭空提高产品研发质量，那么我就根本不可能给出什么解决办法。

[以专业开发人员为伍]

一个敏捷开发团队，其主要成员都熟悉那种高级的——并且往往是随时改变用户需求的——工程方法。这种方法掌握得越多，以及比较实用（而不是纯理论），就越能够敏捷。 反之，如果你找一帮民工从头开始培训，没有人能够参与设计中间件、发明各种工具、为平台里的组件提出新的接口，如果这帮代码民工只是知道“领导给了我界面‘需求’，然后我就‘设计’数据库表，然后抄别人的代码到我的界面代码上。领导只懂得对我的的数据库表的字段说三道四，根本对代码提出不工程意见。”，那么这帮民工就参与不了敏捷开发，就是为了混工资而陪着领导做名义上的敏捷开发。

[以专业开发人员为伍]

如果用户修改了需求，我们就应该对用户说：“对不起，我现在停下工作，重构产品”。这才是敏捷。 反过来说，我们必须及时地与用户沟通，今早确认，而不是带着问题去赶进度。我们一方面知道需求是千变万化的（并且我们每周发布给用户测试的产品总是有让用户感到兴奋、实用的部分，而不是让用户感到我们的团队能力太低），另一方面知道如何引导用户促成项目早日验收，这就是敏捷。

[pptding]

引用 4 楼 xiebird 的回复:

每个迭代期 我们都会安排 预留10% 的时间解决遗留问题 ，或者在3到5个迭代后会一个半周期个缓冲迭代 专门处理遗留 架构 产品线 的问题 敏捷 是并行的，不是瀑布，一个完了才能做下一个 敏捷就是接受反馈 快速反应 不然你还敏捷干嘛，不能变更一般都是说在一个迭代周期内的东西要相对固定

那请问在scrum项目的开始阶段定义冲刺的内容意义何在，我为何不只定义出大概的sprint数量，而具体的sprint该进行什么内容我根据实际情况再具体定义就好。

[Helphi]

在第一个sprint没有完成之前不要计划第二个sprint啊，第二个sprint是在前一个完成后根据具体情况计划的。

[对酒当歌今夕何夕]

定义冲刺是给目标啊，SCRUM 也要有目标啊，只是说SCRUM的目标可以不断变化 像你这个情况就是修改之前的 问题 变成了一个新story，这个时候你要做的还是按优先级排序 因为敏捷的概念是 时间和人力是固定的，做什么东西是变化的 你的观念变过来了，就不会有这样的问题了，SPRINT1的问题，在SPRINT2 就变成新的backlog， 你按需要把它调整到前面来做 就对了 相反 无休止的变化是不坑能让人完成工作的，所以SCRUM 定义在SPRING里是不变的，是希望团队在相对时间内固定的去集中做一些事情， 如果SPRINT里再变，就有没完没了，没办法做任何计划了

[zhangmike]

最直接的解决方法： 在项目初期定义的每个冲刺所要进行的内容所需工作量不能超过可提供工作量的50% 不要再Release计划上面过于精细，所需工作量估计不要超过50%，选择核心要点与及对应的时间点即可 在后续跟踪中，Release计划也不排除调整。

[powerpaul]

实际问题实际分析的，每个sprint都是kick off的时候选哪些story，前一个sprint的defect也可以适当地考虑在将进行的sprint中，或者通过设定适当的生产率来预留空间。提前定好跟迭代开发没啥区别