[Tribune] L'agilité organisée et maîtrisée au service du projet au forfait

Lorsqu'un prestataire est engagé dans un projet "au forfait", c'est généralement dans un but de contrôle du budget initial, de respect d'un planning de livraison bien précis et d'un périmètre de fonctionnalités bien identifiées. L'"approche agile" (plutôt que la "méthode agile") consiste, elle, à raisonner en termes de "gestion de produit" et non plus en "gestion de projet". Est-ce possible alors de réaliser avec succès un projet agile en mode forfaitaire ? Comment lier les contraintes d'un contrat au forfait aux changements culturels imposés par l'agilité ?

Depuis plusieurs années maintenant, l'agilité séduit et efface peu à peu les autres méthodes comme le fameux cycle en V en place depuis 1980. Pourtant, l'approche, la philosophie, l'esprit ou même le courant agile implique un réel changement de culture et de raisonnement que les protagonistes des projets oublient parfois. En effet, on privilégie une collaboration avec le client plutôt qu'un contrat, un logiciel opérationnel plutôt qu'une documentation précise et complète, ou encore l'adaptation au changement plutôt qu'un plan détaillé et des dates figées.

Mais alors ? L'agilité s'adresse-t-elle à tout le monde ?

On peut très bien gérer l'organisation de son mariage en Scrum avec quelques post-it à la maison. Une association de golf peut aussi mettre en place son site web en suivant une approche identique. Un éditeur de logiciels ou un service R&D peut aussi plus facilement appliquer les principes de l'agilité car la notion de contrat au forfait n'existe pas ou est beaucoup plus souple. Mais un client avec un cahier des charges de 300 pages et des spécifications de 1200 pages et qui choisit un prestataire en off-shore le moins cher possible, lui, aura plus de difficultés à suivre les concepts agiles. En tout cas, ce n'est pas la meilleure solution ! Mais c'est bien entendu possible, si tout le monde est prêt à accepter quelques changements dans sa façon de voir le succès d'un projet, que ce soit le client qui va devoir s'investir tout au long du projet, ou que ce soit le prestataire qui devra s'outiller efficacement pour que les processus soient les plus fluides possibles.

Oui, tout le monde peut devenir agile... mais à des degrés et des niveaux d'intégration différents.

Finalement, le client doit-il abandonner l'idée d'un budget fixe ?

Le client doit avant tout être conscient qu'il est au coeur de son projet, que le prestataire n'est plus un sous-traitant mais un partenaire, et que les risques sont partagés. Lorsque le client souhaite une modification, il doit avoir conscience et accepter les effets que cela peut éventuellement avoir sur le périmètre, mais aussi sur le planning et si ce n'est pas suffisant sur le budget.

Cela peut sembler évident lorsque présenté hors du contexte d'un projet, mais prévoir, estimer et planifier 10 fonctionnalités, puis changer le besoin en cours de projet, et choisir de faire finalement 15 fonctionnalités a forcément un impact quelque part. L'approche agile n'annihile pas ce genre d'impact, mais elle offre par contre plusieurs possibilités pour prendre en compte le changement.

...Lire la suite en page 2...

En mode forfaitaire, c'est le devoir du prestataire de s'assurer que le client n'adhère pas à ces idées reçues car l'impact serait catastrophique en cas de difficultés sur le projet.

C'est en travaillant très étroitement avec le client qu'un "product backlog" peut être établi avant le début de projet (phase de cadrage et/ou "Sprint 0"). Très fréquemment, cette phase très courte où le "high-level scope" est défini et validé est d'ailleurs faite sous forme de régie pendant 3 à 4 semaines. Cela permet déjà au client d'intégrer quelques changements grâce aux conseils prodigués par des experts fonctionnels et techniques. Puis, le "product backlog" est estimé et comparé avec l'estimation initiale durant l'avant-vente.

Pour coller au budget initial, si le client n'a pas de levier financier, le périmètre peut être alors revu en retirant quelques fonctionnalités de priorité moins importante (NDLR : grâce aux itérations de l'approche agile, c'est aussi le cas lors de la constitution des "sprints backlogs"). L'ensemble de l'équipe peut alors s'engager en mode forfait tout en continuant à être agile.

Le contrat ne porte plus sur un cahier des charges, mais sur un "product backlog" construit et validé par l'ensemble des acteurs. Tout le monde se sent responsable.

Et pour le prestataire ? Comment gère-t-il le projet produit ?

Certes l'approche agile est orientée produit plutôt que projet, mais elle privilégie aussi l'humain plutôt que les outils et les processus. Est-ce que cela peut s'adapter au projet au forfait ? Quelle équipe constituer pour développer agile ?

Transparence et confiance sont deux aspects primordiaux au sein de l'équipe lorsque le projet est lancé. La communication entre les business analysts et les développeurs est bien entendu essentielle pour garantir la cohérence entre ce qui a été demandé et ce qui a été réalisé. Le Scrum Master est aussi là pour soutenir tous les membres de l'équipe et pour les aider à atteindre leurs objectifs.

Tous les outils et les processus doivent donc être clairs, simples, fluides et avoir une efficacité rapide pour ne pas gêner les individus et leurs interactions dans le projet. Tout doit s'inscrire de façon naturelle pour optimiser les échanges et apporter la solution aux contraintes du projet, comme le fait d'être engagé au forfait justement.

Intégration continue, travail à distance ou off-shore, partage du référentiel documentaire, suivi des campagnes de tests, représentation des "sprints planning" ou des "sprints backlogs", automatisation des tests d'intégration et de l'analyse de code... Chaque choix d'outils et chaque mise en place de processus doivent être longuement réfléchis pour qu'ils s'intègrent de façon intuitive et ergonomique dans les projets agiles au forfait.

Et ça fonctionne vraiment ?

Effectivement, c'est bien beau sur le papier. Mais il peut toujours y avoir une fonctionnalité plus complexe que prévue qui fait déraper un peu le projet, des imprévus de dernières minutes qui nécessitent de revoir une partie de l'architecture... Et au sein d'un projet au forfait, la gestion des risques requiert toujours autant d'attention et de mobilisation.

L'approche agile ne résout pas tous les problèmes. Penser le contraire serait une erreur. Mais elle propose des solutions pour les éviter ou mieux les gérer. C'est surtout grâce à l'ensemble de ses ressources expérimentées, ses outils intuitifs et de ses processus structurants et rassurants que l'approche agile permet de mieux organiser et maîtriser ses projets au forfait.