Méthodes agiles

Objectifs

Savoir énoncer les caractéristiques typiques des approches agiles
Savoir organiser un petit projet avec timeboxing, product backlog et journal de bord.

Introduction aux méthodes agiles

Les méthodes agiles : de la planification au pilotage

Fondamental : De la planification au pilotage

Le fondement des méthodes agiles et qu'il n'est pas possible de tout prévoir correctement, et qu'il vaut mieux planifier au niveau macro uniquement et piloter au niveau micro.

Définition : Méthode agile

Une méthode agile est une approche itérative et incrémentale, qui est menée dans un esprit collaboratif, avec juste ce qu'il faut de formalisme.
(Gestion de projet : Vers les méthodes agiles , p42)

Fondamental : Manifeste pour le développement logiciel agile (2001)

Les individus et leurs interactions avant les processus et les outils.
Des fonctionnalités opérationnelles avant la documentation.
La collaboration avec le client plutôt que contractualisation des relations.
L'acceptation du changement plutôt que conformité aux plans
https://agilemanifesto.org/

Exemple : Exemple de méthodes agiles

Rapid Application Development (RAD)
Adaptative Software Development (ASD)
Crystal
Scrum
eXtreme Programming (XP)

Caractéristiques des organisations agiles

Travail en équipe souple

Organisation horizontale : co-décisions, le chef de projet tranche quand c'est nécessaire, il ne commande pas
Binôme : les travaux en binômes sont favorisés (lorsque les tailles d'équipe le permettent) pour éviter les compétences uniques risquées dans tout projet, a fortiori peu formalisé
Partage d'information et du travail : serveurs de code source, de documentation, forums de discussion, de veille, ...
Polyvalence : les membres de l'équipe sont intéressés largement aux travaux (plusieurs modules, participation à la gestion, aux relations client, ...)

Moins de specs, moins de proto

Chaque itération vise à produire un produit fonctionnel (notion d'incrémentation) et non un prototype ou une spécification.

On travaille moins sur les représentations du produit (spécifications, modèles, etc.) et plus sur le produit lui même.

Remarque : La méthode de Monsieur Jourdain, comme souvent...

Une méthode agile est avant tout une méthode de bon sens, dans laquelle on travaille en bonne intelligence.

Si on est réactif, prêt à changer d'avis quand cela est sensé, que l'on suit de près son projet, qu'on ne perd pas de temps avec le superflu... on fait de l'agile sans le savoir !

Avantages des méthodes agiles

Meilleure communication (moins de formalisme et plus d'information utile)
Meilleure visibilité (réelle et non fantasmée)
Qualité gérée en continue (et non tâche de documentation déconnectée et à la fin, par exemple)
Détection des problèmes au fur et à mesure (et non bilan a posteriori)
Équipe plus solide (démarche de progression et non de conflit, collaboration, relations humaines)

Fondamental : Adéquation au besoin

Meilleure adéquation au besoin, puisque l'on renégocie le champ fonctionnel du système au fur et à mesure de la mise en place des usages réels (et non en fonction d'usages ou d'outils fantasmés).

Fondamental : Visibilité et cumulativité

Valeur ajoutée et visibilité apportées au fur et à mesure et non en fin de projet.
Chaque itération vise à améliorer l'itération précédente (par ajout de nouvelles fonctions, optimisation de fonctions existantes, ou par retrait de fonctions inutiles ou néfastes).

La question des budgets et des délais

Fondamental : Hyperstatisme et degrés de liberté

Les méthodes traditionnelles ont tendance à l'hyperstatisme, rien ne peut être bougé, car tout est fixé : délais, coûts, fonctions.

Dans une méthode agile, en revanche, l'on va maintenir un ou plusieurs degrés de liberté :

Le budget est fixé, voire les délais, mais pas le champ fonctionnel.
Le budget est fixé avec plus ou moins 30%, les délais sont fixés (livraison obligatoire), une partie du champ fonctionnel est optionnelle.
La date de livraison est fixée sans marge de manœuvre et l'on joue sur le spectre fonctionnel pour ajuster, voire sur le budget (accroissement des ressources en parallèle).
...

Intermédiaire forfait/régie

Les méthodes agiles s'accommodent bien :

de budgets à la régie, dans le cadre d'une enveloppe générale plus ou moins stricte correspondant à une évaluation a priori de la MOE en accord avec les moyens de la MOA.
de budgets au forfait, à condition qu'ils soient négociables dans une certaine mesure (et dans les deux sens), et qu'ils ne soient pas (trop) liés contractuellement à un spectre fonctionnel (trop) précis.

Finalement, les deux approches convergent vers un entre-deux...

Exemple :

L'enveloppe initiale fixée a priori est de 100k€, le délai de 6 mois, l'équipe de 4 personnes, pour 200 h.j de travail.
À la fin de la première itération, il apparaît qu'une fonction F1 est beaucoup plus complexe que prévue, elle est simplifiée en F1' et un complément de 20 h.j est estimé, un supplément budgétaire de 10k€ est alloué.
À la seconde itération, la fonction F1' est terminée, finalement sans surcoût, grâce à une nouvelle technologie identifiée ayant permis de gagner du temps.
Les 10k€ supplémentaires sont maintenus, mais alloués à une nouvelle fonction F2 non prévue initialement, que le client a identifié entre temps dans un produit concurrent.
...

To be continued...

Projets agiles = risque de dérive ?

Au contraire car on inverse le raisonnement habituel : On ajuste le contenu aux moyens plutôt que le contraire.

Si on souhaite faire quelque chose d'imprévu, ou que l'on rencontre un problème, on va modifier le contenu de ce que l'on souhaitait faire globalement pour absorber le coût de la modification.

Alors que dans un projet traditionnel, on est soumis à la contrainte globale qui empêche les ajustements locaux sans négociation (avenant, etc.).

Fondamental :

L'objectif des méthodes agiles est de payer plus de réalisation et moins de régulation.

Exemple : Contre-exemple (officieux !)

Les prestataires de services ont coutume d'appliquer un facteur d'ajustement une fois les jours de développement évalués pour payer les coûts de régulation d'une part et tenter de palier par avance aux incertitudes d'autre part.

Ce facteur est en général bien supérieur à 2... Donc pour une journée productive en terme de réalisation, plusieurs sont passées à en parler ou à se protéger de ses éventuelles conséquences néfastes !

Exemple d'outils agiles

Timeboxing (boîtes de temps)

Définition : Timeboxing (gestion par boîtes de temps)

Principe du timeboxing : Les itérations ont une durée fixe, sont à court terme (< 1 mois), on évalue chaque itération à la fin et on réajuste le plan de travail en fonction des résultats.

Exemple :

Définition : Sprint (boîte de temps)

On appelle souvent sprint une itération correspondant à une timebox (boîte de temps).

Attention :

Il est important que les boîtes de temps aient une durée constante, que les réunions soient régulières, idéalement le même créneau à chaque période (c'est cette horlogerie qui permet au projet un pilotage régulier).

Fondamental :

Il est indispensable que les tâches soient découpée de telle façon que leur durée estimée de réalisation ne dépasse jamais une boîte de temps.

Exemple : Boîtes de temps d'une semaine

Tous les jeudis on livre à 18h.
On se réunit tous les vendredis à 14h.

Conseil :

Les livrables sont toujours antérieurs à la réunion et consultés avant celle-ci par le client.
On ne présente pas ce qui a été fait (c'est déjà connu), on entre directement dans l'étude critique des livrables.
On maintien le plan de travail (TODO-list, product backlog...) à jour.

Product backlog

Définition : Product backlog

Liste des fonctions ou tâches à faire
Hiérarchisées : importance, délais, difficulté, coût...

Méthode :

Avant chaque timebox le product backlog sert d'outil d'arbitrage
Après chaque itération le product backlog est mis à jour

Exemple :

Conseil : Kanban

Les logiciels de type kanban sont très adaptés à la gestion de product backlog.

Trello (propriétaire)
Kanboard (libre)
Gitlab boards (libre)
...

Exemple : Exemple de colonnes

Todo/Open : toutes les tâches encore à faire
Delayed : les tâches prévues à un moment, mais reportées entre temps
Doing : les tâches en cours de traitement sur l'itération
Done/Closed : les tâches terminées
Abandoned : les tâches abandonnées

Journal de bord (JDB)

Définition : Journal de bord (JDB)

Le journal de bord est un enregistrement séquentiel de ce qui est réalisé, avec des notes permettant de garder la mémoire des réflexions associées.

Chaque entrée est datée et associée aux acteurs concernés.
Il consigne le temps de travail associé aux réalisations.
Il contient des références vers les livrables (documents publics, CR de réunion...).

Attention :

Le journal doit être rendu chaque semaine.

Attention : On ne raconte pas sa vie, on parle des livrables, on donne à voir

Chaque tâche doit produire des choses à voir et à lire ; chaque compte-rendu d'itération consiste à parler de livrables.

Exemple :

Conseil : Faciliter la tâche de la MOA

Le journal consigne la liste des livrables à consulter pour l'itération concernée (on est aussi précis que possible afin de faire gagner du temps à la MOA ; par exemple si on a créé une nouvelle page web on en donne l'URL directe, si on a modifié une page existante on précise à quel endroit).
Le journal intègre la fiche de temps consolidée depuis le début du projet (par exemple sous forme d'un lien vers un autre document en ligne)
Le journal peut intégrer une logique d'auto-évaluation.

Méthode : Auto-évaluation

Exemple de journal de bord avec auto-évaluation (deux itérations complétées)

Complément : Outils

Fiche de temps

Définition : Fiche de temps (FDT)

La fiche de temps consigne pour chaque personne et chaque tâche le temps de travail passé. Elle sert notamment à évaluer le coût des réalisations et à détecter des dérives.

C'est un enregistrement a posteriori du temps passé.

Conseil : Outils

Gestion directe dans le JDB (temps consommé par personne pendant l'itération et temps cumulé)
Lien vers un tableur en ligne

Exemple :

Auto-évaluation

Définition : Auto-évaluation

Il peut être intéressant de mettre en place une mécanique d'auto-évaluation permettant au réalisateur d'assortir sa livraison de son propre avis sur sa réussite.

Cela facilite l'échange avec la MOA (en mettant en évidence ce qui a été mal finalisé).

Conseil : Outils

Annotation dans le JDB
Exemple d'échelle d'auto-évaluation :
- 0 (non livré)
- 1 (ne correspond pas aux attentes, ne peut pas être publié en l'état)
- 2 (correspond aux attentes avec défauts, peut être publié)
- 3 (correspond aux attentes sans défaut notable, peut être publié)

User stories (petites histoires)

Définition : User stories (petites histoires)

Il s'agit de raconter en petites histoires d'une dizaine de lignes environ, les principaux scénarios d'utilisation illustrant l'usage du système visé.

Ces histoires permettent d'avoir un fil conducteur mental pour visualiser les fonctions pertinentes. Elles doivent être rédigées (correctement !) et ne pas se réduire à un simple schéma ou des listes à puce. C'est le fait d'écrire qui permet de penser au scénario dans son déroulement temporel, de penser la cohérence des actions et processus dans leur agencement et succession.

Exemple : Transcription d'une vidéo

Valérie est en charge de la transcription et de la synchronisation de la collection des 8 entretiens de metteurs en scène. Cette opération préalable à la mise en ligne d'un entretien est longue et fastidieuse. Elle compte ainsi profiter des nouveaux outils pour accélérer cette étape de traitement. Elle est averti de la mise à disposition de l'entretien de Roger Planchon pour l'étape de transcription/synchronisation. Elle consulte alors le document et peut commencer à taper au kilomètre le texte brut. Valérie peut ajouter quelques éléments de typage (important) dans le corps de son texte. A chaque frappe, le player vidéo se met en pause et reprend, une fois la frappe terminée, quelques secondes auparavant. Cette méthode de saisie est très appréciée par Valérie qui peut ainsi écouter un fragment puis taper le texte sans avoir à mettre constamment en play/pause le curseur vidéo, ni à revenir avec la barre de navigation.
(par Ludovic Gaillard, INA, projet C2M, http://www.utc.fr/ics/c2m)

Outils collaboratifs

Conseil : Outils de discussion

La communication par mail est mal adaptée au travail collaboratif et aux échanges de groupe.

On utilisera des outils de chat structurés comme Mattermost (libre) ou Slack (propriétaire).

Conseil : Outils de partage de code

Afin de faciliter le partage du code informatique (voire d'autres type de fichiers textes), on utilisera le gestionnaire de version git et un système collaboratif associé comme Gitlab (libre) ou Github (propriétaire).

Outils réflexifs

Rappel :

À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.
https://agilemanifesto.org/iso/fr/principles.html

Définition : Amélioration continue

Posture critique réflexive d'une équipe agile lui permettant d'objectiver sa façon d'agir en vue de s'améliorer.

Méthode : Rétrospective

Méthode d'amélioration continue consistant à se réunir régulièrement, par exemple à la fin de chaque boîte de temps, pour déterminer :

ce qui s'est bien passé,
ce qui s'est moins bien ou mal passé,
comment l'équipe peut s'améliorer.

Exemple :

Animer vos retrospectives avec le conseil

Introduction aux méthodes agiles (en bref)

Objectifs

Introduction aux méthodes agiles

Les méthodes agiles : de la planification au pilotage

Fondamental : De la planification au pilotage

Définition : Méthode agile

Fondamental : Manifeste pour le développement logiciel agile (2001)

Exemple : Exemple de méthodes agiles

Caractéristiques des organisations agiles

Travail en équipe souple

Moins de specs, moins de proto

Remarque : La méthode de Monsieur Jourdain, comme souvent...

Avantages des méthodes agiles

Fondamental : Adéquation au besoin

Fondamental : Visibilité et cumulativité

La question des budgets et des délais

Fondamental : Hyperstatisme et degrés de liberté

Intermédiaire forfait/régie

Exemple :

Projets agiles = risque de dérive ?

Fondamental :

Exemple : Contre-exemple (officieux !)

Exemple d'outils agiles

Timeboxing (boîtes de temps)

Définition : Timeboxing (gestion par boîtes de temps)

Exemple :

Définition : Sprint (boîte de temps)

Attention :

Fondamental :

Exemple : Boîtes de temps d'une semaine

Conseil :

Product backlog

Définition : Product backlog

Méthode :

Exemple :

Conseil : Kanban

Exemple : Exemple de colonnes

Journal de bord (JDB)

Définition : Journal de bord (JDB)

Attention :

Attention : On ne raconte pas sa vie, on parle des livrables, on donne à voir

Exemple :

Conseil : Faciliter la tâche de la MOA

Méthode : Auto-évaluation

Complément : Outils

Fiche de temps

Définition : Fiche de temps (FDT)

Conseil : Outils

Exemple :

Auto-évaluation

Définition : Auto-évaluation

Conseil : Outils

User stories (petites histoires)

Définition : User stories (petites histoires)

Exemple : Transcription d'une vidéo

Outils collaboratifs

Conseil : Outils de discussion

Conseil : Outils de partage de code

Outils réflexifs

Rappel :

Définition : Amélioration continue

Méthode : Rétrospective

Exemple :

Messager, 2009

MOE

MOA

Product backlog

Définition : Product backlog

Méthode :

Exemple :

Conseil : Kanban

Exemple : Exemple de colonnes