需求变更的太快怎么办？(what if the requirement changes too frequently? )

昨天跟一位朋友讨论问题，谈到了需求变更。他说目前正在遭遇这个情况，变更的太厉害了。2，3天变动一次。需求一变，很多代码都不能用了，包括单元测试代码。而且跑起来一片红。(Yesterday I had a talk with a friend who is suffering the frequent requirements changing. His team has been struggling for this situation that the requirement changes every 2 or 3 days, and every time the change occurs, lots of code including unit tests code doesn't work any more. )

所以他问我是如何看待这个问题的，以及解决办法是什么。( So he asked me how did I think about this issue and what my solution is. )

我的回答是：  ( My answers are: )

1. 关于看待这个问题：  需求变动是正常的。Kent说过： 软件开发中唯一不变的就是需求会变化.  很多需求在被（客户或者产品经理）提出的时候，都没有被完善和想好。很多产品都是一点一点的在开发中完善的。如果一个产品，一旦提出需求之后，不允许客户提变动，那么你就是在跟客户博弈，严重的后果就是失去客户。所以，我们要鼓励客户提出合理的需求变更。  ( 1. about how did I think about requirement changes:  it's normal and understandable.  Kent said:  the only thing that doesn't change in software development is : it always changes.  Most of the requirements are not mature and just an idea, the end-user even don't know what they want. Many and many ideas/products becomes full-fledged in the development processing.  If as a team leader, you don't allow end-users change the requirement, you are probably losing your client. So,  reasonable change request should be encouraged.  )

这里的“合理”指的是：  1. 这个需求是经过深思熟虑的，在逻辑上是行的通，没有前后矛盾的。  2. 这个需求是可行的。 ( here the 'reasonable' means: 1. this requirement changing is well considered, there's no conflicting there. 2. the new requirement is possible to implemented using current technology)

2. 解决办法：  ( solutions are: )
  2.1 新需求是要合理的。  ( the new requirement must be 'reasonable' )
  2.2 保持一个开发节奏。例如以一个星期为单位。这个星期内，一旦需求定下来，就不能更改。 ( keep a healthy development rhythm. e.g. make a week as an iteration. once developer starts coding in this week, the requirement could not be changed until the next week comes. )
  2.3 过时的代码该删就删，不能忍痛留着。无用的代码只会迷惑我们。  ( deprecated code should be always removed, otherwise they will become confusing )
  2.4 开发人员的能力至关重要。( the peopleware is the most important. The code written by experienced developer will be always easy to refactor and make changes. )