迭代地改进敏捷过程中的软件体系结构和质量？

Question

或者换句话说，如何确保架构或质量不受影响，执行敏捷。

在敏捷中处理架构的一些理解如下(通常也适用于测试)

*做建筑，直到风险从你的雷达*最低的设计前，这样你就不会为合理的改变要求付出可怕的代价。*每个特性/需求“刚刚足够”的架构/基础设施

(在搜索其他相关的StackOverflow问题时发现了上述内容)

假设的示例/场景是，需要在现有系统中开发订单处理模块。以下准则是经过谈判和商定的。

1. 模块的体系结构应该能够在一分钟内处理10个订单。
2. 上市时间为4周，计划处理2次短跑，为期2周。
3. 企业的平均业绩预期是令人满意的。

一旦模块交付，让我们说，下面的改进/更改是需要的。

• 改进处理至每分钟15份订单。
• 将性能提高25%。
• 上市时间为2周。

因此，假设来自客户/业务的进一步需求是受欢迎的，但在未来，随着迭代的进行，体系结构需要被彻底修改，测试模块的质量也变得更耗时。

而且，随着估值的增加，上述结果并不令人满意，而且无法快速满足进一步的期望或要求也是可以理解的。即使能在给定的时间内以足够的质量做到这一点，我们也希望我们能够在此之前做些什么，而不是在这个时候面对这种情况。

事后看来，在第一次迭代中进行规模设计是理想的，但这不是目标和重点。关注的始终是及时的市场，并致力于在给定的时间框架内满足业务/客户的期望。不幸的是，从长远来看，这确实对发展造成了损害。

在迭代地改进体系结构或测试过程时，如何避免示例中提到的陷阱？

Answer 1

我认为，大多数情况下，您混合了错误的抽象级别，因此，您将陷入困境。

首先，可以有更改架构的要求，但它们通常并不是很好的故事。例如，您需要将性能提高x%。这不是一个用户故事，它可能是无法实现的。有些系统是无法改进的，有些系统只能以非常大的代价加以改进，等等。

出现在脑海中的前两个缺失部分是：

• 提高业绩x%的业务价值是什么？
• 我们经营的正确界限是什么？

例如，我们就不能简单地购买一台速度为x%的服务器吗？

敏捷开发中没有“架构”故事，因为架构对用户没有实际价值。

架构是一种工具，它具有实用价值，在敏捷开发中很有用，但它与架构故事无关。架构是一种活动，如设计、重构、调试等。这些活动都不会有好的故事，但所有这些活动都是故事开发的典型部分。

另外要记住的一点是，建筑质量成为“完成的定义”的一部分。如果您有一个要求，每个网页应该在不到500毫秒内交付，使DoD的这一部分确保这适用于每一个故事，并成为其接受测试的标准。

此外，将性能级别设置为“完成的定义”，通常是一种冒险的做法。除非您只是简单地犯了错误并设置了错误的值，否则在许多级别上更改应用程序的性能概要都是困难的--这尤其难以估计。

作为另一种选择，您可以通过指定在何种情况下需要此更改以及原因来限制这种影响。这使得团队能够取得成功，并取得可能可以实现的结果。没有人能确定您可以在一般级别上更改复杂应用程序的性能，但是估计单个页面或特性更可行。

关于强化故事:我所见过的唯一一种方法(以及我们在Stack中使用的方法)是让一个人在每次迭代中执行bug任务。这确保了在问题出现时总是有人出现，在本质上是公平的，并且完全避免了将bug当作故事来处理时出现的调度问题(“在迭代过程中出现了一个新的bug，我们是修复这个问题，还是关闭这些故事？”)

Answer 2

敏捷架构是一场持久战。我试图用一种及时的方法来实现它，但最终，它与敏捷方法是直接对立的。这并不意味着它是坏的。这是非常重要的，它只是不适合于敏捷过程。

预先的架构和设计实际上是对敏捷开发风险的一种对冲。你必须平衡你的风险缓解和你的上市时间。在这种情况下，听起来你似乎有点偏离了风险/回报方程式。下一次，您可能会做太多的架构，并浪费大量的时间。不幸的是，仅仅需要经验和智慧才能弄清楚敏捷过程的“太多”架构。

Answer 3

这是一个常见的问题，很多客户在讨论敏捷时都会问这个问题。

你问题中的关键词是“事后发现”。每当我遇到一个“如果我们知道”的时刻，我就会遇到许多“你不会需要它”的时刻(YAGNI)。试图在一个版本中解决当前和未来的所有问题/需求将使您疯狂，使软件变得复杂、延迟和昂贵，并且通常会使您慢下来。

总的来说，改进现有的、精心制作的特性的性能所需的返工比投资于解决假想问题的“体系结构”解决方案要少得多。

在向我的客户和我的团队解释这一点时，我通常说，团队的工作是优化吞吐量和质量；客户的工作是确保我们总是在最有价值的任务上工作。敏捷的全部意义在于，“有价值”的变化会随着时间的推移而发生变化，而团队对此迅速做出反应。只要你能做到这一点，返工并不是什么大不了的事，即使它觉得效率很低。