Chez Ulysse nous utilisons un cycle de développement qui tire quelques principes de ShapeUp — je vous invite à lire le livre, il est en libre accès.

Forcément nous n’appliquons pas exactement les préceptes de ShapeUp. Nous sommes sans doute même assez loin de la méthode initiale. D’abord nous ne sommes pas la même boîte, pas le même nombre de personnes, pas les mêmes enjeux. Nous sommes différents. Et si l’apprentissage passe par le mimétisme, l’émancipation est l’art de construire son propre chemin.

A l’heure où j’écris cet article, nous sommes 15 dans l’équipe technique et produit. Nous ne formons pour le moment qu’une seule et même équipe.

Nous avons choisi des cycles de 5 semaines. Pourquoi ? Je pourrais répondre exactement comme dans le bouquin : il nous a semblé que c’était assez long pour construire des projets importants et assez court pour ressentir la deadline ;)

Nous alternons 3 phases : Shape (1 semaine), Build (3 semaines) et le Cooldown (1 semaine).

Collecter les idées

Tout commence dans le cycle précédent. Plus qu’un cycle, une boucle. Puisque chaque cycle nourrit le cycle suivant.

Tout au long du cycle, les idées sont collectées. À la fin de la semaine de Cooldown, elles passent dans un framework que l’on appelle la priorisation. L’objectif est de définir ce que nous allons potentiellement étudier et réaliser dans le cycle suivant. Elles sont sélectionnées en fonction de nos objectifs, des besoins plus ou moins urgents qui se dessinent, de nos envies …
Nous définissons alors ce qui relève de l’inconnu, qui a besoin d’être spécifié et à l'inverse ce qui est parfaitement maîtrisé dont le développement pourrait commencer immédiatement. Tout ce qui fait partie de la première catégorie sera shape. C'est-à-dire dans notre jargon : étudié et dérisqué.

Dérisquer ensemble

Pendant une semaine entière, toute l’équipe va étudier les différents projets, imaginer le champs des possibles, rechercher des acteurs sur le marché qui pourraient nous aider, évaluer la complexité et le risque que ce projet ne puisse se faire dans les 3 semaines de build, définir un scope, potentiellement aller jusqu’à la conception de l’API d’échange entre le backend et le frontend.

J’apprécie vraiment cette idée que toute l’équipe soit en effervescence, qu’elle réfléchisse ensemble, échange. Nous sommes à la fois pleinement disponibles pour les réflexions durant cette phase et aussi pleinement disponibles pour le développement pendant la phase de build. En plus de construire le produit, les développeurs participent également à sa création. D’après moi c’est une des forces du cycle.

De cette étude, en ressortiront pour chaque projet étudié un pitch. Le pitch décrit le contexte, les éléments de solution, le scope imaginé, les risques potentiels de dérive auxquels il faudra être attentif et possiblement l’équipe qu’il faudrait pour le réaliser.  Certains pitchs peuvent même conclure que le jeu n’en vaut pas la chandelle.

Définition du build

En fin de Shape, nous construisons les trois semaines de Build, en prenant soin de mixer les projets. Nous ne choisissons qu’un long projet (au plus), quelques projets courts et des petites améliorations. Tous les projets qui ont été étudiés ne sont pas nécessairement choisis.

Nous voulons à la fois pouvoir ajouter plusieurs petites fonctionnalités qui auraient de l’impact pour l’utilisateur, sans s’empêcher de construire des gros projets ou de se lancer dans des chantiers conséquents.

Remise en question

Je vous passe le Build, non pas qu’il soit inintéressant puisque c’est ici que tout se construit. Cependant il ressemble sans doute à tous les suivis de sprints/itérations.

Nous arrivons alors au Cooldown. Outre le fait que pour l’instant nous avons encore trop l’habitude de profiter de ce moment pour terminer nos projets, cette phase reste cruciale. C’est le moment où nous faisons une démo à toute la boîte de ce que nous avons construit et, plus important encore, nous nous remettons en question, nous nous questionnons pour simplement itérer sur le fonctionnement du cycle lui-même.

Très certainement que la prochaine fois que nous écrirons sur le sujet, nous aurons déjà fait évoluer notre process.

**

Tout process peut s’améliorer, je serai ravi d’échanger avec vous sur votre façon de fonctionner. N’hésitez pas à me contacter !