我不反对Scrum。我喜欢它，在RAD之后我的第二个偏好是正确的，然而在我现在的团队中他们让我讨厌它。我们可能以最糟糕的方式做到这一点。
我们有通常的Sprint计划，在自己编写用户故事时大约需要30分钟，而这一切都是如此。在那30分钟内，我们回答如下问题：
这真让我失望，他们不会听我说话。没有任何计划，就像没有。 （2）所有4位开发人员都在谈论解决特定问题的不同方法。没关系，但我们也没有任何明确的愿景，因此每个人对整个项目的前景都有不同的理解。因此我们的想法完全不同。这通常最终会陷入混乱。例如，我们最新闪亮项目的第一个冲刺中的最新故事：
愿景：我们需要一个应用程序来对X应用程序执行单元测试。
用户故事：
我担心的是：
Vision并没有说明整个项目的发展方向，因此我们将在下一个春季或之后或之后重新实施我们的大多数功能。 （检查 - 这件事马上就发生了;我无法帮助它，我只是讨厌在下一个春天开始时就会被删除的东西。我不认为Scrum是关于它的，它不是
没有实际的计划。我们还没有澄清数据库应该是什么样子，以及如何创建它？我可以为这样一个系统创建一个具有1到N个表的数据库，具体取决于项目将来应该实现的目标，但这并不像DB可以轻松扩展那样严重。
基于（2）我们开始研究不同的部分。我创建了数据库，而其他人创建了视图，而其他人创建了操作实现。我们所有人都有不同的理解，即使在一天之内，我们最终得到的是不兼容的模型，但这些模型无法集成。
我们做错了什么：
这里出了什么问题？只是我对scrum的错误理解或我的担忧是真的吗？这给了我很大的工作压力，我几乎无法处理它。
答案 0 :(得分：0)
我很感兴趣的是“他们”在这一行：“这真让我失望，他们不会听我的。”？
看起来好像你指的是scrum团队的其他成员。如果是这样，我建议你需要尽快达到“我们”的立足点并进行沟通。
关于你帖子中的一些项目，我会立即想到一些事情：
如果您没有产品，则需要产品所有者拥有该产品，它的愿景和积压。如果你有一个，他们可能受益于良好的培训或指导
您对于需要产品愿景是绝对正确的。你似乎有一个但是，你推断它描述的是一些功能，而不是一个完整的产品愿景。如果是这样，你是否试图在你的团队中讨论这个问题？
如果您没有，则需要一位Scrum master来帮助产品所有者和开发团队遵守Scrum规则，并在您的情况下鼓励团队内部的沟通。如果你有一个，他们可能受益于良好的培训或指导
关于你的担忧，我想补充一下：
我认为你的意思是'sprint'，你写的是'spring'
scrum中常见的产品积压项目已更改以反映更好的理解
启动项目时，您不需要深入描述数据库。 Scrum最适合基于已实现功能的紧急架构
如果多个开发人员在没有沟通的情况下在同一区域工作，那么很可能你会踩到对方的脚趾并获得你描述的结果
答案 1 :(得分：-1)
我认为你应该把它放在你的肩膀上。是编写规范并收集所有必需信息以完成功能或任务的人。规划应该一起完成，但对于没有经验的程序员，你可能需要自己做。几乎每个功能都访问数据，因此必须为这些模型和操作定义接口。如果您的待办事项中没有这些内容，请在first meeting of the sprint
进行规划将所有内容写入待办事项。此数据集不应更改，只能展开。在进行任何开发之前，您需要将所有内容都搁置。你只能移动家具。这个过程本身会花费很多时间，但如果没有它，你就不会对项目所处的位置有清晰的了解。
每天15分钟的会议应该足以讨论所遇到的每一个问题，因为给定的任务应该彼此独立。