功能需求的用户故事

Question

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

如果功能规范“描述了产品如何完全从用户的角度运作。它并不关心事物是如何实现的。它讨论了特征。“那么有没有人看到使用用户故事定义网站的功能规范有任何问题？有没有人真的以这种方式做功能规范？

我真的想尝试一下我的游戏，并想知道这种方法是否适用于那些对功能规范应该包含哪些内容更为严格的大客户，因此可能需要采用正式的方法。目前我们的客户肯定对我们制作文档的方法反应良好。

我很想听听项目管理专业人士对此的看法。

Answer 1

我和其他几个人所说的不一样。

首先，我同意这一点 - 故事是陈述功能要求的好方法。对于我的钱，他们是以最终用户真正接受的方式实际沟通需求的最佳方式之一。我看到太多的规格在没有被阅读的情况下被签署。

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

就适用于大公司而言，这是我不同意的地方。根据我的经验（我已经为壳牌，美国运通，几家跨国银行和其他公司做过项目），他们通常不会比小公司更正式，所以他们会对故事很好。现实情况是，大型公司的用户在阅读课程和序列图方面没有比其他地方更好的装备（或感兴趣）。

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

对我而言，最好的要求文档是适合其受众的文档，对我来说，大多数时候用户的故事都很突破 - 它们足够短且足够清晰，当它们签署时它们意味着什么因为他们已经阅读并理解了它们（与100页规范的签名相反，这总是意味着他们还没有真正阅读它），但对于开发人员来说也足够好了。

Answer 2

是的，您可以根据功能需求使用用户故事。我一直这样做，已经多年了。在我看来，它的效果非常好，并且比我使用的其他系统更好。

这种方法适用于大客户吗？总而言之，没有。他们将有一些用于定义需求的系统，可能不是用户故事。如果您收到用户故事，那么您将不得不解决当前的做法。

我成功地使用了大型组织的用户故事，但需要共同努力，双方都需要承诺。

Answer 3

您所描述的是定义功能的用例场景，这是从可用性角度所需要的，并且正是客户理解并同意的内容。屏幕模型和流程图肯定会帮助客户和开发人员。

然后可能需要一个实现规范来指示开发人员需要包含在实际构造中的内容，其深度将由您的开发人员能力决定，包括他们对房屋架构/框架和方法/惯例的了解。可能包括影响申请各部分的具体内容。

我们也在小团队（有时是一两个开发人员）工作，并且相信上述内容就是这个例子中所需要的。

拥有更大团队的大公司可能会使用建模软件，UML图表和其他更详细的规范。在您是主要开发人员的情况下，您仍然应该花时间设计您的应用程序，但如果没有人会审查设计并坚持所有手续，那么您花在实施软件上的时间会更长。