project-management - 功能需求的用户故事

Question

关闭。这个问题是off-topic .它目前不接受答案。












想改进这个问题？ Update the question所以它是on-topic对于堆栈溢出。

9年前关闭。




Improve this question




由于我们是一家小公司，我既是项目经理又是开发人员。我为客户创建的规范包含许多用于描述和定义项目的元素，包括用户故事以及我认为需要包含的任何其他元素以向客户定义项目(例如线框、用户流、站点地图等)。

如果功能规范“完全从用户的角度描述产品将如何工作。它不关心事情是如何实现的。它谈论功能。“。那么有没有人认为使用用户故事来定义网站的功能规范有什么问题呢？真的有人用这种方式做功能规范吗？

真的，我正在尝试提高我的游戏水平，并且想知道这种方法是否适用于可能对功能规范应该包含的内容有更严格想法的大客户，因此可能需要正式的方法。目前，我们的客户肯定对我们制作文档的方法 react 良好。

我很想听听专业从事项目管理的人对此有何看法。

Answer 1

我与其他几个人所说的不一致。

首先是我同意的一点——故事是陈述功能需求的好方法。就我而言，它们是以最终用户真正接受的方式实际传达需求的最佳方式之一。我见过太多的规范在没有被阅读的情况下就被签署了。

我想说的你可能想要附加到它们的一件事是非功能性需求——包括性能、安全性、数据量、审计、归档等等。虽然它们可以被故事覆盖，但有时它们最好以跨越所有故事的方式进行覆盖。

至于它是否适合大公司，这是我不同意的地方。根据我的经验(我曾为壳牌、美国运通、几家跨国银行和其他银行做过项目)，他们通常不比小公司更正式，所以他们会接受故事。现实情况是，大公司的用户在阅读类和序列图方面并不比在其他地方更好(或感兴趣)。

项目的规模和复杂性可能需要更详细的要求，但在确定如何记录要求时，重要的是项目的规模，而不是公司的规模。

对我来说，最好的需求文档是适合其受众的文档，对我来说，用户故事大部分时间都一针见血——它们足够短且足够清晰，以至于当他们签署它们时，它们意味着什么，因为它们已经阅读并理解了它们(与签署 100 页规范相反，这总是意味着他们还没有真正阅读过)，但也足以让开发人员从中工作。