Vis ma vie de responsable QA (Part I) – Le Definition of Done des User Stories

Vis ma vieContexte

Je travaille actuellement en tant que responsable QA sur un gros site publique d’E-commerce et depuis que je suis dans cette mission, j’ai appris beaucoup sur la façon de mettre en place Scrum par le seul fait que nous n’en fassions pas ou du moins pas au sens strict.

J’aurais pu pondre un énorme document sur l’ensemble de cette mission mais j’ai préféré, ici, découper mon retour d’expérience en plusieurs articles plutôt courts (peut-être pas pour le premier) centrés sur un problème en particulier.

Il n’est pas question ici de donner systématiquement des solutions à des problèmes. J’ai appris au fur et à mesure du projet que lorsqu’on pense avoir gagné, ba en fait non…
Une lutte de tous les instants ou toute perte d’énergie et de motivation vous ramène immanquablement à la case départ.

Cette série d’article me permettra, je l’espère, de poser les problématiques rencontrées, me poser une nouvelle fois les bonnes questions et potentiellement trouver un levier que j’aurais loupé.

Je tiens à m’excuser à l’avance de l’afflux de bullet points dans cet article, j’aime habituellement écrire de façon littéraire mais j’ai trouvé là le seul moyen d’organiser ma pensée.

 

Contraintes

Commençons d’abord par poser les contraintes liées au type de projet qu’est un site grand public d’e-commerce:

  • Empêcher à tout prix toute indisponibilité des services (étonnant non?!)
  • L’affichage est plus important que tout le reste (si une page plante, c’est grave, si le lien qui mène à une page ne s’affiche pas c’est plus grave!)
  • Time To Market fort
    • Les priorités du backlog changent constamment
    • Difficile d’obtenir en amont toutes les informations nécessaires à la bonne construction d’une spécification
  • Des refontes globales fréquentes (le bonheur…)
  • Besoins très fluctuants à mettre en production rapidement (le rebonheur…)
  • Une attente forte de la part de l’équipe dev/int de spécifications détaillées
  • Multiples interlocuteurs sur la partie front (resp. User Experience, chef de projet front, MOA)

Alors Time To Market fort, refontes globales fréquentes, besoin fluctuants… mais… mais c’est de l’Agile!!

En effet, le projet se veut « projet Scrum », cependant je préfèrerais parler de projet Agile du fait que la méthodologie Scrum se limite à quelques miettes par ci par là.
Pas de daily meeting, pas de rétro et un vague planning poker, une besoin de specs fortement détaillées de la part du développement et pas de scrum board, de kanban board ni de Françoise La Board. A et aussi pas de Scrum Master (difficile donc d’avoir un garant de la méthode)

Pourtant, loin de moi l’envie de critiquer le choix fait pour organiser ce projet, nous avons à minima un développement itératif, des user stories et surtout un projet qui fonctionne où le client est satisfait, le management est satisfait, l’équipe travaille dans une bonne ambiance mais si la vision globale est celle-ci, si on zoom un peu on

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s