敏捷解决方案设计

Question

我工作的公司刚刚开始在我正在从事的一个大型项目中使用敏捷(Scrum)。

作为首席开发人员，我的任务是为我的团队正在开发的Epic设计解决方案。

史诗是“登录和注册”。我们目前正在开发注册，它有许多用户故事。

我被要求做我的解决方案设计的方式是每个用户故事，这样一旦用户故事的解决方案设计完成，我团队中的其他开发人员就可以实现它。

我的问题是，当你不着眼于整个旅程时，做一个好的设计真的很难。另外，当我设计每个用户故事时，我发现前一个用户故事的设计有一大堆问题，不得不等待产品所有者回答问题。

我正在做的设计并不深入细节，它们只是用来让我们知道哪个应用层在做什么……更详细的实现细节主要留给开发人员。

我的问题是-在敏捷中解决方案设计的正确方法是什么？它是否应该是每个用户的故事，具有改进设计的迭代...或者它是整个注册过程的解决方案设计，整个过程的改进设计的迭代，我们会继续下去吗？

Answer 1

让我们考虑两种极端的方法。你可以预先做好所有的设计，也可以一个故事一个故事地设计。

这两种方法各有优缺点。在极限编程(XP)方法中，他们以即时方式进行设计。在使用XP时，您可以更好地为需求变化做好准备，因为您的方法旨在快速改变方向。然而，对于XP，重构可能会花费大量的时间。

使用预先设计，您可以考虑全局，并潜在地提出一个比一次完成一个需求更有效的设计。然而，预先设计有时会导致对更改的抵触：“我们不能添加新需求，因为它不适合设计”。这也可能意味着团队在快速设计更改以响应需求更改方面缺乏实践经验。

Scrum团队通常在这两个极端之间运行。他们试图在响应变化和高效设计之间找到平衡。在决定您的方法时，有许多因素需要考虑：

• 您的需求多久更改一次？
• 您有多大的技术风险？
• 是否存在法规或合规性等外部因素？

我认为，最好的方法是产生一个像样的设计(但不是最好的设计)，并允许团队快速适应不断变化的需求。

Answer 2

敏捷用户会建议调整敏捷，并将其作为价值观而不是强制要求，但当你仍然认为它不起作用时，他们会说你没有正确地做敏捷。零散的设计对于敏捷来说是一个持续的风险，因为它在架构上没有价值。所需要的是一种使用敏捷优势方面的方法论，例如持续交付。“权力的游戏”方法论就是这么做的：http://digitalanimal.com/blog/slaying-the-agile-dragon-the-game-of-thrones-methodology/?AT=yf6b32

Answer 3

我们需要记住这一点，严格来说，你只需要设计下一次冲刺(最多几次)要做的事情。因此，您可以让故事变得清晰，并等待稍后定义其他故事。如果你一开始就定义了一切，那就不是SCRUM，而是日常站立的瀑布。

因此，正确的方法应该定义为所需的细节(在PO的帮助下)，一次冲刺。用户故事中的不定义将导致不够好的工作，并将产生额外的工作。

希望能有所帮助