【问题标题】:How to get correct user stories in BDD? [closed]如何在 BDD 中获取正确的用户故事? [关闭]
【发布时间】:2011-11-22 00:50:19
【问题描述】:

我们即将开始一个新项目,我们公司希望采用敏捷方法,即业务分析师编写用户故事的地方,并且我们应该能够执行 BDD 来充实我们的代码。

但是,业务分析师非常含糊,给出的用户故事涵盖了某些功能必须完成的一半。

既然有这么多区域有点“灰色”,开发者是否应该和他坐在一起,确保所有区域都被覆盖?

我想从敏捷的角度来看,业务分析师无法涵盖所有​​用户故事,但我担心的是我们将开始开发代码,并且直到最后都不会涵盖所有用户故事。此外,我们可以让多名开发人员与业务分析师一起成为某些功能领域的专家,而没有整体设计师/分析师将这些领域整合在一起以确保它们都能正常工作。

另一种方法是找一个担任架构师角色的人,并通过 DDD 充实整体设计。但这仍然需要拥有所有用户故事。

那么最好的方法是什么?

【问题讨论】:

  • 伙计们,这应该被迁移而不是完全关闭。 programmers.stackoverflow.com 完全适合这个。
  • JD,非常非常抱歉。我曾预计这个问题会被迁移到programmers.stackoverflow.com,而不是完全关闭 - 这是IMO一个非常好的问题,只是在不同的地方更好地访问。相应地提出了元数据:meta.stackexchange.com/questions/113295/…
  • 虽然这个问题获得的普通“离题”投票多于迁移投票,但随时欢迎您在Programmers.SE 上转发您的问题

标签: architecture domain-driven-design bdd


【解决方案1】:

您不一定需要预先了解所有用户故事。您可能想要这样做的主要原因是确定项目需要多长时间并获得稍微更好的准确性。还有其他方法可以赢得利益相关者的信任。

试试这个。让 BA 考虑系统需要提供的所有功能 - 系统将使用户或公司能够做的所有事情。作为指导,在一个为期 1 年的项目中,我们有大约 30 个这样的词,它们是单个单词或首字母缩略词。

其中一些非常容易理解,并且与其他类似的项目相同。其他人将是新的,或者你会对他们一无所知。这是获得 BA 帮助的好地方。

如果 BA 无法提供足够的帮助,请尽快交付这些有风险的东西,并尽可能频繁地获得反馈。如果 BA 无法帮助您提供反馈,那么您需要更直接参与的利益相关者的帮助。

【讨论】:

  • 感谢 Lunivore。还有一个问题,我们应该为每一项功能分配不同的开发人员,还是应该让一个人参与其中,然后才能充实领域模型?一旦他完成了这项工作,我们就可以将工作分配给其他开发人员。
  • 我倾向于让团队与领域专家一起在墙上建立一个带有卡片、字符串和蓝钉的领域模型。然后谁先接触到该域的一部分,就可以对其进行编码。提前充实域模型通常会导致域模型易于编写而不是易于使用或理解,IMO。如果您想在其他开发人员加入之前完成一件事情,请先编写“快乐路径”场景;这将为其他人提供一个可以工作的骨架。
  • 非常感谢您的建议 :)
【解决方案2】:

既然有这么多地方有点“灰色”,应该 开发人员和他坐在一起,确保所有区域都被覆盖?

当然,你怎么知道要构建什么?猜测会花费每个人的时间和金钱,而且几乎不可能 100% 正确。

我想说回到白板并尝试就第一个版本的所有功能管理达成一致。

BDD/TDD/DDD 并不是解决这个问题的灵丹妙药,但是,它可以给开发人员和业务分析师带来灵感。当您想要传达您的应用程序现在可以做什么时,BDD 真的很出色。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2013-10-28
    • 1970-01-01
    • 1970-01-01
    • 2010-12-15
    • 1970-01-01
    • 1970-01-01
    • 2013-10-28
    • 1970-01-01
    相关资源
    最近更新 更多