Stratégies de livraison

Dans un précédent billet nous avions vu l’importance de livrer de la valeur aux utilisateurs, nous allons donc ici nous intéresser aux différentes stratégies de livraison qu’il est possible de mettre en place pour livrer cette fameuse valeur.

Nous verrons, entre autre, comment une bonne stratégie de livraison permet d’aligner la solution développée avec les vrais besoins des utilisateurs.

Pour information ce billet reprend les stratégies de livraison que l’on peut retrouver dans les différentes présentations d’Henrik Kniberg.

La livraison « Bigbang »

HK_BigBangÉvidemment c’est le modèle de livraison le plus connu, on le retrouve traditionnellement dans les projets conduits en cascade ou dans un mode « Agile à minima » (ou Water-Scrum-Fall). Le produit est livré lorsqu’il est considéré comme terminé, et par « terminé » on entend que toutes les fonctionnalités prévues, en amont, ont été développées, et testées (dans le meilleur des cas).

Ce modèle de livraison offre malheureusement un risque élevé de livrer un produit qui ne correspond pas aux attentes des utilisateurs. En effet, dans ce modèle de développement (qui peut-être itératif) les utilisateurs sont souvent peu ou pas impliqués.

Nous retrouvons généralement ce type de stratégie dans les développements conduits en mode projet.

La livraison itérative

C’est la stratégie de livraison que l’on retrouve le plus souvent en agilité. Dans ce HK_BigIncrementmodèle la solution logicielle est livrée de façon itérative, généralement à la fin d’une itération ou d’un nombre fixe d’itérations. Chaque livraison comporte plusieurs améliorations/modifications à la solution logicielle, ce qu’Henrik Kniberg appelle « Big Increments ». Le contenu de ces livraisons est généralement défini dans ce que l’on appelle des plans de livraisons.

Le modèle reste avantageux par rapport au modèle « Bigbang » mais il pousse souvent le Product Owner à attendre qu’une fonctionnalité soit développée dans sa totalité avant de la livrer. Risquant ainsi de livrer, après de longs efforts, une fonctionnalité qui n’apporte pas ou peu de valeur à ses clients.

La livraison continue

HK_SmallIncrementOn commence ici à quitter le monde de l’agilité pour entrer dans le monde du Lean. La taille des incréments livrés va être diminuée au maximum (Small Increments) afin qu’il puisse être possible de les livrer le plus rapidement, et dans un flux continu.

Ce que cherche ici le Product Owner c’est d’être capable de livrer continuellement de la valeur à ses clients tout en limitant les investissements dans des solutions non-viables.
Généralement l’incrément livré est de la taille d’un récit utilisateur (User Story), sa taille favorise ainsi sa livraison rapide.

Valeur la plus élevée en premier

Ce dernier modèle reprend les principes du modèle précédent, mais cette fois-ci les HK_HighestValueFirstincréments dont la valeur est la plus élevée, mais pour lesquels l’effort de développement est faible, vont être priorisés. Le but souvent recherché ici est de maximiser le retour sur investissement dès le début du projet.

Ce modèle bénéficie généralement des retours utilisateurs dans le choix de priorisation des incréments, les incréments ne sont plus « poussés » par le Product Owner mais « tirés » par les utilisateurs.

« Fail fast, Learn fast! »

Les deux derniers modèles, basés sur la livraison continue de petits incréments, offrent certains avantages. Le premier avantage c’est que l’on est capable de répondre rapidement aux besoins de nos clients, un avantage concurrentiel. L’autre avantage c’est que l’on est capable d’obtenir rapidement des retours de la part des utilisateurs sur les solutions que nous avons pensées pour répondre à leurs besoins, nous permettant ainsi d’aligner plus rapidement notre solution logicielle avec les besoins de nos utilisateurs.

Mais pour profiter des deux derniers modèles, nous devons envisager nos nouvelles fonctionnalités sous la forme de Minimum Marketable Features (MMF). Ainsi les efforts investis dans une fonctionnalité qui ne rencontre pas les attentes de nos utilisateurs seront minimaux. Mais en cas de succès, la fonctionnalité pourra être bonifiée continuellement par la livraison de petits incréments.

Le coût de l’inutile

Dans le merveilleux monde du développement logiciel il n’y a rien de pire que des fonctionnalités non utilisées, soit par ce qu’elles ont été développées trop tôt (le client n’en a pas encore besoin) soit parce qu’elles ne rencontrent pas le marché attendu (mauvaise compréhension du marché). Leurs coûts ne doivent pas être calculés uniquement sur leurs coûts de développement, ils doivent aussi inclure les coûts « collatéraux ».

« You Aren’t Gonna Need It »

J’ai récemment lu l’article de Martin Fowler sur le principe YAGNI, un principe venant de l’eXtreme Programming (XP). Le principe YAGNI stipule que nous ne devons pas ajouter de nouvelles fonctionnalités à notre logiciel tant que celles-ci ne sont pas jugées nécessaires. Ce principe tend à combattre le fameux « tant qu’à… » dont nous sommes souvent victimes.

En tant que développeurs cela se traduit par notre aversion à dépasser la portée du récit utilisateur (User Story) sur lequel nous travaillons. Tant qu’à travailler sur ce récit utilisateur, pourquoi nous n’en profiterions pas pour ajouter/modifier…. De plus nous risquons de tomber dans un cercle vicieux du « tant qu’à… ». Car il y a toujours un « tant qu’à… » à un « tant qu’à… ».

Cela à plusieurs implications :

  1. nous retardons ainsi la disponibilité de la fonctionnalité que nous devions livrer, le retour sur investissement est donc lui aussi retardé.
  2. nous ajoutons de la complexité dans le code de la fonctionnalité que nous devions livrer, cela implique plus de tests et un entretien plus difficile.
  3. nous décalons la livraison de fonctionnalités qui sont plus prioritaires, nous impactons donc le plan de livraison. De plus ce dernier a pu être bâti en tenant en compte de travaux coordonnés entre plusieurs projets, nous retardons alors les livraisons de plusieurs autres projets.

Toutes ces implications induisent des coûts collatéraux!

Une fonctionnalité non utilisée s’appelle une dette!

Il nous arrive parfois d’avoir un regard objectif et critique sur les logiciels que nous développons et nous nous apercevons alors (grâce à l’instrumentation du code source notamment) que les fonctionnalités que nous pensions si utiles à nos utilisateurs ne sont que rarement utilisées. C’est à ce moment-là que nous prenons conscience du temps passé, livraison après livraison, à entretenir et exécuter des tests de régression (automatisés ou non) pour des fonctionnalités que (presque) personne n’utilise. Le temps n’est-il pas de l’argent?

Michael Feathers, dans son article intitulé « The Carrying-Cost of Code: Taking Lean Seriously », nous recommande d’effacer le code des fonctionnalités non utilisées afin de réduire la complexité (inutile) du code de nos applications. Nous bénéficierions ainsi d’un code source pour lequel les efforts d’entretien et d’évolution seront réduits, nous offrant, par conséquence, la possibilité de livrer plus vite.

Retarder ses livraisons à un coût celui d’arriver sur le marché après ses concurrents!