Découper un programme en projets

Mais un énorme programme de transformation est impossible à mener?

Un découpage astucieux permet d'éviter l'effet tunnel, de valider progressivement le nouveau Modèle, de gérer des éqipes plus petites

le Programme est découpé en projets

  1. Les difficultés d’un Programme trop complexe

    Un système complexe est difficile à construire compte tenu du nombre d’interaction entre ses éléments.
    On parle souvent de « plat de nouilles » pour évoquer les Solutions informatiques complexes.
    Chaque fois que l’on change une partie de la Solution, on déstabilise l’ensemble : les tests de « non-régression » qui ont pour objectif de vérifier que la Solution reste robuste malgré les dernières évolutions, peuvent s’avérer beaucoup plus coûteux que la modification : on peut faire une modification pendant une semaine et exécuter des tests de non-régression pendant 2 mois.
    Lorsqu’un problème apparait, la correction est d’autant plus longue qu’il faut en chercher la raison dans un ensemble trop large.
    La seule méthode consiste à architecturer la Solutions en Modules pour que le nombre d’interactions soit plus limité.
    Cette stratégie n’a pas qu’un avantage de simplification globale. Elle permet aussi de livrer rapidement de premiers résultats concrets aux utilisateurs Opérationnels, elle évite l’effet tunnel et crédibilise le Programme parce que les premiers Projets délivrent de la Valeur rapidement à travers les premiers Modules. C’est aussi une façon de tester progressivement la viabilité de la Solution sans attendre une livraison globale en fin de Programme.
    Mais comment effectuer le découpage d’un Programme en Projets?

  2. Comment découper un Programme en Projets

    1. Bâtir le cadre avant la Solution

      Chaque Projet du Programme sera plus simple s’il s’inscrit dans un cadre bien structuré. La clarté du périmètre, la précision des interfaces avec les autres Solutions, la réutilisation de Fonctions d’accès aux Informations sont autant d’atouts pour concentrer l’énergie du chef de Projet sur son Modèle, et non sur son environnement.
      Avant d’entamer la construction de la première solution il faut donc disposer du cadre dans laquelle elle va s’inscrire. Ce cadre a deux dimensions :

    2. Simplifier progressivement un système existant

      Lorsque la Solution complexe est déjà en place et qu’on souhaite la simplifier, une autre stratégie est possible qui consiste à simplifier progressivement la Solution au fur et à mesure des Projets.

      Pour définir la road-map de simplification progressive, il faut isoler progressivement les composants d’accès aux informations pour rendre indépendants l’évolution des données de l’évolution du logiciel. Puis isoler progressivement les Fonctions Métier réutilisables. En déduire des interfaces standardisées entre Solutions.
      Cette stratégie a été définie dans le livre blanc du CEISAR « Simplify Legacy Systems » : nous proposons au lecteur intéressé de télécharger ce livre blanc à partir de www.ceisar.org
    3. La première Version d’une Solution est la plus difficile

      La Création de la Version 1 de la Solution est plus coûteuse que chacune des Versions suivantes puisqu’elle inclut la Construction de l’Architecture de la Solution et de la Fondation qui seront conservées pour les Versions suivantes.
      Mais, compte tenu de la durée de vie des Solutions, la somme des coûts des Versions 2 à n représente 2 à 3 fois le coût d’origine de la Version 1. L’Agilité est donc non seulement l’art de Construire rapidement la première version de Solution, mais aussi l’art de Construire, dès cette 1° Version, une Architecture de Solution efficace pour que les Versions suivantes en bénéficient. L’Agilité à l’instant T ne doit donc pas hypothéquer l’agilité à l’instant T+1 : c’est la définition du développement durable appliqué aux Systèmes d’Information.

      Agilité = construire vite et bien
    4. Donner un sens « Métier » au découpage

      Il faut aussi que les jalons du projet correspondent à des "étapes métier", c'est à dire à des étapes qui font aussi du sens pour le métier, et pas seulement pour l'IT. Car sinon, il sera très difficile de faire adhérer au projet les partenaires métier. Il faut donc être capable de "raconter une histoire" autour du projet, et sur la valeur apportée au métier à chaque étape.

Licence Creative Commons
L'histoire de George Le Boulanger est mise à disposition selon les termes de la
Licence Creative Commons Attribution - Pas de Modification 4.0 International.
Table des Matières

Commentaires

comments powered by Disqus