La conception émergente

Cet article a été publié depuis plus de 6 mois, cela signifie que le contenu peut ne plus être d'actualité.

Ceux qui me connaissent le savent bien, je suis un fervent défenseur des principes et des méthodes agiles. Même si aujourd’hui ces dernières se sont énormément démocratisées, les mettre en oeuvre au sein de projets n’est pas toujours une chose aisée (les habitudes ont la vie dure).

Ce billet, j’aurais mis un an pour l’écrire. Avec du recul ce n’est pas forcément une mauvaise chose car je vais vous raconter l’histoire d’un projet. Un projet qui, bien que développé en utilisant la méthode SCRUM, n’a pas fait l’objet d’une conception agile (que je qualifie également de conception émergente).

Utiliser une méthode agile est un bon début, mais ce n’est pas suffisant. Pour que cela fonctionne, il est nécessaire (d’après moi) que le processus de développement soit également fait de manière agile. Pour maximiser les chances de réussite, il est important de considérer les principes KISS (Keep It Simple and Stupid: ne compliquez pas les choses inutilement) et YAGNI (You ain’t gonna need it: vous n’en aurez pas besoin). C’est en respectant ces deux règles et en utilisant de manière efficace un certain nombre de Design Pattern qu’une conception émergente apparaît.

Contrairement à une “conception classique” où l’essentiel de l’architecture est réalisée en début de projet, la conception émergente a pour objectif de décrire la conception au fur et à mesure de l’avancement du projet. C’est-à-dire que l’architecture du produit est conçue au fil du développement des évolutions demandées par le métier. Ce mode de fonctionnement colle très bien à des projets agiles où les spécifications sont réalisées et priorisées tout au long de la vie du produit.

La notion de conception n’est pas remise en cause, le travail s’effectue différemment. Cela a alors un impact direct sur l’équipe. Il est important que chaque membre doit être capable d’identifier les éléments de conception redondants et de proposer des simplifications du code existant. L’équipe doit également être capable de différer une décision de conception liée à une exigence future et d’identifier le moment pertinent pour introduire une décision structurante.

Pour le projet dont je parlais au début de ce billet, l’équipe (composée d’un product owner, un scrum master et de 3 développeurs) a décidé (à mon grand regret) de partir sur une approche “traditionnelle”. De ce fait, une conception entière du système a été réalisée (le travail de développement était estimé à environ 6 mois/homme). Les sprints ont ainsi démarré par la réalisation d’un MCD complet répondant à l’ensemble des fonctionnalités qui devaient être fournies par l’outil. De cette conception a découlé la création de toutes les entités du modèle. Par la suite, les différents éléments du cahier des charges ont été découpés en users stories qui étaient réalisées de manière itérative lors de chaque sprint selon les priorités définies par le product owner.

Il est important pour la suite, de préciser que le projet en question n’est pas un projet “prioritaire” pour l’entreprise. Il est possible de le qualifier de “side-project” car il n’a pas d’impact business direct. Les membres de l’équipe sont donc affectés prioritairement sur d’autres projets (en respectant un ratio de 80/20). C’est pour cette raison, que le product owner a décidé de s’attacher à la réalisation de fonctionnalités techniques avancées afin de s’assurer de la faisabilité de ces dernières. Cela a eu pour conséquence de s’attarder sur des éléments techniques au détriment de la réalisation d’une application fonctionnelle.

Comme on pouvait s’y attendre, les délais de réalisation de l’application ont commencé à être rallongés. Le projet prenait du retard et a dû être mis en pause. Cela jusqu’à aujourd’hui, environ 6 mois après son arrêt temporaire.

Seulement les choix de conception qui ont été fait, rendent la reprise du travail difficile. La base de données a été entièrement modélisée pour les fonctionnalités annoncées il y plus d’un an maintenant. 80% des propriétés des entités ne sont pas utilisées (et correspondent donc à des colonnes de base de données à null). De plus, le fait de s’être concentré sur des éléments principalement techniques, a pour conséquence que de multiples fonctionnalités ont été commencées, mais qu’aucune n’est terminée. Il n’est donc pas possible de saisir une information dans l’interface d’administration et de la retranscrire correctement côté interface utilisateur. Et après 6 mois de pause, aucun membre de l’équipe n’est capable de dire ce qui fonctionne ou non, ni même où le travail s’était arrêté.

Lorsque l’on démarre un projet, il est important d’être pragmatique et d’avancer petit à petit. Il est également primordial de commencer un projet par un MVP (Minimum Viable Product: un produit minimum viable). Ne vous concentrez pas sur des aspects techniques qui n’ont que peu de valeur ajoutée. Développez votre produit rapidement (sans bafouer la qualité), mais avec un minimum de fonctionnalités. Ces dernières s’étofferont par la suite. Le plus important c’est que l’on utilise votre projet, cela vous rassurera en vous confrontant à votre marché, et pour l’équipe qui est derrière ce n’est pas un long tunnel sans fin.