Archives de catégorie : Agilité

Une opinion tranchée sur les formats de rétro.

Voici une opinion bien tranchée sur les rétrospectives, que je donne après en avoir suivi et animé des dizaines dans différents contextes, et après avoir échangé des collègues qui sont du même avis.

Garder le même format à chaque sprint

Garder le même format à chaque sprint permet aux participants de se concentrer sur le fond (les points d’amélioration) et non sur la forme. Les membres de l’équipes ont leurs repères, visualisent comment amener les points qu’ils ont repérés pendant le sprint, voire même revoient la rétrospective précédente et ses actions.

Changer de format à chaque sprint crée une habitude de l’imprévisibilité, chaque rétro est une découverte, sans repères pour les participants. On perd du temps en discussion sur la forme, les participants ne savent où et comment remonter leurs idées, etc…

Briser la routine de temps à autre avec un format différent est intéressant, mais cela doit être exceptionnel, par exemple tous les quatre ou cinq sprints. L’effet positif de la nouveauté ne peut être ressenti que s’il y a une routine à briser.

Rester sur les classiques

Je préfère les formats simples et classiques (type KALM, ou 4L, qui d’ailleurs se ressemblent beaucoup). Ils sont faciles à comprendre, permettent aux participants de remonter toute sorte de choses (problèmes, suggestions, améliorations, blagues…) et peuvent être adaptés en direct en ajoutant des votes, des étapes, ou en timeboxant si besoin.

D’ailleurs, un autre inconvénient du changement de format régulier est que l’on tombe parfois sur des formats qui ne permettent pas tous les types de retours, ou pas facilement, ou qui peuvent paraitre infantilisants (voir par exemple la montgolfière ou les petits cochons) (mais peut-être que c’est moi qui suis ennuyeux ?).

Historisation

Toutes les rétrospectives devraient être sauvegardées (dans le wiki de l’équipe ou outil équivalent), et on devrait commencer chaque séance en projetant la rétrospective précédente pour vérifier que les actions ont bien été menées, que l’équipe a progressé.

Le rappel permet également de renforcer le sentiment de continuité : on progresse de semaine en semaine, on se souvient d’où on en était avant, et en quoi c’était moins bien.

En résumé, un animateur de cérémonies doit mettre en place une routine de l’amélioration continue, ce qui passe par de la stabilité, de la simplicité et du suivi. Il peut amener de l’air en changeant parfois les choses, mais cela ne peut être intéressant que s’il y a une routine à briser.

Votre projet est un arbre

Elle est mal tenue cette forêt, il y a des arbres partout! — Obélix

En informatique on aime les patterns. Il a des trucs qu’on refait partout. Par exemple les arbres.

Les arbres, en informatique, sont des structures de données récursives, chaque élément est un noeud qui peut avoir des enfants, les éléments sans enfants sont des feuilles et… Enfin comme toujours le mieux c’est d’aller voir wikipédia. L’exemple typique c’est le système de fichier : les répertoires, les noeuds contiennent des répertoires, qui contiennent des fichiers, les feuilles.

Capture d’écran 2014-01-30 à 22.33.22

Et donc comme on aime les patterns on voit des arbres partout. Enfin moi en tout cas.

Par exemple dans les livres ou les articles : en général ils sont un plan, avec des chapitres,  des sous chapitres, etc… Ben ça fait un arbre :

I Le grand chapitre
    I.1 Petit chapitre premier
        1.1.a Le baba
            Le contenu du a
        1.1.b
            Contenu...
     [...]
II Le grand chapitre rouge

Autre exemple : les minds maps, technique de brainstorm. Ca se représente en étoile, mais si on le met à plat, ça reste quand même un arbre :

mm_languagelearning

Le code du projet est un arbre…

Idem pour le code : on a non seulement l’arbre du système de fichier avec les modules,  paquetages et classes, mais aussi les fonctions, avec les if, boucles, etc… le tout est arbre.

…Mais aussi le projet tout court

Il m’est venu à l’esprit qu’un projet, si on le prend comme un ensemble de tâches à réaliser est aussi un arbre : à la racine on a la tâche de plus haut niveau (le projet quoi), et puis on découpe et on affine en descendant, jusqu’à arriver aux trucs super bas niveaux du genre « importer la classe Machin » :

arbre

Bien sur, comme les arbres, les projets sont tous différents, votre projet peut-être un hibiscus, un baobab, un chêne, voir un peuplier (comme les roseaux).

So what ?

Explorer cette comparaison est intéressant. Ainsi :

Le niveau d’intérêt des protagonistes pour chaque étage de l’arbre varie en fonction de leur responsabilités.

Plus un exécutif est haut dans la hiérarchie (directeur de projet, CTO, …), moins sa vision sera proche des feuilles. Il explore l’arbre moins en profondeur.
Dragonnier millénaire

Remonter mentalement dans l’arbre permet de mieux comprendre le projet.

Pour comprendre un système il faut s’en extraire : passer à un niveau de réflexion de plus haut niveau permet de mieux comprendre les tâches en cours. Pour bien travailler, il faut comprendre le but du projet et sa structure générale. Et donc avoir une bonne vision de l’arbre, de ce qu’il y a à faire, et pourquoi.

Il possible de remonter de quelques niveaux pour changer de solution.

Quand on bute sur un problème ou qu’une solution s’avère inadaptée, plutôt que de s’acharner à la même profondeur, remonter de quelque niveaux permet de trouver peut-être une autre solution plus simple. Par exemple si on arrive pas à faire marcher une implémentation, plutôt que de s’acharner, on peut essayer de trouver une autre solution. On explore alors une autre branche.

On peut faire quoi avec les arbres ?

En théorie des graphes et en IA, on peut faire plein de trucs avec des arbres. Par exemple il y a des parcours en largeur et en profondeur. Comparons avec les méthodes de gestion de projets :

Parcours en largeur

Le cycle en V adopte plutôt un parcours en largeur du projet, explorant toutes branches et affinant la granularité jusqu’à arriver aux feuilles. On ratisse large, on analyse tout.

Parcours en profondeur

A l’inverse, en agilité, on fait plutôt un parcours en profondeur de certaines branches, par priorité. On explore les branches correspondants aux storys, et l’arbre est découvert (voire taillé) petit à petit.

Sur la même veine :

L’élagage

Lors d’une recherche en IA, on parle d‘élagage quand on ignore volontairement des branches pour accélérer. Pour un projet ce serait une réduction de périmètre.

L’équilibrage

Pour que  les recherches dans un arbre soient efficaces il faut qu’il soit équilibré. Dans la mesure où les tâches sont réparties entre des équipes et des personnes, l’équilibrage d’un projet est aussi intéressant.

Conclusion : Software craftmanship et taille-haie

Edward-ScissorhandsL’idée derrière le terme « software craftmanship » c’est qu’un développeur est plus un artisan qu’un ingénieur : il façonne une pièce unique avec ses mains, son savoir faire et les matériaux bruts qu’on lui fournit. Comme un artiste qui sculpte des troènes.

C’est peut-être à cause de tout cela qu’on parle tant de green-IT.

Chaque site ou application a, ou devrait, avoir une fonction unique formalisée

Petite réflexion du week-end : chaque application, chaque site a une ou des fonctions, qui peuvent normalement se résumer en une ou quelques phrases.

Exemples :

  • fnacspectacles : Vendre des billets de spectacles.
  • outlook.com : Permettre aux utilisateurs la consultation et la gestion de leurs mails en ligne.
  • facebook.com : Permettre aux utilisateurs d’échanger sur  leur actualité personnelle et de discuter.

Formaliser ?

Cette fonction est en générale implicite et évidente. Mais dans certains cas, elle gagnerait sans doute à être formalisé. On voit parfois des applications déesses qui font trop de choses, dont la fonction n’est pas clairement déterminée. Un exemple sur le web (pas forcément le meilleur, puisqu’il s’agit de la définition d’un portail, mais le premier qui m’est venu à l’esprit) : yahoo.fr qui fournit de la recherche, des actualités, un accès à des mails, …

On construit autour de cette fonction

Définir formellement, la mission, la fonction maitresse d’un site ou d’une application permet de mieux définir et de mieux prioriser le besoin et les fonctionnalités : on construit pour et autour de cette fonction.

Référence

De plus cela permet, en cas de doute, d’avoir une référence. La question « est-ce que cette fonctionnalité doit être implémentée/mise en avant ? » devient « est-ce que cela correspond à la fonction de mon application ? ». A chaque questionnement sur le design ou le planning, on peut se référer au but déclaré du projet.

Mobile-first

On dit souvent qu’il faut construire d’abord pour les mobiles, puisque l’espace limité sur l’écran permet de choisir la/les fonctionnalités importantes, à mettre en avant sur tous les supports. Définir formellement la mission de l’application va dans le même sens : qu’est-ce qui est essentiel ?

Fortement lié au business model

Bien sur cette mission est en général fortement corréllée au business model. Dans le cas de facebook par exemple, les auteurs ont tout intérêt à ce que les utilisateurs passent le plus de temps possible sur le site afin d’augmenter les chances qu’ils cliquent sur une des publicités, ciblées avec leurs données. De même le site de fnac spectacles comporte de nombreux liens vers fnac.com.