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.

Advertisements