功能需求的用户故事

Question

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

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

真的，我试图提升自己的游戏的一点点，并且想知道这样做是否适用于大型客户，他们可能对功能规范应包含更严格的想法，因此可能需要正式的方法。当然，我们的客户对我们的文档制作方法有很好的反应。

我有兴趣听取项目管理专业人员对此的看法。

Answer 1

我与其他一些人说过的话不一致。

首先，我认同 - 故事是阐述功能需求的好方法。对于我的钱来说，他们是实际沟通需求的最佳方式之一，最终用户将会真正接受。我已经看到太多的规格说明，但没有被阅读过。

我想说的你可能想追加的一件事是非功能性需求 - 包括性能，安全性，数据量，审计，归档等。虽然他们可以用故事来报道，但有时他们可以更好地覆盖所有故事。

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

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

对我来说，最好的需求文档就是适合它的读者的文档，对我而言，用户的故事大多数时间都是头疼的 - 它们足够短并且足够清晰，当它们签名时它们意味着因为他们已经阅读并理解它们（而不是签署100页的规范，这总是意味着他们没有真正阅读它），但对于开发人员来说也是足够好的。

Answer 2

是的，您可以使用用户故事来满足您的功能需求。我一直这样做，并且已经有很多年了。在我看来，它工作得很好，比我用过的其他系统更好。

此方法适用于大客户吗？为了总体概括，没有。他们将有一些用于定义需求的系统，可能不是用户故事。如果您使用用户故事，将会与目前的做法脱节，您将不得不努力。

我已经成功地在大型组织中使用用户故事，但需要双方共同努力，双方需要致力于此。

Answer 3

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

然后可能需要一个实现规范来指导开发人员需要包含在实际构建中的什么，深度取决于开发人员的能力，包括他们对房屋结构/框架和方法/惯例的知识并可能包含对应用程序的各个部分有何影响的具体内容。

我们也在小团队（有时是一个或两个开发人员）工作，并认为以上是在这种情况下所需要的。

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