我正在与一个团队一起开始一个项目，我们使用 SCRUM 作为方法论。这是我第一次使用 SCRUM。我们列出了我们的功能并制作了我们的故事（用户故事和技术故事以及他们的任务）。
我有一个严格的 UML 方法来启动任何开发项目，对我来说，在列出所有功能之后，下一步是制作用户案例图，让每个人都能看到应用程序要做什么以及谁将与之交互。但是我的团队说在 SCRUM 中使用 UML 没有兴趣。
我可以使用 UML 的用户图来表示 SCRUM 中的用户故事吗？SCRUM 中还可以使用哪些其他图表？（这可能是一个愚蠢的问题，因为我无法想象没有类图或序列图的应用程序，但我真的很想看看 SCRUM 专家的建议）
谢谢。
我可以使用 UML 的用户图来表示 SCRUM 中的用户故事吗？
用例图会很有帮助，因为它非常简单，并且提供了项目的高级概念。
但是，我不建议在 scrum 中使用任何其他 UML 图。我同意其他人的观点，即在敏捷项目中代码更改如此频繁，以至于您的图表在几天后就会过时。在这种情况下，您必须重新绘制它们，这是一种浪费。
例如，如果您使用 eclipse 进行开发，一个简单的重构步骤可能会破坏您的类图:-(
SCRUM 中还可以使用哪些其他图表？
我建议使用思维导图。最近，我们开始创建自己的用户故事，绘制大型思维导图并将它们放在办公室的墙上。
我们中间有一个功能，我们将子用户故事连接到它 - 并将子用户故事连接到它们 - 以及我们目前拥有的所有可用信息。通过这种方法，我们将一切都集中在一个地方：用户故事、技术信息、问题等。
当然，思维导图每天都在增长，我们对必须实现的功能了解得越来越多。
实际上，我们正在做类似敏捷 dzone 文章中描述的事情，但是由于您使用的是 scrum 而不是 xp+看板，所以我谈论的是用户故事而不是MMF。
你可以在 Scrum 中使用任何你喜欢的东西来帮助你的团队有效地沟通。Scrum 不会就哪些工具对团队有效做出决定、判断或指导。它只要求您反思在执行 Sprint 时使用的工具和实践并做出相应的调整。这是检查和适应循环。
在讨论用于交付价值的工具和技术的好处时要开诚布公，这需要每个成员付出大量的努力和愿意接受改变。
我从使用 Scrum 一段时间的人那里得知（即：这是意见），制作 UML 图可能会有点费时，因为您的开发方法是敏捷的，您的需求很容易发生根本性的变化在第一个 sprint 的展示和讲述之后，这意味着您可以进行相当大的重新设计。
当然，在 sprint backlog 中，你将如何处理你的任务——你当然可以随时记录，但是维护一个类图的中央存储库等可能会稍微浪费资源。
我不确定您在项目中的角色，我假设您是 PO。在这种情况下，如果有意义，请使用其他文档。考虑将用户故事作为提醒团队与 PO 进行对话的提示。
如果您认为用户案例图将阐明您所要求的功能，那没关系。事实上，把它放在 Scrumboard 和燃尽图旁边的墙上。
根据我的经验，为每个故事指定一个“如何测试”场景就足够了。例如，假设我有一个 Stackoverflow 的故事：
“作为用户，我可以发布一个新问题”
“如何测试”的场景可能是：
“点击‘提问’按钮，将显示一个表单，其中包含问题文本的文本区域和标签的文本字段。用户输入两者后 - 它们是强制性的 - 用户被重定向到问题列表。用户可以看到列表中的问题标题以及标签”
所以也许真的不需要用例图。我建议尝试“如何测试”，看看效果如何。这对团队非常有用，因为他们从功能的角度知道您对故事的期望。而且您不会为每个故事都做文档。
如果您不喜欢它，请使用用例图，但最好给团队提供比故事描述更多的东西。
现在，关于你提到的技术故事。这些是什么？为什么技术要求与功能要求混合在一起？也许这是项目的真实需求，但通常不是，并且可以重写为功能故事。除非您的产品类似于框架或库。
例如，技术故事“为'get questions'查询创建索引”可以重写为“加速问题列表页面”。
我只在 Scrum 中使用类图和序列图，因为这两个图与 Java 代码实时同步。我当然不会创建 UseCase 或其他图表，甚至不会尝试从图表（例如 MDD）生成代码，因为一旦我的项目和代码发生更改，更新图表真的太痛苦了。图表应自动更新，无需任何人工干预。我用 Omondo EclipseUML 做了很多项目，效果非常好。
SCRUM 是一个应用程序生命周期管理框架，而不是您所说的方法。请参考 scrum.org
用例是抽象的。如果他们在改进过程中帮助您的团队，那就太好了。但是一旦你的团队致力于故事，改变就会受到欢迎，一旦故事完成，维护它们就没有什么意义了。目标始终是用户可接受的工作软件！
UML 状态机图在 Scrum 中对于专注于重新设计 UI 同时保留业务逻辑的项目很有用：
状态机建模是一种动态建模技术，它专注于识别系统内的行为——在这种情况下，特定于单个类的实例的行为。我的风格是当一个类根据其状态表现出不同的行为时，绘制一个或多个状态机图。例如，Address 类相当简单，表示您将在系统中显示和操作的数据。另一方面，研讨会对象相当复杂，因此为它们创建状态机图是有意义的。
参考