熟悉了多年的瀑布流程，一开始做敏捷，是被敏捷对需求的快速响应所吸引。互联网公司宣扬的快速迭代，已经深入人心。而敏捷所说的：需求在一开始并不明确也无法明确，在构思和开发多款新产品的过程中，也深感切肤之痛。
瀑布模型周期长，在一次需求确定之后，开发人员非常讨厌变更。而变更总是不可避免。所以，在正常开发流程之外，总是要附加另一个需求变更流程。在网上搜“华为需求变更管理流程”，你会找到一张长长的流程图，诸多的审批环节，这本身就说明需求变更是个多么讨厌的麻烦的事情，以至于要这么多环节去限制它。
而在流程不那么规范的公司——我相信这种公司应该是大多数的，毕竟象华为这样的公司还是少数——老板、总监、甚至销售人员，都能在开发过程中随意给提出几个需求要求开发人员去实现。即便是产品经理去建立一个需求变更流程也无济于事，毕竟一次开发需要半年到一年的时间，毕竟老板发现有新的很重要的需求总不能憋着不提。
那么需求为什么不能一开始就定清楚？这就是敏捷的核心之一，很多需求就是一开始定不清楚的。
那么敏捷怎么解决这个问题？快速迭代！
一次开发过程中的需求变更不是限制，在敏捷中是被禁止了。对需求的任何变更，都预先记录下来，然后放在下一次迭代前的需求评审中。每次迭代很快，一周到两周不等。
不过，在公司的实践中，要求每次迭代需求一点儿都不变，总没有那么绝对的事情，不过要好处理的多：对于一些文字的小修改，开发人员也并不在意，对于稍微大一些的修改，由于一次迭代速度快，放在下一个迭代中，对于公司老板和其他人员，一旦逐渐理解了敏捷，也是会接受的。并且迭代周期短，意味着提出的需求变更也不会太多了。
并且，在这个过程中，我会观察到一些有意思的事情。一开始的时候，一个迭代中忽然插入的需求——提出者往往是刚刚拜访客户回来的销售或者老板——会说这个需求如何的紧急、重要，势必加入开发不可。然后我把它放入下一期需要评审的重要需求中。等过了几天需要评审的时候，把这个需求拿出来和别的一对比，往往又觉得，其实没有那么紧急，也没有那么重要了。这种需求有时候一放就是好几个迭代都没有开发，甚至一直躺在需求池里面。敏捷的这种流程，还能让产品经理去重新审视需求的必要性，也能让提出需求的人“冷静一下”，更客观地和产品经理去评估需求。产品经理这时候也更容易去说服他们，把哪些不必要的需求推迟，即使那个人是老板——我知道，在很多公司，有很多产品经理都不知道怎么对付老板提出的古怪需求的，这或许就是其中的方式。