期遭遇需求变更时，只能束手无策，但RUP与敏捷方法却能够坦然面对需求的变更，Kent Beck甚至在敏捷开发中提出了拥抱变化，真是足够勇敢与足够信心的宣言啊！在软件开发中，若要应对软件开发，一般的做法是合理设计，以求系统与架构具有足够的可扩展性；其次则是采用迭代的开发方式，通过定期甚至是短周期地交付可工作的产品，以印证需求与实现是否一致。同时，在项目中通过引入客户的积极参与，使得项目组与客户的交流能够畅通无阻，从而避免因为隔阂而导致需求分析产生的误差，以及需求变更无法及时提出。此外，利用原型快速开发方式，可以尽快地交付一个无具体实现的产品框架或原型，以验证业务规则、业务流程以及客户对GUI的要求。然而，需求变更绝对不能无休止地进行，这会导致迭代的永无眠日。
即使是敏捷开发，我们仍然要设定客户委托事项的基本线，一旦超出这一基本线，变更委员会（CCB）或其他担负这一职责的角色就必须提出异议，与客户协商或探讨这种变更是否是必须的。控制需求变更的一个实践是，获得客户对分析出来的功能点的书面确认。虽然在发生变更时，客户的意见甚至可以无视这种书面文章，但至少可以在与客户的谈判中抢得先机。根据Mark Lines所说，通过变更控制的增强还可以降低项目风险。确实如此，在与客户谈判中，我们要学会说出“拒绝”两个字。当然，在对需求变更做出决定性意见之前，必须分析判断这样的变更是否合理，是否必要，或者优先级高。一种折中的办法则是，欣然承诺此次变更，但需要延迟最后期限，或者放在下一次版本迭代之后。
7、预先评估风险。风险无处不在。Cockburn将软件开发形容为攀岩或者穿越沼泽，已经充分说明了软件开发过程中的风险。孙子兵法云：夫未战而庙算胜者，得算多也；未战而庙算不胜者，得算少也。先预先着失败的可能，方能够谨慎地做好各种准备，考虑各种风险以及驱避措施，方能够最大可能地取得胜利。软件开发的风险有很多，其中至关重要的是进度风险、技术风险、需求变更风险、成员变动风险。
软件是可以度量的吗？看起来是，因为已经有了很多方法来完成软件的度量。从控制学的理论来看，你无法控制那些你无法度量的。因而软件度量对于控制软件开发而言，就成为了关键。软件度量甚至因此成为了一门学问。然而，我可以肯定地说，软件的度量不可能准确，尤其是对进度的把握而言。即使一个项目的开发周期看起来是如此的充裕，以至于感受不到最后期限的压力，我们仍然要对软件进度的控制采取如坐针毡的谨慎态度，即使这样在某些人的眼中，我成为了持怀疑论者，或者悲观主义者，我仍然愿意背着这样的名身恶意地怀疑项目时间不够。原因有二。其一是我们的工作量估算无法做到精确，即使是经验丰富的天才程序员，在估算项目的整体工作量时，都会出现偏差。是的，我们采用了分而治之的方式，对功能进行分解，从最小单元来评估工作量。但我们无法估算各个功能单元之间存在的各种显式和隐式关系，以及各种非功能性需求带给项目的影响。其二，我们无法事先完全预知开发过程中的各种风险。我们得为这种风险买上一份保险，这样才不至于在风险真正产生时要我们自己来买单，或者追悔莫及。
关于技术风险，最佳方式莫过于事先进行技术预演。不要揣测，或者从理论上去推导。在这个过程中，我们可以应用经验，但最保险的方式还是对系统中的核心问题以及关键问题进行研究，创建技术原型。它才是规避技术风险的定心丸。
成员变动风险是最难以预知的，因为人是最难以通过数据分析得出正确结论的动物。人的心理太复杂了，因此在软件业中还专门诞生了“人件（Peopleware）”这门学问。在我们进行项目开发过程中，谁知道有多
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
