需求变化！组织如何应对？

       不同的敏捷团队以不同的方法应对变化。一些团队采用XP过程，在一个迭代周期中也接受变化。这些团队允许他们的客户或产品经理在一个迭代周期中直接引入变化，高效地将原开发中的某个特性替换为新的特性需求。
 还有一些团队采用Scrum过程，即一个迭代周期内不允许变化。对于这些团队，在一个迭代周期中一旦确认了一个新特性集，就不允许再变化这个新特性集了。
 这些方法中，很多团队（无论采用了哪一种）都获得了成功，所以不能简单地说，敏捷团队对需求变化的态度都要一致。然而，我认为每一种方法都有明显的优点和缺点。本文中所陈述的是一些指导原则，团队可以用这些指导原则来决定他们如何对待变化：即在一个迭代周期内是否允许变化？
 就我所知，建立高效软件开发团队的一个显著障碍就是很多组织不能建立一套优先级并把它们应用到重要的周期中。很多组织虽然建立了这套优先级，却在那些采用相对较短的迭代周期的敏捷团队中也一成不变。这些组织好象把自己当成了医院的急诊室－－新的商业机会常常出现而去不给它们时间对这些机会进行分清优先级。等到分清优先级以后，条件已经发生变化了，需要再一次评估优先级。然而，大多数时候，却不是这样的。
 很多努力变换这套优先级的组织是这样做的。因为事先考虑是很难做到的。对于客户或产品拥有者，他们经常不遗余力地说；“这是一个非做不可的需求”，并坚持要在当前这个迭代中完成。由于对这个新需求评估和说服客户是很困难的，所以很多组织采用了错误的方法让需求变化进入到迭代过程。这想这是一个错误，它让我：
 原则1：发展建立和坚持优先级的能力，以便能够在需求变化时，正确的判断是否让它进入迭代。
 除非你的组织在一个完整迭代中可以不考虑优先级，否则在迭代周期内引入变化是不可避免的。然而学会对优先级至之不理也是不容易的。对于客户或产品经理来说，学会对优先级至之不理的一个途径就是“多加练习”。在不改变优先级的情况下做的迭代越多，你会发现再做迭代时就越容易。然而，练习对优先级至之不理的人一定会问：最开始的每一个迭代怎么做？我的建议是：
 原则2：如果你不能在一个周期里对优先级至之不理，那么就缩短迭代周期吧
 这一点主要是说：如果一个团队还不知道如何把变化拒之于一个迭代周期之外，那么缩短迭代周期的方法要比让变化进入当前迭代要好。一些敏捷方法论认为迭代周期为一个月比较合适。如果以一个月为迭代周期，组织偶尔会在两个月以后才拿到新特性。这对于一个活跃的组织来说，时间显得有点儿长。如果真的是这样，那么试着缩短迭代周期。现在有的组织已经缩短迭代周期为一星期。缩短迭代周期的目的不是为了固定一个时间长度，而是有机会学习如何坚持优先级（即使只是非常短的时间）。
 已经习惯于在一个星期的迭代周期里坚持不改变优先级的组织也许有能力在两个星期的周期中坚持不改变优先级了。以此类推，如果两个星期可以的话，那么它想延长周期为一个月，也是可能的。
 一旦一个组织在迭代过程中能够坚持优先级不变的话，那么它的目标已经达到了。接下来做什么呢？
 原则3：善于在预计变化必须进行之前，运作优先级不变的迭代过程。
 当组织善于将变化拒之当前迭代门外后，就可以考虑如何看待变化的问题啦。对于变化在一个迭代中进行这个问题，XP方法允许，Scrum方法不允许。而此时此刻，组织已经有了选择。，即项目团队本身就可以做出结论啦。