Le meilleur moyen de renforcer le travail d'équipe entre les départements de développement et d'assurance qualité?

Question

Je travaille en tant que Sysadmin pour les départements de développement et d'assurance qualité d'une entreprise de développement de logiciels. Je soutiens les deux équipes également. Récemment, on m'a demandé quelques idées pour améliorer la communication entre les équipes.

Premièrement, comment améliorer la relation entre une équipe de développement et une équipe d'assurance de la qualité, du point de vue du développeur?

Deuxièmement, quelles sont les choses que vous recherchez d'un administrateur système en ce qui concerne les interactions? Te laisser seul? Email? JE SUIS? Temps de travail personnel? Comment puis-je améliorer mes relations avec les développeurs?

Answer 1

Une bonne gestion est un bon début. Je dirais que le plus important est d’obtenir que les deux groupes réussissent ou échouent ensemble. Vous voulez que les deux aient une compétition amicale (l'un essaie de trouver des bugs, l'autre essaie d'empêcher que cela se produise), mais à la fin, ils doivent être considérés comme faisant partie de la même équipe. Les déjeuners d'équipe et autres activités sont toujours une bonne idée.

Answer 2

Co-localisez-les et traitez-les comme une équipe interfonctionnelle. Si les QA veulent écrire du code (comme des tests d'acceptation), laissez-les. Si les développeurs souhaitent procéder à un contrôle qualité sur une autre partie du système (pas sur le code sur lequel ils ont travaillé). Laissez-les et demandez aux deux groupes (si vous voulez les voir comme des entités distinctes) de travailler ensemble pour résoudre le problème.

Answer 3

Faites participer le personnel d’AQ dès que possible. Si vous faites de l'agilité, ils font partie de l'équipe. Même si ce n’est pas le cas, ils peuvent néanmoins fournir des informations précieuses sur la façon dont le code peut être amélioré en le rendant plus testable et en évitant ainsi les problèmes ultérieurs.

Answer 4

Les équipes d’assurance qualité et de développement sur mon lieu de travail s’entendent très bien parce que nous sommes géographiquement proches les uns des autres. Ceci élimine la boucle de "défaut de fermeture ouvert" à défaut de fermeture de dev-dev " cela semble favoriser l'irritation passive-agressive. Une communication claire et ouverte entre les deux groupes et des attentes claires sont toujours attendues. En dehors de cela, des exercices standard de renforcement d'équipe sont un bon début. Nous organisons des déjeuners, des pique-niques, des jeux sur la pelouse pendant les mois les plus chauds, etc.

En ce qui concerne le style d’administration, parlez à vos employés et voyez ce qui leur convient. Certains aiment rester seuls avec des mises à jour sporadiques, d'autres aiment les retours constants. Vous devez faire ce qui est confortable pour votre développeur et vous.

Answer 5

Dépend de la taille de votre organisation, mais arrêtez de les considérer comme deux groupes distincts . Si vous êtes le seul administrateur système, je suppose que votre organisation n’est pas énorme.

Intégrez-les physiquement. Ne pas avoir dev dans un domaine et assurance qualité dans un autre. Demandez-leur de partager les bureaux / cubes les uns à côté des autres.

Vous emmenez les gens déjeuner? Prends-les ensemble. Saisir une bière? Faites-le avec des gens des deux groupes.

Answer 6

Activités hors contexte telles que sport ou restauration au restaurant à l'heure du déjeuner.

Faire en sorte que les gens se connaissent mieux que d’autres emplois ne contribue à l’instauration de relations de confiance et de liens entre deux groupes.

Answer 7

Je pense qu'il serait très bénéfique d'impliquer les développeurs dans le développement (ou l'utilisation d'outils déjà développés) d'outils de test automatisé. Ainsi, l'ensemble du processus d'assurance qualité sera amélioré et les développeurs auront une meilleure vision des tests. et aussi les deux équipes communiqueront davantage en le faisant. Je pense qu'en tant que développeur, il serait amusant de travailler sur un tel projet.