scrum的失败或者效果不理想通常由以下因素造成：
1.对未知结果的恐惧心理。出于习惯，大多数人更愿意事先得到一个固定的最终发布日期和一个承诺的结果，哪怕到了日期无法得到结果再延期。我们常常都需要这样的心理安慰，宁愿把苦头放在后面而不愿正视软件开发的规律。
2.在sprint过程中加入新需求的诱惑。很难很难抵御这样的诱惑，scrum第一杀手。
3.不愿意调整目标而任意延长sprint的时间。不知不觉你就又回到了老路上。
4.急于看到结果而压缩sprint的时间。能得到一定的效果，但总体上消耗的更多的资源。我们曾经一度这样做，每周末完成一个可以审查的结果，很有效，但很累人，在整合上花了太多的力气。
scrum的实施
除了按照scrum的流程按部就班的执行，需要理解scrum的几个要点，否则很难达到效果。
1.理解软件开发过程中的几个变量：成本、期限、质量和功能。如果这四个变量都能确定，我们就在家数钱就可以了。有时候我们有机会尽量确定期限和功 能，CMM之类的软件方法就是着重于在这种情况下如何尽可能保证质量。有时候我们希望通过加人手，提高成本来保证期限、功能和质量不受影响，《人月传说》 有不少关于这样是否可行的讨论。也有的时候，频繁的需求变化导致功能无法确定，期限一拖再拖，成本不断增加，质量无从保证，一片混乱(chaos)，这时 候我们就可以通过scrum，先确定期限和成本，在短期内一定程度上确定需求，让这个四元方程式好解一些。
2.确保开发团队在sprint中不受干扰，不被分心。如果能理解上一条，你就能理解为什么在sprint中不随意添加修改需求对团队开发很重要。永远变 化的需求只能导致永远不能发布的产品。scrum同时保证了你有足够的机会在下一个sprint实现新的需求，隔这样一段时间，你会对新需求有更多的了 解，很有可能它并没有你想像得那么重要。
3.注意任务划分的粒度。任务划分的粒度越小，团队对任务的理解也越透彻，对时间的估计也会越准确。
4.彼此信任。特别是老板，应该信任他的团队，有能力使用正确的方法完成应该完成的工作，不然你雇他们干什么？
scrum不是万灵药，不可能解决所有的问题。但是如果你要使用scrum，在完全领会它之前，最好按部就班的执行scrum要求的每个步骤，遵守每个原则，至少可以少走一些弯路。
scrum的失败或者效果不理想通常由以下因素造成：
1.对未知结果的恐惧心理。出于习惯，大多数人更愿意事先得到一个固定的最终发布日期和一个承诺的结果，哪怕到了日期无法得到结果再延期。我们常常都需要这样的心理安慰，宁愿把苦头放在后面而不愿正视软件开发的规律。
2.在sprint过程中加入新需求的诱惑。很难很难抵御这样的诱惑，scrum第一杀手。
3.不愿意调整目标而任意延长sprint的时间。不知不觉你就又回到了老路上。
4.急于看到结果而压缩sprint的时间。能得到一定的效果，但总体上消耗的更多的资源。我们曾经一度这样做，每周末完成一个可以审查的结果，很有效，但很累人，在整合上花了太多的力气。
scrum的实施
除了按照scrum的流程按部就班的执行，需要理解scrum的几个要点，否则很难达到效果。
1.理解软件开发过程中的几个变量：成本、期限、质量和功能。如果这四个变量都能确定，我们就在家数钱就可以了。有时候我们有机会尽量确定期限和功 能，CMM之类的软件方法就是着重于在这种情况下如何尽可能保证质量。有时候我们希望通过加人手，提高成本来保证期限、功能和质量不受影响，《人月传说》 有不少关于这样是否可行的讨论。也有的时候，频繁的需求变化导致功能无法确定，期限一拖再拖，成本不断增加，质量无从保证，一片混乱(chaos)，这时 候我们就可以通过scrum，先确定期限和成本，在短期内一定程度上确定需求，让这个四元方程式好解一些。
2.确保开发团队在sprint中不受干扰，不被分心。如果能理解上一条，你就能理解为什么在sprint中不随意添加修改需求对团队开发很重要。永远变 化的需求只能导致永远不能发布的产品。scrum同时保证了你有足够的机会在下一个sprint实现新的需求，隔这样一段时间，你会对新需求有更多的了 解，很有可能它并没有你想像得那么重要。
3.注意任务划分的粒度。任务划分的粒度越小，团队对任务的理解也越透彻，对时间的估计也会越准确。
4.彼此信任。特别是老板，应该信任他的团队，有能力使用正确的方法完成应该完成的工作，不然你雇他们干什么？
scrum不是万灵药，不可能解决所有的问题。但是如果你要使用scrum，在完全领会它之前，最好按部就班的执行scrum要求的每个步骤，遵守每个原则，至少可以少走一些弯路。