...以及如何向管理层证明用例可以是非正式的并且仍然有用？
大家好，
我参加了一个项目，发现没有用例、用户故事、需求，也没有任何类似于规范的东西。由于截止日期很短，目前的开发团队不想花时间在这些事情上。我想加入那个项目，但通过挖掘更多，我发现当前的开发只是通过考虑它们的“哇效应”来添加功能，并通过使用底层技术提供的易用性来选择添加什么。我很惊讶他们是如何在没有要求的情况下做到这么远(超过 4 个月)的，但这就是我们现在所拥有的。我相信他们选择的方式是最有把握扼杀具有良好营销值(value)的产品的方式。
我说得对吗？在类似的情况下，您会怎么做才能证明开发团队/管理层在继续前进之前制定用例/要求？在此先感谢，kh。
附:两本 Cockburn 的书在书架上……
最佳答案
您应该向您的同事介绍用例:D 告诉他们用例是有用的，因为它们是:
- 一种以所有利益相关者都能合理理解的方式捕获业务流程的方法。这有助于弥合程序员、客户和用户之间的差距。
- 可追溯的功能单元。用例(理想情况下)在分析阶段形成，在设计阶段被引用，并且可以用作以后测试用例的来源。
- 即使是非正式的，也可以快速轻松地编写且有用。
如果您需要更多弹药，您可能需要阅读 Ivar Jacobson 的用例 - 昨天、今天和明天。
如果您的同事仍然无法看到用例作为业务分析工具的潜在用途，那么他们可能已经无能为力了:P 您应该提醒他们，他们正在开发软件以满足其他人的需求 并从长远角度解决他们的问题，而不是在短期内用小噱头来炫耀地打动他们。因此，一些方向和规范会有所帮助。即使用例本身没有被证明是有用的，提出它们的简单行为也会迫使您的同事考虑软件的实际潜在用途。
关于project-management - 如何向同事证明用例很重要？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4250117/