发布时间: 2012-08-30 02:51:00
昨天跟一位朋友讨论问题，谈到了需求变更。他说目前正在遭遇这个情况，变更的太厉害了。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. )