❤️💕💕包含软件工程、算法与架构：设计模式、软件架构、协同开发、质量保障。更多关注我的博客：Myblog:http://nsddd.top
[TOC]
瀑布模型是从制造业和建筑行业借鉴而来，最早于 1970 年由 Winston Royce 提出。
从对应领域的专家和潜在用户那里收集信息，从而建立一个需求文档。需求文档是一系列要求，指导我们在当前发布版本中应该实现哪些功能。功能就是软件的种种职责。
接着是要根据写好的需求文档去设计软件。这些设计的形式通常是设计图例和其他表达设计思想的产出物。这并非代码，相当于另一个文档：如何构建软件的图例和描述。和蓝图不一样，蓝图是对建筑的每个细节的事无巨细的表达，但是软件的架构远谈不上精确或者全面。
在设计之后是实现阶段，这个阶段代码被编写出来以满足设计。编码就是单纯地完成设计产出物中描述的设计。
在所有代码编写完毕之后开始集成阶段。在集成阶段中，所有团队成员编写的代码放到一起。这通常是第一次所有代码被编译到一个计算机程序中。
一旦软件集成完毕则测试阶段开始，验证软件表现是否如预期的那样。这个阶段包括对软件执行一系列的测试用于证明软件正常工作。
在安装阶段，软件发布给用户。此阶段可能包括将载有程序的 CD 邮寄给用户或者在线上提供软件下载。
最后，就是对软件进行持续维护：修复问题，添加新功能，提供更新。 瀑布模型在桥梁建造或者制造小物品时意义重大，因为将需求整合投入生产的方式更加高效。
许多 bug 都是只在集成阶段才会出现。我们在项目的最后阶段才集成代码，这给开发过程带来极大的不确定性。由于已经进入集成阶段，任何必要的修改和奇怪的 bug 都会成为严重且代价高昂的问题，需要付出大量的努力（以及附带的成本）去修复。我难以想象，还会有其他编写软件的方式比这样风险更高、更容易出错。
从高级架构实践到低级编程实践，有一系列敏捷设计实践，参见图1。这些实践中的每一个都很重要，如果您的团队要在敏捷设计方面有效，则每个实践都是必需的。
图1.敏捷设计实践。
- 敏捷设计是紧急的，它们不是预先定义的。随着时间的推移，您的整体系统设计将不断涌现，不断发展以满足新的需求并酌情利用新技术。虽然在“迭代0”期间您经常会在项目的最初阶段进行一些初始架构建模，但这足以让您的团队继续前进。在您开始编码之前，敏捷者不需要获得完整记录的模型集（尽管有时，有时候，您可能需要执行前瞻性建模）。
- 您的单元测试构成了大部分详细的设计文档。使用测试驱动开发（TDD）开发方法，您可以编写测试，然后编写足够的域代码来完成测试。这种方法的一个重要副作用是，您的单元测试不仅验证您的代码，它们还以可执行规范的形式构成您的大部分设计文档。TDD是AMDD的补充，实际上是由AMDD扩展的。
- 设计模型需要勉强够用。您不需要对模型中的每个细节进行建模，模型不需要完美，并且它们当然不需要完整。还记得你最后一次从设计规范编码（如果你曾经做过）？你真的看过所有细粒度的细节吗？不，因为你有足够的能力自己处理细节。
- 多种型号。有效的开发人员意识到每种类型的模型都有其优点和缺点，因此他们需要为手头的工作应用正确的模型。由于软件开发很复杂，因此您很快意识到需要了解各种模型才能有效。本新闻稿中提到的所有模型等都在
Agile Models Distilled页面中进行了描述。 - 您通常只需要模型的子集。虽然您可以使用许多建模技术，但事实是任何给定的项目团队只需要一个子集。可以这样想：在家里的工具箱里，你有各种各样的螺丝刀，扳手，钳子等等。对于任何给定的维修工作，您将只使用一些工具。不同的工作，不同的工具。您永远不需要同时使用所有工具，但随着时间的推移，您将以各种方式使用它们。
- 每种型号都可用于各种用途。
UML类图可用于描述高级域模型或低级设计，更不用说介于两者之间的事物了。用例可用于模拟流程的基本性质或详细的系统使用描述，其中考虑了架构决策。永远不要低估模型的灵活性。 - 设计师也应该编码。每当模型被移交给其他人进行编码时，程序员就不会理解模型，会遗漏一些细微差别，甚至可能完全忽略模型以支持他们自己的方法。此外，即使交接成功，您也会发现模型中需要的细节远远多于您自己编写的细节。简而言之，将设计与编程分离是一个风险和昂贵的主张。在团队中推广可以设计和编码的专家是更有效的。
- 用代码证明它。永远不要假设你的设计有效相反，通过编写代码来确定它是否确实有效，从而获得具体的反馈。
- 反馈是你的朋友。永远不要忘记你和你团队中的其他人一样只是凡人。期待收到反馈 - 我建议您积极寻求 - 关于您的工作，并准备好考虑并采取相应行动。您的系统不仅会更好，您还可以在此过程中学到一些东西。
- 有时最简单的工具是复杂的
CASE工具。在需求方面，我更喜欢纸和白板等包容性工具，但在设计方面，我倾向于使用复杂的工具（重新）为我生成代码。就像我的祖父总是说的那样，你应该使用合适的工具来完成工作。 - 迭代，迭代，迭代。使用迭代的开发方法，您可以根据需求进行一些工作，进行一些分析，进行一些设计，一些编码，一些测试，并根据需要在这些活动之间进行迭代。您还将在处理各种工件之间来回迭代，在正确的时间处理正确的工件。
- 设计非常重要，你应该每天都这样做。在构建之前，仔细思考如何构建某些东西，实际设计它是至关重要的。您的设计工作可以采用白板上的草图形式，使用复杂建模工具创建的详细模型，或者在编写业务代码之前编写的简单测试。敏捷开发人员意识到设计是如此重要以至于他们每天都在做，设计不仅仅是您在完成编写源代码的“实际工作”之前在项目早期所做的一个阶段。
- 明智地为您的实施环境设计。利用您的实施环境的功能，但要聪明一点。权衡是正常的，但要了解其影响并管理所涉及的风险。每次使用产品（例如数据库，操作系统或中间件工具）中的独特性能增强功能时，您可能会将系统与该产品耦合，从而降低其可移植性。为了最大限度地降低实施环境对系统的影响，您可以对软件进行分层并包装特定功能，使其对用户显得通用。
- 记录复杂的事情。如果它很复杂，那就彻底记录下来。更好的是，花时间设计它，这很简单。记住AM练习创建简单内容。
- 不要过度记录。您需要记录您的设计，但不应该过度记录。请记住，用户付钱给您构建系统，而不是记录它们。在记录和文档之间有一个细微的界限，只有通过经验才能找到它。在文档方面尽量保持敏捷。
- 不要被数据社区所牵制。不幸的是，数据社区中的许多人认为您需要采用串行方法进行设计，尤其是涉及数据库时。这种信念是由于不了解进化发展或某种被误导的需要来确定“一个真理高于一切”。诸如敏捷数据建模，数据库重构和数据库回归测试等进化数据库设计技术在实践中工作得非常好。
- 记住用户体验（UX）。对于最终用户，用户界面（UI）是系统。这意味着您的设计的一个重要方面是UX。有关更多信息，请参阅敏捷可用性简介以及如何将设计集成到敏捷过程中。
图2描绘了通用敏捷软件开发生命周期。为了便于讨论，需要注意的重要一点是，传统主义者不熟悉设计阶段，也没有需求阶段。敏捷开发人员将在迭代0期间进行一些高级架构建模，也称为预热阶段，在开发迭代期间甚至在最终游戏期间（如果需要）进行详细设计。
图2. Agile SDLC（单击以展开）。
图3描绘了敏捷模型驱动开发（AMDD）生命周期，其重点是建模如何适应整个敏捷软件开发生命周期。在项目早期，您至少需要了解如何构建系统。它是大型机COBOL应用程序吗？一个.Net应用程序？J2EE？别的什么？在迭代0期间，项目的开发人员将聚集在一个房间，通常围绕白板，讨论，然后勾勒出系统的潜在架构。这种架构可能会随着时间的推移而发展，它不会非常详细（它现在只需要足够好），并且需要编写很少的文档（如果有的话）。目标是确定架构策略，而不是编写大量文档。
图3. AMDD生命周期。
当开发人员有新的实施要求时，他们会问自己是否理解要求的内容。如果没有，那么他们会做一些即时（JIT）“模型风暴”来确定实施要求的策略。这种模型风暴通常在迭代开始时在迭代的详细规划工作期间完成，或者在迭代期间的某个时间如果他们意识到他们需要进一步探索需求。这种建模工作的一部分将是对需求的分析以及解决方案的设计，这通常会在几分钟的时间内发生。在极限编程（XP）中，他们将此称为“快速设计会话”。
如果团队采用测试驱动开发（TDD）方法，则详细设计被有效地指定为开发人员测试，而不是详细模型。因为在编写足够的生产代码来完成测试之前编写测试，实际上在编写测试时会考虑生产代码的设计。您不是创建必然会过时的静态设计文档，而是编写一个可执行规范，开发人员可以通过该规范来保持最新，因为它实际上为它们提供了价值。该策略是单一采购信息的AM实践的一个示例，其中信息被捕获一次并用于多种目的。在这种情况下，详细规范和确认测试。
Scrum 的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为 Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。
产品负责人（Product Owner）主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。
流程管理员（Scrum Master）主要负责整个 Scrum 流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。
开发团队（Scrum Team）主要负责软件产品在 Scrum 规定流程下进行开发工作，人数控制在 5~10 人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到 Sprint 的目标。
Sprint 是短距离赛跑的意思，这里面指的是一次迭代，而一次迭代的周期是 1 个月时间（即 4 个星期），也就是我们要把一次迭代的开发内容以最快的速度完成它，这个过程我们称它为 Sprint。
1、我们首先需要确定一个 Product Backlog（按优先顺序排列的一个产品需求列表），这个是由 Product Owner 负责的；
2、Scrum Team 根据 Product Backlog 列表，做工作量的预估和安排；
3、有了 Product Backlog 列表，我们需要通过 Sprint Planning Meeting（Sprint 计划会议）来从中挑选出一个 Story 作为本次迭代完成的目标，这个目标的时间周期是 1~4 个星期，然后把这个 Story 进行细化，形成一个 Sprint Backlog；
4、Sprint Backlog 是由 Scrum Team 去完成的，每个成员根据 Sprint Backlog 再细化成更小的任务（细到每个任务的工作量在 2 天内能完成）；
5、在 Scrum Team 完成计划会议上选出的 Sprint Backlog 过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在 15 分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint 燃尽图）；
6、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实 TFS 就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到 TFS 中，中间有任何失败，都会用邮件通知项目管理人员；
7、当一个 Story 完成，也就是 Sprint Backlog 被完成，也就表示一次 Sprint 完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个 Scrum Team 的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；
8、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮 Sprint 的产品需求中；