architecture - 敏捷解决方案设计

标签 architecture agile software-design

<分区>

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

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

史诗是“登录和注册”。 我们目前正在研究注册,其中包含许多用户故事。

我被要求按照用户故事设计解决方案的方式,因此一旦完成用户故事的解决方案设计,我团队中的其他开发人员就可以实现它。

我的问题是,如果您不展望整个旅程,就很难做出好的设计。另外,当我在设计每个用户故事时,我发现以前的用户故事的设计存在一大堆问题,不得不等待产品负责人回答问题。

我所做的设计并没有深入细节,它们只是用来让我们知道哪个应用层在做什么...更精细的实现细节主要留给开发人员。

我的问题是 - 敏捷解决方案设计的正确方法是什么?应该根据用户故事进行迭代改进设计……还是针对整个注册流程设计解决方案,然后在整个旅程中进行迭代改进设计,然后我们继续?

最佳答案

让我们考虑两种极端的方法。您可以预先完成所有设计,也可以逐个故事地进行设计。

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

通过预先设计,您可以考虑全局,并有可能提出一种比一次完成一项要求更有效的设计。然而,预先设计有时会导致对更改的抵制:“我们不能添加新要求,因为它不适合设计”。这也可能意味着团队没有实践过快速更改设计以响应需求变化。

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

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

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

关于architecture - 敏捷解决方案设计,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/34413735/

相关文章:

asp.net-mvc - EF 代码优先模块化设计

.net - 说服管理层使用 WCF

从前端开发人员角度看敏捷开发

Java 匿名类作为实用函数?设计实际使用的参数,或一个参数(较大的对象)

http - "service injection"是否有软件工程概念/模式?

javascript - 举起,玩耍!或 BlueEyes(带有一堆 Javascript 框架)

c# - 用于构建应用程序的 "Main Form"想法的其他替代方案

agile - 什么样的敏捷实践适合小团队?

jira - JQL 检索与特定史诗相关的所有故事和子任务

java - 关于工厂方法模式的澄清