已完成的用户故事-放弃?档案文件?[关闭]

将它们存档以供将来项目参考。当你需要估计故事点时,它们会很有用。通常情况下,项目之间也会发生类似的故事。

嗯-把它们放在项目文件里。在任何情况下都是Cya。你永远不知道客户什么时候会回来问你“为什么会这样?”或者“是谁决定的?”。然后,您可以提取用户案例并进行备份。

在您的软件的保修期到期之前,请始终保持这样的状态…除非你想被安排到一个可以让你“修理”一些真正免费改变的地方。

垃圾桶似乎是个合适的地方。

佩兹几乎是对的。回收卡片,而不是将其丢弃。:)

真的没有保留它们的意义。如果需要更改的历史记录,可以从配置管理和测试脚本中获取。

再投一张保留票。我知道这是一个脏话,但是用户故事是您文档的一部分,并且具有重要的用途。

三年后,当你(或继承人)正在对系统进行更改时,让历史文档知道你为什么会这样做是很有帮助的。

当情况发生变化时,您必须重写,以便能够返回应用程序满足的用户情景,并确定这些相同的情景是否适用于新版本,这也会有所帮助。

我通常用橡皮筋和前面的一张新卡片包装每一个用户故事(和任务)的迭代,说明速度和估计点。不过,除了怀旧,我从来没有用过它们。所以把它们保存起来,我会说-9

抓住他们!

我编写需求(而不是代码),但我经常发现自己在重读旧的用户故事和验收测试(我的和其他人的)。

回顾过去的故事可以帮助我为复杂的概念找到最清晰的措辞,而不是重新设计轮子。它们有时作为有用的提醒,提醒我可能忘记记录的细节。其他人写的故事可以帮助我快速了解我不参与的功能,并且可能是新员工的一个很好的学习工具。

我可以继续说下去,但让我这样说:
哪一个更有可能导致更大的问题——保留故事而不需要它们,或者需要故事而不拥有它们?

保存它们(存档),这样如果将来有关于某件事的争议或争论,你就可以参考它,并且可以覆盖你自己。

完成的用户故事基本上是项目的最终规范。如果您从一个正式的需求文档或规范开始,那么通过将已完成的用户案例与该文档进行比较,可以学到很多经验。如果您没有初始文档,那么您完成的用户故事将记录项目的功能。在这两种情况下,我认为无论是在项目事后分析中,还是在评估和规划后续项目时,坚持这些方法以供将来参考都是非常有价值的。

我发现我们永远不知道将来什么会有用,所以我的建议是标记它们并将它们归档。如果你使用的是物理卡,扫描它们,然后做一些简单的事情,比如在图像文件中添加一个标签。想象一下,稍后查看标签云以查找公共线程或查找和重用您的内容。

就像所有的事情一样,Scrum,但是,如果它开始花费太多的时间,它可能不值得你的努力。不要让它成为一个疯狂的过程,只需快速归档并忘记它。

干杯, 李维斯