标题取得有点大，此文仅是对一次 Free Talk 中同事所提问题的思考。
在敏捷开发中，「拥抱变化」和「朝令夕改」的区别是什么？
我理解他想问的是，对于项目中上午定好的需求，下午就变更了，敏捷的我们是不是依然要接纳？
It depends? 可能这么回答并没有什么营养..
软件功能是现实行为的映射，现实世界的不确定性和软件固有的复杂度不可避免的会带来各种需求变化。敏捷开发模式并不能解决变化这一源头问题，相反它就是为了响应这些变化而生的。
当面临突发的需求变更时，我们需要明确它们是否跟软件最终交付的价值相关。（人话版：这个需求变更带来交付的功能是否对用户有用，是否能给客户带来收益。）如果是，那无疑我们必须无条件的接受，毕竟软件交付的目标就是为了创造更多的价值，而非遵循计划以完成更多的任务，完成了迭代内的任务但没有创造价值比没有完成任务带来的损失更大。突如其来的变更就好像高速公路上出现的突发交通事件，我们有必要设立一条应急车道去临时处理这类情况，而不能因为任务被打乱而一味的去抵触。
但是频繁的需求变更是肯定不被接受的，好比车辆占用应急车道行驶是违法的一样。相对于传统的瀑布开发模式，敏捷开发模式本就将大量和不定的任务切分到一个个短期的迭代中。只有确保每个迭代内的任务不被干扰，才能优先交付价值更高的软件功能。如果在这样一个相对短暂的周期内还总伴随着大量需求变更，可想而知一定是团队哪里出现问题了，我们需要暂缓一下去找出问题并予以解决，而不是不假思索的去“拥抱变化”。
敏捷开发中不变的是团队速率，即一轮迭代团队能完成的故事点（任务）。它由团队能力和迭代周期共同决定。团队能力是随着团队成熟度上升而达到的一个平衡，不能无限增加；迭代周期视团队而定，一般是1～4周。为什么我们需要极力保证团队速率的稳定？因为只有不变才能够更好的约束变化。
如果全部都是可变的，那么一定会是失控。
好比在两个路口之间（迭代周期），在一定的车速限制下（团队能力），一个红绿灯的时间通过的车辆数量是固定的（团队速率）。那么在一个迭代内，变更的需求就像加塞的汽车，它的通过必然就会造成有的车辆需要多等一个红灯，这应该是大众都能够接纳的认知。所以在一个迭代内如果某些需求变更造成了额外的投入，那我们理应将本该在迭代内完成的任务往后延。可惜我们总是又想加塞，又想原本的车辆能够通过，那唯一的办法就是超速行驶，违章不说，一旦出现车祸，整条马路就会瘫痪。
太多的侥幸只会带来不幸。
遇见过一些团队，喊着敏捷的口号做着敏捷的项目，但似乎又和跟敏捷一点关系都没有。团队内部的互不信任带来了多方立场，而敏捷只是被拿来当作互相制衡的武器罢了。起初我认为是因为他们对敏捷一知半解造成的，但想起这些变与不变不仅仅只存在于软件交付项目中，现实世界中更是随时随地都在发生，一些浅显的道理其实大家都知道。
可能和是否敏捷无关？只是需要多一些契约精神，少一些制约手段罢了。
