问题可能看起来很奇怪！
在我现在正在工作的项目中，Scrum方法从过去三个月开始改编。我们曾经遵循V-Model，因为它是嵌入式行业的标准。
我们的项目遇到了一些麻烦，我们做出了这个决定。目前正在做的是客户（产品负责人）直接向开发团队提出顶级要求，需求团队只是其中的一部分。
开发团队开展工作并向产品负责人展示最终结果，如果需要进行更改，则会进行更改。一旦产品负责人对结果没问题，那么所做的更改将报告给需求，并将其记录下来并传递给测试团队。
这种方法的问题在于，在这个过程中，我们在技术上使需求团队和测试团队过时了。他们来得太晚了。
这是Scrum的工作方式吗？在这个过程中，一切都是由开发团队驱动的，而其他人基本上或多或少都是观众。
有些地方我看到我们仍然可以在Scrum方法中使用V-Model？
编辑：
我理解微型V模型每次冲刺都会发布。但我的问题是他们都是并行工作吗？例如：在传统的V模型中，这是一个经过修改的瀑布，总是有一个流程 - 需求团队将发布开发和测试的需求，他们在设计中并行工作，然后一旦开发完成，测试团队就开始测试。如何以scrum方式处理流程？
您已经提到过＆＃34;在为每个故事完成要求和测试部分之前，冲刺是不完整的。 ＆＃34;在我们的项目中，至少要求部分正在完成（测试团队完全被拒绝，测试或多或少由开发团队在产品上完成）。但是需求工作或多或少是一个文档工作。
整个Scrum都受到开发团队视角的驱动。我们看到的情况是开发团队决定某些功能的工作方式（因为最初的概念对他们来说太难实现或者可能更复杂）。
在任何级别都没有创建边界！这是Scrum认为的工作方式吗？
项目中的测试团队目前或多或少士气低落。他们非常清楚地知道他们在系统测试级别发现的任何问题都不会引起太多关注。开发团队通常的理由是，他们通常不会在机器上看到问题。
答案 0 :(得分：1)
有一个单独的需求工程团队在Scrum工作方式中已经过时了。你们都应该一起工作。
Scrum建议您应该在多学科团队中工作并以较小的增量工作。您可以将此视为每个sprint执行微型v模型发布。在为每个故事完成要求和测试部件之前，sprint不完整。您应该将它们视为已完成定义的一部分。
我建议您真正阅读Scrum Guide。关于开发团队的组成如下：
- 开发团队是跨职能的，具有创建产品增量所需的所有技能;
- Scrum不会识别开发人员以外的开发团队成员的头衔，无论该人员正在执行哪些工作;那里 这条规则不例外;
- Scrum不会识别开发团队中的任何子团队，无论需要解决的特定域如测试还是业务 分析;这条规定没有例外;和，
- 个人发展团队成员可能拥有专业技能和重点领域，但问责制属于开发团队 一个整体。
顺便说一句，我有一些使用敏捷方法在嵌入式系统中工作的经验，我们使用自动化测试取代手动测试人员取得了巨大成功。我们的测试人员，几乎是因为负责在各种硬件上运行测试套件，实际运行测试。我们甚至将测试完全纳入生产过程;每一件新硬件都直接通过我们的测试套件（一部分）装配线！