... 以及如何向管理层证明用例可以是非正式的并且仍然有用？
嗨伙计，
我来到一个项目的中间，发现没有用例、用户故事、需求，也没有任何类似于规范的东西。由于截止日期很短，目前的开发团队不想花时间在这些事情上。我想加入那个项目，但通过挖掘更多，我发现当前的开发只是通过考虑它们的“哇效应”来添加功能，并通过使用底层技术提供的易用性来选择添加什么。我很惊讶他们是如何在没有要求的情况下做到这么远（超过 4 个月）的，但这就是我们现在所拥有的。我相信他们选择的方式是最有把握扼杀具有良好营销价值的产品的方式。
我是对的，在类似的情况下，你会做什么来证明开发团队/管理层在继续前进之前制定用例/要求？在此先感谢，kh。
PS 两本 Cockburn 的书在书架上……
你应该给你的同事用例说明：D 告诉他们用例很有用，因为它们是：
如果您需要更多弹药，您可能需要阅读Ivar Jacobson 的用例 - 昨天、今天和明天。
如果您的同事仍然看不到用例作为业务分析工具的潜在用途，那么他们可能已经无能为力了：P 您应该提醒他们，他们正在开发软件以满足其他人的需求并解决他们在从长远来看，不要在短期内用小噱头来炫耀地打动他们。因此，一些方向和规范会有所帮助。即使用例本身没有被证明是有用的，提出它们的简单行为也会迫使您的同事考虑软件的实际潜在目的。
向双方提出问题。在开发方面，询问他们是否确定他们考虑使用应用程序的所有方式都是最终用户想要使用它的所有方式；如果他们说有，请索取证据。在管理方面，询问他们是否曾经使用过能够满足他们所有需求的软件，但最终仍然难以使用（他们将拥有）。这些问题将使双方产生这样一种观念，即交付的东西可能不是双方想要的。然后，利用这个想法的种子，就如何使用软件以及如何解决任何差异展开讨论（不是文档，不是一开始）。他们最终会处理用例文档。
我的职业是产品经理，我对你的帖子的第一反应是想法可以来自任何地方，如果开发团队有不错的想法，他们应该被纳入产品中。
话虽如此，一个产品不能通过一系列不符合最终目的的不连贯的想法来发展灵魂（简单的信息）：解决目标用户的需求。而且，最终归结为让时间更好地花在对产品有意义的需求/用例上，而没有明确的战略/最终目标的机会成本将导致太多的厨师和厌倦的产品信息。
让这个信息深入人心的最终方法是让其他利益相关者参与进来，并让开发展示他们的工作。最终，会有分歧，更正式（更少牛仔）的方法将导致更精致和简单的产品。
您提到的问题之一是开发人员自己引起的紧迫的时间表和范围蔓延。向他们解释，通过使用用例，您可以通过放弃功能来赢得时间，这些功能最终可能会被“从未使用”过。通过用例，您可以了解客户需要哪些功能并且愿意付费，并通过将不重要的功能从您有时间实施的范围中删除。除了定义范围之外，用例还有助于识别所有利益相关者，这可能有助于您在定义范围时更好地集中注意力并防止忘记琐碎的事情，这些事情并不那么明显，但如果产品应该可用，这是必须的.
只是给他们看。
榜样不是教育人的最好方法，它是唯一的一种。
以身作则，专注于扩展和例外。换句话说，强调失败场景，因为每个人都知道系统应该如何工作。书面用例的真正价值在于确定出现问题时应该发生什么。
值得注意的是，考虑到您可能不得不在没有书面用例的情况下生活。而且，对于您描述的环境，一个主要的胜利是任何类型的需求文档。屏幕组合和/或原型设计通常更容易引入。