Project management 功能需求的用户故事

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

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

事实上，我正在尝试改进我的游戏，我想知道这种方法是否适用于那些对功能规范应该包含什么有更严格想法的大客户，因此可能需要一种正式的方法。目前，我们的客户肯定对我们制作文档的方法反应良好

---

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

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

这种方法适用于更大的客户吗？总体来说，不适用。他们将有一些用于定义需求的系统，很可能不是用户情景。如果你有用户情景，就会与当前的实践脱节，你将不得不进行处理

---

我在大型组织中成功地使用了用户案例，但这需要双方共同努力。您所描述的是定义功能的用例场景，这是从可用性角度所需要的，也是客户将理解和同意的。Scr即使是实体模型和流程图也肯定会对客户和开发人员都有帮助

然后可能需要一份实施规范来指导开发人员实际施工中需要包括哪些内容，其深度将由您的开发人员的能力决定，其中包括他们对房屋架构/框架和方法/惯例的知识，并可能包括关于各种影响的细节部分应用程序

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

---

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

我不同意其他几个人所说的话

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

我想说的一件事是，您可能希望附加到它们之上的是非功能性需求—包括性能、安全性、数据量、审计、归档等。虽然它们可以在故事中涵盖，但有时最好以跨所有故事的方式来涵盖

就是否适合大公司而言，这是我不同意的地方。根据我的经验（我曾为壳牌、美国运通、几家跨国银行和其他公司做过项目）他们通常不比小公司正式，所以他们对故事没什么意见。事实上，大公司的用户在阅读类图和序列图方面并不比其他地方的用户更有能力（或兴趣）

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

---

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

谢谢你的回答——这非常有帮助——我同意你的所有观点。所有有趣的评论。然而，即使是发明敏捷的人也同意“用户故事”！=“用例”或者功能需求。也就是说，我不知道……20年后，我仍然不知道如何正确实现用户故事“学生必须能够购买停车通行证”。除了1-2句话的故事外，功能需求中还有很多细节。因此，提交内容可能是通过未经验证的学生的伪造电子邮件，系统将向其颁发停车证？我敢说，用户故事根本不是“可操作的需求”。