Thierry Cros Organisation

l’Extreme Programming garde aujourd’hui une image centrée Développement. Certes, XP est intrinsèquement dédié au Développement. C’est du Lean appliqué. Si l’activité, dans la création de logiciels, qui crée la valeur est le Développement, alors centrons-nous vraiment, extrêmement… sur cette activité. C’est aussi simple. Et XP est bien plus riche. Examinons aujourd’hui l’Exploration, première phase du cycle de vie d’un produit logiciel.

Le cycle de vie XP

Voici un extrait de mon (vieux) support de cours XP. Le cycle de vie d’un logiciel est constitué de deux phases importantes : l’Exploration et le « pilotage par feedback ». Intéressons-nous à l’Exploration.

Trois axes exploratoires

• Périmètre initial : de quoi avons-nous besoin ?
• Architecture initiale : savons-nous faire ? Quelle solution évolutive ?
• Organisation : comment allons-nous fonctionner au départ ?

Précisons tout de suite que chaque élément considéré devrait être systématiquement qualifié par quelque expression du style « en l’état actuel ». Autrement dit, rien de définitif.

Principes de l’Extreme Programming

Gardons à l’esprit ces principes essentiels d’XP.

• Rapid and concrete feedback : c’est une déclinaison du Just in Time du Lean, ou, si vous préférez, de « Petits stocks » ,
• Assume simplicity : que l’on retrouve dans le 10ème principe du Manifeste agile ;
• Incremental change : de petits changements incrémentaux, ce que l’on retrouve dans les premiers principes du Manifeste
• Embracing change : accueillir le changement car… that’s Life!
• Quality work : d’où les pratiques de type Test 1st Programming, qui traduisent dans le domaine du logiciel le principe de qualité intrinsèque du Lean. Et bien d’autres, comme le Pair Programming ou le Clean Code.

Périmètre et besoins

Dans XPE2E, deuxième édition de Extreme Programming Explained, Kent Beck propose, sans vraiment le dire d’ailleurs…, une expression de vision de produit qui me semble très pertinente, basée sur trois questions concernant le produit : quels sont les faits, les hypothèses, l’intention ?

Aujourd’hui, le Lean Canvas est utilisé. Pourvu que les infos soient notées « fait » ou « hypothèse ». Les hypothèses deviennent naturellement les idées confirmées (ou pas…) dans la boucle de feedback du Lean Starup.

Enfin, l’Exploration peut permettre d’initialiser les listes de features et stories.

De l’Extreme Programming à SAFe

J’ai déjà dit que pour ma part, SAFe est de l’Extreme Progamming à l’échelle. Je parle du cadre, pas du Business Model.

Voir Kanban Features dans SAFe pour plus de précisions sur les activités proposées pour transformer une idée en valeur. l’Activité ou état d’analyse nous intéresse particulièrement. Le cas échéant, cela peut s’appliquer à l’état « Analyse » du portfolio. Notez au passage le clin d’œil : c’est l’exploration continue dans SAFe.

Architecture initiale

Cette phase peut aussi permettre de créer un skeleton, histoire de se rassurer sur la faisabilité. De ce skeleton émergera au fur et à mesure l’architecture du produit. Dans le cadre d’une architecture intentionnelle de SAFe par exemple.

Constitution d’équipe

Enfin, l’Exploration permet aussi de constituer les bases du fonctionnement de l’équipe, par exemple grâce à un Team Canvas. C’est aussi le bon moment pour se poser la question de l’outillage : gestion des stories, de la configuration, de l’automatisation des tests…

Séquence Nostalgie

Pour plus d’infos sur l’Extreme Programming, canal historique, je vous renvoie vers le site de référence inter-galactique : le wiki c2 !