如何向同事证明用例很重要？

Question

... 以及如何向管理层证明用例可以是非正式的还是有用的？

嗨大家好，

我进入了一个项目的中间，发现没有用例，用户故事，要求，也没有任何类似于规范的东西。由于截止日期很短，目前的开发团队不想花时间在这些事情上。我想加入这个项目，但是通过挖掘更多我发现当前的开发只是通过考虑它们的“哇哇效应”来增加功能，并通过使用底层技术提供的简单性来选择添加什么。我很惊讶他们如何设法到目前为止（超过4个月）没有要求，但这就是我们现在拥有的。我相信他们所选择的方式是最有把握的产品，具有良好的营销价值。

我是对的，在类似情况下你会做些什么来证明开发团队/管理层在前进之前制定用例/要求？先谢谢你，

P.S。书架上有两本Cockburn的书......

Answer 1

你应该向你的同事提供用例spiel：D告诉他们用例是有用的，因为它们是：

• 以所有利益相关者可合理理解的方式捕获业务流程的方法。这有助于弥合程序员，客户和用户之间的差距。
• 可追溯的功能单元。用例（在理想情况下）在分析阶段形成，在设计阶段引用，可以在以后用作测试用例的来源。
• 即使是非正式的，也能快速轻松地编写和使用。

如果您需要更多弹药，您可能需要阅读使用案例 - 昨天，今天和明天，而不是Ivar Jacobson。

如果您的同事仍然无法看到用例作为业务分析工具的潜在用途，那么他们可能无法帮助：P您应该提醒他们他们正在开发软件以满足其他人的需求并从长远来解决他们的问题，而不是用短小的噱头在短期内给他们留下深刻的印象。所以一点点的方向和规范都有帮助。即使用例本身并未证明有用，但提出这些用例的简单行为将迫使您的同事考虑软件的实际潜在目的。

Answer 2

提出双方的问题。在开发过程中，询问他们是否确定他们考虑使用该应用程序的所有方式都是最终用户想要使用它的所有方式;如果他们说有，请要求证明。在管理方面，询问他们是否曾经使用过他们想要的所有软件，但最终仍然难以使用（他们会有）。这些问题将会产生这样的概念，即双方所提供的内容可能不是所希望的;然后，利用一个想法的种子，开启讨论（不是文件，而不是一开始）关于如何使用软件的讨论，以及以何种方式解决任何差异。他们最终会绕过用例文档。

Answer 3

我是专业的产品经理，我对你的帖子的第一反应是，想法可以来自任何地方，如果开发团队有不错的想法，他们应该被纳入产品。

话虽如此，产品无法通过一系列不符合最终目的的断开连接的想法来发展灵魂（简单的信息）：解决目标用户的需求。并且，最终它归结为表明时间更好地花在对产品有意义的需求/用例上，而没有明确的策略/最终目标的机会成本将导致太多的厨师和厌倦的产品消息。

让这个信息成为主页的最终方式是让其他利益相关者参与其中并让开发人员展示他们的工作。最终，会出现分歧，更正规（更少牛仔）的方法将导致更精致和简单的产品。

Answer 4

你提到的一个问题是开发人员自己引起的紧张的时间表和范围蔓延。解释一下，通过使用用例，您可以通过删除功能来获得时间，这可能会最终导致“从未使用过”的堆。通过用例，您可以了解客户需要和支付的功能，并从您有时间实施的范围中删除不重要的功能。除了定义范围之外的用例还有助于识别所有利益相关者，这可能有助于您在定义范围时更好地集中注意力并防止忘记琐碎的事情，这些事情并不那么明显，但如果产品应该可用，则必须这样做。关于用例的第三个最重要的事情是，它们允许您开始考虑在开发之前对客户可能很重要的极端情况，因此您可以向客户了解什么是理想的解决方案而不是让编码器决定他/她在截止日期的压力下。

Answer 5

只是展示它们。

示例不是教育人的最佳方式，它是唯一的方式。

Answer 6

以身作则，专注于扩展和例外。换句话说，强调失败场景，因为每个人都知道系统应该如何工作。书面用例的真正价值在于确定当某些内容错误时会发生什么。

注意到，考虑到您可能不需要书面使用案例。而且，对于您描述的环境，主要的胜利是任何类型的需求文档。屏幕组件和/或原型设计通常更容易引入。