vendredi 4 novembre 2011

Forfait, marché public et agilité : petit REX

J'ai récemment clôturé une petite affaire, au forfait pour un organisme public, donc un marché public. Le projet a été proposé et mené dans une approche agile dont voici un petit retour d'expérience.

Contexte

  • Evolutions et corrections sur une application WEB interne existante
  • Liste des points à traiter fournie dans le cahier des charges mais manque de clarté et de précision
  • Affaire traitée en moins de 2 mois par une personne (moi)
  • Seulement 3 intervenants : 2 interlocuteurs côté client (dont 1 que je connaissais déjà) et moi-même

Idée de départ

Adepte des approches agiles, il me semble désormais difficile, voir impossible, de mener une affaire en mode "classique" :
  • Etablir et signer un cahier des charges fixe
  • Se mettre d'accord sur un délai et un tarif (et donc un contenu)
  • Développer "hors site" pendant plusieurs semaines (ou moi)
  • Le jour J, livrer ce qui a été réalisé, prendre acte des problèmes et mécontentements, les gérer au mieux, et se faire payer !
J'ai donc souhaité proposer une approche plus agile, en m'inspirant de Scrum, et de mes expériences en agilité, en me donnant quelques objectifs précis :
  • Satisfaire les utilisateurs finaux et donc mon client
  • Permettre les changements par le client en lui donnant le contrôle de la priorisation
  • Fonctionner en cycle court pour avoir du feedback régulier

Vocabulaire

Les 2 interlocuteurs pour ce projet ne sont pas du tout expert en informatique, logiciel, développement, etc ... De plus, le projet était court en durée. J'ai donc opté pour une adaptation du vocabulaire par rapport à Scrum :
  • "Histoires" (Stories) : j'ai plutôt parlé de "fonctionnalités" tout simplement
  • "Carnet de produit" (Product backlog) : j'ai introduit la notion de "Référentiel des fonctionnalités" pour le document que j'ai créé en début de projet, avec la liste des points à traiter, que j'ai complètement ré-exprimés, et que j'ai maintenu à jour tout au long des développements, fournissant ainsi en fin de projet un état des lieux des points traités ou non
  • "Itérations" (Sprints) : j'ai gardé le terme d' "itérations" qui reste intuitif et a été très bien adopté par tout le monde
  • "Vélocité" (Velocity) : j'ai plutôt évoqué la "capacité de production" journalière permettant d'estimer un "volume de production" par itération
  • "Réunion de planification" (Sprint planning) et "Revue d'itération" (Sprint review) : j'ai regroupé ces 2 cérémonies en une seule baptisée simplement "Réunion d'itération"
J'ai laissé de côté le rôle de ScrumMaster pas vraiment utile dans ce contexte. Le terme de "Responsable de produit" (Product Owner) a été évoqué dans la présentation initiale de l'approche, mais sans être utilisé par la suite.

Approche proposée et organisation

Le projet a commencé par la ré-expression des points à traiter pour donnant naissance au "Référentiel des fonctionnalités", sur base des éléments initialement fournis, et grâce à des échanges avec les 2 interlocuteurs pour leur faire exprimer les besoins (et non les solutions comme c'était le cas dans le cahier des charges fourni).

J'ai ensuite estimé chaque fonctionnalité en "points", de 1 à quelques dizaines. Les fonctionnalités ambiguës ont été estimées avec des fourchettes de points, et séparées des autres pour être précisées avant d'être implémentées. Un repère de 6 points par jour a été utilisé.

A chaque début d'itération, le RDV de la prochaine "Réunion d'itération" était fixé permettant d'en déduire le nombre de jours possibles de production (selon le calendrier et mes disponibilités), et donc le volume estimé de production selon la "capacité de production". Exemple pour l'itération 1 : 6 jours à 6 points = 36 points. Le client pouvait alors "faire son marché" et choisir lui-même les fonctionnalités à implémenter dans la prochaine itération.

Les échanges en cours d'itération ont été nombreux, surtout par mails, pour demander des précisions ou des validations mineures, et tenir informé le client des éventuels changements de planning (1 jour de production en moins par exemple).

En fin d'itération avait lieu la "Réunion d'itération" découpée ainsi :
  • Point sur l'itération écoulée, bilan du temps passé, des fonctionnalités traitées ou non, évaluation de la nouvelle "capacité de production"
  • Démonstration sur mon portable de chaque fonctionnalité traitée
  • Si la satisfaction est au RDV, et si c'était prévu, mise en production
  • Préparation de l'itération suivante
Une mise en production a été prévue et réalisée en fin d'itération 2, et bien sûr, en fin de projet.

Observations et constats

Adoption de la méthode : malgré des réticences en début de projet, la méthode proposée a été très vite adoptée, avec une satisfaction manifestée dès la fin de l'itération 1.

Référentiel des fonctionnalités : ce document a vraiment été la colonne vertébrale du projet, servant de référence permanente pour tous, mais nécessitant un investissement pour sa mise à jour quotidienne. Son intégration parmi les livrables à chaque itération, et donc en fin de projet, a permis de fournir au client un véritable état des lieux des développements, et notamment en fin de projet, une vision claire de ce qui a été réalisé, et surtout de ce qui ne l'a pas été, par exemple pour prévoir une prochaine intervention sur l'application.

Vélocité : pour la première itération, la capacité de production avait été estimée à 6 points par jour. Malgré 1 jour de production en moins, tout ce qui avait été prévu a été traité, amenant à constater une capacité de production supérieure à 7. Cette capacité a donc été portée à 7 pour l'itération suivante et est restée à cette valeur pour le restant du projet.

Priorisation : le système de "marché à points" proposé a tout de suite été compris et bien pris en main. Les interlocuteurs connaissait bien le sujet, les objectifs du projet et les points à traiter. Ils n'ont jamais eu de difficultés à choisir les fonctionnalités à traiter selon la capacité disponible.

Suivi et feedbacks : ce point a été parmi les plus forts du projet, puisque les échanges réguliers ont permis d'établir une véritable collaboration avec le client, qui avait une vision claire et transparente de l'avancement, et sentait au jour le jour sa capacité à aller ensemble vers un résultat de qualité permettant de satisfaire les utilisateurs.

Proof of concept : un exemple caractéristique de l'intérêt du feedback :
Pour plusieurs fonctionnalités, j'ai proposé une solution de pages à comportement dynamique (afficher certains champs selon des choix effectué par l'utilisateur). Pour permettre au client d'appréhender la solution proposée avant de l'appliquer à plusieurs endroits, elle a été implémentée sur un cas lors de la première itération. Le client a ainsi pu la visualiser et la valider pour qu'elle soit implémentée sur le reste de l'application.

Droit au changement : le client ayant bien adopté le système de priorisation à sa charge sur base du système de points, il a tout naturellement intégré la possibilité de changements, évidemment en respectant les volumes de charges. Ainsi, bon nombre de changements ont eu lieu au cours de chaque itération, avec des changements sur certaines fonctionnalités, sur leur priorisation, mais également la prise en compte de nouvelles fonctionnalités ou extensions de tâches réalisées.

Encore plus fort ... : lors de la préparation de la quatrième et dernière itération, une discussion a eu lieu autour de fonctionnalités de recherches au sein de l'application existante. Le client a exprimé son insatisfaction récurrente et ancienne par rapport à ces fonctionnalités, et le souhait d'un unique moteur de recherches croisées. J'ai fait quelques remarques et propositions de fonctionnement et d'ergonomie. Le client m'a demandé une estimation (en points bien sûr) qui s'est avérée assez importante, quasiment égale à la capacité de production pour la dernière itération à venir. Après réflexion, le client a décidé d'abandonner tout ce qui restait au cahier des charges pour favoriser la mise en place de ce nouveau module, qui n'avait pas du tout été prévu dans le projet ! Donc un changement complet du reste du projet aux 3/4 de son déroulement ! Et le résultat ne l'a pas déçu, sans aucun regret pour les fonctionnalités écartées, qui ne sont finalement que partie remise pour un prochain projet ;-) .....

A améliorer

Le premier point est dû à ma découverte des appels d'offres pour marchés publics, pour lesquels le montant est fixé (politiquement), alors que j'avais imaginé plus d'échanges et mises au point avant le lancement du projet (évaluation des besoins, explications sur la méthode, ajustement du volume, ...).

Le second point qui m'a piégé est d'avoir mal anticipé la fin du projet pour lequel il aurait été bon de prévoir un volume d'intervention après la dernière itération pour finaliser les développements selon les remarques et observations exprimées lors du bilan de la dernière itération.

Enfin, le "Référentiel des fonctionnalités" devrait idéalement être tenu de façon collaborative, donc un format type Wiki sur un serveur accessible de tous pourrait être intéressant. Mais dans le contexte de ce projet, l'implication du client ne serait pas allée jusque là, et la mise à disposition d'un fichier PDF en fin de projet a été apprécié.

Conclusion

Pour moi, elle est simple : une réussite totale (ou presque) du traitement en mode agile pour ce projet.

Bien sûr, il faut pondérer ce résultat en prenant en compte le contexte "favorable" de ce projet : tout petit projet, liste assez précise des besoins, interlocuteurs connus et collaboratifs, etc ...

Néanmoins, cette expérience reste intéressante et me semble transposable à plus grande échelle, vivement une prochaine opportunité ...

Et vous ? Que vous inspire ce retour d'expérience ? Quelles sont vos expériences en la matière ? ...

13 commentaires:

  1. Bonjour, merci pour ce retour d'expérience.
    Je suis assez curieux de savoir à quoi ressemble le "Référentiel des fonctionnalités". Tu dis qu'au départ, le cahier des charges se focalisait plus sur les solutions que sur les besoins. Par expérience, je trouve que l'écriture de bonnes user stories est l'une des choses les plus compliquées dans Scrum. Comment le client a réussi cette étape ? Tu l'as accompagné j'imagine, mais ça a pris longtemps ? C'était douloureux ?

    RépondreSupprimer
  2. Bonjour Xavier,
    Merci pour ce REX très intéressant.
    Tu parles d'une application existante. As-tu pris/prévu du temps pour prendre connaissance de l'existant (architecture, technos, usine logicielle)? Ton client et toi avez-vous pu discuter de qualité d'application (ex : qualité de code (existante/souhaitée), couverture de tests, utilité des fonctionnalités...)? As-tu pris en charge de la dette technique (ex : dette de tests, refactoring...) au cours des itérations?

    RépondreSupprimer
  3. Jean-Pierre Vickoff6 novembre 2011 à 12:42

    Cela fait plaisir de lire un texte comme celui-ci autant dans le fond que dans la forme. Merci aussi pour nous avoir éviter le franglais qui semble devenu l'indispensable messe en latin des médiocres.

    RépondreSupprimer
  4. Bonjour et merci pour l'intérêt porté à ce REX et pour vos commentaires !

    @Marc : ce "Référentiel des fonctionnalités" n'est autre qu'un document texte rédigé avec mon traitement de textes préféré. Le cahier des charges initiale était composé de 2 parties :
    - 1/ une partie "améliorations" pour répondre à une charte qualité, essentiellement basées sur des captures d'écrans annotées par du texte peu clair
    - 2/ une liste d'anomalies existantes à corriger, parfois très précises (ex : "Mauvais code postal pour ..."), parfois très vague ("Manque certaines données quand on fait une recherche")

    C'est essentiellement dans la première partie qu'il y avait des expressions de "solutions" sur lesquelles j'ai pas mal travaillé avec le client pour comprendre son métier, l'application existante, et le véritable besoin. C'est comme cela que des "Ajouter une case à cocher ..." sont devenus des "Compléter la liste de choix existante ...", et inversement.

    Il y a donc effectivement eu un gros travail d'échanges et discussions avec le client pour comprendre tout le cahier des charge initial, le reformuler et donner des estimations en points. C'est comme ça qu'est né ce "Référentiel des fonctionnalités" correspondant au "Carnet de produit". Il reprend les 2 grandes parties du cahier des charges et présente les tâches sous forme de tableaux avec les informations suivantes :
    - formulation initiale (pour que le client retrouve bien ses petits)
    - reformulation ou complémentes d'informations
    - estimation
    - état (apparu à la fin de l'itération 1 pour noter les histoires réalisées et avoir ainsi un véritable "référentiel")

    Pour chaque partie, comme je l'ai dit, les histoires manquant de précisions et ne pouvant donc pas être chiffrées précisément, étaient présentées séparément, dans une sous-partie "A préciser". Il est intéressant de constater que ces chapitres n'ont quasiment pas bouger, pas de traitement de ces histoires, le client ayant compris très vite de lui même que ces tâches ne seraient pas traitées. La principale explication est que pour bon nombre de ces tâches, le client ne savaient plus bien de quoi il s'agissait, ni qui les avait fait remonter, donc impossible de les préciser ...

    Pour répondre à tes questions finales, le client et moi avons bien réussit cette étape en grande partie parce que je l'ai prise en charge à 100% : j'ai très vite compris qu'il avait exprimé ce qu'il pouvait comme il pouvait, la seule chose qu'il pouvait encore fournir, était de répondre à mes questions, à moi de poser les bonnes et reformuler le tout.

    Pour moi, cette étape n'a pas du tout été douloureuse, au contraire, un moment indispensable et néanmoins plaisant permettant de bien capter le besoin pour mieux satisfaire ensuite. Ce fut un gros travail en début de projet, mais également au cours de chaque "réunion d'itération".

    @Marc : mais qui es-tu exactement ? ;-)

    RépondreSupprimer
  5. @Emilie : concernant l'application existante, c'était du PHP/MySQL "à l'ancienne" dont j'avais eu un aperçu lors d'un précédent contact. Donc pas d'usine logicielle, pas de tests, pas vraiment d'architecture, juste quelques inconnues sur les solutions mises en place (gestion des formulaires, validations, interface BDD, ...). Mais effectivement, dans mes estimations, j'ai pris en compte une répartition d'un "ticket d'entrée", surtout pour certaines parties (pages) que j'imaginais plus complexes.

    Comme je l'ai expliqué dans le commentaire précédent, j'ai beaucoup travaillé avec le client sur l'expression des ses besoins, et j'ai pris en charge le reste. Je rappelle le contexte : organisme public, 2 interlocuteurs pas du tout informaticiens, simplement utilisateurs de leur application (qu'ils connaissent bien) et de certains points précis qu'ils en attendaient. Pour compléter le tableau, le projet visait à améliorer le système existant en attendant une migration possible d'ici 2 ans vers un système tout autre. Donc, le focus pour le client était sur les évolutions fonctionnelles, pas trop d'approche pérenne ...

    Le client avait également comme souhait d'augmenter le taux d'utilisation de l'application par les agents (en interne). J'ai donc mis pas mal d'énergie à proposer des changements et des nouveautés pour avancer sur ce point : allègement de certains formulaires selon les remontées des utilisateurs finaux, ajout de comportements dynamiques dans les pages pour une interface plus simple, plus intuitive et plus conviviale (javascript, jQuery, ajax, ...), etc ...

    Donc, pour te répondre, j'ai eu en permanence le soucis de l'amélioration de la qualité de l'application existante, mais le chantier était assez conséquent : présence d'anciennes mauvaises pratiques en grand nombre. Je pense donc avoir augmenté cette qualité, un peu, notamment sur les parties que j'ai retouchées, mais il reste pas mal de points négatifs que je n'ai pas pu traiter (faute de moyens). Mais c'est un sujet que j'ai commencé à évoquer avec le client, et que je remettrai à l'ordre du jour lors de ma prochaine intervention (prévu d'ici quelques mois).

    Ai-je répondu à tes questions et attentes ?

    RépondreSupprimer
  6. Merci pour votre article clair et encourageant.
    Pourriez-vous préciser de quel type de marché public vous parlez svp ? (mapa, consultation hors marché avec simple publicité, etc...).

    En général, un marché public se base notamment sur un CCTP ? est-ce ce que vous appelez "cahier des charges" en entrée ? Est-ce à dire que votre projet a respecté les souhaits et satisfait votre client (facteur important nous sommes bien d'accord :),... mais sans respecter le CCTP (ou cahier des charges) ?

    C'est bien là que se pose le problème des projets agiles en marchés publics à mon avis ; et votre article, très intéressant par ailleurs, ne précise pas comme ce dilemne a été résolu.

    merci de votre retour.
    C.MONNIER

    RépondreSupprimer
  7. Merci de partager ce REX intéressant.

    Je te rejoins sur le fait qu'un point important est le fait d'avoir un bon référentiel des fonctionnalités et que c'est une colonne vertébrale pour le bon déroulement du projet. Je suis intéressé pour savoir comment
    tu t'y es pris pour reformuler le besoin avec tes 2 interlocuteurs. Sous quelle forme les as-tu décrit ?

    Une difficulté est souvent que les Product Owner qui commencent avec l'agilité, pense que comme on peut changer, il n'y a pas besoin de définir des spécifications.

    - Un de tes objectifs était de "Satisfaire les utilisateurs finaux et donc mon client"
    Aviez-vous définis des critères particuliers pour indiquer que ton client était satisfait ?
    Comment pourrais-tu définir la valeur/plus-value que tu as apporté à ton client ?

    Rémy

    RépondreSupprimer
  8. @C.Monnier : encourageant ? Tant mieux !

    Effectivement, il s'agit d'un MAPA ou MPA (Marché à procédure adaptée). Je ne suis pas sûr de pouvoir en dire d'avantage, et en plus, je découvre ce domaine dans lequel je suis loin d'être expert ... Là n'est pas l'important, mais comme vous le suggérez, il y avait bien un cahier des charges (plus ou moins) sous forme de CCTP.

    Et "oui" : le projet n'a pas respecté le cahier des charges ou CCTP ... Je m'explique.

    Je propose une approche agile pour donner au client le droit au changement, c'est-à-dire changer d'avis sur le contenu fonctionnel : modifier des fonctionnalités, en ajouter ou en supprimer. Le contenu est ajustable, ce qui ne l'est pas, c'est le volume de travail, donc les moyens (coûts) et les délais (même si ces derniers ont été ajustés en totale collaboration). Dans ce contexte de changements possibles, il est donc impossible de respecter un cahier des charges !

    C'est pour cela que j'ai introduit la notion de "cahier des charges initial", en précisant dès le début, en expliquant la méthode, que le cahier des charges représente ce que le client "aimerait avoir" aujourd'hui (à l'instant t), mais pas ce qu'il "aura" ! Et finalement, je lui démontre que ça ne change pas d'une approche "classique" qui est un leur, mais qu'au moins, on met cela sur la table et on en tire profit ... (je pourrais détailler dans un autre article)

    Merci pour vos réactions !

    RépondreSupprimer
  9. @sanlaville : Salut Rémy !

    Concernant le Référentiel des fonctionnalités, voir les explications dans un commentaire précédent. Est-ce que ça répond à ta question ?

    Mes critères pour évaluer la satisfaction du client ont été son sourire et son enthousiasme ... ;-)

    Plus sérieusement, à chaque réunion d'itération, je faisais une démonstration de chaque fonctionnalité (i.e. histoire). Je m’efforçais alors de bien vérifier si cela correspondait aux attentes. Mes 2 interlocuteurs étaient très tolérants, en partie parce qu'ils ont vite été en confiance dans notre relation (je pense), j'ai donc dû m’astreindre à être très rigoureux sur la satisfaction de chaque fonctionnalité, en étant exigeant avec moi-même.

    Donc plus globalement, pas de critères de satisfaction, le projet et le contexte ne semblait pas le nécessiter, mais ça peut être une bonne approche. Juste des ressentis, apparemment très positifs, peut-être en partie dus à la rigueur évoquée précédemment ... Et tout de même un retour très concret lorsqu'en fin de projet, le client m'a dit que mon approche était "super" et avait répondu "au-delà" de ses attentes, probablement en comparaison d'expériences passées et plus .... classiques et figées ...

    Concernant la valeur apportée :
    * sur le projet lui-même : une mise en production à la moitié et dès la fin du projet avec des premiers retours utilisateurs la semaine suivante, et l'annonce par le client d'une phase supplémentaire d'ici quelques mois
    * sur la gestion du projet : une réelle flexibilité, un droit au changement concrétisé par une maitrise des priorités par le client
    * sur l'application existante : une expertise et un œil neuf :
    . sur l'ergonomie (remarques et propositions au client) : simplifications des pages et formulaires, détections automatiques de doublons, fenêtre type "dialog" plutôt que "popup", ergonomie dynamique, etc ...
    . mais également plus techniquement, sur les sources (moins visible par le client) : amélioration des requêtes SQL, meilleure cohérence globale, introduction de conception objet pour simplifier et améliorer la lisibilité, etc ...

    RépondreSupprimer
  10. Hello Xavier,

    Oui à mon avis c'est une bonne pratique de ne pas embarquer les mots clefs agiles pour simplifier une relation ou une mise en confiance.

    Mais pour les projets au forfait : "tout va bien lorsque tout va bien". Peux-tu extrapoler et imaginer ce qui se serait passer en cas de conflit, de désaccord, de pression ?

    Ok pour les projets "au forfait" qui dissimulent un engagement de moyens car les deux parties sont capables de s'entendre là dessus.


    Ravi d'avoir fait ta connaissance lors de l'agile marseille.

    RépondreSupprimer
  11. Merci Xavier pour le complément, cela répond tout à fait à ma question !
    Ca n'a probablement pas été facile de se lancer dans les évolutions "sans filet" (comment être sûr de ne pas casser qqch ailleurs...). Toutefois, cela répond aux attentes de ton client, surtout sachant qu'ils ne comptent pas faire évoluer beaucoup l'application par la suite. Et comme tu l'as dit, là où tu as pu et où tu es intervenu, tu as eu le souci d'améliorer la qualité (le développeur du futur, ici, ça peut encore être toi ;-).

    RépondreSupprimer
  12. @Pablo : Salut Pablo !

    Effectivement, c'est un REX sur une expérience qui s'est bien passée.

    Le problème avec l'agilité, c'est qu'on va avoir besoin de confiance et de transparence. Dès lors qu'une des parties commence à craindre un conflit, à mettre des billes de côté "au cas où", le doute s'installe, la confiance n'y est plus, le projet en mode agile est voué à l'échec.

    Il faut vraiment oublier les "anciens" réflexes, il faut y croire ensemble, main dans la main, dans le même bateau, dès le début et jusqu'à la fin. Avec le client, il faut former une équipe pour la réussite ensemble du projet. Nous serons tous responsable du succès ou de l'échec ! Oui, je sais, c'est simpliste, c'est mon côté optimiste ...

    Tous les projets et toutes les équipes ne sont pas éligibles à l'agilité. Il en va de même pour les affaires et les clients, il faut un contexte positif dès le début. Si les premiers échanges, les premières explications, n'initient pas une petite étincelle, mieux vaut faire autrement, non ?

    Tout le plaisir était pour moi de cette brève rencontre à Marseille, et merci pour le Marshmallow ;-)

    RépondreSupprimer
  13. @Emilie : je suis du genre pragmatique ...

    Donc, s'il existe des tests unitaires, tant mieux, super ! Sinon, s'il n'y en a pas, je ne vais pas refuser d'intervenir sur un code, mais je prends , plus d'attention, plus de tests manuels !

    Pour la qualité et les améliorations, il faut y aller petit à petit. Comme je dit lorsque je parle de tests unitaires et TDD : "Commencez petit, là où vous le sentez, là où c'est propice, mais toujours un peu et encore un peu, ce sera toujours ça, et toujours mieux que rien !".

    RépondreSupprimer