mai 2010Monthly :

jour 3

Malheureusement, je ne peux être présent pour cette 3e journée. L’équipe procède quand même au découpage des items du backlog.

jour 4

Dernière journée du sprint 0. Une grosse journée en perspective. Seulement 1 story du backlog est découpé en tâches et il y en a très peu d’écrites (3 ou 4 autres stories). Selon le plan initial, il nous reste à faire le release plan, un plan d’actions pour les risques, la définition de terminé et la rétro du sprint 0. Tout ça et il n’y a pas assez d’éléments du backlog de découpés pour remplir le premier sprint!! Je propose de modifier le plan de la journée et de travailler à remplir le backlog. Sans ça, on ne pourra pas vraiment (pas du tout même) débuter le sprint 1. Le release plan et le plan d’actions sont repoussés dans l’itération 1 comme des tâches non-fonctionnelles. Je suis conscient que cette proposition n’est pas idéale, mais c’est le mieux qui me vient à l’esprit pour que l’équipe ait des stories à sprinter.

On prend donc les stories écrites. On s’assure de bien comprendre la portée et les conditions de succès. Puis on les place à mesure sur la table selon leur complexité relative aux autres stories déjà décrites. Ça combine en quelque sorte la compréhension de stories par l’équipe et le “wall/table poker planning”. L’équipe n’a pas de difficulté à placer les stories en relation entre elles pour évaluer la complexité relative. Lorsque c’est terminé, je place alors au hasard des points sur les stories, ce qui donne 1,2,3,5 et 8 comme pointage. L’équipe est assez confortable avec ces pointages, sauf pour le 8. L’équipe propose que cette story est plus que 2 fois plus complexe et comporte assez d’inconnu que celle qui est à 5. Le 13 ne suffit pas, alors on la met à 20. Wouah! Ensuite, le découpage des stories en tâche débute. D’abord par celle qui vaut 1, puis 2 et ainsi de suite. Celle de 20 n’est pas touchée. Selon le découpage en tâche, on arrive à une approximation que 1 point = environ 16 heures. Ah! d’accord.

Enfin le lunch! Ça va faire du bien!

Au retour, l’équipe se détermine une définition de terminé. Je la trouve correcte. Pas trop ambitieuse, mais suffisamment d’éléments pour qu’on sente qu’ils mettent de la qualité. C’est à ce moment que l’équipe demande, est-ce que les tests intégrés, je fais une tâche ou ça va dans la définition de terminé ? J’ai le goût de répondre simplement: oui! Hélène sent mon ambivalence et lance une chanson (elle n’a pas vraiment chanté, mais ça aurait pu) “Write it until it’s a habit”; comprendre “faites-en un tâche jusqu’à ce que ca devienne une habitude (mais mettez-le aussi dans la définition de terminé – ceci est en sous entendu)”.

Comme tout au long du sprint 0, l’équipe se pose des bonnes questions, auxquelles j’ai assez souvent une suggestion de réponse. Dans les cas incertains, je fais un Éric Laramée de moi-même et je réponds “ça dépend” et à ce moment, quelqu’un de l’équipe propose quelque chose qui fait ressortir un élément de réponse intéressant.

Enfin durant la rétro du sprint 0, il ressort que :
points positifs

• l’utilisation d’un taskboard pour gérer les taches du sprint 0 est efficace et utile
• assigner un timebox en avance sur les éléments facilite l’avancement
• l’équipe a une bonne idée du projet grâce aux épics
• une bonne chimie de groupe est déjà présente dans l’équipe
• utile de mettre immédiatement en pratique les notions de Scrum par la pratique

points à améliorer

• il n’y a pas de date de release à présenter au patron du PO
• l’équipe part facilement dans des discussions un peu à côté du sujet – le modérateur ne modère pas assez!
• peur de perdre les cartes et post-it des stories, aurait préféré écrire tout dans Excel
• sprint 0 un peu une perte de temps (pour l’analyste et le PO) parce que ce sont tout des éléments qui étaient connus

questions sans réponse

• quel outil utiliser pour gérer tout ça
  • Urban Turtle (puisqu’ils ont un environnement TFS)
  • Excel devrait suffire aux premiers sprints, on réajustera quand on sentira des douleurs

On amorce la deuxième journée avec un absent. Un développeur a eu un feu à son domicile, il sera absent pour la journée et probablement une partie de la semaine prochaine. On pense à lui.

Nous débutons en retournant au backlog pour découper les epics. Je ne veux pas tout de suite les transformer en stories, je tente d’amener à découper en étapes. La première epic attaquée est “Charger les informations de base”. Selon le PO, les étapes à suivre sont très techniques, du style “prendre tous les produits du système X et les amener dans le système Y”. Ouff! En creusant, on se rend compte qu’il y a trois types de chargement possible; initial, mise à jour et automatisation. Plus tard, un quatrième apparait; synchronisation. À ce point, le découpage manque de détails, mais à force de discussion, après 1 bonne heure, on réussit à écrire la première story accompagnée de ses conditions de succès. La deuxième story suit dans l’heure suivante. Sur ce, l’avant midi prend fin. Je suis plutôt satisfait, l’équipe a sorti 2 stories et des règles d’affaire qui semblaient évidentes ont fait surface; par exemple quand le PO parle de charger “tous les produits”, ça ne veut pas dire tous les produits, mais bien tous les produits d’un certain type et qui sont actifs. Quand même une distinction intéressante.

Durant l’avant-midi, la patron du PO est passé faire un tour dans le local du sprint 0. Son arrivée correspondait pas mal au moment de prendre une pause, alors il n’a pas vraiment interrompu le déroulement. Une chose intéressante s’est produite, il a regardé le backlog, a discuté avec le PO et ils en sont venu à modifier la valeur/priorité associée à certains items du backlog. Wouhou! C’était des items au bas du backlog, alors ça n’a pas eu d’impact sur les items en cours de travail, mais c’est quand même beau de voir cette collaboration. Ceci a soulevé l’importance, pour moi, que le PO discute avec les intervenants du projet de façon régulière, avant de faire un planning, pour s’assurer qu’il apporte vraiment la valeur attendue pour le projet.

Au retour du diner, nous décidons comment nous allons gérer les autres jours du sprint 0. Étant donné le congé de Pâques qui tombe en plein milieu. Certaines personnes sont en congé vendredi, d’autres lundi. Ce n’est pas idéal selon moi, on fait une pause jusqu’à mardi (4 jours d’arrêt, incluant la fin de semaine). Une fois ceci clarifié, on se lance dans les règles d’équipe. Ça se passe assez bien. L’équipe hésite sur les timeboxes à se donner et se fie pas mal sur nos recommandations. Ils ne se donnent pas trop de règles autres que ce qui entoure les cérémonies de Scrum et se laisse de la place pour en découvrir durant l’itération (qui durera 2 semaines).

En fin de journée, il reste un petit peu de temps. J’en profite pour faire un petit rappel sur ce qu’est la dette technique. Ceci pour préparer l’équipe si elle décide de composer sa définition de terminé mardi. J’ai pris cette avance, parce que (autre chose que ne me plait pas) je dois être absent du sprint 0 mardi. L’équipe va quand même continuer, mais pour cette journée elle sera coachée par Hélène. En principe, l’équipe va continuer à découper le backlog et Hélène se sent en confiance pour cette partie.