你会想更多地了解整个敏捷开发运动。敏捷就是所说的：能够快速适应。

• 罗伯特•C•马丁2002年的书-一部经典之作。

• 敏捷开发于C# - 这就是我使用的

• 看书单。

• 您会想要阅读敏捷宣言！

• 再来一个：肯特·贝克的作品 - 尤其是测试驱动开发。

对我来说，具体的代码似乎比抽象的和概化的代码更易于修改。因此，如果您想要可变的代码，请坚持使用具体的代码并避免元编程。

从现在开始的6个月内，很可能没有人会理解那些泛化和抽象化的方法的真实用例，并且害怕更改它们。

如果这是您的开发环境，您将希望使用敏捷开发过程。

作为这个过程的一部分，你可能希望持续展示一个工作中的系统，以便客户可以在其实施过程中进行调整。这将帮助他们了解进展情况和你的位置。但更重要的是，它将使他们更好地了解当前业务要求下系统的运行方式以及他们新变更的影响。

要小心，不要让你的原型看起来太吸引人。如果原型外观精美，你的业务拓展人员很有可能会认为软件比它实际完成得更多。我建议尝试让原型看起来不那么精美，更注重其功能。例如，如果你在Java Swing上工作，有一个名为Napkin的很棒的外观，它可以帮助你实现这一目标。它允许你构建任意多的功能，但屏幕看起来就像在餐巾纸上画的一样。因此，人们的注意力和重点是在功能上，而不是图形细节上。

尝试设计一个通用系统，以便轻松适应不断变化的需求根本行不通。正如马克所建议的那样，整个敏捷运动是基于这样一个认识，即简单具体的代码比通用代码更易于适应，只要它被良好编写和可维护。

领域驱动设计是一个不错的方法，有一本不错的书可以帮助你入门。

这种方法的重点是在软件中使用的开发领域模型和实际建模的"真实世界"之间建立紧密的反馈循环，因此变化的现实世界是可以接受的。

请考虑业务需求的变化规模是什么：

• if small-scale requirements change frequently, i.e. people change their minds about what they want, but what they need to do has not really changed, then adopt Agile practices and keep your iterations very short (as short as 1-feature iterations, if necessary to actually get to complete something!)
• if larger-scale requirements change often, i.e. what infrastructure is needed to run the business, this may be a reflection of changing management whims (what i think of as the "last salesman syndrome" - whatever the last salesman was selling is suddenly The Way Of The Future). If you re involve in these decisions, try to reduce technical issues to the fundamentals (communication, storage, computation, interaction, access, ...) and don t get distracted by product-level bells and whistles. Remember that nothing is likely to be a 100% fit, but the cost of changing your mind too often may outweigh the benefit of changing platforms or architectures. If you ve not involved in these decisions, there s not much you can do about it except learn quickly and gently encourage deeper commitment when you can ;-)
• if the natur of the business changes often, i.e. new lines of business are needed every few weeks, old lines consolidated, et al, and you are involved in discussions at this level, you can try to anticipate the future changes by probing deeper into the company plans. If you re not involve at this level, try to be flexible and invaluable until you find a job with a more stable company ;-)

考虑一个业务规则引擎。虽然并不总是合适的，但可以帮助将业务逻辑和需求与技术架构/解决方案分离。例如，假设您需要根据一组测试结果设置汽车的安全分类。对汽车进行的测试可能会变化，分类标准也可能会改变（包括实际的分类数量，例如从五星制到十星制）。在这种情况下，业务规则引擎可能是对汽车进行分类的一种好方法。

规则引擎将提供基于文本或XML的规则，理论上至少可以由非编程员（例如业务分析师）编写和维护。这些规则将应用于一个Car对象（假设Car对象包含对TestResults对象的引用）。规则/规则引擎将分析测试结果并相应地设置Car对象的SafetyClassification 属性。

实际规则可以存储在数据库或共享位置中，甚至可以通过消息基础设施或Web服务调用提供给系统。 新的规则可以提供给系统并在不重新编译/部署系统的情况下激活。

不同的技术有不同的规则引擎可用。例如，.Net有Drools.Net、WWF规则引擎和其他一些引擎。Java有JBoss Rules和其他许多引擎。

(almost) every program have changing business requirements. Trying to negotiate with the customer (marketing or product manager are also costumers) is important, but never enough. the requirements always change. Scrum has a lot of techniques to manage changes in the requirements.