SBE 规范应该有多完整？

Question

我正在处理一个相当大的现有代码库，其中创建了 SBE 规范来定义产品的行为。

目前大约有 450 个场景，而且随着代码库中添加的每个新功能，这个数字还在增长。

与传统的单行需求陈述相比，由于 SBE 规范的冗长性质，很难对系统的功能有高度的了解。例如，这些故事目前共有 46,830 个单词：

$ find src/main/resources/stories/ -name *.story | xargs cat | wc -w
   46830

另一个问题是我们正在使用gerrit code review 工具来协作处理故事，这导致团队之间出现formalized communication。

问题 1：SBE 是否应该是一个完整而全面的回归测试套件 (example)？或者，他们是否应该只关注每个 sprint 所需的关键功能？

问题 2：如答案 here 中所述，是否需要问题跟踪器等工具来管理大型项目的故事？

Answer 1

通常验收测试和行为测试侧重于确保交付价值，因为它们本身就是一种黑盒测试。

所以对于 1. 答案是否定的，它们不应该是完整的。他们应该确保产生价值的外部行为不会倒退。

关于 2. 我会避免使用此类工具，因为查询它们以获取基于时间的信息非常困难：通常像 Rally 或第一版这样的敏捷工具能够制作燃尽图，为您提供每日燃尽图和速度图表.使用错误跟踪器进行跟踪，使用敏捷工具实现敏捷！