使用敏捷方法时如何获得良好的设计？

我已经使用敏捷方法（SCRUM）大约三年了，我看到了它的某些优势，特别是在许多级别的短期反馈中（来自能够早期访问已实现功能的客户，来自可以测试功能的测试人员）。实施后，其他开发人员可以通过审查等方式就新代码提供非常早期的反馈）。

另一方面，我有两个悬而未决的问题，第一个我将尝试在这个问题中进行解释。

问题：难以获得良好的设计

我试图在代码混乱时立即进行重构，我会尽力编写单元测试（这确实有助于防止错误，尤其是重构时）。另一方面，以小增量开发一些复杂的功能，每天提交并在非结构化代码时不断重新思考代码，这使我无法产生出真正好的设计。

我最近采用的另一种方法可以生产出唯一经过精心设计的模块，方法是采用不同的方法：我分析了几天的问题（实际上，在我开始认真研究该问题之前，我已经将这个问题花了几个月的时间） ），为所有涉及的类及其之间的关系草拟了相当详细的设计，持续了两天，然后将自己锁在办公室，并通过不间断地工作了大约三周时间写下了整个代码。结果是我一段时间以来取得的最好的结果，很少有易于定位和修复的错误，并且设计非常清晰，自此以后就不需要进行任何相关更改。

因此，到目前为止，我发现预先了解要执行的操作的总体效果比开始以小增量编写代码要有效得多，以期在此过程中神奇地出现大效果。尽我最大的努力，小增量开发方法一直使我的设计变糟。

问题：有没有类似的经历？我是否以错误的方式应用SCRUM，或者如果我想以较小的增量进行开发并且最终仍然使用精心设计的软件，应该注意什么？还是应该在开始实际编码之前安排设计用户故事？至少对于比平均水平更复杂的功能，这是否被视为一种好的做法？

编辑-注意

我知道这样一个事实，即好的设计不是绝对的东西，本身没有价值，而是取决于上下文，因此，人们应该针对一种足以解决当前问题的设计。

例如，如果我必须实现一个简单的组件，即（1）必须尽快准备就绪，（2）仅使用一次，（3）不用，那么我不会在乎（过分）好的设计。由系统的其他部分（YAGNI）使用。

当组件（1）会被多次使用并且会在产品的几种不同版本中使用时，我确实会在乎良好的设计；（2）需要维护并随着时间的流逝而扩展；（3）取决于它，还有很多其他组件。

另一方面，以较小的增量开发一些复杂的功能，每天提交并在非结构化代码时不断重新思考代码，这使我无法产生真正好的设计。

那不要那样做

并非所有内容都适合漂亮的敏捷框。通常情况下，产品会包含一些复杂的东西，这些东西无法耕种给个人，并且无法在冲刺中以任何理智的方式完成。强迫他们进入那个盒子只会造成麻烦。但是这些之间应该是很少的。如果您发现许多组件都是这样的，那么您的产品负责人就需要更好地分解（与您的团队合作）。我做得很好，就像您所做的一样：编写故事，设计故事，然后尽快将其付诸实践，期望会花费几周的时间。

在更一般的情况下，为了在Agile中获得良好的设计，我完成了三件事：

• 实际进行设计 -我见过的很多地方都开始了冲刺，只是开始编写代码。这样您将获得糟糕的设计。敏捷不会改变计划-代码-测试-发布的开发过程，只是将其缩短为更精细的部分。在冲刺开始时，根据需要坐下来，然后实际设计解决方案。

• 拥有一名架构师/负责人 -一旦您的项目足够大，您最终将需要多个Scrum团队来处理应用程序的不同部分。让某个人（或多个人，取决于应用程序的大小）的主要工作是从设计的角度了解所有团队的工作，这非常有用。他们可以回答问题，并指导团队进行更和谐的总体设计。我也已经看到，让每个Scrum团队都有一个领导，知道其他团队的大部分工作，并且非常有效。

• 成为实用主义者 -我已经在上面提到了这一点。敏捷是一种工具，就像任何其他工具一样；它并不适用于所有问题。如果没有必要将其应用于某个组件，则不要将其应用于该组件。您的目标是交付良好的软件。不要忘记它。

以很小的增量实现并最终得到结构良好的可维护代码是很有可能的。从理论上讲，这非常简单：如果您确保每次更改后代码的结构正确，那么它将始终保持结构良好。您的代码结构变得很糟糕，因为您应该在重构时继续添加代码。

无论您花多少时间进行设计，最终需求都会以某种无法预料的方式发生变化，并且您将不得不编写与原始设计不符的代码。然后，您将不得不进行增量更改。如果您有一套很好的单元测试，并且精通重构，那么您可以在满足新要求的同时保持结构良好的代码。

“精心设计”是主观的

什么是“精心设计的”对你意味着什么？给产品负责人？给客户？

是“精心设计 ”的产品拥有者的目标是什么？客户的目标？还是只是你？

请问是什么原因，你认为“没有设计好”仍满足产品负责人的期望，使顾客高兴的？那是相当“精心设计的”。

足够好，YAGNI

在大多数敏捷方法论中，没有什么是“精心设计的”，因为产品负责人认为故事是完整的，并且客户认为满足其要求的任何系统都是“精心设计的”。

据预计，开发商是专业人士，将务实地采用最佳做法，适当的设计和成语来实现的功能和故事。

如果您没有考虑到正确的时间做开发人员的问题，如果产品负责人在更短的时间内要求完成这些事情，那么这样做是他们的特权，并且您有责任对他们进行教育。技术债务故事形式的后果。

SCRUM

_{可以写下的敏捷方法论不是敏捷方法论。”-Jarrod Roberson}

SCRUM被认为是管理软件产品总生命周期的工具框架。它不应该是一成不变的事情，而只是一个开始并希望有所改进的好地方。

我工作过的大多数商店都有所谓的Sprint ZERO，即Sprints，用于团队的高级成员草拟产品的总体架构或主题。

大于20的故事通常会被分解，直到实际上只有3-5点的故事为止。其中一个故事是：“作为一个团队，我们需要开会讨论我们将如何设计此功能，以便在分配的时间范围内，我们将承担尽可能少的技术债务。”

通常

总的来说，“精心设计”的系统足够好，并且遵循YAGNI。

敏捷，尤其是SCRUM作为敏捷的实现，更多地是关于如何对产品所有者/赞助商透明地生产产品。

这与技术设计/架构无关。它是关于如何交付满足客户需求和期望的软件的一种哲学。如果没有所谓的“设计精良”的零件，那么这本身并不是失败，因为它不是哲学的基本组成部分。

我们已经与Scrum合作了几个月，我想分享一下有关您的问题的经验。

几个月前，我得到了很大的实施空间。我已经准备好所有规范，因此必须相应地实现新功能。任务大约需要5-6周（据我估计）。我花了第一周的时间只从事设计。任务有点复杂：正如我从规范中得出的那样，有一个主要对象具有15个不同的状态，UI对于每个状态都具有不同的行为。

我设计了整个工作流程，然后设计了数据库结构和类。

我的情况没有其他方法。如果我立即投入编码，那么最终我将陷入一团糟-几乎无法维护，并且极难进行任何进一步的更改。但是更改是在接下来的2周内完成的，因此我不得不重新编写代码。通过最初的深思熟虑的设计，现在这很容易。这节省了我们的时间，金钱和神经。

经过这一经验，我绝对确定在开始时就值得做一个可接受的设计，而不是希望奇迹般地在最后得到它。

后视是20-20。如果您在项目开始时就掌握了信息，可以弄清整个过程，然后在几周内编写代码，那么建议您这样做。

您没有对获得的所有见解，尝试过的和失败的/必须改变的方法以及客户/用户提供需求的能力增加给予足够的信任。

为什么任何拥有成功的瀑布项目历史的人都转向敏捷方法？

在开始项目之前，您始终需要了解最终目标应该是什么，打算实现什么功能以及何时实现。将故事作为原子任务进行工作会带来麻烦。您需要牢记未来的需求。