GDP Agile avec SCRUM

Chapitre 1 : Qu'est-ce qu'une approche agile?

C'est une approche (qui est une alternative à l'approche traditionelle ou "cycle en v") utilisant une ou plusieurs partageant des points communs avec un document sorti en 2001 : "Le manifeste pour le développement agile de logiciels" qui valorise:

• Les individus et leurs interactions plus que les processus et les outils
• Des logiciels opérationnels plus qu'une documentation exhaustive
• La collaboration avec les clients plus que la négociation contractuelle
• L'adaptation au changement plus que le suivi d'un plan

Ces 4 valeurs s'appuient sur 12 principes:

Notre plus haute priorité est de satisfaire le client
en livrant rapidement et régulièrement des fonctionnalités
à grande valeur ajoutée.

Accueillez positivement les changements de besoins,
même tard dans le projet. Les processus Agiles
exploitent le changement pour donner un avantage
compétitif au client.

Livrez fréquemment un logiciel opérationnel avec des
cycles de quelques semaines à quelques mois et une
préférence pour les plus courts.

Les utilisateurs ou leurs représentants et les
développeurs doivent travailler ensemble quotidiennement
tout au long du projet.

Réalisez les projets avec des personnes motivées.
Fournissez-leur l’environnement et le soutien dont ils
ont besoin et faites-leur confiance pour atteindre les
objectifs fixés.

La méthode la plus simple et la plus efficace pour
transmettre de l’information à l'équipe de développement
et à l’intérieur de celle-ci est le dialogue en face à face.

Un logiciel opérationnel est la principale mesure d’avancement.

Les processus Agiles encouragent un rythme de développement
soutenable. Ensemble, les commanditaires, les développeurs
et les utilisateurs devraient être capables de maintenir
indéfiniment un rythme constant.

Une attention continue à l'excellence technique et
à une bonne conception renforce l’Agilité.

La simplicité – c’est-à-dire l’art de minimiser la
quantité de travail inutile – est essentielle.

Les meilleures architectures, spécifications et
conceptions émergent d'équipes autoorganisées.

À intervalles réguliers, l'équipe réfléchit aux moyens
de devenir plus efficace, puis règle et modifie son
comportement en conséquence.

 

Ce manifeste illustre "l'état d'esprit agile". Ces méthodes sont nées du constat que les procédures étant si complexe dans le monde du logiciel, les incertitudes sont grandes; de plus, puisqu'on ne peut connaître complètement le besoin tant que les utilisateurs n'ont pas utilisé, il fallait de nouvelles approches. SCRUM est le cadre méthodologique le plus utilisé.

Les méthodes agiles prônent le fait que chercher à donner tous les détails du projet avant de se lancer est contre-productif, car on devra faire face à des imprévus. La planification et les spécifications peuvent vite devenir obsolètes : on va plutôt commencer par un premier objectif, et adapter son itinéraire une fois celui-ci atteint. On pourra alors faire une projection basée sur l'expérience acquise, pas exacte mais meilleure qu'avec une approche traditionelle : on parle d'approche empirique.

Jean-Pierre Chardon : "L'entreprise doit avoir l'agilité du banc de poisson qui agit et réagit avec vitesse, simultanéité et précision". (lol)

Une entreprise doit savoir s'adapter rapidement et utiliser une intelligence collective.

Pour faire simple, la méthode agile passe d'une approche prédictive à une approche empirique et pragmatique.

 

Chapitre 2 Fonctionnement de SCRUM : une démarche itérative et incrémentale.

SCRUM est basé sur un processus empirique basé sur 3 piliers; scrum privilégie la légèreté méthodologique et l'approche empirique (acquérir des connaissances en se basant sur l'expérience et prendre des décisions basées sur des faits connus).

3 piliers:

• Transparence, pour donner de la visibilité aux responsables du projet
• L'inspection, pour détecter les écarts indésirables
• L'adaptation pour rectifier ces écarts.

Comme pour une bataille, les plans sont inutiles mais la planification est capitale : il ne faut pas chercher à tout prévoir mais plutôt chercher à planifier au fur et à mesure.

Comment ce mécanisme se traduit-il en termes de processus?

Cela commence avec le product owner, qui représente les utilisateurs et a la vision du produit que l'on souhaite réaliser.

• Il travaille sur la vision du produit (Quel produit, pour quoi faire?)
• Il met l'ensemble de ses besoins dans le product backlog, mais sans aller dans le détail; de plus il sollicite l'équipe de dev pour estimer chaque fonction notamment d'un point de vue technique.
• Une fois que cela est fait il ordonnance son product backlog, avec en haut les élements très importants ou a forte valeur, et en bas les élements moins importants. Il peut s'appuyer pour ça sur d'autres acteurs (devs, etc...)

Une fois que cela est fait, on peut démarrer le SPRINT (les itérations) en procédant à la réunion de planification de sprint; on va choisir un sous-ensemble d'élements dans le product backlog qui seront réalisés dans le sprint en cours. Cette réunion a surtout le client et l'équipe de dev, et on essaie d'avluer la difficulté du projet (l'estimation sera de plus en plus précise au fur et à mesure des réunions de sprint).

Les élements sélectionnés vont dans le sprint backlog, qui détermine le périmètre du sprint et le plan d'action associé à l'atteinte de l'objectif. Il peut aussi faire l'objet d'un découpage en sous-tâches pour répartir le travail et améliorer la mesure de l'avancement. La réunion de planification de sprint est "timeboxée", ie elle doit s'arrêter avant la fin de la deadline afin de rester concentré sur l'objectif (en général 8 heures max pour 1 mois de sprint). Ca permet de se concentrer sur l'objectif.

Une fois cela fait, les travaux commencent, avec la conception détaillée, mise en oeuvre et test des fonctionnalités. Chaque jour au cours de la "mêlée quotidienne" l'équipe se synchronise vis-à-vis de l'objectif du sprint pour la journée avec un stand-up meeting de 15 minutes, et on ne regarde pas les problèmes (on fait plutôt ça après les mêlées avec les personnes concernées).

Le sprint est timeboxé, il se termine par la revue de sprint (le produit incrémenté avec ses nouvelles fonctionnalités est présenté aux parties prenantes comme users, sponsors, service marketing... dont les retours serviront, on choisit aussi la direction à prendre). La retrospective de sprint sert elle à revenir sur le sprint pour améliorer le processus dès le sprint suivant. Cette réunion est limitée à 3h pour 1 mois de sprint et rassemble tout le monde : Product owner, Devs et scrum master. C'est un genre de post-mortem, mais qui permet de tenir compte des remarques tout de suite.

Le Scrum master s'assure que tout le monde reste dans la méthodologie de Scrum.