Agile

Agile est un ensemble de valeurs et de principes utilisées pour prendre des décisions sur la façon de développer un produit. Différentes méthodes et outils peuvent être adoptés pour aider une équipe à suivre les principes Agile, mais ils ne sont pas “Agile” en eux-mêmes.

Agile Manifesto

Agile est définit par le manifeste Agile. Il ne fait que 68 mots.

Il dit simplement que nous pouvons améliorer le processus de développent en valorisant

les individus et 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

12 principes Agile

En plus du manifeste, 12 principes sont définis pour soutenir les valeurs Agile.

La priorité est de satisfaire le client grâce à une livraison rapide et continue de produits de valeur.
Les changements de besoins sont toujours les bienvenus, même tard dans le développement.
Cela donne un avantage compétitif au client.
Les produits sont livrés fréquemment, de quelques semaines à quelques mois.
De préférence les délais plus courts.
Les clients et les développeurs doivent travailler ensemble tout au long du projet.
Construire des projets autour d’individus motivés.
Leur donner l’environnement et le soutien dont ils ont besoin, et leur faire confiance pour faire le travail.
La méthode la plus efficace et efficiente pour transmettre de l’information est une conversation face à face.
Un logiciel opérationnel est la principale mesure du progrès.
Les processus agiles encouragent un rythme de travail soutenable.
Les acteurs doivent être en mesure de maintenir un rythme constant indéfiniment.
Une attention continue à l’excellence technique et à une bonne conception améliore l’agilité.
La simplicité - l’art de minimiser la quantité de travail inutile - est essentielle.
Les meilleures architectures, spécifications et conceptions émargent d’équipes auto-organisées.
À intervalle régulier, l’équipe réfléchit à la façon de devenir plus efficace, puis ajuste son comportement en conséquence.

Pratiques Agile

Agile consiste à prendre chaque décision en fonction des principes et des valeurs que l’équipe a décidé de suivre. Simplement essayer d’imiter les actions et les pratiques d’une autre équipe ne rend pas une équipe Agile. Les pratiques utilisées par les équipes sont moins importantes que les raisons pour lesquelles elles sont utilisées.

En effet, au fil du temps, une équipe Agile va probablement changer et affiner les pratiques utilisées. Une équipe pourrait commencer avec des réunions quotidiennes debout, puis décider qu’une réunion assise une fois par semaine est plus efficace. Cela ne veut pas dire qu’il est inutile de regarder les pratiques utilisées par les équipes qui fonctionnent bien, mais de pas juste recopier.

Concept de base

Agile est un processus itératif, on livre rapidement et souvent. Au lieu de livrer le produit en un seul bloc, en fin de projet, on livre progressivement.

La première livraison ne contient que le minimum vraiment nécessaire, ce qu’on appelle un MVP: Produit Minimum Viable. C’est le produit minimum qui satisfait à l’exigence de base.
Puis on améliore ce produit au fil du temps, en ajoutant de plus en plus de fonctionnalités, toujours sur de courtes périodes de développement - appelées sprints.

Roles

Une équipe Agile a essentiellement 3 rôles principaux

Le client
Il s’agit de l’utilisateur, de l’entreprise ou d’un représentant. Il définit les priorités et fournit des commentaires à l’équipe projet
Le Scrum Master
Il s’agit du chef de projet. Il s’assure que le projet progresse bien et que chaque membre de l’équipe dispose des outils dont il a besoin pour accomplir son travail. Il établit les réunions, assure la liaison avec le client et facilite la planification des livraisons.
L’équipe projet
Il s’agit des personnes en charge de l’execution ou qui font partie de la mise en ouvre du projet: les développeurs, testeurs, analystes métier, etc. Ils construisent le produit et s’assurent qu’il répond aux exigences du client.

Avant de commencer Agile

Définir qui fera partie de l’équipe et que rôle jouera chaque personne
Convenir avec l’équipe des jours et des heures pour les rituels agiles (planning, réunion, demo, rétrospective)
Préparer les outils physiques ou numériques (par exemple un tableau Kanban)
S’assurer d’avoir rempli le travail préparatoire au projet (analyse de rentabilisation, budget, etc)
Déterminer les contraintes du projet (temps, argent, cycle économique, etc)
Définir le jour de sprint, de test et de livraison (par exemple, les mises en production se fera le jeudi matin)

Processus Agile

Le processus Agile mis en place dépend de chaque équipe. On présente ci-dessous un processus général qui n’a pas vocation à être suivit à la lettre mais peut être utilisé à titre d’exemple.

On établit une liste des fonctionnalités voulues, une sorte de wishlist de ce que le produit final sera, qu’on appelle le product backlog. Cette liste peut changer.
Pour toutes ces fonctionnalités, on établit des user stories.
Une user story définit qui, quoi et pourquoi. Par exemple: en tant que client, je veux pouvoir utiliser Facebook pour m’identifier au site e-commerce, pour ne pas avoir à créer un nouveau compte et gagner du temps.
On estime le niveau de difficulté de chaque user story, ce qu’on appelle des story points. On peut utiliser n’importe quelle unité de mesure: 1,2,3,4,5 ou s,m,l,xl,xxxl par exemple.
On décide quelle user stories feront partie de la prochaine livraison, qu’on appelle le release backlog.
On donne des priorités aux user stories et on estime la charge de travail requise: 1,2,4 ou 8 heures.
Si une user story prend plusieurs jours, on la décompose en sous-tâches pour en estimer la durée.
On divise les user stories sélectionnées pour la prochaine livraison (release) en sprints, de courtes périodes pendant lesquelles l’équipe de développement s’occupe de créer puis tester les fonctionnalités.
Chaque sprint dure généralement entre 2 et 30 jours.
À chaque fin de sprint, on teste le produit puis on passe au prochain sprint ou à la livraison.
La liste des user story qui constitue un sprint est un sprint backlog.

On peut utiliser un kanban board, un tableau qui contient des colonnes “à faire”/”en cours”/”fait”, pour suivre la réalisation des tâches du sprint. Ce tableau peut être physique ou numérique.
Le fait de diviser en sprints permet de s’assurer de l’avancement du projet. Ainsi, si un sprint est en retard alors il est probable que le projet sera fini en retard.
On peut surveiller l’avancement du projet grâce à un burndown chart, un graphique qui permet de visualiser l’ensemble des tâches effectuées et des tâches qui restent à accomplir en terme de charge de travail.
La pente du graphique est la vélocité du travail (burndown velocity), autrement dit la productivité moyenne pour chaque jour.

Pour que le burndown chart soit exact au jour le jour, l’équipe de dévelopemment doit mettre à jour l’avancement des tâches au jour le jour: tâches réalisées ou le temps restant pour celles en cours.
Le daily Scrum est une réunion debout de moins de 15 minutes où chaque personne explique brièvement ce qu’elle a fait depuis la dernière réunion et si elle rencontre des obstacles. Cela permet de s’assurer que tout le monde soit toujours informé et que tout problème est remonté le plus rapidement possible.
Une retrospective est organisée en fin de sprint pour que l’équipe communique ce qui s’est bien ou ne s’est pas bien passé, et puisse réfléchir à ce qui peut être amélioré.

This site is open source. Improve this page.