敏捷对商业意味着什么

这是我第13部分系列文章的第7个帖子， “敏捷的神话和误解” ，它基于我在第一届PSIA Softech菲律宾软件工程大会上的演讲。 我正在努力纠正有关敏捷软件开发的12种常见误解。

首先，让我纠正一下敏捷几乎不关心设计的观念。 敏捷宣言的许多（即使不是大多数）签署人都是设计方面的思想领袖。 Martin Fowler和Robert Martin是两个在2001年在Snowbird度假胜地举行开创性的“轻型过程峰会”的人 ，其中创造了“敏捷软件开发”一词，并写了“敏捷宣言”。 Martin Fowler是“设计模式”的代名词。 罗伯特·马丁（Robert Martin）撰写了第一批标题为“敏捷”的书，即“敏捷软件开发”。 在这本书中，他概述了现在著名的“ SOLID”原则 ，而本书的其余大部分涉及设计模式，重构和测试驱动开发。

现在让我们讨论前期设计。 敏捷团队被告知“大设计先期”是不好的，因此有人将其解释为“无设计先期”必须是好的。 事实恰恰在中间–由Spikes支持的“最小设计前期”。

关于敏捷的第一本书籍之一。 它的覆盖范围主要是设计–
这就是SOLID原则的引入，
其余的大部分都涉及
设计模式，重构和测试驱动的开发。

大的前期设计有什么问题？

“大型前期设计”的主要问题是，在花了所有时间和精力来创建设计之后，我们几乎总是发现，只有当团队开始编码时，或更糟糕的是，当团队开始时，许多设计是错误的在项目结束时进行性能测试！

对于Java开发人员，您还记得EJB2的黑暗时代吗？ 我们所有人都喜欢将EJB引入我们的项目，因为这是旨在使系统“可伸缩”的Sun Microsystems标准。 我们最终要做的是一个接一个的项目，只能支持他们打算支持的部分用户。 我知道一个工资项目应该支持数千个用户，但是当仅用十个用户进行测试时，系统就会爬行。 经过两年的发展，整个项目被取消，给客户和供应商带来巨大损失。

那Healthcare.gov呢？ 许多问题归咎于使用了非常新的列式数据库，该数据库保证了性能和可伸缩性，但引起的问题却比解决的多。 当我自己是一名开发人员时，我记得我盯着一个UML图，它是我的老板强迫我实现的，但是不可能用代码实现！

Big Upfront Design的主要问题是很少经过验证 。 而且，当我们发现设计决策是错误的时，已经编写了太多的代码，因此更改设计变得昂贵，浪费和冒险。

敏捷设计基于增量和证据

那么如何在敏捷中完成设计呢？ 首先是“只需要足够的设计”的想法–团队只需做出足够的设计决策即可继续进行该项目。 但是，与敏捷中的所有决策一样，决策需要基于经验或基于证据。 因此，在对设计投入大量代码之前，需要对设计决策进行验证。

验证设计决策的最佳方法之一是通过Spike解决方案。 团队编写一个或多个实现设计的小型原型，通常会从项目中获取实际用例或功能。 如果性能是设计的考虑因素，则团队可以对Spike解决方案进行性能测试。 根据设计应达到的关注程度（安全性，完整性，可伸缩性，易用性等），也可以应用其他类型的测试。因此，团队很早就发现设计方法是简单还是简单。难以使用，无法按预期执行或与设计要解决的问题相关。

在做出一些初步的设计决定之后，其余的设计将随着每个Sprint逐步完成。 这就是“紧急设计”的概念。 对于每个Sprint，团队将继续进行足够的设计以实施近期工作。 人们通常会通过重构来发现并实施对设计的改进或纠正。

关于UML工具的说明

当我提倡设计时，我不主张提倡购买一些UML软件。 我在软件领域工作多年，尝试过很多工具– UML工具起初适用于小型设计，但是随着设计变得越来越复杂，以及在设计上进行协作的需求增加，UML工具只会使团队陷入困境比帮助团队前进。

可以说，对于团队来说，最好的设计工具是白板 。 它可以向整个团队散发信息，可以进行即兴讨论和协作，而且有限的空间可防止您使设计过于复杂，因此您可以继续执行代码。

不要浪费时间在一些UML工具上详述您的设计。 在白板上随意涂抹即可使团队继续前进。 在代码本身中完成设计。

不要浪费时间在一些UML工具上详述您的设计。 在白板上随意涂抹即可使团队继续前进。 在代码本身中完成设计。

设计的哪些部分是前期的？

那么，设计的哪些部分是预先完成的？ 对于我所观察到的所有项目，至少在设计的三个方面，甚至在第一个Sprint开始之前就已经进行了一些前期工作。 这些是域模型，体系结构和用户界面。 除非事先在这三个方面中的每个方面都至少确定了一些设计，否则要使团队高效地合作几乎是不可能的。 同样，仅完成了足以让团队开始使用的设计。 设计的其余部分随每个Sprint一起出现 。

领域模型

系统的业务逻辑是最重要的部分，因为这就是系统存在的原因。 它也是系统中更改最频繁的一部分。

许多团队只是将他们的业务逻辑塞入称为“事务脚本”的程序例程中。 这对于简单的系统来说是很好的，但是对于任何中等复杂的情况，这会导致很多混乱，混乱，重复的，难以理解的代码。 而且由于业务逻辑发生了很大的变化，因此这种令人困惑的代码可能会成为错误的来源。 除此之外，难以理解的代码会使团队工作减慢。

因此，以组织化，可读性强且易于更改的方式编写业务逻辑非常重要。 推荐的实现此目标的方法是通过所谓的“丰富域模型”，即将特定业务域的实体建模为类，并将它们之间的交互编码为方法调用。

设计域模型是一个冗长的话题 ，我可能已经失去了一些人，所以让我为您提供一个很好的起点-Craig Larman的“ Applying UML＆Patterns” （ 应用UML和模式） ，它是分步指导您分析业务领域来设计领域模型。 作为补充，请使用Len Silverston的“数据模型资源手册”系列，该系列是经过行业测试的数据模型的目录，这些数据模型是域模型设计的起点。

学习领域分析和设计的最佳起点。

3卷目录，包含针对各种行业（例如制造，会计和保险）的已建立数据模型。

我建议团队开始一个项目时，它会绘制一些简单的，局部的，低细节的UML类图，以达成他们对业务领域的理解。 如果团队可以邀请产品负责人或客户来验证他们的理解，那将是很好的。 这是偏向于低细节图而不是高细节图的原因之一–低细节图往往更容易理解，并且对非技术人员的威胁较小。

建筑

“架构”只是设计中处理“非功能性”需求（换句话说，不是业务逻辑的需求）的一部分的幻想。 例如性能，正常运行时间，安全性和成本。

通常，架构错误只会在系统部署到最后或更糟糕的时候才发现。 架构错误可能会表现为系统运行缓慢或安全漏洞！ 它可能表现为昂贵的经常性成本或扩展系统的成本很高。 由于这些错误是在最后发现的，因此更改这些体系结构决策非常昂贵且冒险，因为已经在所选体系结构之上投入了很多代码。

为什么架构决策经常出错？ 架构决策通常基于供应商文档，供应商演示或受欢迎程度。 供应商可能会提供演示或概念证明来销售您的产品，但请记住，供应商存在偏见–他建立了概念证明来销售您的产品，而不是真正测试产品是否有效为您的特定项目。

还有诸如“恢复驱动开发”之类的东西。 这是开发人员选择技术的地方，不是因为他们认为这是最适合其项目的技术，而是因为该技术的经验会在他们的简历中看起来不错。 他们将使用该技术一段时间，将其放入简历中，并寻找更好的工作。 您现在可能会选择可能不是最佳选择的技术。 哦，我在代码基础混乱的组织中多次见过这种情况。

架构决策应基于团队进行的测试，并针对要解决的问题 。 在敏捷中，我们构建了简单的原型，称为“尖峰解决方案” ，以解决技术问题。 这些钉可以进行性能测试和其他适用性评估。 可以使用所讨论的技术选择某些用户案例或场景并将其实现为完整堆栈，然后进行各种测试和其他评估。

用户界面

为了保持用户界面的一致性，应尽早确定系统用户界面的高级主题和布局。 每次迭代时，都会根据客户的反馈进行改进和详细说明。

结语

好的设计，尤其是面向对象的设计，是敏捷的核心。 因此，需要预先设计一些思路，以使团队朝着正确的方向发展。 敏捷只是在设计决策中强调简单性和证据 。

翻译自: https://www.javacodegeeks.com/2014/09/agile-myth-6-agile-means-no-upfront-design.html

敏捷对商业意味着什么