能、可用性和产品质量。
5、开发环境的保护与基础设施的维护。
兵家云：天时、地利、人和。没有一个好的开发环境，很难想象开发人员能够高效率的工作。开发环境必须是相对独立，又利于交流与沟通的工作室。具体的说，项目组的工作环境必须拒绝项目无关人员的干扰与破坏，但却无阻于项目成员，特别是同一小组成员的交流。此外，会议室的数量非常重要。我在管理一个项目时，竟然常常为寻找会议室而东奔西走，将大量的时间浪费在会议准备上。此外，服务器、客户机、网络、打印机、白板、卡片，以及开发工具和软件，例如IDE开发环境、版本控制工具、Bug管理工具等，都需要在团队建立之初就要准备好。对于计算机、网络和相关工具，则必须保证在项目开发期间的稳定性、畅通性。我曾经在项目开发中，因为网络中断、病毒侵袭以及服务器坏掉从而破坏了SVN的版本管理等诸多突发事件，让我在本来就紧张的开发时间里，牺牲了不低于三天的时间，真是让我抓狂不已！所以说，一个好的网络管理中心、一个好的配置管理员，在关键时刻，可以抵得上半打高效的开发人员呢。如果你在项目开发过程中，频繁遭遇这样的问题，我的忠告是，赶紧准备换一家公司吧。
6、合理控制需求变更。
需求变更是软件开发必然遭遇的暴风雪，也是导致“没有银弹”的渊薮。传统的瀑布开发模型在项目后期遭遇需求变更时，只能束手无策，但RUP与敏捷方法却能够坦然面对需求的变更，Kent Beck甚至在敏捷开发中提出了拥抱变化，真是足够勇敢与足够信心的宣言啊！在软件开发中，若要应对软件开发，一般的做法是合理设计，以求系统与架构具有足够的可扩展性；其次则是采用迭代的开发方式，通过定期甚至是短周期地交付可工作的产品，以印证需求与实现是否一致。同时，在项目中通过引入客户的积极参与，使得项目组与客户的交流能够畅通无阻，从而避免因为隔阂而导致需求分析产生的误差，以及需求变更无法及时提出。此外，利用原型快速开发方式，可以尽快地交付一个无具体实现的产品框架或原型，以验证业务规则、业务流程以及客户对GUI的要求。然而，需求变更绝对不能无休止地进行，这会导致迭代的永无眠日。即使是敏捷开发，我们仍然要设定客户委托事项的基本线，一旦超出这一基本线，变更委员会（CCB）或其他担负这一职责的角色就必须提出异议，与客户协商或探讨这种变更是否是必须的。控制需求变更的一个实践是，获得客户对分析出来的功能点的书面确认。虽然在发生变更时，客户的意见甚至可以无视这种书面文章，但至少可以在与客户的谈判中抢得先机。根据Mark Lines所说，通过变更控制的增强还可以降低项目风险。确实如此，在与客户谈判中，我们要学会说出“拒绝”两个字。当然，在对需求变更做出决定性意见之前，必须分析判断这样的变更是否合理，是否必要，或者优先级高。一种折中的办法则是，欣然承诺此次变更，但需要延迟最后期限，或者放在下一次版本迭代之后。
7、预先评估风险。
风险无处不在。Cockburn将软件开发形容为攀岩或者穿越沼泽，已经充分说明了软件开发过程中的风险。孙子兵法云：夫未战而庙算胜者，得算多也；未战而庙算不胜者，得算少也。先预先着失败的可能，方能够谨慎地做好各种准备，考虑各种风险以及驱避措施，方能够最大可能地取得胜利。软件开发的风险有很多，其中至关重要的是进度风险、技术风险、需求变更风险、成员变动风险。
软件是可以度量的吗？看起来是，因为已经有了很多方法来完成软件的度量。从控制学的理论来看，你无法控制那些你无法度量的。因而软件度量对于控制软件开发而言，就成为了关键。软件度量甚至因此成为了