我和团队一直在做scrum一段时间，但由于某些原因，事情似乎很混乱。我一直在考虑如何改变这些问题并提出一些我想在此提出的问题。
首先，测试人员，设计人员和非开发人员在Scrum流程中的角色应该是什么？ 如果他们与其他团队成员相同，则会出现一些问题。设计人员和测试人员通常在开发完成后处理任务，因此由于这种依赖性，他们无法充分计划冲刺。
其次，我们有截止日期。这些都很严格，对优先级有很大影响。最终结果是由于截止日期的变化而在sprint中间进行了积压更改，或者在sprint结束时出现了糟糕的结果。 我们还有许多非技术性工作，例如客户支持，必须在此期间完成，并且由于变化很大，因此无法进行规划。 所以我认为团队结构，文化和实践与Scrum不兼容。对我而言，Scrum是一个流程管理工具，适用于开发单个软件产品的团队。
你们有什么想法在更具体和复杂的场景中应用它？你有经验可以分享吗？
答案 0 :(得分：7)
一般来说，测试人员和记录员（以及其他非开发人员）都是Scrum团队的平等成员。这背后的想法是最小化风险。
要求对已完成的定义（包括经过充分测试和记录的潜在可运输产品）强制项目在每个sprint结束时聚集在一起。
如果测试直到AFTER开始后才开始。完成之后，在开发人员完成任务后会发现很多错误。因此，现在你必须修复这些错误，这非常缓慢和昂贵，因为错误相互作用，因为一般规则是：“修复错误的费用随时间呈指数级增长。”你早期捕获的bug很便宜且易于修复，迟到的bug是一场噩梦。
这就是为什么您希望测试（和文档）与开发同步进行的原因。现在你应该问，怎么样！测试速度很慢，它如何与dev一起移动？
答案是自动化，即SCRUM始终位于XP或Agile之上，两者都需要出色的单元测试覆盖率和TDD。这是另一个需要注意的问题。开发人员应该是编写单元和系统测试的功能。所有测试自动化都应由功能开发人员完成。球队。有些地方拆分了功能开发。来自自动化开发那很糟糕。
好的，所以现在你有很好的自动化测试，你每天至少运行一次。显然你实行持续集成吧？这大大减少了测试人员的工作量。这就是测试与开发人员保持同步的方式。还有一件事，测试人员现在正在研究那些不可能或非常难以自动化的非常难以创造的东西，每当他们发现错误的时候，揭露错误所需的一切都是自动化的，并成为日常回归测试的一部分。哎呀，这是一个很长的答案！
现在问题的第二部分。 Scrum是关于纪律的。短跑很短，冲刺期间的积压变化不应该发生。非技术性工作应该分支到客户支持团队，他们可以围绕这个做Scrum。当你说这听起来像你的文化和做法与scrum不相容时，你是对的。
根据我的经验，过渡到Scrum / Agile是一个非常痛苦，压力很大的过程，大多数过渡尝试都失败了。成功的关键之一是在执行团队中获得Scrum / Agile的冠军。根据你的描述，听起来你没有。
Scrum有成本和收益，但是你做得很糟糕，你可能会产生很少或根本没有收益的成本。如果你正在做错误和严重的Scrum，你可能最好不要做Scrum。
答案 1 :(得分：5)
首先，测试人员，设计人员和非开发人员在Scrum流程中的角色应该是什么？如果他们与其他团队成员相同，则会出现一些问题。设计人员和测试人员通常在开发完成后处理任务，因此由于这种依赖性，他们无法充分计划冲刺。
如果设计人员和测试人员由于开发依赖性而无法计划sprint，那么这意味着您的开发计划不正确。这是一个需要修复的问题。
您的团队应该能够说“任务B要求先完成任务A。任务A需要8个小时，然后任务B需要4个小时”。如果您的任务估计是准确的，那么依赖性根本就不是问题。
其次，我们有截止日期。这些都很严格，对优先级有很大影响。最终结果是由于截止日期的变化而在sprint中间进行了积压更改，或者在sprint结束时出现了糟糕的结果。我们还有许多非技术性工作，例如客户支持，必须在此期间完成，并且由于变化很大，因此无法进行规划。
如果发生这种情况，那么问题是你没有做Scrum。 Scrum工作的唯一方法是管理层完全购买流程。这意味着让开发人员在他们计划的sprint上工作30天，并通过Scrum已经实施的方法添加新工作。您将愿望清单项添加到产品待办事项中，然后在sprint计划期间，开发人员和利益相关者就下一个sprint中将要处理的内容达成一致。
如果您始终遇到中断正常开发的客户支持问题，那么您应该认真考虑划分团队并让一个团队专门致力于Scrum的开发，并让另一个团队负责客户支持问题。然后，您可以在每个冲刺结束时来回旋转人员。
答案 2 :(得分：3)
你真的不应该根据Sprint中间提出的变化添加对Sprint积压的更改，他们应该只进入产品积压并忽略直到Sprint结束。
您应该将您的截止日期与Sprint对齐。我认为在Sprint中期退出任务是可以接受的，但不会引入新的任务。
如果您发现在Sprint中间添加了大量任务，那么您的Sprint可能太长了。请记住，您的目标是在每个Sprint中进行大约20天的工作，并且您开始解决您所描述的问题！
测试人员对任何敏捷过程都很重要，但是并不真正适合Scrum，理论上任何没有主动任务的人都会接受下一个任务。试图选择任务和人之间的关联开始进入调度，整个事情都试图避免！
测试员，如果在开发人员附近工作，可以协助确定工作项目是否真正完成！
答案 3 :(得分：0)
首先，你根本就没有使用Scrum，你可能正在使用一些scrum实践，但不是整个过程。
设计人员和测试人员通常在开发完成后处理任务，因此由于这种依赖性，他们无法充分计划sprint。
任务依赖没有关系，很少发生，并且能够正确计划。在sprint计划中，团队应该估计有关“完成定义”的故事。如果它包含，并且它确实应该设计和测试故事，那么完成故事验收标准所需的工作量估算必须包括设计和测试任务。
最终结果是由于截止日期更改而在sprint中间进行了积压更改，或者在sprint结束时出现错误结果。
您的冲刺长度似乎比您需要的更宽。你为什么不试着缩短它。良好的冲刺长度是您可以承诺保持更改冲刺的长度。我想1周就行了。
这种行为表明你的Scrum Master没有正确地完成他的工作，因为他没有消除障碍。