Walking Skeleton
Pas sûr qu’Alistair Cockburn ait choisi la meilleure métaphore quand il a conceptualisé cette étape du développement logiciel, tant les squelettes ont la fâcheuse habitude de faire peur… Cependant, la métaphore fonctionne, si l’on considère que les os matérialisent l’architecture du logiciel tandis que la chair, absente, représente ses fonctionnalités.
Poser des bases saines pour minimiser la dette technique
Voici donc la définition du Walking Skeleton :
A Walking Skeleton is a tiny implementation of the system that performs a small end-to-end function. It needs not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.
Autrement dit, la fonctionnalité en question importe peu. Elle n’est qu’un prétexte à poser des fondations, de solides fondations techniques sur lesquelles s’appuieront ensuite les fonctionnalités à venir. Meilleures seront les fondations, plus le développement de ces fonctionnalités sera facile. C’est à la fois une question de contrôle de la dette technique et de Developer eXperience (DX).
Le Walking Skeleton se positionne entre le POC (possiblement les POCs d’ailleurs) et le MVP, qui représente une quantité de travail substantielle – du moins si l’on s’accorde à cette définition. Mais même sans adhérer à cette définition, il y a bien un moment où vous déciderez de construire « du solide », et à ce moment-là il sera question de Walking Skeleton.
Liste non exhaustive des sujets à aborder
Concrètement, cela implique d’aborder a minima les sujets suivants :
- L’architecture, forcément « à date » (nous y reviendrons juste après) ;
- L’authentification et la gestion des droits applicatifs ;
- Plus largement toutes les bonnes pratiques de sécurité (ex : programmation défensive) ;
- Les conventions de nommage et de style (leur absence crée des inhomogénéités, donc de la dette) ;
- Les pratiques de test et d’écriture de code (entre autres le Test-Driven Development) ;
- La mise en place d’une CI/CD (plus ça fait mal, plus il faut anticiper) ;
- La gestion des logs en production (indispensable au debug) ;
- À cela j’ajouterais volontiers l’implémentation du Design System, si cela n’a pas déjà été fait ;
- etc.
L’idée est de permettre ensuite des développements production ready : vous ne voulez pas découvrir toutes ces problématiques au moment de passer en production (+3 mois dans la vue) ou en production (dette technique, failles de sécurité).
Dans la définition ci-dessus, l’expression « evolve in parallel » est la clef : il serait en effet illusoire de vouloir graver toutes ces décisions dans le marbre. Des fonctionnalités apporteront tôt ou tard de nouvelles contraintes, qui conduiront l’équipe à revenir sur certaines décisions à la marge.
L’occasion de documenter vos décisions d’architecture
Pour faire en sorte que cela se passe bien, l’équipe aura tout intérêt à initialiser un Architecture Decision Record (ADR) lors de la mise en place du Walking Skeleton. L’ADR expose les tenants et aboutissants de chaque décision, ce qui évite de remettre périodiquement les mêmes sujets sur le tapis. En effet, si le contexte n’a pas changé et que les résultats sont là, une décision ne doit pas être remise en question.
À bien y regarder, de nombreuses équipes procèdent à la mise en place d’un Walking Skeleton sans vraiment s’en rendre compte, lorsque viennent les premières « grosses » fonctionnalités. Alistair Cockburn — celui-là même à l’origine de l’architecture hexagonale — a eu le mérite de rendre la démarche explicite et, ce faisant, de la dissocier de l’implémentation des fonctionnalités.