我开始创建我们的敏捷板，并且遵循创建用户案例的敏捷最佳实践
作为[角色]，我想[做某事]，以便[某事发生]
根据最佳做法，故事也应该足够小以适合一次迭代，也就是说我们的冲刺周期很短（1周），故事如下：
作为一名代理商，我想查看贷款申请的历史更改 我正在努力，以便能够审核应用程序
这个故事至少需要
如何进一步打破这些类型的故事，但仍然关注“用户”。
答案 0 :(得分：0)
尝试思考一个提供一些价值的故事。诀窍在于，它的价值可能很小，但仍然是有效的故事。
例如：
作为一名代理商，我想列出对贷款申请的所有更改，以便我可以审核申请
可以将其实现为存储过程或简单的数据库查询，该查询将返回贷款申请的所有更改的列表。
它并不是特别有用，但是它是一个有效的故事，因为从理论上讲，代理可以将数据输入电子表格并对其进行操作，或者按照这些方式进行操作。您不希望这是最终的解决方案，但是它确实带来了很小的价值（比完全没有代理的Agent更好）。
这个故事较小，使您更接近所需的全部功能。
下一个故事可能类似于：
作为一名代理商，我想列出特定贷款申请的所有变更，以便我可以审核申请
现在，您正在修改数据库查询，以使其接受特定贷款申请的输入。
再一次，它不是特别有用，但是它确实可以提供价值，并使您更接近最终目标。
之后，您可以添加一个需要简单UI的故事。
像这样继续前进，提供的解决方案并不完美，但可以使您更接近最终解决方案。您只需要使故事足够小以适合您的冲刺，因此您就不必为此烦恼了。
一开始这样做可能有点人为。但是您很快就习惯了它，它为您提供了很大的机会，可以随时添加自动化测试。
答案 1 :(得分：-2)
这实际上归结为有效的迭代，增量和自适应方法来编写代码。确切的方法是非常有条件的，但是作为示例，此用户故事实际上只需要保留一些记录，将其链接到应用程序并显示它们的列表。严格来说，这并不需要数据库，但是即使是这样，一个带有应用程序ID和文本字段的简单表也可以存储更改信息，对于这个故事来说，这项工作可能还不错。显示可能不是很多工作。作为开发人员，我最担心的风险是要记录什么。在那里，我可能会根据记录的内容来分解故事。也许一开始我只是记录有人进行了更改，从审核的角度来看，这无疑增加了价值。从那里开始，我们可能会有更多的故事来跟踪更多信息，进行不同的搜索等。这可能涉及对UI和数据库设计的更改，但是能够以较低的开销有效地进行这些更改是在Microsoft中开发软件的关键部分。敏捷的方式。