由于这些开发团队实际上都是一个孤岛，所以我想开始为测试团队提供日常工作。这主要有两个原因：
通信-跨团队的交互很少。在测试团队中进行沟通将帮助我们所有人发现整个开发部门中的潜在问题，并将其传达给团队负责人。
支持-孤独地成为团队中的唯一测试者可能是孤独的。我希望每个测试人员都知道他们是测试人员团队的一部分，并提供所有支持。
考虑到以上几点，我是否应该以与正常Scrum不同的方式对测试人员进行Scrum？换句话说，他们是否应该传达比平常的“昨天，今天，阻止”更多的信息？
#1 楼
对于这组测试人员，“昨天，今天，阻止”是什么值？大概他们有类似的Scrum，他们向分配给他们的职能团队提供相同的信息。因此，您可能会要求他们重复他们刚才所说的内容，或者很快就会说出来。
也许您反而希望将会议重点放在“其他测试者听到的重要内容”上。也许一个团队的问题与另一团队有关。数据库团队的延迟可能会影响支持团队等。
我不确定是什么使这次会议成为您公司中的“混乱”。但是对于所有会议，组织者都应该考虑
我们应该开会吗？
我希望与会人员从这次会议中获得什么价值？
这是
我们每周举行团队会议，讨论现状和跨团队影响。
我们每两周举行一次学习会议，讨论技巧，技巧，以及一般的质量检查专家。
最后，我每周与每个人进行一对一的会谈，以关注他们的特定需求。
评论
好答案。会议策略加强了“在测试人员团队的支持下所带来的所有支持”。
–user246
2013年1月4日14:08
我同意@ user246。这是一个不错的策略。我认为从长远来看，每周一次的会议可能会更有成效。我也喜欢学习课程的想法，尽管我认为每两周一次对于我工作的地方来说可能太频繁了。
–SheyMouse
2013年1月4日15:14
#2 楼
即使已经接受了一个答案，我仍可以提供另一种观点：您不应只为测试人员运行Scrum。
有效的Scrum团队依赖于他们的自我能力治理和自我组织。因此，每个团队将以自己的方式处理事情。如果测试人员有问题，他/她应将其带到Scrum管理员并在团队中解决。如果他们不能解决问题，那么它就会进入分配适当资源的争夺战。我认为，强大的团队动力是成功争夺成功最重要的部分，这需要团队本身来确定，而不是由他们来决定。召开侧边栏Scrum会议可能会产生问题。事物可以在一个而不是另一个中提出，或者事物被重复两次并拥有两个单独的资源来尝试解决同一件事。最糟糕的是，这可能会使测试人员远离他们自己的Scrum团队的其他成员。
我认为您想要组织的事情是实践社区。我创建了我们的，它非常有用。我们使用它来与其他测试人员保持联系，分享出色的测试思想并确定测试标准。有关创建一个的更多信息，我发现本文很有用。
评论
根据Joe和Phil的评论，我想澄清一下我使用scrum这个词来表示每天的站立会议。我真的不喜欢对任何人进行多次“每日站立会议”的想法。如果您的测试人员已经参与了一个“ scrum”，那么我将避免添加另一个。甚至快速的站立会议也可能开始占用您所有的时间...
@JoeStrazzere你说的很对。希望我对您的原始答案的评论能解决此问题。我现在倾向于每周一次的状态会议。我在原经理的陪同下工作了6个月，发现一个团队中存在一些问题，所有测试人员之间的定期会议可能已经解决了这些问题。