迭代开发模式(9)需求变更的关键步骤--(转)

前面我们提到了需求变更。当客户提出了需求变更，经过与我们的需求人员的详细讨论与分析，最后确定下来了变更内容和修改方案。但这时草率地开始进行设计和开发是不正确的，它将成为项目后期的一个巨大的风险，一颗定时zhadan，为什么呢？我们来详细分析分析。

每当发生需求变更的时候，不管是大是小，项目的许多因素都会相应地发生变化。首先发生变化的是工作量。每次的变更必然造成工作量的增加，到底增加了多少呢？我们需要对其进行评估。同时，我们还要对增加的工作进行优先级评估。一般来说，新增加的工作往往优先级都是最高的，是客户急切想看到结果的部分，那么其它的工作的优先级就会收到影响，优先级就会有所下降。当工作量的增加与优先级的调整完成后，随后的工作就是项目计划的调整。

前面我们说过，迭代式开发的项目计划与传统的项目计划是存在巨大差异的。迭代式开发的项目计划其核心，就是如何将各项任务合理分配到各个迭代期中去。任务就像一个个大小不一的石子，迭代期就如同一个个网格，项目计划就是将石子分发到各个网格中，虽然有一些空隙，但大体是满的。现在新任务来了，就如同要将新的石子放到已满的网格中，有几种可能：石子很小，利用网格的空隙就可以填满了；石子太大了，如果要把这个石子放进这个网格中，就必须将里面的某个石子取出来，放到别的网格里。现在项目计划的变更就是这样。

如果新的工作量很小，往下一个迭代期挤一挤，即使超了1、2天也能挤下，那就挤挤吧，但这个迭代期可能会延期，后面工作的时间节点也必然随之调整；如果新的工作量还不小，优先级还比较高，那么只能将下一个迭代期中已有的任务取出，调整到其它迭代期中，这可能会导致后面整个的工作计划都将调整。不论怎样调整，我们都应当将调整后的工作计划告知客户。

不论业务需求怎样变更，不论项目计划怎样调整，通知客户，让客户理解，并与我们共同承担项目延期的风险，这是从无数失败的项目中总结出来的血的教训。一定要让客户明白，你们可以改需求，可以提出修改意见，但必须与我们一同承担风险。当客户意识到这一点时，也许他们就会慎重考虑了，甚至一下变更需求就会被取消。

在变更项目计划的同时，另一项重要的工作就是变更我们的产品需求说明书。在项目管理中，需求文档往往分为两个：原始需求和产品需求说明书。原始需求是客户编写的，站在客户角度描述的业务需求，而产品需求说明书是我们在对原始需求分析、理解、调研以后，剔除那些技术无法实现的内容，最后形成的文档，是我们的软件最终做成什么样的依据性文档（需求文档其实很多，如需求规格说明书、产品规格说明书等等，但都大同小异）。产品需求说明书是程序开发的依据，软件测试的依据，用户验收的依据，贯穿整个软件开发的核心。因此，当业务需求发生变更之后，产品需求说明书一定要进行相应的变更，并做好变更的记录，与客户签字确认。这样做的另一个好处就是防止客户随意变更需求，使客户对变更的提出更加慎重。

另外一个需求变更中常常出现的尴尬局面就是，当所有情况都清楚告诉客户以后，客户提出需求必须要变更，但最终交付时间却不能改变。这着实是一个相当矛盾的问题，变更必然造成工作量增加，工作量增加必然影响最终交付时间，但交付时间又不能变，这听起来既不合情又不合理，但在现实的项目中经常发生，而且各有个的充分理由，我们这怎么办呢？其实解决这种情况的办法就是在制订项目计划之初就提前考虑到。记得我们前面提到，我们在制订项目计划时应当在时间上留有一定的富余。如何制订项目计划，《越狱》这部电影给了我们很多的启示。如何成功越狱，主人公在越狱过程中的每个风险点都制订了风险规避和补救的办法，项目计划也是这样。项目需求变更就是一个风险点，因此项目经理应当在制订计划之初就应当做好准备，并提前预留出相应的时间，当项目进行过程中风险出现时才能从容应对。

总之，需求变更不是什么洪水猛兽，也不是一个项目可以完全规避得了的。我们提前准备好，从容应对之，就不是什么大不了的事情。

转自http://fangang.iteye.com/blog/1213670