1 story, 2 points d’effort, 3 FAIL(s)


BSODJe ne sais pas pour vous, mais il existe des moments où les galères s’accumulent. Tout avait pourtant bien commencé dans le Sprint précédent. On savait que le contenu du Sprint devrait absolument être mis en prod ce lundi car il contenait 2 fonctionnalités attendues pour l’ouverture de 10 nouvelles agences, dont la fonctionnalité « MAGAM ».

Bon, personne n’est alarmé plus que ca :

  • On vient d’installer en prod la version précédente : nous n’avons pas de stock :)
  • Le besoin métier est facile : l’équipe évalue les 2 fonctionnalités à 1 point chacun et nous produisons 60 points par itération.

On commence le Sprint par le plus prioritaire et après 4 jours (sur 15) on a une version stable contenant le minimum obligatoire. L’application est alors mise à disposition du P.O qui valide le fonctionnement. On continue alors le reste du Sprint. J-1, tout le contenu du Sprint est prêt. C’est le début des ennuis :

  1. 3 Story sont finalement annulées (Elles représentent à elles seules la moitié de l’effort) car le P.O a besoin de communiquer sur ces fonctionnalités lors d’une réunion située APRES la date de mise en prod (dont la date est fixée, ferme et définitive). Bon, c’est pas agréable … Mais l’équipe n’a pas tellement le choix : une nouvelle version est disponible en début d’après-midi.
  2. Ce lundi, SPM pour un nouveau Sprint. Nous mettons la version en prod le soir même. La réunion commence par une « Urgence » : la fonctionnalité « MAGAM » ne fonctionne pas dans un cas bien précis mais arrivant régulièrement. Il est Hyper Impératif de faire une nouvelle version dans la journée pour qu’on la passe en prod le soir même. Pour faciliter le tout, le P.O n’est pas avec nous mais à 300 km, pour l’ouverture des agences. Encore une fois, on garde la tête froide et on fait le nécessaire : une nouvelle version est prête à 14h, la fonctionnalité est de nouveau testée à 16h. 18h30, la version est installée en prod. Ouf
  3. Ce mardi, 8h00, mail « Raaaah, les gars, la fonctionnalité « MAGAM » ne fonctionne pas non plus dans un autre cas ! » Commence alors un échange de mail, qui vire un peu au règlement de compte (gentiment, quand même …). Bref … Une nouvelle version est développée, …
Il est certain que tous ces points seront abordés lors de la prochaine rétro.
Pour moi, les leçons à retenir sont les suivantes :
  • Oui, des critères d’acceptations sont importants. Notamment lorsque c’est « évident » !
  • Oui, des tests automatiques sont importants : Nous sommes dans une partie de l’application que nous ne savons pas tester par l’IHM. Il faut maintenant dépasser cette étape.
  • Le mail est le plus mauvais outil de communication. Il aurait sans doute été préférable que l’échange est lieu par téléphone (si l’on ne peut se voir).
  • Nous devons revoir notre définition du « done » pour voir comment tenir compte de la « communication »
Ca vous parle ?

Tags:

«
»

9 Réponses à “1 story, 2 points d’effort, 3 FAIL(s)”

  1. Alex :
    5/10/2011 à 09:13

    Bouh qu’il est pas beau cet écran bleu … mais on apprend beaucoup de ses erreurs … alors rien n’est perdu :)

  2. Sanlaville :
    5/10/2011 à 12:06

    Merci pour ce retour qui montre la réalité du terrain.

    Sur les leçons à retenir, j’ajouterai : les changements de dernières minutes sont jamais une bonne et cachent souvent plus de choses qu’on ne le croit.

    Il faudrait sans doute analyser pourquoi ces changements non pas pu être identifiés avant (sorte de mini-tunnel).

  3. dibus :
    5/10/2011 à 17:21

    Sanlaville : Merci pour ce commentaire. Tu as tout à fait raison : les modifications du Sprint Backlog sont à bannir … Surtout en fin de Sprint. Mais les exigences « terrains » nous imposent parfois de ne pas être dogmatique. Il faudra cependant que nous fassions en effet un travail d’analyse pour comprendre « pourquoi ces changements n’ont pas pu être identifiés ».

  4. dibus :
    5/10/2011 à 17:37

    Il n’y a que ceux qui ne développent pas qui ne font jamais d’erreurs .. hein ? :)

  5. ramuncho :
    6/10/2011 à 11:37

    J’ai l’impression de vivre la même situation…
    et je suis d’accord avec ces conclusions surtout :
    - Oui, des critères d’acceptations sont importants. Notamment lorsque c’est « évident » !
    - Le mail est le plus mauvais outil de communication.

  6. rocheto :
    6/10/2011 à 12:43

    tout est dit : « Pas de tests automatisés » . SCRUM sans IC n’est pas SCRUM.

    F.

  7. Xavier Nopre :
    7/10/2011 à 09:08

    Salut !

    Merci pour ce REX, la réalité du terrain n’est jamais à négliger, la preuve !

    Je suis bien intéressé par l’analyse qui sera faite, et les solutions envisagées.

    Je note que la situation semble avoir été amplifiée par une mise en prod rapide après la fin du sprint, malgré une apparente maitrise des risques et difficultés : peut-être prévoir plus de délai entre la fin du sprint et la mise en prod pour permettre au PO de bien tester ? Et prévoir une possible disponibilité de l’équipe en cas de problème …. A voir

  8. dibus :
    7/10/2011 à 16:51

    Merci Xavier,
    Nous devrions nous voir avec une équipe « élargie » pour une rétrospective spéciale dédiée à ce sujet.
    J’espère pouvoir organiser cet évènement d’ici 15 jours.

    En tout cas, merci pour le commentaire, c’est toujours très agréable de se sentir lu … et apprécié !

  9. Liens informatiques du mois – octobre 2011 | Gestion de projet et développement informatique :
    14/10/2011 à 16:50

    [...] 1 story, 2 points d’effort, 3 FAIL(s) [...]