De plus en plus de sociétés de services et leurs clients se retrouvent empêtrés dans des conflits portant le plus souvent sur la non-atteinte du périmètre applicatif escompté. Ils s’en rendent généralement compte lorsque le ScrumMaster se fait appeler « Monsieur le Président ».

Voici un petit article sur des « détails » et des responsabilités réciproques des uns et des autres que les vendeurs de certifications et soupe Agile à base de « bouquins » pompés sur les méthodes US ne vous annoncent pudiquement jamais.

Éléments différenciateurs des méthodes Cascade et Agile

La méthode Cascade et la méthode Agile sont les deux approches formelles de conduite de projet actuellement utilisées lors d’un développement applicatif. Elles répondent aux concepts suivants :

1. Dans une approche Cascade, les activités du projet sont découpées en phases produisant obligatoirement un livrable (cahier des charges, spécifications détaillées, conception, réalisation, test et mise en exploitation), dont l’acceptation conditionnera la suite du projet et sur lequel il ne sera pas possible de revenir sans remettre en cause le contrat projet préalablement accepté.
2. Dans une approche Agile, les parties assument que dans une étape préparatoire (nommée « Sprint0 » par la méthode Scrum), l’équivalent des informations d’un cahier des charges, incluant les spécifications générales (nommées Product Backlog) sont fournies. L’objectif est de pouvoir réaliser une estimation initiale du projet en l’état de la complétude des spécifications à ce moment donné. Ensuite, toutes les autres activités du projet (spécifications détaillées, conception, réalisation, test et mise en exploitation) se réalisent simultanément en une seule phase. Afin de faciliter le contrôle de l’avancement du projet, cette production est découpée en périodes d’activité de durées généralement identiques nommées Sprint. Durant un Sprint, un ensemble de fonctionnalités sera développé avec l’aide du client (qui en a choisi la priorité) et qui doit :

• en affiner la spécification du détail (itérations) ou en changer si nécessaire ;
• les tester fonctionnellement et les valider (done) pour la mise en production

L’équipe de développement ayant pour sa part :

• la responsabilité de la qualité du code ;
• l’obligation d’accepter les changements.

Le déterminant d’une méthode par rapport à une autre n’est donc pas le type de projet sur laquelle celle-ci s’applique, mais la mise en œuvre d’un phasage unique, associé à un concept d’engagement consensuel des parties offrant des facilités adaptatives à la maîtrise d’ouvrage.

Avantages et inconvénients du choix de la méthode

Mettre en œuvre une méthode Cascade ou une méthode Agile consiste à choisir entre deux maux :

1. Cascade : la nécessité d’une formulation longue, coûteuse, mais extrêmement précise et difficilement modifiable du besoin, avec, en contrepartie, la capacité de définir un périmètre fixe.
2.   Agile : les possibilités de lancer le développement sans attendre la formalisation complète du besoin et l’acceptation de sa modification en cours de développement, avec, en contrepartie, la variabilité du périmètre.

L’objectif de cette nouvelle organisation dite « Agile » des développements est donc :

• d’éviter au client d’avoir à fournir l’ensemble des spécifications dès le début du projet ;
• de pouvoir changer ses exigences en cours de réalisation.

Pour l’équipe de développement, la contrepartie de l’incertitude ainsi générée est la variabilité du périmètre à produire. Ce point est le fondement même du paradigme Agile et se comprend ainsi :

• Dans une méthode classique de conduite de projet (mode Cascade), le périmètre des fonctionnalités est fixe et défini par contrat. La variable d’ajustement en cas de problèmes est le temps de développement (avec son impact en équivalent financier).
• Avec une méthode Agile de type Scrum, les fonctionnalités ne sont pas nécessairement détaillées et celles ayant fait l’objet de l’estimation initiale en « unités d’œuvre » ne seront peut-être pas exactement celles livrées au final. En cas de problème ou de changements souhaités, la variable d’ajustement est le périmètre. De ce fait, toute contractualisation formelle est difficile et sujette à controverse.

L’usage d’une méthode Agile est donc un pari sur :

• la compétence de l’équipe technique de réalisation ;
• la capacité du métier, représenté par le Product Owner, à fournir en permanence les informations permettant de développer et de tester.

Note : Ce principe d’un marché se voulant gagnant-gagnant est généralement bien compris en théorie par les deux parties en ce qui concerne les avantages qu’elles peuvent en tirer, mais les contraintes d’engagement qu’il impose sont souvent sous-estimées par le métier. En revanche, en cas de difficultés, on se rend rapidement compte que le principe n’avait été imaginé qu’en termes d’avantages.

Scrum engagement réciproque et simultané des parties À ce point, il est nécessaire de comprendre les engagements réciproques.

• L’équipe de développement Agile Scrum a pour responsabilité la qualité technique du code et l’amélioration de son processus de développement (lors de rétrospectives).
• Le représentant du client (Product Owner Scrum) a pour responsabilité de fournir régulièrement, si ce n’est en permanence, les spécifications détaillées des fonctionnalités à produire, leurs priorités, leurs conditions de tests et la validation fonctionnelle de leur livraison (notion de « done »). Il est donc en mesure quotidiennement de connaître exactement l’état de la production en termes d’avancement et de qualité fonctionnelle (affichage mural, BurnUp chart).

Comment déterminer une conduite de projet Agile ?

Les principaux paramètres déterminant le mode Agile par rapport au mode Cascade sont les suivants :

1. Lorsqu’un projet est annoncé officiellement comme allant se réaliser en mode Agile Scrum, le client est prévenu qu’il participe à un contrat gagnant-gagnant. Il n’aura pas la nécessité de formaliser immédiatement une spécification détaillée et complète et il pourra ensuite changer le contenu (non encore réalisé) du projet sans pénalité ni nouvelle contractualisation. En contrepartie, il accepte :

• la variabilité du périmètre (dont il a la responsabilité),
• un engagement régulier de spécifications des besoins détaillés au moment où il décidera qu’ils devront être développés.

2. Responsable de ces choix, le Product Owner doit en contrôler en permanence la validité et la faisabilité. Il disposera pour cela d’un affichage mural mis à jour en permanence.
3.   La production est organisée en « Sprint » (processus encore nommé itération ou incrément) et les changements sont acceptés.

Comprendre ces notions, c’est comprendre la réalité de la conduite de projet Agile comme principe méthodologique accepté par les deux parties (qui n’en font alors plus qu’une orientée vers un but commun : la finalisation d’un produit). Par contre, lorsque tout tourne mal il faut garder à l’esprit deux points fondamentaux :

• Dans une approche conventionnelle ou Cascade, l’expression des besoins est nécessairement exhaustive et conditionne la réponse à l’appel d’offres, et par suite le contrat projet qui en résulte. Lequel n’est plus amendable que formellement (par des avenants).
• Dans une approche Agile, le principe fondamental majeur est l’acceptation d’une expression des exigences incomplète – ou peu formalisée – au début du projet. Il en découle que la variable d’ajustement en cas de problème est le périmètre.

Dans ce type de contexte, deux visions se considérant comme légitimes se superposent alors :

• D’une part, des informaticiens agissant dans la certitude de travailler dans le cadre d’une approche méthodologique Agile leur offrant la possibilité de rendre le périmètre variable au gré des aléas du projet et de la dispersion des ressources liées à l’acceptation du changement et des retards de spécifications. Ils acceptent donc les changements.
• D’autre part, un client persuadé que l’agilité lui offre la souplesse du changement sans aucun coût, ni prise de risque, ni réduction de son périmètre applicatif initial et qui, de surcroît, n’a pas saisi l’importance de la nécessité incontournable d’un engagement continu en matière de spécifications et de validations en quasi temps réel.

Lorsque le client (ou le Product Owner)  change de priorité ou de fonctionnalité selon la possibilité offerte par les principes de l’agilité, l’équipe de réalisation n’a pas à formuler de réserve car le coût de ces changements s’inscrit naturellement dans la variabilité du périmètre final. Cela occasionne alors un glissement normal des autres fonctionnalités, et celles ne pouvant plus être réalisées dans le cadre du contrat projet défini dans le Sprint 0 (ou ailleurs) devront faire l’objet d’un contrat projet suivant.

De ces faits, en mode Agile, les glissements de livraisons sont aussi naturels que la variabilité du périmètre qui en découle. En revanche, le Product Owner ne peut en ignorer les conséquences puisque c’est lui le pilote de l’acceptation fonctionnelle qui détermine ce qui sera considéré comme « done » et présenté en démonstration de fin de Sprint.

Jean-Pierre Vickoff - JDN Juin 2016