Développé, livré et testé dans une itération: pas toujours facile

Développé, livré et testé dans une même itération : ce n’est pas forcément naturel ; c’est même souvent une vraie difficulté pour les projets utilisant les les méthodes Agile: Processus Unifié (UP), SCRUM ou XP.

Le TimeBoxing (fixer les dates d’iteration quitte à faire évoluer le contenu de celle-ci) et les livraisons intermediaires sont bien acceptés. Reste à s’entendre sur ce qu’on livre …

Vérifier continuellement la qualité de l’application est principe fondateur du Processus Unifié. Le processus Unifié (« Unified Process » en anglais ou plus simplement « UP ») met l’accent sur la qualité des processus, sur la qualité du produit : des points déterminants dans notre choix de la méthode.
Une discipline est même formalisée, des rôles (« worker ») identifiés.

Quand vous présentez ce principe aux hautes instances de votre organisation, cette dernière est enthousiaste …il en est de même pour les équipes de développement.
Puis c’est le moment de concrétiser tout cela avec vos nouveaux projets: « ce sera environ 25% (parfois plus) de charge pour la discipline Test sur l’ensemble du projet ». Mettre le focus sur la qualité, ça a un prix : « Ah bon, vous êtes sur ? »
Mais jusque là tout va bien.

Enfin c’est le moment de mettre en application notre principe sur une itération, et c’est là que se présentent les premiers dérapages :

  • « tester, désolé on a plus le temps » …
  • « au fait qui va tester ? » …
  • « on a pas les ressources » …
  • « vous avez pris du retard les testeurs ne sont plus dispo »
  • « les cas de test ne sont pas prêts »
  • « ah pour vos tests on a pas l’environnement »
  • « attendez !! on a livré c’est déjà bien non ? »

Et bien non, ce n’est pas suffisant: ce qu’on livre on l’a testé. On ne peut se contenter de tester dans l’iteration suivante ce qu’on vient de produire dans notre itération. Une stratégie, non, plutôt un constat d’echec et surtout davantage de risques pour l’avenir.

Ce problème est donc récurrent; malheureusement il n’y a pas de recette miracle.
Encore une fois, une prise de conscience doit avoir lieu.
L’itération entière doit être tournée vers la recherche de la qualité. Les tests doivent être planifiés, anticipés, toute l’équipe doit se mobiliser et la QA team impliquée au plus tôt dans une approche collaborative (QA n’est pas mon ennemi !!)

Bon, un vrai travail d’optimisation des ressources est à mener mais je pense de plus en plus à intégrer les SCRUM dans ma gestion de projet (scrum signifie mêlée), ou plus exactement intègrer le « scrum daily meeting », (une courte réunion quotidienne, sauf que pour moi ce serait plutôt tous les 2/3 jours, d’environ 15 minutes, rassemblant les membres de l’équipe, où chacun décrit entre autres ce qu’il a fait la veille et va faire aujourd’hui).
Ces points intermédiaires seraient par exemple l’occasion pour les développeurs et les QA de faire un point sur leurs tests respectifs, et de rester en alerte sur cette question.

Et vous, comment faites-vous ?