Je suis de plus en plus contacté pour des conseils sur l’agilité et plus particulièrement sur les tests et l’agilité.
J’ai donc décidé de vous proposer cet article sur comment reconnaitre une équipe agile.
Commençons par casser quelques stéréotypes :
- Une équipe est-elle forcément agile si testeur et développeur sont co-localisés ?
Non, la co-localisation n’est pas suffisante pour proposer une équipe agile. Même si l’agilité recommande très fortement la co-localisation pour faciliter les interactions entre individus (échanges direct).
- Une équipe est-elle forcément agile si les tests sont automatisés ?
Non, l’automatisation n’est pas une preuve d’agilité d’une équipe. Il est possible, au début de développement d’un produit avec une équipe agile de ne pas avoir de tests automatisés. De même, rien n’empêche d’automatiser des tests dans une projet classique type Cycle en V.
- Une équipe est-elle forcément agile si elle dispose d’une chaine d’intégration continue ?
Non. La chaine d’intégration continue (avec au minimum l’exécution des tests unitaires) est d’ailleurs une bonne pratique qu’elle que soit la méthode utilisée pour le développement
- Une équipe est-elle forcément agile si elle utilise le langage « gherkin » (Given, When, Then) ?
Non. Il faut d’ailleurs faire particulièrement attention avec ce langage. Ce langage est trop souvent, à tort, confondu avec le BDD qui est une vraie pratique agile ! Or, comme il est bien expliqué dans la conférence d’Hiptest, on peut faire du BDD sans gherkin et utiliser du Gherkin sans faire de BDD. Le langage Gherkin n’est qu’un outil !
- Une équipe est-elle forcément agile si elle a des réunions appelées « Daily meeting » ?
Non, les daily meeting font partis des cérémonies proposées dans le Framework Scrum qui est, un framework agile. Néanmoins cette cérémonie est souvent mal utilisée, mal implémentée mais surtout mal comprise… Tout cela entraine une non agilité !
- Une équipe agile est-elle forcément agile si elle utilise le framework Scrum
Oui, mais uniquement si la méthode est bien comprise. Mettre en place les cérémonies du Scrum ne suffit pas à faire une équipe agile !
En fait, pour être une équipe agile, seules quelques conditions sont nécessaires… Elles sont d’ailleurs également suffisantes.
Pour être Agile une équipe doit :
- Être composée d’une équipe pluridisciplinaire, ou qui a plusieurs compétences commes les tests et le développement…
- Communication régulière et fluide entre les différents membres à propos du produit
- Avoir un processus d’amélioration continue. Sans amélioration continue il n’y a pas d’agilité. L’équipe doit repérer des difficultés et l’amélioration continue doit permettre de les résoudre. L’équipe évolue et s’améliorer. L’implémentation de l’automatisation, des chaines d’intégration continue de l’ATDD/BDD intervient suite à des problèmes rencontrés par l’équipe.
- Proposer un développement itératif. L’agilité, par essence, fonctionne avec des retours réguliers en proposant des logiciels fonctionnels régulièrement aux utilisateurs où à ses représentants afin de recueillir, au plus tôt leurs retours.
Bref, pour être agile, une équipe doit principalement avoir le bon état d’esprit, un « état d’esprit agile ». Si cette équipe a cet état d’esprit alors c’est une équipe agile et ce même si ses tests ne sont pas automatisés, si elle n’utilise pas de framework prédéfinis ni de BDD….
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
N’hésitez pas à faire vos propres retours d’expérience en commentaire.
5 Responses
Certes l’agilité, ça marche!
mais je reste curieuse de connaître l’avis des développeurs, surtout ceux qui ont déjà travaillé avec les méthodes classiques et agiles!
Je pose la question parce que j’ai fait une formation dans une grande Esn, tout le monde avait l’air fatigué, avec deux personnes qui étaient en arrêt dépression, je me demande si ce n’est pas à cause des sprints?!
Bonjour,
j’ai beaucoup travaillé et continue de travailler en agilité sans jamais être confronté à ce cas de figure. Le problème remonté est un problème fréquent mais est lié à une mauvaise implémentation de l’agilité.
D’ailleurs, le terme « sprint » dans le Scrum est mal choisi car le but est d’atteindre une vitesse de production de croisière que l’on peut soutenir sur le long terme.
Dans certains cas, l’agilité peut servir d’outil pour « fliquer » ou demander toujours plus aux équipes. Ces dérives entrainent toujours les problèmes de votre commentaire. Néanmoins, pour être honnête, je ne pense pas que ces problèmes soient liés à l’agilité mais plutôt aux manager. Les problèmes de pression et de fatigue au travail existent même sur des cycles de production plus classique.
Bonjour ,
Je trouve que cet article vient du terrain avec beaucoup de flexibilité , au contraire les principes de l’agilité cité dans la certification Agile ISTQB d’où vient les questions alimentés dans l’article !!
Que pensez-vous
Bonjour,
oui cette réponse vient du terrain et de mon analyse à travers mes divers échanges et expériences.
Par contre, il faut faire attention, l’ISTQB parle de l’agilité mais reste concentrée sur le test.