La vie d'un item dans IceScrum

Scrum, ça se présente de façon simple : on a un backlog de produit dans lequel on inclut tous les travaux à faire (on les appelle des items). Et on les fait sprint par sprint. Quand on développe un outil (IceScrum) qu'on veut vraiment utile tout en restant simple, ça se complique un peu.

Un item (IBP) possède les attributs suivants dans IceScrum :

  • son énoncé (sous forme d'exigence)
  • son thème (ou domaine fonctionnel)
  • son type (par exemple user story, exigence non fonctionnelle, demande de changement)
  • son estimation en points (estimation relative fonction de la grandeur de l'IBP). Cette estimation est donnée par l'équipe.
  • sa valeur pour le client (optionnel)
  • éventuellement les tests de recette (acceptance test) associés à l'item

En fonction de la priorité définie par le directeur produit, un item est associé à un sprint, lors de la réunion de planification en début de sprint. Pendant le sprint, l'item est réalisé (c'est à dire analysé, conçu, codé, testé). A la fin du sprint si tout s'est bien passé, il est considéré comme terminé.

Jusque là, c'est simple : un item est créé, sélectionné pour être développé dans le sprint courant, puis terminé. Cependant le processus qui permet la sélection n'est pas instantané. Un item doit d'abord être estimé (en points). Cela se fait généralement lors d'un workshop avec l'équipe, bien avant (pour les items créés en début de release) ou un peu avant (pour les items ajoutés ensuite) que les items puissent être sélectionnés pour un sprint. La sélection officielle (comme à Cannes !) est définie lors de la réunion de planification.

Dans IceScrum, nous avons décidé qu'un sprint était en phase de "préparation" à partir du moment où il devient le prochain sprint (c'est à dire celui qui suit le sprint en cours) jusqu'à ce qu'il soit "activé", à la fin de la réunion de planification. Cela permet d'offrir, dans l'outil, des facilités pour faciliter la sélection.

La vie d'un item passe alors par les états suivants :

  • créé
  • estimé
  • associé au sprint en préparation (le prochain sprint)
  • associé au sprint courant (on le réalise)
  • réalisé (terminé)

Voici le diagramme d'états complet du comportement qui sera dans IceScrum :

Etats d'un élément de backlog

Commentaires

1. Le vendredi 12 mai 2006, 08:37 par Cédric

Pour rester dans la philosophie de Scrum, moins il y aura de contraintes, de contrôles et plus l'outil sera intéressant et souple, s'adaptant ainsi à des environnements de travail différents.
La notion de sprint en préparation "force" les utilisateurs à se focaliser sur ce qui se passe sur le moment (réactivité accrue, tests plus pertinents, etc) plutôt que de perdre du temps à planifier très loin pour finalement s'apercevoir que ce que l'on réalise effectivement est différent.
Ceci dit, l'outil peut faire seul une planification, en proposant d'associer automatiquement les IBP aux sprints à venir en fonction de la vélocité calculée. Ceci permettrai quand même de pouvoir anticiper les délais, coûts, etc.

2. Le lundi 15 mai 2006, 08:54 par claude aubry

La planification de la release consiste à associer les exigences aux sprints prévus. Un outil peut faciliter cette association en se basant sur la vélocité. Au début on utilisera une vélocité estimée.