敏捷解决方案设计


3

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

作为首席开发人员,我负责为我的团队正在开发的Epic设计解决方案。

史诗是“登录和注册”。 我们目前正在开展注册,其中有许多用户故事。

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

我的问题是,当你没有在整个旅程中展望时,很难做出好的设计。另外,当我设计每个用户故事时,我发现以前用户故事的设计存在一大堆问题,必须等待产品负责人回答问题。我正在做的设计并没有深入细节,只是为了让我们知道哪个应用程序层正在做什么...更细致的实现细节大部分留给了开发人员。

我的问题是 - 敏捷中解决方案设计的正确选择是什么?是否应该按照用户故事,通过改进设计的迭代......或者它是整个注册过程的解决方案设计,并且为整个旅程进行改进设计的迭代,我们会继续?

  0

我知道你的意思。在一个团队中,我们以“敏捷的方式”工作 - “只关注当前的故事”,没有展望。我们被咬坏了。 16 1月. 162016-01-16 21:36:08

0

我们必须牢记,严格来说,您只需要设计下一步冲刺中将要完成的工作(最多几个)。因此,您可以制作清晰的故事,并等待稍后定义其他故事。如果你在开始的时候定义所有的不是SCRUM,它是每日站立的瀑布。

因此,正确的方法应该定义所需的细节(在PO的帮助下)一次冲刺。用户故事中的不确定性往往不够好,会产生额外的工作量。

希望它有帮助

+1

我在这篇appoarch中遇到的问题是,当我有4条用户故事时,我们意识到以前故事中做出的决定现在没有任何意义,我们必须重新设计并重写所有以前的用户故事。 22 12月. 152015-12-22 14:34:16


1

让我们来思考两种极端的方法。你可以预先设计所有的设计,或者你可以在故事的基础上进行设计。

这两种方法都有优点和缺点。在极限编程(XP)方法论中,他们确实以及时的方式进行设计。使用XP时,您可以更好地满足需求变化,因为您的方法旨在快速改变方向。但是,XP可能会花费大量时间进行重构。

借助前期设计,您可以考虑全局,并可能提出一种比一次完成要求更有效的设计。然而,前期设计有时会导致变革的阻力:“我们不能添加新的要求,因为它不适合设计”。这也可能意味着团队不会根据需求变化进行快速设计更改。

Scrum团队通常在这两个极端之间的某处工作。他们试图找到应对变化和有效设计之间的平衡点。在决定您的方法时,需要考虑多种因素:

  • 您的需求多久改变一次?
  • 你有多少技术风险?
  • 是否有像监管或合规性的外部因素?

我认为最好的方法是生成一个体面的设计(但不是最好的设计),也允许团队快速适应不断变化的需求。


1

敏捷用户会建议调整敏捷并将它们用作值而不是授权,但是当您仍然认为它不起作用时,他们会说您没有正确执行敏捷操作。碎片化的设计是敏捷的持续风险,因为架构没有价值。我们需要的是一种使用敏捷的有利方面的方法,例如持续交付。权力的游戏方法论只是这样做的:http://digitalanimal.com/blog/slaying-the-agile-dragon-the-game-of-thrones-methodology/?AT=yf6b32