Agile, Scrum, Méthodologie – Un tour d’horizon rapide sur la méthode agile

Agile, voilà bien un mot qui est dans l’air du temps en ce qui concerne la gestion de projet web, mobile ou applicatif.
Cet article n’a pas vocation à faire de vous un “Scrum Master” mais l’objectif simple de présenter les points essentiels de la méthodologie agile en se concentrant essentiellement sur les mots-clés et les notions de base qui sous-tendent l’approche agile.

Things Have Changed

Sous l’impulsion du web notamment où les notions de ROI et d’expérience utilisateur sont devenues centrales, la gestion de projet a donc connu une révolution dans sa pratique. Deux tendances se dégagent que l’on peut résumer ainsi :

• Itératif vs Prédictif
  Le développement web ou logiciel présente une évolution majeure : on est passé d’un modèle de direction de projet prédictif à un modèle itératif.
• ROI & UX
  Ces deux affirmations sonnent comme des évidences mais bon, c’est agile !
  • Chaque étape de développement doit produire un résultat tangible (ROI), ce qui implique une gestion du temps parcimonieuse et surtout bornée (timeboxed).
  • Les impératifs du client prédominent désormais, une application ne conçoit plus à priori mais à posteriori, au fil de l’eau. Certes, le client décide en amont et hiérarchise son expression de besoins mais c’est via les retours d’usage (processus itératif) que le produit émerge (site, application…etc).

Cascade vs Agile

C’est presque une répétition de ce qui est énoncé plus haut mais dans une perspective historique cette fois-ci. Cette évolution peut-être résumée par l’affirmation suivante :
D’un développement encascade = prédictif, on passe à un développement enagile = itératif. Pour mémoire, une définition des deux méthodes :

• Développement en cascade
  Un développement en cascade se fait à partir d’un cahier des charges complet, qui aboutit à la livraison d’un produit «fini»
• Développement agile
  Un développement agile se fait par versions successives (itérations) où le prestataire livre, sur plusieurs mois, des versions qui s’enrichissent progressivement.

Le graal : information & communication

C’est la clé de voute de la méthode Agile, en effet fort du constat que + de la 1/2 des fonctionnalités développés ne sont pas utilisées et + de la 1/2 des défauts sont liés à un mauvais recueil des besoins.
Etre agile, c’est comprendre ce que le client a en tête, “l’accoucher” sans perdre de temps donc d’argent tout en lui transférant la responsabilité du rendu via le product backelog car c’est avec ses mots que le produit sera défini via des user stories par exemple et bien sur loin de toute exhaustivité, ne sera pris ne compte que ce que le client énonce ! Agile et Habile.

Recueil des besoins

Pourquoi est-ce si difficile de recueillir les besoins du client. Plusieurs raisons à cela, incommunicabilité, absence de culture commune, ignorance… Bref être agile, c’est pratiquement faire oeuvre d’ethnologue. Il s’agit de vaincre les maux suivants :

• Mauvaise communication
• Exhaustivité Illusoire
• Défaillance de client (par essence le client ne sait pas)

Faire émerger les besoins

Un besoin n’est pas seulement une fonction mais la capacité du système à assurer cette fonction. Pour dire les choses de manière prosaïque, si le client ne peut lui même opérer la fonction donc à la reproduire quand bon lui semble, cela ne sert à rien.

• Cela va mieux en le disant !
  Sortir tout ce qui est implicite. En effet, il est question de maïeutique, c’est donc que tout doit pouvoir être dit et énoncé.
• Laisser du temps au temps mais pas trop…
  Le recueil des besoins et la hiérarchisation s’inscrit dans une démarche itérative. Le démarche itérative est dangereuse d’un point de vue strictement financier en effet il est fort à parier que le projet tombe dans l’histoire sans fin, le client renouvelle en permanence l’expression de ses besoins, l’itération produit du désordre en lieu et place de l’efficience.

Pourquoi nous “agilons” ?

Quelques-unes des valeurs agiles :

1. Utilité et «Usability» (ce que les japonais parait-il nomme la bienveillance du produit)
2. Efficacité (le moins d’efforts possibles en terme de développement)
3. Efficience (le plus rapide pour obtenir la réponse à un besoin du client)
4. Satisfaction (meilleur expérience possible ou comment maximiser la satisfaction client en montrant que les choses avancent.)

C’est donc choisir le plus court chemin pour l’obtention d’un résultat avec en ligne de mire la satisfaction du client et de ses besoins. Le mantra ROiste du chef de projet agile

La boucle du feedback

Le feedback, c’est le retour utilisateur/client. C’est sans doute la dimension la plus chronophage mais la plus efficiente puisque elle offre au client la possibilité d’être entendu et compris.

• La boucle du feedback est connu sous le nom de démarche en T, les besoins «grosse maille» puis les besoins affinés.

Les techniques de recueil

Il existe moult manières de recueillir les besoins d’un client, il est toujours possible de faire un panachée des méthodes suivantes.

• Brainstroming
• Benchmark
• Interviews
• Workshop
• Analyse de l’existant
• Observation comportement utilisateur en situation

Formaliser les besoins

Une fois les besoins recueillis, il est impératif de : N’avoir aucune déperdition d’information, Assurer la traçabilité nécessaire des informations. Voilà donc la raison d’être des redmine, wiki qui historisent et sont le principal canal de communication vers toutes les parties prenantes du projet.

Toutefois, en mode agile, la fonctionnalité livrée constitue le meilleur support de discussion. Voir et expérimenter la fonction est toujours plus convaincant, cela privilégie le langage utilisateur (UX) compréhensible par tous (clients, développeurs, marketing….etc.), reste à être en mesure de fournir la fonctionnalité au terme d’une itération (AKA sprint).

Le recueil des besoins : les 3 approches

• Approche IEEE
  Une approche qui définit les exigences essentielles (fonctions, performances, contraintes de conception, attributs de qualité).
• Approche UML
  C’est la méthode utilisant des cas d’utilisation (UC), les User-Case.
• Approche user stories
  Une exigence est formulé avec le langage utilisateur, en 1 ou 2 phrases pour servir un but.
  C’est souvent sur cette base que s’appuie la méthode agile
  L’estimation sur la base des User Stories permet de définir des User Story points.

  Exemples de User Stories

  Les étudiants peuvent acheter un passe de stationnement mensuel en ligne.
  Le passe de stationnement peuvent être payés par carte de crédit.
  Le passe de stationnement peuvent être payés via PayPal ™.
  Les professeurs peuvent donner des notes aux élèves.
  Les étudiants peuvent obtenir le calendrier des cours en ligne.
  Les étudiants peuvent commander relevés de notes officiels.
  Les cours seront disponibles en ligne via un navigateur standard.

User Story, User Points, Vélocité

• User points
  Chaque User Story se voit attribuer un nombre de points.
  On prend la User Story la plus petite et on lui affecte le poids de 1, ensuite on cherche le poids relatif des story par rapport à cette première Story.
• Qu’est-ce que la vélocité ?
  C’est le nombre de Story points que l’équipe est capable de parcourir en une itération (sprint)
• Un exemple de vélocité ?

  Si la taille du projet est estimé à 100 story points et la vélocité de l’équipe est estimé à 10 points pour une itération (sprint) de 2 semaines. Le projet prendra donc (2×100)/10 = 20. Ce qui fait que le projet prendra 20 semaines.

La pièce maîtresse : le “Product Backlog”

Ces 3 approches peuvent être combinées, elles vont constituer le PRODUCT BACKLOG (PB)

Le PB regroupe l’ensemble des besoins/exigences ou des livrables à réaliser. C’est la “file d’attente” ou le portefeuille des fonctionnalités dont certaines seront sélectionnées au cours des itérations (sprint).

• Les composants du PB sont les PBI (Product Backlog Items)
• Les PBI (Product Backlog Items) sont hiérarchisés en fonction de leur valeur ajoutée (VA)
• Le “Product Backlog” ou PB est sous le responsabilité du “product owner”

Définition du “product owner”

A Scrum project is driven by a product vision compiled by the Product Owner, and expressed in the Product Backlog.

Source : Scrum Handbook de Jeff Sutherland

Bien que le “Product Backlog” puisse être mis à jour par “product owner” afin de refléter l’évolution des besoins en raison de nouvelles idées, de mouvements de la concurrence, des obstacles techniques qui apparaissent bref ce qui est constitutif de la vie d’un produit, il est impératif de hiérarchiser les besoins.

Hiérarchiser les besoins

La hiérarchie des besoins se fait selon :

• Le bénéfice attendu

  Estimer le bénéfice surtout à l’aune de la satisfaction du client.

• Le coût de développement estimé

Etre dans l’enveloppe globale ou ne pas être.

• L’opportunité d’apprentissage pour l’équipe
  La méthode Agile permet de ne pas brider la créativité d’une équipe toutefois il faut pouvoir mesurer la courbe d’apprentissage d’une équipe, élément déterminant dans sa velocité.
• Le risque de développement
  En d’autres termes, quelles risques y-a-t-il à se lancer dans le développement de telle ou telle fonctionnalité.

Le degré de satisfaction du client

Il faut enfin intégrer le degré de satisfaction du client. Un des modèles les plus connus pour qualifier ces exigences du client et leurs satisfactions, c’est la nomenclature du Modèle de MoSCoW dont la terminologie sans forcément en connaitre l’origine, s’est imposée.

1. Exigences obligatoires (les “Must-have”)
2. Exigences exprimées (les “Should-have”)
3. Exigences latentes (les “Could-have”)

Une mention est à préciser, c’est que le web reste quand même le règne du “Good-enough”. On peut donc additionner à ce Modèle de MoSCoW, une notion d’exigence suffisante ou satisfaisante (le “Good-enough”).
Source : http://en.wikipedia.org/wiki/Principle_of_good_enough

Les abréviations d’origine du Modèle de MoSCoW

• M pour “Must-have”, que l’on peut traduire en français par Indispensable
• S pour “Should-have”, que l’on peut traduire en français par Souhaitable
• C pour “Could-have”, que l’on peut traduire en français par Possible
• W “Want to have but Won’t have”, que l’on peut traduire assez brutalement d’ailleurs par Eliminé

Source : MoSCoW Method

Planifier agile, c’est penser produit fini

En abandonnant une approche prédictive, qui consiste à tout planifier au début, on privilégie l’agilité c’est à dire une approche adaptative afin d’intégrer l’incertitude. Toutefois, l’objectif est la satisfaction du client enfin cela doit être le but affiché ! Aussi est-il toujours profitable de penser au produit fini.

Si pour chaque projet, il est défini une enveloppe globale. Avec la méthode Agile, quand l’enveloppe globale est consommée, les développements certes s’arrêtent mais il y a fort à parier que le client obtient un produit fini avec au moins les fonctionnalités les plus importantes, les fameux "Must-have" et puis c’est "Good-enough".

Définir une enveloppe globale

C’est l’aspect financier qui ne dit pas son nom. En effet de cette enveloppe globale sortira la quotation, le pricing, en clair le fric que le client va devoir lâcher :):) Pour l’occasion, la méthode agile est aussi dépourvue que toutes les autres méthodes !

En rationalisant un peu, l’enveloppe globale peut-être définie à la louche mais au moins à l’aide de 3 étapes : estimation de la taille du projet, prise en compte des spécificités, estimation de la charge.

1. Estimer la taille
   C’est la quantification des composantes du projet à développer : nombre de pages, d’écrans, de fonctionnalités, de tables… On donne à chacun de ces composantes des points.
   Les usages veulent que un écran = 3 jours alors une base de données…
2. Prendre en compte les spécificités du projet
   Il faut penser aux facteurs d’influence à prendre en compte comme faisant parties du contexte. Doux euphémisme ou pur exemple de novlangue pour désigner tous les aléas liés à notre incapacité à prédire le futur avec un plan ou pas. Une sorte de talon d’agile en quelque sorte.
3. Estimer la charge
   Elle est exprimé en jours/homme, indépendant de la durée du projet. C’est le prix…

Planifier avec une démarche agile

Il y a 5 niveaux de planification dans la démarche agile :

• Niveau 1 vision du produit
  C’est l’enveloppe globale + le PB (product backlog)
• Niveau 2 roadmap ou jalon
  C’est la livraison de versions successives en fonction des priorités définies par le client. Chaque livraison constitue une «release».
• Niveau 3 plan de la release
  Une «release» se définit par une date de début et de fin, un thème et une sélection de fonctionnalités à implémenter. A l’intérieur de la «release», on définit des itérations auxquelles sont affectés les différentes «stories».
• Niveau 4 plan de l’itération
• Niveau 5 cycle quotidien
  C’est le daily stand-up meeting en clair motiver ses troupes même si personne ne veut travailler.

Ce que Agile est d’évidence, c’est une méthode où la prédictibilité est exclue, c’est bannir l’adage tout est défini à l'avance, Beurk ! Certes, il est possible de s’appuyer sur une batterie de documents (cahier des charges, diagramme de gantt… etc.) qui peuvent au final rendre totalement indigeste la vision du produit mais l’être humain est ainsi cela le rassure ! Car en mode prédictif, l’objectif deviendrait presque de suivre le planning coûte que coûte indépendamment de la réalité de ce qui est produit. La méthode agile, c’est une planification macroscopique initiale, puis détaillé au fil de l’eau, bref la gestion de l’incertitude, reste à savoir si on est risk-adverter ou risk-lover ?

En savoir plus

• Scrum Log de Jeff Sutherland
  http://scrum.jeffsutherland.com/
• Scrum Handbook de Jeff Sutherland
  http://jeffsutherland.com/scrumhandbook.pdf
• The Enterprise and Scrum de Ken Schwaber
  http://www.amazon.com/Enterprise-Scrum-Ken-Schwaber/dp/0735623376
• Scrum Foundation
  http://scrumfoundation.com/
• A Lightweight Guide to the Theory and Practice of Scrum
  http://assets.scrumfoundation.com/downloads/1/scrumprimer20.pdf
• http://fr.wikipedia.org/wiki/Novlangue