Mikel
前言
这是我在重读《代码大全》这本书的第二版的时候做的笔记（红色部分是我的评注）。这一段对于需求的描述以及如何处理需求变更很有帮助，希望也给大家一些参考。我自己做过的项目中，也遇到过几乎下面提到的所有问题（甚至真的有项目到了要取消的地步），所以还是挺有感触的。
稳定需求的神话
“一旦客户接受了一份需求文档，就再也不做更改”是一个美好的愿望。 然而，对一个典型的项目来说，在编写代码之前，客户无法可靠地描述他们想要的是什么，问题并不在于客户是低级生物。就如同你做这个项目的时间越长，对这个 项目的理解也就越深入一样，客户参与项目的时间越长，他们对项目的理解也就能越深入。开发过程能够帮助客户更好地理解自己的需求，这是需求变更的主要来 源。计划严格依照需求办事，实际上就是计划不对客户端要求做出回应。
典型情况下需求会有多少改动？IBM和其他公司的研究发现，平均水平的项目在开发过程中，需求会有25%的变化。在典型的项目中，需求变更导致的返工占到返工总量的75%～85%。【在做项目规划的时候，对于这个比例有所了解将有助于你更好地安排日程和计划】
如何在构建期间处理需求变更
在构建期间，要最好地应对需求变更，有以下一些可以采用的方式。
评估需求质量。
如果需求不够好，那么就停止工作，退回去，先把它做好，再继续前进。当然，因为在此期间你会停止编码，所以感觉似乎进度会落后。不过，假 设你正开车从芝加哥到洛杉矶，突然看到纽约的路牌，那么停下来查看路线图是浪费时间吗？当然不是，如果没有对准正确的方向，那就要停下来检查一下路线。【这个隐喻太形象，太棒了，记得当你提出要评估需求时遇到反对意见的时候，讲这个隐喻给他们听听。当然我知道，你可能会遇到一些两难境地，软件项目的复杂性是很高的，但至少你遇到问题的时候，要去权衡，而不是将错就错，因为那肯定是到不了终点的】
确保每一个人都知道需求变更的代价
客户只要想到一个新功能就会很兴奋。在兴奋时血液会涌向大脑，人会晕头晕脑，他会把所有你们开过的讨论需求的回忆、签字仪式、以及已经完 成的需求文档统统抛诸脑后。最简单的对付这种新功能中毒症患者的办法是说：”咦，这听起来是一个很不错的主意。不过由于它不是需求文档中的内容，我会整理 一份修订过的进度表和成本估计表，这样你可以决定是现在实施，还是过一阵子再说。” 进度和成本这两个字眼闭咖啡和洗冷水澡都要提神，许多”必须要有/must have”很快会变成”有就最好/nice to haves”。【这是一个很好的沟通方式，我觉得。掌握这个方法的前提是，你必须能让人信任地估算进度和成本，我的意思是，你所说的最好不是信口开河。由于不信任导致的沟通问题可能会更加严重。】
建立一套变更控制程序
如果你的客户激情不减，那就要考虑建立一个正式的变更控制委员会，评审提交上来的更改方案。客户改变他们的想法，认识到他们需要更多的功 能，这不是坏事。问题是他们提交更改方案太频繁了，让你跟不上进度。如果有一套固定的变更控制程序，那么大家就会很愉快——你知道自己只需在特定时候处理 变更；而客户知道你打算处理他们的提议。【变更控制程序，在我们的实际工作中，可能就是要有一个需求变更单，以及一定的审核流程，这样可以促使用户提出新的想法的时候，经过讨论和确认，而不至于随意。同时，在开发管理过程中，区分需求、任务、Bug，并且对它们进行清晰的管理是很必要的。】
使用能适应变更的开发方法
某些开发方法让你”对需求变更做出响应”的能力最大化。演进原型法能让你在投入全部精力建造系统之前，先探索系统的需求。演进交付是一种 分阶段交付系统的方法。你可以建造一小块、从用户获得一点反馈、调整一点设计、做少量改动、再多建造一小块。关键在于缩短开发周期，以便更快地响应用户的 要求。【采用迭代的开发方式，应该已经成为目前开发系统或者软件的事实标准了，尤其是在互联网应用以及移动应用的情况下。】
放弃这个项目
如果需求特别糟糕，或者极不稳定，而上面的建议没有一条能奏效，那就取消这个项目。即使你无法真的取消这个项目，也设想一下取消它之后会 是怎样的情况。在取消它之前想想它有可能变得多糟糕。假如在某种情况下你可以放弃这个项目，那么至少也要问问自己，目前的情况和你所设想的那种情况有多大 距离。【有时候很难，真的】
注意项目的商业案例
在提到实施这个项目的商业理由的时候，许多需求事项就会从你眼前消失。有些需求作为功能特色来看是很不错的想法，但是当你评估”增加的商业价值”时就会觉得它是一个糟透了的主意。【技术发烧友容易犯的毛病，尤其是新技术狂热者。】
