使用 Agile 阅读并理解建筑设计规范

2020-09-05 08:00:00 · 飞浪

介绍如果您要建造房屋，您首先会根据房屋的功能设定要求：大小、房间数量、地板材料等。下一步是聘请建筑师进行设计，以满足您的要求，从而确定房屋布局和楼层平面图、电气原理图等。对于建造房屋的

介绍

如果您要建造房屋，您首先会根据房屋的功能设定要求：大小、房间数量、地板材料等。下一步是聘请建筑师进行设计，以满足您的要求，从而确定房屋布局和楼层平面图、电气原理图等。对于建造房屋的工程师来说，虽然要求对于理解项目背后的愿景很重要，但设计规范才是具体细节，说明要做什么，因此从工程师的角度来看，这是最重要的（工程师可能不太关心您真正想要什么）。

在传统的软件世界中，情况并没有太大不同。架构设计规范是一份技术文档，描述了如何开发软件系统以实现需求中描述的目标。它类似于房屋平面图。它是开发人员最重要的文档，因为它列出了要构建的具体内容，甚至包括技术细节。传统上，由于设计中涉及大量精细细节，因此开发的这一阶段非常昂贵且耗时。

在敏捷世界中，需求以用户故事的形式出现，当用户故事被细化以包含系统设计细节时，它也会封装规范。用户故事可以更准确地捕捉到真正的需求和所需的功能，而且形式要简单得多。虽然它可能为灰色地带和主观解释留有余地，但这种以用户为中心的方法通常会带来更好的最终产品。敏捷宣言中有一行是“可用的软件优于详尽的文档”，这是有原因的，这是因为详尽的文档远不如倾听用户的意见来做正确的事情重要。

在本指南中，我们将探讨如何推理 Agile 中的架构设计规范。

共享理解

在敏捷中，需求让位于更以用户为中心的用户故事，完善用户故事和起草细节的责任由产品所有者和团队中的开发人员共同承担。这只有通过对最终用户的共同理解和同理心才能实现，而这正是敏捷文化的核心。这种共同理解使产品所有者能够专注于高层次的目标，而所有低层次的设计和实施细节都可以由开发团队制定。

因此，达成共识应是任何敏捷项目的首要任务，从早期阶段开始。虽然很难知道何时实现了这一目标，因为“理解”可能非常主观，但如果满足以下条件，您应该有信心实现这一目标：

您的团队拥有足够的客户背景，即他们知道客户是谁。
您的团队知道他们正在构建什么，即他们正在解决什么问题以及最终产品应该是什么样子。
您的团队了解他们为什么这样做，即产品背后的业务目标、愿景和动机是什么。

需要明确的是：团队实际上是指整个团队，而不仅仅是产品所有者。一旦建立了共同的理解，一切就都水到渠成了：协调功能性和非功能性需求、完善用户故事和确定待办事项的优先级成为自然而持续的团队工作，而不是由个人进行的一次性大型活动。

理解敏捷中的架构设计规范

因为在敏捷实践中，需求被捕获到用户故事中并从最终用户的角度来制定，所以设计工作从一开始就应该与该观点保持一致。因此，在设计系统时采用客户角色非常重要，以确保系统能够提供预期的价值。

理解架构设计可以归结为以下步骤：

确定假设：正在做出哪些技术和业务假设？正在对用户做出哪些假设？
确定技术和业务约束：每个人都应该注意哪些技术约束？例如，是否存在影响整体设计的基础设施容量限制？语言和工具约束？需要遵守的标准和法规？
识别非功能性需求：属于设计的系统“隐藏”品质是什么？

非功能性需求和 FURPS+

FURPS+ 缩写由 HP 设计，代表一种对软件质量各种属性进行分类的模型。尽管有些过时，但 FURPS+ 仍然是敏捷文化中非常有用的软件开发框架。它可以用作从敏捷用户故事中引出需求的一种方式。该缩写代表：

功能：软件产品的功能需求和能力。这是软件应该做的事情，也是最终用户更直接表达的内容
可用性：美学和人为因素，包括响应性和一致性等
可靠性：系统的可用性和稳定性
性能：速度、效率、容量等。
可支持性：系统的可维护性、可扩展性、修复速度等

除了首字母缩略词中的“F”部分，其他所有内容都与非功能性需求有关，这就是为什么应该投入大量时间和精力来理解它们的原因。再次强调，共享理解是一个重要的先决条件，因为只有通过假设用户的观点并理解用户的顾虑，才能将其中一些品质正确地融入设计中。

FURPS+ 中的“+”部分是作为对原始框架（FURPS）的修订而添加的，其中包括一些前面提到的技术和业务限制。

应对变化

关于架构设计的最后一点是，与 Agile 中的其他所有内容一样，它不应一成不变并被视为不可协商的合同。最终产品是合同，设计可以根据需要多次演变以适应变化 — 无论是技术变化，例如来自平台更新的新约束，还是仅仅是视角的变化，因为有人意识到了实现用户目标的略微更好的做法。因此，通过共享理解的更广泛视角以及 FURPS+ 等框架的视角来解释架构设计规范非常重要，这些框架包括构建良好软件产品所必需的系统质量。