在我个人实施敏捷转型过程中，以及刚刚接触敏捷文化时。有一条原则或者宣言是我印象深刻，至今也深有感触。

拥抱变化

响应变化高于遵循计划。更详细的介绍，在之后的敏捷原则中也提到过。

欣然面对需求变化，即使在开发后期也一样。

那要如何理解这句话呢？

我在这里斗胆猜测一下（也是基于我之前的开发、项目的经历）。

开发：啊？难道接受敏捷就是要纵容产品经理随意的变更需求吗？

产品：啊？难道敏捷支持我可以正大光明的不做分析，随意变更需求吗？

项目：啊？那我之前的项目规划书，合同都白签了吗？

如果我猜中的一部分的心思，那请继续读下去。如果不是，请出门右转，那里有更专业的人士。

我当时身为程序员时，也角色需求变来变去，那么开发怎么办？开发一半的功能，需求变了？我的工作白做了？一大推的问号充满了脑袋。当时负责我们团队的Master也没有过多的解释。我当时有了抵触情绪后，也就懒得问了。觉得，哎，敏捷也就那么回事儿吧。

有机会做了产品经理，角色的转换，思维也随着变了。我们在给客户做前期规划的时候，规划的非常好。从年初开始一直到年底要做的事儿都详细的策划了一遍。（交代一下背景，我是做医疗行业的或者说TO B行业）医疗行业是很喜欢做规划、做计划的。它们掏钱，享受服务。我们赚钱，提供服务。医疗行业发展相对金融、汽车等行业还是较慢，因为出于政策的考虑，安全的审计等。所以这个行业就会出现一个“奇怪”的现象。上半年什么动静也没有，下半年会出现好多要求。

所以年初规划的至少一半内容都要作废而增加新的内容。怎么办？已经把PRD发给了开发团队，已经把计划排到了2030年，合同都已经签了。一系列的问题摆在那里。是我不得不思考多年前接触的敏捷。“拥抱变化”，究竟拥抱的时候，变化到底指的是什么？

重新看书，重新找老师咨询。这里拥抱变化到底应该如何理解。拥抱变化的前提是我们要基于这样一个共同的认识：变化是常态。举个栗子，敏捷就像我们开车。从A地到B地的距离是固定的，但是这一路上路过的路口，等了多少红绿灯是不固定的。运气好，一路绿灯，顺顺利利的到了目的地。所以现在的软件开发就和开车的路况一样复杂。理解了变化是常态，那想拥抱就是如何面对的事情了。

回到之前的问题。拥抱变化是在开发过程中可以随意变更需求吗？答案是否定的。需求变化是常态，但是敏捷并不是说在开发过程中，对于开发中的需求可以所以的变化。我们先转换成程序员的视角：程序员需要一切确定的信息，比如点击按钮弹出什么界面，界面展示的数据都是什么，如何排序等。这些信息给到程序员时，会让程序员很舒服。因为一个人在处理确定信息的时候会比处理不确定信息要淡定的多，这里面蕴含的恐惧是老祖宗留下来的，谁也没办法避免。

敏捷将原来的长远的、大的计划，拆分成小的、具体的计划。而产品每次提交到迭代中的内容一旦开始开发，就禁止需求变更了。如果非要发生变更，Master要维护时间盒的秩序等。所以说来说去，敏捷更多的要求产品规划层面做出改变，去拥抱变化。比如产品团队只能给出未来两周的预测，那么就做这两周的任务。至于接下来再说什么，到时候再说。要么等待市场调研，要么等待软件使用反馈。有结果了，在决定开发什么。更夸张一点将，只操心今天的事儿，明天的事儿明天再说。

所以我的理解，拥抱变化更多的是在产品规划层面做到灵活应对市场瞬息万变的变化，而不是在团队内部反复的折磨开发团队。

至于项目经理担心的合同问题。哈哈，中国的项目，合同只有在出事儿的时候才有用。如果产品没有按照合同而超预期的满足的用户，用户也是会掏钱的。

以上，纯属个人观点，不喜勿喷且欢迎交流。