L'approche agile

Réflexions sur le périmètre de la gestion de projets

Développement d'un produit

• Distinction entre idée et développement.
• Le client n'est pas toujours distinct du fournisseur.

Un bon produit du point de vue du client

• peu coûteux
• respecte des critères de qualité
• livré dans les délais
• fait ce qu'on lui demande de faire

Un bon produit du point de vue du fournisseur

• minimise les coûts
• minimise les délais
• maximise les profits
• fait ce qu'on attend de lui

Que faut-il pour le développement ?

• une équipe développeurs, chefs de projets, testeurs, etc.
• de la communication
• un procédé
• des outils

Au sujet de l'évaluation

• critères : délais, coût, qualité
• problématique du point de vue
• de nombreuses difficultés : gestion des équipes, évolution des besoins et de l'environnement, difficultés de communication, ...

importance de la formalisation

Introduction

Produire quelque chose

Oui, mais comment ?

Time to market

• Temps que met une idée pour se transformer en fonctionnalité utilisée
• Notion de Temps de conception d’un produit minimum viable
• Associé à la fréquence de livraison, à la fonctionnalité minimum commercialisable

Release early, release often

• diffusions précoces et fréquentes
• boucle de rétroaction rapide entre développeurs et testeurs/utilisateurs

La Cathédrale et le Bazar, Eric S. Raymond, 1997

Quelques remarques sur l'agile

• Simple à comprendre, difficile à maîtriser
• Nécessite un engagement de tous les participants
• Formalisation de pratiques parfois familières

Chronologie

• Années 40 : cycle de production itératif et incrémental — W. Edwards Deming
• Années 80 : modèle en spirale incrémental — Barry Boehm
• Années 90 : Développement Rapide d'Applications (RAD) — James Martin
• 1991 : première mise en œuvre de Scrum
• 2001 : réunion de 17 experts du développement logiciel qui émerge sur le Manifeste Agile

Méthodes agiles

• Rapid Application Development (RAD, 1991)
• Intégration continue (1991)
• Dynamic systems development method (DSDM, 1995, consortium anglais commercialisant le RAD)
• Scrum (1996)
• Extreme programming (XP, 1999)
• Adaptive software development (ASD, 2000)
• Développement basé sur les fonctionnalités (FDD pour Feature Driven Development, 2003)
• Behavior-driven development (BDD, 2003)
• Crystal clear (2004)

Valeurs

Les 4 valeurs du manifeste agile

Nous découvrons de meilleures approches pour faire du développement logiciel, en en faisant nous-même et en aidant les autres à en faire. Grâce à ce travail nous en sommes arrivés à préférer et favoriser :

• Les individus et leurs interactions plus que les processus et les outils.
• Un logiciel qui fonctionne 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.

Cela signifie que bien qu'il y ait de la valeur dans les items situés à droite, notre préférence se porte sur les items qui se trouvent sur la gauche.

Les 12 principes du manifeste agile (1)

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

Les 12 principes du manifeste agile (2)

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.

Les 12 principes du manifeste agile (3)

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 12 principes du manifeste agile (4)

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

Les 12 principes du manifeste agile (5)

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

Les 12 principes du manifeste agile (6)

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.

Les 12 principes du manifeste agile (7)

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

Les 12 principes du manifeste agile (8)

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.

Les 12 principes du manifeste agile (9)

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

Les 12 principes du manifeste agile (10)

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

Les 12 principes du manifeste agile (11)

Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées.

Les 12 principes du manifeste agile (12)

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

Quelques outils d'organisation du temps

Timeboxing

• Fixer une durée, puis planifier les tâches
• Implique la flexibilité des livrables
• Permet une meilleure gestion du temps (bien-être des individus)

Getting Things Done

• Méthode de gestion des tâches
• Critères décisionnels : contexte, temps disponible, énergie physique et mentale, priorité
• Objectifs
  • choisir en pleine connaissance de cause ce que l'on fait
  • ne porter son attention que sur ce qui est actionnable maintenant
  • on est tranquille sur ce que l'on ne fait pas

Quelques outils pour la programmation

Programmation en binôme

Fonctionnement

• Un conducteur qui rédige le code, un observateur qui assiste
• Les rôles s'échangent régulièrement

Motivations

• Transfert de connaissances
• Amélioration des compétences communicationnelles
• Amélioration du plaisir au travail

Réusinage de code

Objectifs 

• Améliorer la lisibilité
• Faciliter la maintenance
• Rendre le code source plus générique

Outils

Modification de la présentation, de l'algorithmique, de procédures, de la conception

Activités

Suppression de code mort, ajout d'assertions, renommage, commentaires

Intégration continue

Vérifier à chaque modification qu'il n'y ait pas de régression

• Code source partagé (systèmes de gestion de version)
• Les développeurs intègrent quotidiennement leurs modifications
• Tests d'indégrations développés pour valider l'application

Nécessite de bonnes pratiques : tout commit compile, etc.

Premières méthodes

RAD, une méthode historique

le focus, démonstration du prototype aux utilisateurs

Kanban, un outil à s'approprier

Système visuel de gestion des processus qui indique, quoi produire, quand le produire et en quelle quantité

• Visualiser le workflow
• Limiter le nombre de tâches
• Adapter l'outil à ses besoins

Scrum

Scrum c'est...

Un cadre de travail plutôt qu'un processus ou une technique. On peut y employer ses propres processus et techniques

Fondé sur la théorie du contrôle de processus empirique

Trois piliers de Scrum

• Transparence — partage d'une compréhension commune de ce qui est observé
• Inspection — inspecter fréquemment les artefacts Scrum et l'avancement
• Adaptation — adaptation dès que possible du matériel ou du processus pour minimiser les risques de dérive

Réunions prescrites par Scrum

• Planification du sprint — Sprint Planning
• Mêlée quotidienne — Daily Scrum
• Revue de Sprint — Daily Scrum
• Rétrospective de Sprint — Sprint Retrospective

Rôles prescrits par Scrum

L'équipe Scrum comprend :

• Propriétaire du produit — Product Owner
• Équipe de développement — Development Team
• Maître de mêlée — Scrum Master

Un schéma rapide

Le propriétaire du produit

Il est responsable de maximiser la valeur du produit et du travail de l'équipe de développement

• C'est une personne (non un comité)
• Responsable du Backlog Produit

L'équipe de développement

• Auto-organisée
• Pluridisciplinaire — toutes compétences nécessaires
• Pas de titre aux membres de l'équipe

Nombre de membres : de l'ordre de 3 à 9

Le maître de mêlée

Garant de la compréhension et mise en œuvre de Scrum, c'est un leader-serviteur de l'équipe Scrum, un facilitateur.

• Au service du Product Owner : outils pour la gestion du backlog, pour le bon fonctionnement agile
• Au service de l'équipe de développement : coacher l'équipe en terme d'auto-organisation, supprimer les obstacles, faciliter les événements scrum
• Au service de l'organisation : aider à comprendre et adopter Scrum, au sein de l'organisation

Les artefacts de Scrum

Représentent un travail ou une valeur pour assurer la transparence et les possibilités d'inspection et d'adaptation.

• Backlog du sprint : liste ordonnée de tout ce qui pourrait être nécessaire dans un produit
• Backlog produit : ensemble d'items sélectionnés pour le sprint

Le sprint

Cœur de Scrum

• Durée fixée
• Création d'un incrément produit fonctionnel
• Constitué de : planification de print, mêlées quotidiennes, activités de développement, revue de sprint, rétrospective de sprint

Pendant le sprint

• L'objectif du sprint est fixe
• Les objectifs de qualité sont maintenus
• Le périmètre peut être renégocié entre le Product Owner et l'équipe de développement

Planification du sprint

Réunion pendant laquelle on décide du travail à effectué

Répond aux questions :

• Que peut-on livrer comme incrément du sprint à venir ? nécessite le backlog produit, le dernier incrément produit, la capacité projectée, les performances pacées
• Comment le travail choisi sera réalisé ? constitution du backlog du sprint par décomposition des tâches à court terme

Définition d'un objectif de sprint

La mêlée quotidienne

Destinée à l'équipe de développement pour synchroniser ses activités — timeboxing de 15mn

• Qu'est-ce que j'ai fait hier qui a aidé à atteindre l'objectif ?
• Que ferai-je aujourd'hui pour aider à atteindre l'objectif ?
• Est-ce que je vois un obstacle qui empêche de respecter l'objectif ?

Inspection de la progression vers le sprint

La revue de sprint

À la fin du sprint, pour inspecter l'incrément ; réunion unformelle — timeboxing suivant la durée du sprint

Participants : équipe Scrum et possibles invités

• Le Product Owner indique les items du Backlog produit finis
• L'équipe de développement discute du déroulement du sprint
• L'équipe de développement démontre le travail fini
• Le Product Owner discute du Backlog produit tel qu'il est
• Le groupe convient de ce qu'il faut faire pour la suite
• Revue des délais, budgets, fonctionnalités potentielles, conditions du marché

Production d'un backlog produit révisé

La rétrospective de sprint

S'inspecter et proposer un plan d'amélioration pour le prochain sprint

• Inspecter le dernier sprint (personnes, relations, processus, outils)
• Identifier les principaux éléments qui ont bien fonctionné, les améliorations potentielles
• Créer un plan pour mettre en œuvre les améliorations

Le backlog produit

Liste ordonnée de tout ce qui pourrait être nécessaire dans un produit

• Unique source d'exigence
• N'est jamais complet, évolue au fil des évolutions du produit et des besoins
• Liste de fonctionnalités, fonctions, exigences, améliorations, corrections
• Ne contient pas uniquement des User Stories
• Raffiné par le Product Owner et l'équipe de développement
• Premiers items généralement plus détaillés que les suivants
• L'équipe de développement est responsable des estimations de la quantité de travail associée

Le backlog du sprint

Items sélectionnés pour le sprint

• Détaillé pour que l'évolution soit compréhensible pendant la mêlée quotidienne
• Modifié tout au long du sprint
• Suivi de la progression grâce à la somme de travail restant

L'incrément

Éléments du Backlog produit finis pendant le sprint

Pour récapituler

Un court exemple

Extrait du Guide Léger de la Théorie et de la Pratique de Scrum

Représentation pratique

Outils logiciels : Taiga, Tuleap, Trello...

Extreme Programming (XP)

Le cycle de l'XP

• Phase d'exploration pour sélection des Scénarios utilisateurs
• L'équipe transforme les scénarios en tâches à réaliser et tests fonctionnels
• Chaque développeur s'attribue des tâches et les réalise avec un binôme
• Produit livré quand les tests fonctionnels passent

Différences entre XP et Scrum

• Itérations généralement plus courtes avec XP
• Plus grande flexibilité d'ajustement du backlog de sprint dans XP
• La priorité des tâches est imposée par le Product owner dans XP
• XP prescrit des pratiques d'ingénierie

Valeurs

• Communication, travail en binôme, rôle du coach
• Simplicité, anticiper les extensions futures est inutile
• Feedback au programmeur et client (tests)
• Courage face aux changements
• Respect des autres, de soi

Outils

• Conception simple
• Importance centrale des tests (unitaires, fonctionnels)
• Conventions de nommage
• Appropriation collective du code
• Refactoring

Outils complémentaires

Planning poker

Suite de Fibonacci : 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144

• Les participants s'installent autour d'une table, placés de façon que tout le monde puisse se voir.
• Le responsable de produit explique à l'équipe un scénario utilisateur (user story).
• Les participants posent des questions au responsable de produit, discutent du périmètre du scénario, évoquent les conditions de satisfaction qui permettront de le considérer comme "terminé".
• Chacun des participants évalue la complexité de ce scénario, choisit la carte qui correspond à son estimation et la dépose, face vers le bas, sur la table devant lui.
• Au signal du facilitateur, les cartes sont retournées en même temps.
• S'il n'y a pas unanimité, la discussion reprend.
• On répète le processus d'estimation jusqu'à l'obtention de l'unanimité.

Graphique d'avancement

Remarque : pas forcément décroissant

La philosophie Lean

Lean en quelques mots

Inspiré de méthodes de gestions japonaises, recherche de la performance par l'amélioration continue et l'élimination des gaspillages, afin d'améliorer la valeur globale pour le client.

Livrer plutôt que produire

Comprendre ce qui plaît au client pour spécifier la valeur du service ou du produit

Production sans stock

Augmenter le niveau de Juste à temps, c'est-à-dire réduire le délai entre la commande client et la livraison du produit ou de l'offre

Aller jusqu'au fonctionnement en flux tiré

Rechercher la cause première

S'arrêter à chaque défaut et résoudre le problème plutôt que de le contourner

Amélioration quotidienne

Impliquer les opérateurs dans l'amélioration et la reconception de leurs environnements de travail

Trois outils lean

7 alternatives

Outil d'exploration des voies d'amélioration

5 pourquoi

Outil de recherche de la cause première

5 M

Matière, matériel, méthode, main d'œuvre, milieu : thèmes de la recherche des causes

Pour continuer

Bibliographie

Sur la méthode Scrum

• Le Guide de Scrum, Ken Schwaber et Jeff Sutherland, 2016
• Guide Léger de la Théorie et de la Pratique de Scrum, Pette Deemer, Gabrielle Benefield, Craig Larman, Bas Vodde, 2012
• Scrum et XP depuis les tranchées, Henrik Kniberg

Sur le lean

• Le plus petit pas, Nicolas Gouy, 2015

Prochaine séance

TD : initiation à git