Exemple de backlog et utilisation de la valeur métier

Pour illustrer la mise en place d’un backlog et de l’ algorithme de valeur métier rien de tel qu’un exemple pratique. A l’instar des « coding dojos », le principe du projet SudokuGame est de mettre  en œuvre certains principes dans un projet sans enjeu industriel. Le backlog complet après 6 itérations est disponible ici.

Définition des utilisateurs

On ne considère qu’un seul utilisateur : le joueur qui fait une partie de sudoku. Il joue pour son loisir mais essaye de s’améliorer. Il peut faire une partie sur plusieurs jours.

Écriture des « epics »

Les « epics » sont définis en terme de lot de fonctionnalités. Pour les définir on se pose les questions suivantes : Quels groupes de fonctionnalités l’utilisateur est il prêt à essayer ? Quels sont les lots qu’il est prêt à payer ? Si on retire une fonctionnalité, l' »epic » intéresse-t-il toujours l’utilisateur ?

Définition de l’algorithme de valeur métier

L’algorithme qui a été mis en place est le suivant :

Valeur epic = Nécessité + Satisfaction utilisateur

Les deux grandeurs sont estimées par deux entiers.

Répartition de la valeur métier sur les user-sory

  • La valeur de chaque epic est répartie équitablement sur chaque user story qui le compose
  • Ensuite la valeur de chaque US est pondérée par l’estimation de l’effort (colonne valeur / cout).
  • On essaye de fixer les priorités en fonction de cette valeur.

Petite rétrospective

  • La valeur métier comme indicateur : lorsque l’on ne veut pas suivre l’algorithme c’est peut être qu’il y a un problème de découpage. Par exemple en début de projet il n’y avait qu’un seul epic « confort de jeu », dès la deuxième itération on se rend compte qu’il y a des fonctions de confort qui son indispensable pour l’utilisateur. L’épique est alors divisé en deux avec une nouvelle répartition de la valeur.
  • Pas facile d’être PO. Sur un projet simple, même lorsque le PO est lui même l’utilisateur final, on arrive pas forcément à fixer les priorités au début du projet. (La sauvegarde de la partie en cours était tout en bas dans les priorités mais est très vite devenue indispensable après quelques démos). Vive l’itératif !
  • Le problème de cet algorithme est qu’il repose uniquement sur des grandeurs arbitraires difficiles à pondérer.
Références:
User stories applied – Mike Cohn
http://www.xp.be/businessvaluegame/
Laisser un commentaire

100 % tested – comment jardiner les tests automatiques

Dernièrement je suis intervenu dans une équipe qui débutait dans la pratique de Scrum et n’avait pas la culture « tests automatiques ». La pratique de Scrum et notamment la perte de propriété du code est périlleuse sans une forte utilisation de tests automatiques. En effet quand on est tout seul responsable de son code, on se passe généralement de tests auto vu qu’on se porte garant à la fois des non régressions et de la cohérence du code. Dans une équipe conséquente, où plusieurs personnes peuvent intervenir sur les mêmes parties du code on perd cette centralisation.

Voici la petite recette que j’ai utilisée pour jardiner la culture test :

  • Commencer par tester tout le code qu’on produit soi-même (balayer devant sa porte… 🙂 )
  • A chaque fois qu’un développeur fait passer au rouge, ne pas le laisser tout seul, l’aider à tout remettre au vert, et identifier le comportement mis en défaut.
  • Pair programmer pour montrer comment on peut faire des tests petits et simples
  • Pair programmer pour montrer comment on peut appréhender le TDD
  • Être un peu « intégriste » : un bug trouvé est une fonctionnalité non testée
  • Utiliser des outils pour afficher la couverture de code (voir des zones à 100% est  très motivant)

Par l’exemple, en refusant de fournir du code non testé, l’équipe s’est peu à peu rendue compte des avantages des tests automatiques. Au bout de 4 mois  de projet j’ai commencé à entendre des phrases du type : « Si les tests ne passent pas c’est que j’ai changé du comportement… », « J’ai encore du mal avec le test before, mais je comprend l’utilité du test auto », « J’ai été convaincu de l’utilité du test unitaire, c’est indispensable pour pouvoir faire des évolutions sereinement », « Quand je code un comportement, je suis serein lorsque d’autres personnes développent sur le même code car tout changement est signalé ».

Les tests auto sont une ceinture de sécurité et quand on n’en a plus on se sent un peu nu 🙂

Laisser un commentaire

Profils agiles et profils d’équipe

Hier j’ai assisté pour la première fois à une « rencontre autour de l’agilité » organisée par le CARA. Jérôme Barrand  nous a présenté « l’Agile profile » qu’il utilise dans ses échanges avec les équipes de management. L’approche de Jérôme est intéressante dans le sens où il ne vient  pas du monde informatique. Il est l’auteur  du livre « Le manager agile » qu’il avait présenté en ouverture de l’Agile Tour 2008.
Le profil est une projection de l’individu sur 6 comportements répartis sur 3 principes :
ANTICIPACTION
(Agir et anticiper la conséquence)
PROOPERATION
(Coopération réciproque / échange de satisfaction)
JUSTINOVATION
(Juste ce qu’il faut au bon moment)
Intuition
pro-action
Empathie systémique
Synchronisation
Rébellion constructive
Pédagogie managériale

Jérôme nous a ensuite montré comment les méthodes agiles de nos systèmes d’informatiques encourageait ces comportements :

  • Daily meeting pour la synchronisation
  • Rétrospectives pour la rébellion constructive
  • Dashboard visuel : pour la vision systémique

D’après lui l’agilité d’une équipe est renforcée lorsqu’il ne manque pas d’individus moteurs dans chaque comportement.

Merci à Jérôme Barand et au CARA pour cette conférence.
Je lui mets 4/5 au ROTI.
J’aurais mis 5 si on avait pu plus échanger sur les parallèles avec le développement informatique.

Un commentaire

Votre architecture est elle SOLID ?

Non il ne s’agit pas d’une publicité pour vous vendre un audit sur l’architecture de vos concurrent 😉 mais bien de patterns d’architecture définis par Robert C. Martin.

Comme on peut le lire dans wikipedia, SOLID est un acronyme pour définir les 5 principes :

  • Single Responsability
    • Un objet n’est responsable que d’une chose
  • Open/Close
    • L’objet doit être ouvert au extension de comportement sans modification du code
  • Liscov Substitution
    • On doit pouvoir substituer un objet par un autre de classe dérivée
  • Interface segregation
    • Multiplier les interfaces plutôt que d’avoir une interface à tout faire
  • Dependency inversion.
    • Les objets doivent dépendre d’interfaces pas de classes concrètes

On trouve un document de Robert C. Martin très complet sur le sujet ici.  Sa lecture donne envie de se procurer le livre du même auteur Clean Code.

L’article fournit quelques indicateurs pour mesurer la SOLIDité de l’architecture. Certains sont facile à mettre en œuvre :

  • Sur un objet compter le nombre de responsabilité (facile)
  • L’utilisation de if / switch sur les types d’objets peuvent indiquer une violation du principe Open/Close
  • Compter le nombre d’interfaces d’un objet et visualiser les dépendances vers les classes concrètes

D’autres plus compliqués sans outils adéquat :

  • Rapport des dépendances entrantes vs dépendances sortantes d’un package
  • Détecter les violations du principe de Liscov

En analysant ces critères sur son code, on ne trouve pas son architecture toujours aussi SOLID. Etonnamment on n’aime pas avoir à intervenir sur du code FRAGILE 😉

Laisser un commentaire

Planning poker : régulateur de discussion

Dernièrement en réunion de planning nous avons eu un bel exemple de l’utilisation du planning poker comme régulateur de discussion. Nous devions estimer une user story qui consistait à réaliser un prototype pour un client. Après avoir négocié le périmètre fonctionnel avec le product owner, le débat s’est vite orienté sur la pertinence de telle architecture par rapport à telle autre. Au bout de quelques minutes de discussion, nous avons arrêté le débat pour estimer une des deux propositions. Comme souvent après deux “plis” de planning poker les estimations ont convergé. Nous avons décidés de ne pas aller plus loin en estimant l’autre architecture car nous avons convenu qu’elle n’allait pas diverger suffisamment. Le débat sur l’architecture a été reporté à plus tard, c’est à dire au moment où la user story sera réalisée.

Souvent nous avons tendance à alimenter le débat avant les premières estimations. On voit ici que cela n’est pas toujours pertinent. Je pense cependant qu’il faut faire attention et vérifier que chaque personne ait pu exprimer son point de vue avant de conclure avec des estimations convergentes. En tous cas c’est une idée pour faire avancer les choses lorsque le débat tourne un peu en rond.

Laisser un commentaire

Code Retreat à Grenoble : mise en oeuvre de pratiques extrem programming

Vendredi dernier j’ai participé à une session de Code Retreat à Grenoble organisée par le CARA et le JUG. Merci aux organisateurs pour cette belle journée.

Le principe :

La scéance comporte 6 itérations. Le principe du code retreat réside dans le fait d’effacer le code à chaque itération . L’analogie aux arts martiaux tient dans l’idée de travailler plusieurs fois le même geste pour se perfectionner.

Le travaille est réalisé en TDD et en Pair programming. L’objectif est d’investiguer les pistes que l’on ne se permet pas dans un cadre industriel. Une consigne supplémentaire est d’appliquer les règles SIMPLE DESIGN :

1 – Les tests doivent passer
2 – Supprimer les doublons
3 – Nommage pertinent
4 – Faire court

Une itération se compose de :45 min de code, 10 min de rétrospective, 5 minutes de pause.

Ce que m’ont apporté ces itérations :

Pair programming de 10 minutes : l’idée est de changer de rôle toutes les 10 minutes : le pilote devient copilote et vis versa. La sensation est grisante : on a l’impression de courir une course de relais. S’échanger le clavier si souvent oblige à partager le design et la direction où l’on veut aller.

Mesurer le temps de cycle rouge : le TDD définit trois phases : une rouge pendant laquelle le test ne passe pas, une verte lorsque le test passe, et une dernière de refactoring. On s’attache à minimiser le temps de phase rouge en dessous de 5 minutes. L’exercice est intéressant car il oblige à ne pas prendre trop d’avance dans le design et à ne coder que ce qu’il faut pour que le test passe. Cela implique une réflexion sur les contraintes nécessaires pour garantir que le programme fonctionne.

Nouvel indicateur de design : facile à mettre en œuvre, si l’on a un « if » sur un état on peut éventuellement le supprimer en implémentant des classes dérivées.

Refactorisation des tests : attention à ne pas introduire des bugs dans la couverture de test sans s’en rendre compte. C’est pour moi le bémol de cette approche : comment garantie-t-on l’intégrité des tests si on les modifie ?

Le rôle du copilote : en recentrant les questions sur ce que l’on veut faire et les contraintes que l’on s’est donnée, le copilote influe directement sur la productivité. Il limite ainsi une tendance naturelle à s’éparpiller.

Le test comme guide pour le design : stressé par un design complexe, on a souvent tendance à anticiper et à écrire du code en avance alors qu’il n’est pas nécessaire. En essayant de limiter le temps rouge, le design nait de l’analyse de toutes les contraintes plutôt que des aprioris que l’on peut avoir en abordant le problème.

En conclusion :

  • Bilan très positif : 4/5 au ROTI. Il m’a peut-être manqué deux minutes de rétrospective en binôme avant de mettre en commun avec les autres participants.
  • Nouvelle facette du pair programming en changeant toute les 10 minutes : à essayer !
  • TDD : Ne pas trop se poser des problèmes de design en cours de test. Vraiment se concentrer sur l’aspect spécification. Ce sont les tests qui vont nous montrer la voie, il faut leur faire confiance.
  • Cette exercice est très bon pour enrichir ses approches. Promis j’essaierais de venir aux prochains Coding Dojos du CARA.
  • Attention au refactoring des tests.
Laisser un commentaire

Rétrospective 2010

Voici venu le temps de la rétrospective annuelle sur ce blog en particulier et l’agilité en général.

Continuer la lecture

6 commentaires

Méli mélo sur les conférences Agile Grenoble 2010

Cette année était encore une fois riche en information et partage d’expérience. Cette fois-ci j’ai pu assister à toutes les sessions que j’avais choisies sans jouer des coudes ;). Voici pèle-mêle quelques lignes sur mon ressenti.

Continuer la lecture

Laisser un commentaire

Agile Grenoble 2010 / J -5

Plus que quelques jours avant Agile Grenoble 2010 !!! Ce sera la troisième fois que j’assiste à ces conférences et j’espère que celles-ci seront aussi enrichissantes que les autres.

Le programme est disponible en ligne : http://agile-grenoble.org/programme

Comme d’habitude il est très riche et c’est difficile de choisir :).

Cette fois-ci j’essaierais d’assister aux sessions suivantes :

Laisser un commentaire

XP Business value game

Il y a six mois, un article de Claude Aubry éveille ma curiosité à propos du jeu XP Business Value Game. Trop pressé pour attendre d’y jouer dans un séminaire, voici comment je me suis lancé dans l’organisation et l’encadrement d’une session au sein mon entreprise.

Ce jeu est le complément du XP Game. XP Game a pour objectif d’illustrer les principes de eXtrem Programing de manière ludique. XP Business Value Game place le point de vue à l’extérieur de l’équipe de R&D et se concentre sur comment produire de la valeur en répondant à des demandes client.

En avril dernier après avoir imprimé gratuitement le jeu sur XP.be, nous nous sommes lancé dans une session lors de la pause déjeuner. Avec 12 participants, nous avons formé deux équipes composées de personnes de métiers différents (R&D, marketing, service client, commerciaux). Tous avaient entendu parlé de SCRUM, une petite moitié l’avait déjà pratiqué.

Le retour des participants a été plutôt bon : l’analogie entre le  jeu et la gestion de projets réels est étonnante. Voici les principales difficultés que j’ai rencontrées :

  • Animer 2 équipes n’est pas facile pour une première session.
  • Le timing est dur à tenir : les participants doivent faire des choix dans un temps assez court. Cela se complique lorsqu’il y a des débats dans une équipe.
  • Comme nous étions en retard, les débriefings qui ponctuent la session ont été très sommaires.

L’objectif du jeu est d’apprendre à définir un algorithme pour aider à affecter les priorités. Aujourd’hui nous n’avons pas encore d’algorithme de valeur métier dans l’entreprise. Cette expérience me sert surtout à poser certaines questions lorsqu’il est difficile de définir des priorités.

Si je devais recommencer, je ferais une session avec une seule équipe (même si cela a l’avantage de créer un peu de compétition)  et préparerais les débriefings. Je regrette seulement de ne pas avoir pu jouer avant d’encadrer, car le jeu comporte quelques surprises qui perdent de leur charme quand on a lu les règles.

Laisser un commentaire