Scrum - Méthodes agiles

Un plan de release permet d'avoir la connaissance actualisée de ce qui va être fourni au long des sprints de la release. C'est une projection du backlog sur les sprints qui constituent la release.

Lire la suite -->

Done done

Lire la suite -->

Une discussion récente avec un acheteur d'une grande administration m'a conforté dans l'idée que le contrat au forfait n'est pas un obstacle à l'introduction de l'agilité. Au contraire, l'agilité apparaît comme une voie à suivre pour éviter les difficultés rencontrées dans les contrats actuels.

Lire la suite -->

Sur 2 projets Scrum que je coache actuellement nous avons eu à peu près le même besoin, lié à la collecte du feedback.

Lire la suite -->

J'avais proposé aux étudiants de l'IUP ISI de venir au SigmaT5 présenter un retour d'expérience de l'utilisation de Scrum ou XP sur leurs projets. Ils ont tous suivi un enseignement des méthodes agiles et pratiqué sur leur projet.

Seuls 2 étudiants du projet Wilos se sont portés volontaires(l'équipe IceScrum a aussi participé activement au SigmaT5). Ils ont présenté les points notables de l'utilisation de Scrum sur le projet, en particulier les scrums de scrums et l'utilisation de GoogleDocs pour le travail collaboratif (j'en avais parlé au début). Je joins leur présentation (ppt) à ce billet. Elle contient les liens actifs vers les backlogs GoogleDocs.

Y figurent aussi deux dinosaures. Comment je dois le prendre ?

Dans les applications Web, il existe souvent un rôle secondaire qui a accès à des informations seulement en lecture et qui a besoin d'une ergonomie particulière, soit parce que les personnes qui jouent le rôle ne sont pas expertes dans l'utilisation de l'outil informatique, soit parce que les informations doivent constituer un tableau de bord facilement lisible et permettre d'avoir une vue synthétique. L'ergonomie est essentielle et fait que ces exigences ne sont pas des histoires comme les autres.

Je retrouve ce genre d'exigences dans les 3 projets que je suis actuellement. Dans une première approche, elles sont insérées dans le backlog. Pour les identifier, elles sont classées dans la catégorie (thème) Utilisabilité. Leur traitement nécessite une approche spéciale.

En effet, dans les méthodes agiles, un élément du backlog (une histoire d’utilisateur) est censé être fini à la fin d’une itération et donc ses tests passés. Pour ces exigences concernées par l’utilisabilité, la notion de fini ne repose pas sur des tests qu'on peut décrire à l'avance. Les conditions de satisfaction sont la facilité de compréhension, la facilité d’apprentissage et l'attractivité qui s'évaluent en utilisant. Fini signifie obligatoirement passer par du feedback des utilisateurs et cela ne peut généralement pas être fait à l’intérieur d’une itération. Les utilisateurs potentiels, qui apporteront le feedback, doivent obtenir une première version, l’utiliser pour éventuellement demander de changer le contenu et proposer des évolutions d'IHM.

La solution pour anticiper le feedback du point de vue de la gestion de projet est de scinder une exigence d’utilisabilité en 2 histoires d’utilisateur incluses dans le backlog :

1. une première qui définit ce qui sera fait pour la première version
2. une deuxième comme réceptacle du feedback des utilisateurs à la vue de la première version

Evidemment la quantité de feedback n’est pas connue à l’avance. Cependant pour prendre en compte cette histoire dans les plannings, il est possible d’utiliser un coefficient pour l’estimer. Par exemple 30%, ce qui donnerait avec une estimation à 3 de la première version, une estimation de 1 pour la seconde.

Avec ce principe, une exigence d'utilisabilité est représentée dans le backlog par 2 histoires d’utilisateur, avec le même nom suffixé par version 1 et version 2.

Cela implique qu’elle ne sera pas finie en une itération, mais en au moins 2 et probablement 3 :

• une pour réaliser la première version
• une pour utiliser et remonter du feedback
• une troisième pour réaliser la deuxième version

Il conviendra d’organiser les livraisons aux utilisateurs pouvant apporter du feedback et de faire en sorte de l’inscrire dans le créneau ad hoc.

Alistair Cockburn, dans son article Three cards for user rights, suggère de systématiser cette pratique à toutes les stories et de faire trois entrées pour chacune. Intéressant pour favoriser le feedback au delà du Product Owner, mais cela demande de bien maîtriser le processus et la gestion du backlog. Il faut pour cela un bon Product Owner qui maintienne scrupuleusement le backlog, ce qui n'est pas fréquent si on en croit David.

Que faire des bugs relatifs à une user story et découverts dans un sprint postérieur à la réalisation de cette story ?

Lire la suite -->

On peut essayer la télépathie pour le communiquer efficacement...

Lire la suite -->

Un élément du backlog doit amener de la valeur, en principe

Lire la suite -->

Les mettre dans le backlog, comme tout le monde !

Lire la suite -->

Avec l'utilisation des listes

Lire la suite -->

Avec l'avis du consultant...

Lire la suite -->