如何向同事证明用例是重要的?

您应该向您的同事提供用例spiel:D,告诉他们用例是有用的,因为它们是:

• 一种以所有涉众都能合理理解的方式捕获业务流程的方法。这有助于缩小程序员、客户和用户之间的差距。
• 可追踪的功能单元。用例在分析阶段形成(理想情况下),在设计阶段被引用,并且可以在以后用作测试用例的源。
• 写起来又快又容易,而且有用,即使是非正式的。

如果你需要更多的弹药,你可能想读 用例-昨天、今天和明天 只有艾瓦尔·雅各布森。

如果你的同事仍然不能看到用例作为一个业务分析工具的潜在用处,那么他们可能就无能为力了:P你应该提醒他们,他们正在开发软件来满足其他人的需求 需要 解决他们的 问题 从长远来看,短期内不要用小伎俩来炫耀。所以有一点指导和规范是有帮助的。即使用例本身没有被证明是那么有用,提出它们的简单行为将迫使您的同事考虑软件的实际潜在用途。

问双方的问题。关于开发,询问他们是否确定他们考虑使用应用程序的所有方式都是最终用户希望使用的所有方式;如果他们说有,则要求提供证据。在管理方面,问问他们是否曾经使用过可以做任何事情的软件,但最终还是很难使用。这些问题将孕育出这样一个概念,即在双方,交付的东西可能不是期望的东西;然后,利用这一想法的种子,就如何使用软件以及如何解决任何差异展开讨论(不是文档,不是一开始就讨论)。他们最终会找到用例文档。

我是一名专业的产品经理,我对你的帖子的第一反应是,创意可以来自任何地方,如果开发团队有不错的创意,他们应该融入到产品中。

尽管如此,一个产品不能通过一系列不连贯的想法来发展灵魂(一条简单的信息),而这些想法并不能达到最终目的:解决目标用户的需求。而且,归根结底,这可以归结为让时间更好地花在对产品有意义的需求/用例上,而没有明确的战略/最终目标的机会成本将导致太多的厨师和疲惫不堪的产品信息。

让这一信息深入人心的最终方法是让其他股东参与进来,让开发人员展示他们的工作。最终,会有分歧,一个更正式(少牛仔)的方法将导致一个更精致和简单的产品。

您提到的一个问题是由dev本身引起的日程紧张和范围爬行。向他们解释,通过使用用例,你可以通过删除特性来赢得时间,而这些特性最终可能会出现在“从未使用过”的堆中。有了用例,您可以发现客户需要什么样的特性,并将为此付出代价,将不重要的特性从您有时间实现的范围中移除。除了定义范围之外,用例还有助于识别所有涉众,这可能有助于您在定义范围时更好地集中精力,并防止忘记那些不那么明显的琐碎事情,但如果产品应该是可用的,那么这些琐碎事情是必须的。关于用例的第三个最重要的事情是,它们允许您在开发之前开始考虑对客户来说可能很重要的角落用例,因此您可以与客户一起发现什么是理想的解决方案,而不是让程序员在截止日期的压力下自行决定。

给他们看看。

榜样不是教育人的最好方法,它是唯一的方法。

以身作则,关注扩展和异常。换句话说,强调失败场景是因为每个人都知道系统 应该 工作。书面用例的真正价值在于确定当某件事情发生时应该发生什么 错误的 .

注意到了这一点,考虑到您可能不得不在没有书面用例的情况下生存。对于你所描述的环境来说,一个重大的胜利是 任何 需求文档的种类。屏幕组件和/或原型通常更容易引入。