Contractualisation agile pour le secteur public, deux propositions

Nous avons définit dernièrement, pour deux clients différents, deux méthodes de contractualisation agile adaptés pour le secteur public, voici la première  :

1./ la contractualisation par unité d’oeuvre, ou par points, nous avons appliqué sur un contrat au CNRS pour une appel d’offre marché public :
C’est une méthode est très cohérente, mais pas facile à mettre en place. il s’agit de contractualiser sur le nombre de point… c’est à dire que le fournisseur s’engage à réaliser un certain nombre de point d’effort (unité d’oeuvre dans le langage juridique). Elle demande une expérimentation du modèle par rapport au contexte (l’expérimentation peut être faite par un contrat public du type « dialogue sélectif »).

Ce modèle peut être aussi très bien être appliqué à une relation client-fournisseur basé sur le modèle des « centre de service » ou « bundle » qui correspondent à des cadres de contractualisation qui héberge une multitudes de projets, ce qui est très favorisé actuellement par les achats.

Nous n’alons pas approfondir aujourd’hui cette méthode (je le ferais dans un futur article).

La deuxième méthode, que je vais décrire précisement dans cet article, est la suivante :

2./ la contractualisation sur les « epics » haut niveau. (variante de la contractualisation agile « change for free »),  nous avons appliqué ce modèle entre une filiale d’un constructeur aérospatial et un de leur client important :
Le fournisseur s’engage sur un périmètre « haut niveau » (epics) répartis sur plusieurs releases, ce périmètre est fixe… (il peut être changé mais par avenant), par contre le « profondeur fonctionnelle » est agile. c’est à dire que pour chaque élément de haut niveau il sera définit une suite des fonctionnalités à granularité fine, qui elles seront priorisés de manière agile. Et il sera aussi possible d’ajouter et d’enlever des fonctionnalités à granularité fine tout au long de la release.
C’est un mode de contractualisation « mixte » qui plait un peu à tout le monde, achat et projet. par contre cela pose des contraintes fortes : le périmètre de « haut niveau » ne pourra pas être changées au cour du projet. elle est compliqué à mettre en place, car une logique opératoire est spécifique (par exemple on va interdire au client de changer de feature aux derniers moments de la release)

Disons que la contractualisation sur les « epics » est idéal quand on est dans un mode mixte scrum/rup par exemple, ou une phase initiale de spécifications sont réalisés.

Voici le principe dans le détail :

Le périmètre fixe est défini au niveau des epic, l’engagement consiste à réaliser l’ensemble des epics. La « gouvernance projet » doit assurer cet engagement. La profondeur fonctionnelle est flexible. Il s’agit de rendre possibles les changements de profondeur pour chaque features.

Principe d’adaptation

Le backlog a été initialisé avec les epics (contractualisées). Elles ne sont pas priorisées ni évaluées, mais fournies avec une estimation du nombre d’user stories.

En termes de points d’effort, chaque story est considéré, a ce niveau, comme étant une story moyenne, en pesant par exemple 3 points.

Le nombre de points d’effort de l’epic, c’est la somme des points d’effort de chaque stories.

Par exemple l’epic 1, si elle possède 5 user stories, alors elle pèse 15 points d’effort.

Dans l’exemple si dessus, le projet a un total de 222 points d’effort. Le Client aura la possibilité de changer pour chaque sprint l’estimation du nombre de stories, et de réévaluer l’effort de chacune.

Le client aura aussi la possibilité de reprioriser les epics en fonction de leurs priorités en termes de feedback. En priorisant les user stories les plus importantes en valeur métier.

attention, le changement durant l’incrément ne pourra pas se faire de la même manière si on est au début ou à la fin de l’incrément. Il est nécessaire de respecter une zone de dynamique, élevée au départ, restreinte à la fin :

Voilà, j’en dis pas plus! C’est déjà pas mal !

A votre dispo pour plus d’info !

Advertisements

6 Commentaires

  1. Pingback: La contractualisation et l’agilité | Improvisons autour de l'Agilité

  2. Hi! I’ve been following your weblog for a while now and finally got the bravery to go ahead and give you a shout out from Austin Texas! Just wanted to tell you keep up the good work!

  3. elolozone

    Non je n’ai pas (encore) développé, par contre si cela t’intéresse je peux le faire 🙂

  4. Bonjour Laurent,

    As-tu écrit le deuxième article de cette série concernant la contractualisation par unité d’oeuvre, ou par points, appliquée à un contrat au CNRS pour une appel d’offre marché public?

  5. Pingback: Soirée spéciale agilité à Cocoaheads Toulouse « agile generation

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s