本文概述了敏捷软件开发团队的设计策略。这些策略对于扩展敏捷软件开发以满足现代IT组织的实际需求至关重要。敏捷的设计方法与传统方法截然不同，显然也更有效。重要的是要了解：
- 敏捷设计实践
- 敏捷设计理念
- 整个敏捷生命周期的设计
1.敏捷设计实践
从高级架构实践到低级编程实践，有一系列敏捷设计实践，参见图1。这些实践中的每一个都很重要，如果您的团队要在敏捷设计方面有效，则每个实践都是必需的。
图1.敏捷设计实践。
2.敏捷设计理念
- 敏捷设计是紧急的，它们不是预先定义的。随着时间的推移，您的整体系统设计将不断涌现，不断发展以满足新的需求并酌情利用新技术。虽然在“迭代0”期间您经常会在项目的最初阶段进行一些初始架构建模，但这足以让您的团队继续前进。在您开始编码之前，敏捷者不需要获得完整记录的模型集（尽管有时，有时候，您可能需要执行前瞻性建模）。
- 您的单元测试构成了大部分详细的设计文档。使用测试驱动开发（TDD）开发方法，您可以编写测试，然后编写足够的域代码来完成测试。这种方法的一个重要副作用是，您的单元测试不仅验证您的代码，它们还以可执行规范的形式构成您的大部分设计文档。TDD是AMDD的补充，实际上是由AMDD扩展的。
- 设计模型需要勉强够用。您不需要对模型中的每个细节进行建模，模型不需要完美，并且它们当然不需要完整。还记得你最后一次从设计规范编码（如果你曾经做过）？你真的看过所有细粒度的细节吗？不，因为你有足够的能力自己处理细节。
- 多种型号。有效的开发人员意识到每种类型的模型都有其优点和缺点，因此他们需要为手头的工作应用正确的模型。由于软件开发很复杂，因此您很快意识到需要了解各种模型才能有效。本新闻稿中提到的所有模型等都在Agile Models Distilled页面中进行了描述。
- 您通常只需要模型的子集。虽然您可以使用许多建模技术，但事实是任何给定的项目团队只需要一个子集。可以这样想：在家里的工具箱里，你有各种各样的螺丝刀，扳手，钳子等等。对于任何给定的维修工作，您将只使用一些工具。不同的工作，不同的工具。您永远不需要同时使用所有工具，但随着时间的推移，您将以各种方式使用它们。
- 每种型号都可用于各种用途。UML类图可用于描述高级域模型或低级设计，更不用说介于两者之间的事物了。用例可用于模拟流程的基本性质或详细的系统使用描述，其中考虑了架构决策。永远不要低估模型的灵活性。
- 设计师也应该编码。每当模型被移交给其他人进行编码时，程序员就不会理解模型，会遗漏一些细微差别，甚至可能完全忽略模型以支持他们自己的方法。此外，即使交接成功，您也会发现模型中需要的细节远远多于您自己编写的细节。简而言之，将设计与编程分离是一个风险和昂贵的主张。在团队中推广可以设计和编码的专家是更有效的。
- 用代码证明它。永远不要假设你的设计有效相反，通过编写代码来确定它是否确实有效，从而获得具体的反馈。
- 反馈是你的朋友。永远不要忘记你和你团队中的其他人一样只是凡人。期待收到反馈 - 我建议您积极寻求 - 关于您的工作，并准备好考虑并采取相应行动。您的系统不仅会更好，您还可以在此过程中学到一些东西。
- 有时最简单的工具是复杂的CASE工具。在需求方面，我更喜欢纸和白板等包容性工具，但在设计方面，我倾向于使用复杂的工具（重新）为我生成代码。就像我的祖父总是说的那样，你应该使用合适的工具来完成工作。
- 迭代，迭代，迭代。使用迭代的开发方法，您可以根据需求进行一些工作，进行一些分析，进行一些设计，一些编码，一些测试，并根据需要在这些活动之间进行迭代。您还将在处理各种工件之间来回迭代，在正确的时间处理正确的工件。
- 设计非常重要，你应该每天都这样做。在构建之前，仔细思考如何构建某些东西，实际设计它是至关重要的。您的设计工作可以采用白板上的草图形式，使用复杂建模工具创建的详细模型，或者在编写业务代码之前编写的简单测试。敏捷开发人员意识到设计是如此重要以至于他们每天都在做，设计不仅仅是您在完成编写源代码的“实际工作”之前在项目早期所做的一个阶段。
- 明智地为您的实施环境设计。利用您的实施环境的功能，但要聪明一点。权衡是正常的，但要了解其影响并管理所涉及的风险。每次使用产品（例如数据库，操作系统或中间件工具）中的独特性能增强功能时，您可能会将系统与该产品耦合，从而降低其可移植性。为了最大限度地降低实施环境对系统的影响，您可以对软件进行分层并包装特定功能，使其对用户显得通用。
- 记录复杂的事情。如果它很复杂，那就彻底记录下来。更好的是，花时间设计它，这很简单。记住AM练习创建简单内容。
- 不要过度记录。您需要记录您的设计，但不应该过度记录。请记住，用户付钱给您构建系统，而不是记录它们。在记录和文档之间有一个细微的界限，只有通过经验才能找到它。在文档方面尽量保持敏捷。
- 不要被数据社区所牵制。不幸的是，数据社区中的许多人认为您需要采用串行方法进行设计，尤其是涉及数据库时。这种信念是由于不了解进化发展或某种被误导的需要来确定“一个真理高于一切”。诸如敏捷数据建模，数据库重构和数据库回归测试等进化数据库设计技术在实践中工作得非常好。
- 记住用户体验（UX）。对于最终用户，用户界面（UI）是系统。这意味着您的设计的一个重要方面是UX。有关更多信息，请参阅敏捷可用性简介以及如何将设计集成到敏捷过程中。
3.整个生命周期的设计
图2描绘了通用敏捷软件开发生命周期。为了便于讨论，需要注意的重要一点是，传统主义者不熟悉设计阶段，也没有需求阶段。敏捷开发人员将在迭代0期间进行一些高级架构建模，也称为预热阶段，在开发迭代期间甚至在最终游戏期间（如果需要）进行详细设计。
图2. Agile SDLC（单击以展开）。
图3描绘了敏捷模型驱动开发（AMDD）生命周期，其重点是建模如何适应整个敏捷软件开发生命周期。在项目早期，您至少需要了解如何构建系统。它是大型机COBOL应用程序吗？一个.Net应用程序？J2EE？别的什么？在迭代0期间，项目的开发人员将聚集在一个房间，通常围绕白板，讨论，然后勾勒出系统的潜在架构。这种架构可能会随着时间的推移而发展，它不会非常详细（它现在只需要足够好），并且需要编写很少的文档（如果有的话）。目标是确定架构策略，而不是编写大量文档。
图3. AMDD生命周期。
当开发人员有新的实施要求时，他们会问自己是否理解要求的内容。如果没有，那么他们会做一些即时（JIT）“模型风暴”来确定实施要求的策略。这种模型风暴通常在迭代开始时在迭代的详细规划工作期间完成，或者在迭代期间的某个时间如果他们意识到他们需要进一步探索需求。这种建模工作的一部分将是对需求的分析以及解决方案的设计，这通常会在几分钟的时间内发生。在极限编程（XP）中，他们将此称为“快速设计会话”。
如果团队采用测试驱动开发（TDD）方法，则详细设计被有效地指定为开发人员测试，而不是详细模型。因为在编写足够的生产代码来完成测试之前编写测试，实际上在编写测试时会考虑生产代码的设计。您不是创建必然会过时的静态设计文档，而是编写一个可执行规范，开发人员可以通过该规范来保持最新，因为它实际上为它们提供了价值。该策略是单一采购信息的AM实践的一个示例，其中信息被捕获一次并用于多种目的。在这种情况下，详细规范和确认测试。
当你停下来思考它时，特别是在图2中，TDD有点用词不当。虽然您的开发人员测试正在“推动”代码的设计，但您的敏捷模型正在推动您的整体思考。
谢谢大家关注，转发，点赞。
