Planning Game: Informations environnementales

Un article de Agile-Swiss.

Les user stories (U-S) étaient découpées sous forme de petites tâches saisies dans un simple bugtracker (phpbugtracker). Les priorités étaient données, voire changées en cours de dev par l'interlocuteur privilégié du client, ie le chef de projet. Les développeurs codaient les fonctionnalités prioritaires. Concernant la centralisation des U-S, les fonctionnalités étaient bien regroupées par groupe dans le tracker, les dépendances entre tâches aidant (une entrée dans phpbugtracker peut avoir plusieurs dépendances avec d'autres entrées). Cela dit ces U-S étaient "suggérées" par le client puis réellement "exprimées" par le chef de projet. Il pouvait donc y avoir encore une petite zone de floue lors du passage de l'état "suggéré" à l'état "exprimé". Sans grand impact en général puisque dans notre cas l'équipe était petite et la communication entre nous faisait qu'une demande client pouvait être précisée par une discussion chef de projet/client qui était facilement possible. Lorsqu'un besoin évoluait, les tâches associées étaient "réouvertes" dans le tracker, avec les descriptions associées.

A noter qu'il est difficile de convaincre d'utiliser les fiches bristol préconisées pour les user stories: encore une fois, dans ce projet, l'informatique a eu le dernier mot. La communication autour des fiches était un atout mais le fait de ne pas perdre ces fiches tenait presque du défi ;). De plus, en terme de traçabilité des fonctionnalités implémentées, les fonctions de recherche de l'outil en dépannaient plus d'un. Le fait que l'outil soit disponible via client léger facilitait la transparence avec la hiérarchie qui pouvait à tout moment vérifier l'état d'avancement de l'itération, ce qui contribue à une plus grande confiance générale

      client
      /    \
     /      \
 equipe --- management

<Contribution->Reste à parler des évaluations des tâches, de la vélocité, ...

Retour à la matrice des pratiques