我们即将开始一个新项目，我们公司希望采用敏捷的方法来处理业务分析师编写用户故事的方法，并且我们应该能够使用BDD来充实我们的代码。
然而，业务分析师一直非常模糊，并且提供的用户故事涵盖了某些功能必须完成的一半。
由于有太多的区域有点“灰色”，开发人员是否应该与他坐在一起并确保所有区域都被覆盖？
我认为，从敏捷的角度来看，业务分析师无法涵盖所有用户故事，但我担心的是我们将开始开发代码，而不是所有用户故事都被覆盖到最后。此外，我们可以让几个开发人员成为业务分析师在某些功能领域的专家，而没有整体设计师/分析师将这些领域整合在一起，以确保它们都能正常工作。
另一种方法是让具有建筑师角色的人通过DDD充实整体设计。但这仍然涉及到所有用户故事。
那么最好的方法是什么？
答案 0 :(得分：4)
您不一定非常需要所有用户故事。您可能希望这样做的主要原因是确定项目需要多长时间并获得稍微更好的准确性。还有其他方式可以吸引利益相关者的信任。
试试这个。要求BA考虑系统需要提供的所有功能 - 系统将使用户或公司能够做的所有事情。作为指导，我们在一年的项目中有大约30个，它们是单个单词或首字母缩略词。
其中一些将非常容易理解，并且与其他类似项目相同。其他人将是新的，或者你会对他们一无所知。这是接受BA帮助的好地方。
如果广管局不能提供足够的帮助，请尽快提供这些有风险的事情，并尽可能多地获得反馈。如果广管局无法帮助您提供反馈，那么您需要得到更直接参与的利益相关方的帮助。
答案 1 :(得分：1)
由于有太多的区域有点“灰色”，应该是 开发人员和他坐在一起，确保所有区域都被覆盖？
当然，你怎么知道要建造什么？猜测每个人花费时间和金钱，实际上不可能100％正确。
我会说回到白板并尝试就管理层可以期待的第一个版本的所有功能达成一致。
BDD / TDD / DDD对此问题没有灵丹妙药，但它可以为开发人员和业务分析师提供灵感。当你想要传达你的应用程序现在可以做什么时，BDD真的很棒。