敏捷QA/Dev团队建设练习

Question

有没有人有一个良好的团队建设练习,以帮助将质量保证/开发团队等不同的团队聚集在一起？

我是公司"敏捷教练"(就像我讨厌这个术语一样),我的任务是让我们的公司更敏捷,并带来更敏捷的任务/技术.

话虽如此,我正在努力弥补两个团队之间的差距,并且我正在尝试进行良好的团队建设练习,因为QA/Dev团队应该被视为一个团队,需要进行更多沟通.

对于适合您的事情,任何想法都会非常感激

Answer 1

根据我的经验,改善团队之间互操作性的关键是打破"我们和他们"的心态.令人惊讶的是,即使在一个每个人都能上场的组织中,这种自然倾向于刻板印象其他球队,认为他们只是"困难",并且退回到球队自己的围墙花园.

要将其应用于团队建设练习,最主要的是将参与者分成小组(4-6人),并且至关重要的是,确保团体充分混合.确保人们与通常最适合的人分开.目的是增加通常不能沟通的人之间的互动,并为他们提供一个可以共同创造经验的环境.

吉姆霍姆斯的观点在实用工程师中很常见,我过去也有同样的观点.大多数的这些东西是注定要失败,因为经营不善的没有解决的核心问题,还是因为参与者是完全持怀疑态度,并希望锻炼失败(因为他们已经在过去这么没用).

直到我参加了一个真正有用的为期一周的(!)团队建设项目,我才明白这些类型的练习的可能性.使这门课程脱颖而出的重点是:

1. 从参与者那里获得支持.如果你想让人们认真对待你的运动并做出真正的努力,那么你必须预先解决怀疑论.告诉他们你期望达到什么目标,为什么你想要它(如何改善他们的生活)并要求他们提前买入.并承担责任 - 告诉他们你真的相信这是有用的,并准备好接受敌意和负面反馈,如果它不足.
2. 使难度水平充足.如果您的观众都是博士或经验丰富的软件架构师,那么就不要像孩子一样对待他们.使练习变得有趣,复杂和困难.例如,我们被扔直深水的一端,用我们从未见过面的人合作,给予了危机情况管理,移交的背景信息一个巨大的堆栈,并且告诉我们有10分钟的准备.这是一场噩梦(我们并没有做得很好)!如果您使问题更简单,那么大大减少可用时间.练习应该很难,并且小组应该尽早让其中一些人失败,把他们带回家,努力,他们缺乏团队合作能力.
3. 清楚地确定您想要实现的目标.在一个房间里吸引人并告诉他们"在团队中工作"是行不通的.有明确的目标,并解释人们在最后会如何变得更好.确保跟踪这些目标.如果参与者觉得他们在课程结束时没有多大帮助,那么找出原因 - 并认真对待这些反馈.
4. 帮助参与者反省他们如何工作和互相交流.团队问题的一个重要部分是不了解其他人的工作方式.对于聪明人来说,这通常被视为无关紧要 - "我不关心他们如何工作,我可以做自己需要做的事情"是一个共同的观点.这就是为什么问题必须太困难/太多工作/花费太长时间才能让任何一个人完成.尊重他人的优势并调解他们的弱点是成功团队成员的关键特征.
5. 有详细的反馈.每次练习后,确保团队反映他们的表现.你应该提出建设性的批评,但更好的是让团队理解并确定自己的局限性.一旦他们知道如何改进,就直接跳到下一个练习中.例如,在一个团队中,我们遇到的问题是每个人都在谈论,但没有人真正倾听.由于这种不正常的沟通失败了几次,我们制定了一个简单的沟通协议 - 一次只允许一个人谈话.虽然显而易见,但令人惊讶的是,这对我们后续练习的表现有多大改善!