Introduction aux méthodes agiles
V. Deslandres © IUT Univ. LYON1 Licence pro DEVOPS
Librement adapté du support de Guillaume Collic, Univ. de CAEN 1
Objectifs du cours
Et vous, quelle expérience avez-vous de l’agile ?
• Prendre connaissance des principes de l’agilité
• Découvrir les méthodes agiles
o Scrum, Kanban et XP
o Point de vue Développeurs (ici) et peu Gestion de Projet
o Les mettre en œuvre sur des ateliers
• Comprendre leurs limites
• Positionner la modélisation dans le développement agile
Plan de ce cours
• Introduction : c’est quoi être agile ?
• Approches déterministes
– Les méthodes « classiques »
• Exercice : planifier un trajet
• Approches empiriques
– Les méthodes agiles
• Un atelier
• Debrief / Questions
3
ÊTRE AGILE ?
Préambule
C’est quoi être Agile ?
• Énormément de réponses possibles, suivant l’angle et le prisme choisi, la plupart complémentaires
Agilité
Faire les choses efficacement
(productivité)
Bien être et valeurs
(prévention de risques psycho-sociaux au travail)
Faire les bonnes choses
(satisfaction client)
……
……
5
Pour beaucoup d’agilistes
• Évoluer vers une organisation
– plus organique (vivante, centrée sur l’homme)
– en petites structures auto- organisées
– apprenantes
– respectueuses de leur
écosystème (gagnant-gagnant)
6
Conséquences
– De meilleurs résultats (prouvé) – Un regain de sens dans le travail
• (souhait générationnel)
Source : VersionOne, 2017
Et ça demande…
• Une ouverture d’esprit
• Du courage
– Remettre en question nos modes de pensées – Réapprendre l’entreprise
• Considérer toutes les parties prenantes
• Un lâcher prise
– Management
• Mieux atteindre le « quoi » en contrôlant moins le « comment »
– Des acteurs plus responsables
• Sachant que « grands pouvoirs » implique « grandes responsabilités »
• Reconnaissance du métier de codeur
7
Mais avant d’en arriver là…
8
• (avant les considérations managériales…)
• On commence par mettre un pied dans des choses plus terre-à-terre
– Réduire les problèmes techniques
• Intégration continue
• Tests unitaires, TDD, …
– Améliorer la visibilité et la priorisation (pilotage)
• Management visuel
• Incréments
– Etc.
– Pour ça : quel cadre ?
Intégration continue
• Maintenir un dépôt unique de code source versionné
• Automatiser les compilations
• Rendre les compilations auto-testantes
• Tout le monde commit tous les jours
• Tout commit doit compiler le tronc (trunk) sur une machine d'intégration
• Maintenir un cycle de compilation court
• Tester dans un environnement de production cloné
• Rendre disponible facilement le dernier exécutable
• Tout le monde doit pouvoir voir les évolutions du code
• Automatiser le déploiement
9
APPROCHES DÉTERMINISTES
La voie classique du développement logiciel
Historique
• Le « Génie Logiciel » est né lors de la réunion de l’OTAN (portée militaire surtout)
• Garmisch, Allemagne, 1968-1969
• Objectifs : optimiser, formaliser, planifier
• Simple à mettre en œuvre
• Utiliser des approches de Gestion Projet connues et enseignées partout
• « Contrat » avec le Client
– Tout est prévu précisément à l’avance
• Qui / Quoi / Quand
11
Modèle en cascade (Waterfall)
http://www.commentcamarche.net/contents/genie-logiciel/cycle-de-vie.php3 12
Critique : aspect séquentiel
Cycle en V
http://www.commentcamarche.net/contents/genie-logiciel/cycle-de-vie.php3
Phase de Recette Exigences
13
Comparer fonctions / exigences
Tests d’intégration
Effet « Tunnel »
• Coté client : X mois sans visibilité, « Nuit polaire »
• Importance des documents écrits
– Servent de référence ultime pour
• Le besoin
• La solution
• La validation
http://www.projectcartoon.com 14
spécifications
livraison
Marge de manœuvre : 4 axes
• Périmètre
– Fixe
15
• Délais
– Fixe
• Coûts
– Fixe
• Qualité
– ?
Coût des anomalies
http://www.agitar.com/solutions/why_unit_testing.html
L’approche scientifique pour obtenir ces chiffres
n’est pas garantie
16
Défauts introduits
Défauts identifiés
Coût de réparation du défaut
ON TESTE ?
Plans, carte, planification
Exercice
• Planifier dans les détails un trajet « Lyon - Briançon" en voiture en évitant l’autoroute
• Départ : samedi 8 février 2020 à 10h
• Pour cet itinéraire, spécifier :
– Chaque ville et village traversé, – L'heure de passage associée,
– Les rues à emprunter dans les agglomérations, – Le carburant qui sera consommé,
– Le nb de kilomètres parcourus entre chaque étape
9/02 : début vacances Hiver
18
10’
GO !
Après 5’…
• Observons les résultats :
• Sur une échelle de 1 à 10, quelle valeur accordez-vous à ce que vous avez obtenu ? Est-ce proche de la réalité ?
– Quels seraient les imprévus possibles ?
• Votre planification et vos spécifications vont être très vite obsolètes.
• Si je vous avais laissé poursuivre, combien de temps auriez-vous passé à réaliser ce travail… n’est-ce pas un peu inutile ?
• Frustration de ne pas pouvoir appliquer le plan à la lettre, d’avoir fait un travail « pour rien »
19
Une autre idée sur la façon de procéder ?
20
! Quel était au fond l’objectif de la demande, dans cet exercice ?
Planifier et prédire au mieux le trajet,
contrôler l’imprévu
Une autre idée sur la façon de procéder ?
" Reconsidérer le besoin
Un objectif intéressant ne serait-il pas plutôt de planifier l’heure d’arrivée en ayant un trajet agréable ?
– En optimisant le trajet selon les critères variables (le plus court, sécurisé, agréable avec de beaux paysages et des aires de repos sympas, etc.)
21
Autre solution : approche empirique
• Se fixer un 1er objectif à court terme : une grande ville par exemple
• Se lancer sur la route sans tarder
• Une fois ce 1er objectif atteint, on marque une courte pause et on adapte son itinéraire en fonction de la situation du moment
– Bouchon, humeurs du moment, etc.
• Ainsi de suite jusqu'à atteindre la destination finale
• A l’arrivée : satisfaction d’avoir maîtrisé son trajet, et non pas d’avoir suivi un plan figé
22
Parallèle avec le dév. logiciel
• Le client élabore sa vision du produit à réaliser et liste les fonctionnalités ou exigences de ce dernier, avec ses
priorités
• Il explique cette liste à l'équipe de développement, et communique directement avec elle (plutôt que par
documents)
• L’équipe avance dans la réalisation, montre des briques de réalisation au client
• Le client ajuste ses demandes
• L’équipe ajuste son travail en fonction de ses compétences et
des imprévus 23
Atelier Naufrage
24
Autre exercice
• Vous êtes sur un bateau dans l’océan Pacifique, à 1800 km de toute côte. Le feu est déclaré à bord. D’ici 1h, le bateau aura coulé. Il y a des barques de sauvetage à rames en nbre juste suffisant pour sauver tout le monde.
• Peut-être pourrait-on emmener quelques objets à bord ? L’équipage rapporte une liste d’objets susceptibles d’être emporté, il y en a 15.
• Il faut en choisir 5. Comment procédez-vous ?
25
15 objets possibles
1. Sextant + tables de calcul 2. Miroir pour se raser
3. Bidon de 15l. d’eau 4. Moustiquaire
5. Paquet de ration de survie de l’armée
6. Carte du Pacifique 7. Coussin flottant
8. Bidon 10l. mélange essence gazoil
9. Petite radio réceptrice 10. Produit anti-requin
11. 3 m2 de toile plastique 12. Bouteille rhum
13. 5 m. corde nylon
14. 2 boites tablettes choc.
15. Équipement de pêche
26
Si on ne devait emporter qu’un seul objet : le quel choisir ? Si on peut en prendre un 2e ? Etc.
LA SOLUTION ?
• Proposée par les spécialistes de la Marine
• Il faut identifier les objectifs poursuivis et les hiérarchiser en groupe
• 5 objectifs sont identifiés par la Marine :
– Soutenir le moral des naufragés – Survivre
– Se diriger vers la côte – Se faire repérer
– Repêcher et soigner ceux qui tombent à l’eau
• Comment les hiérarchiser ? 27
LA SOLUTION
• Proposée par les spécialistes de la Marine
• Il faut identifier les objectifs poursuivis et les hiérarchiser en groupe
• 5 objectifs hiérarchisés sont identifiés par la Marine :
– Se faire repérer – Survivre
– Repêcher et soigner ceux qui tombent à l’eau – Soutenir le moral des naufragés
– Se diriger vers la côte
28
Liste des priorités
29
1. Miroir pour se raser
2. Bidon 10l. mélange essence gazoil
3. Bidon de 15l. d’eau
4. Paquet de ration de survie de l’armée (nourriture concentrée) 5. 2 boites tablettes choc.
6. 3 m2 de toile plastique (recueillir eau pluie : suppose qu’il pleuve)
7. Équipement de pêche (suppose qu’il y ait du poisson)
8. 5 m. corde nylon (lancer à celui qui est tombé)
9. Coussin flottant (bouée sauvetage) 10. Produit anti-requin
11. Bouteille rhum (soigner blessures)
12. Petite radio réceptrice
13. Moustiquaire (protection insectes) 14. Carte du Pacifique
15. Sextant + tables de calcul (se diriger)
Se faire repérer
Survivre
Repêcher et soigner ceux qui tombent à l’eau
Soutenir le moral des naufragés
Se diriger vers la côte
Parallèle avec le développement Logiciel
• Revenir aux objectifs fondamentaux du Client
• Les hiérarchiser
• Démarrer le développement sur les objectifs prioritaires
• Problème : le Client ne sait pas toujours quels sont les objectifs prioritaires
– Un travail est nécessaire, mené avec l’analyste
• L’analyste n’est pas du domaine et ne peut pas identifier les besoins prioritaires
– Même si pour nous, le bon sens voudrait que…
– La preuve avec cet exercice : seule la connaissance Métier compte
30
MÉTHODES AGILES
Approches empiriques
http://agileconsulting.blogspot.com
Développement de produit
• 2 types de projet
– En masse, répétitif, prédictible
• Voiture, meuble, lampe, etc.
– Nouveau, inconnu, non prédictible
• artisanat, art, logiciel
• Nouveau Produit
– Apprentissage par l’expérimentation – Amélioration continue
– Tolérant au changement
– Repousser les décisions irréversibles
• Garder un maximum d’options
32
Génie Logiciel : le constat
• Années 2000, un postulat : les méthodes de GL ne sont pas satisfaisantes
• Les spécifications ne sont pas complètement comprises tant que le projet n’est pas commencé
• Les utilisateurs ne savent ce qu’ils veulent qu’après avoir vu une première version de l’application
• Agile : origine en 2001, réunion Snowbird, 17 consultants au ski (UTAH) discutent de la production de logiciels
! Rédigent le « Manifeste Agile »
33
Manifeste Agile : les 4 valeurs de l’Agilité
“Nous reconnaissons que les éléments à droite ont de la valeur, mais nous privilégions ceux à gauche”
Processus et outils
Individus et interactions
Documentation exhaustive
Un produit opérationnel
Négociation du contrat
Collaboration avec le client
Suivi d'un plan
Adaptation au changement
34
Caractéristiques des méthodes agiles
• Méthodes réactives et incrémentales d’organisation du travail
• Focalisées sur le produit et la satisfaction client
• Construit en adéquation avec les capacités et limites humaines
35
Marge de manœuvre : 4 axes
• Qualité : fixe
– La dette technique doit être évitée
– DEF dette technique : tout ce qu’on repousse à plus tard
• « Pas de souci, j’utiliserai ce composant que je connais bien »,
• « Ça sera vite fait, promis »
• « Je ferai ça après quand j’aurai le temps »
• Priorisation suivant les 3 autres axes :
Périmètre
Délai Coût
36
Comparatif
37
L’agilité en 2 slides (1/2)
À 50% du temps total, le client ne voit statistiquement que 10% de son application
Expression des besoins Conception
Développement
Tests, recette & debugging
En développement classique
38
L’agilité en 2 slides (2/2)
Expression de besoins Conception
Développement
Tests, recette & debuggage
À chaque itération, le produit est 100% fonctionnel
i1 i2 i3 i4 i5 in
Backlog, user stories Simplicité, refactoring
TDD, acceptance Demos, reviews
En développement agile
39
À la moitié, le client voit 80%
des fonctionnalités principales de son application
Les facteurs de succès
• Le client / l’utilisateur est impliqué quotidiennement (ou son représentant, le Product Owner)
• Le management intermédiaire soutient l’équipe
• L’équipe est auto-organisée
• Les pratiques sont adaptées au mode incrémental :
– Automatisation des tests : rejoués souvent – Code compréhensible car souvent modifié – Pas de code d’auteur, code collectif
• Soutien de la hiérarchie
40
Taux de réussite
11%
29%
60%
Approche Traditionnelle
Succès Echec Mitigé
39%
9%
52%
Approche Agile
Succès Echec Mitigé Source : the Standish Group, « Chaos Report 2015 »
3x plus de projets réussis 3x moins d’échecs
41
Je retiens…
Bénéfices des méthodes agiles
42
Source : VersionOne, rapport annuel 2017 (1492 réponses, 55% USA, 27% EU)
Satisfaction dans le travail
• 15 mois après l’adoption de Scrum, 86% des employés de
Salesforce.com avaient de bons ou de très bons moments au travail
– (seulement 40% le disaient avant d’adopter Scrum)
• 92% recommanderaient l’agilité à d’autres
• Une raison possible :
– 2/3 d’heures sup. en moins selon une étude de recherche de l’Université de Calgary
Source : Mike Cohn, 2009, www.mountaingoatsoftware.com Traduction, Adaptation : Claude Aubry
43
Agile vs. classique
Les profils des projets
44
Répartition des méthodes (sondage 2017)
http://www.versionone.com/state_of_agile_development_survey 45
Une maturité acquise
• Les outils associés sont maintenant disponibles sur le marché
– y compris en Open Source
• Les formations, certifications, conférences, livres, blogs se sont multipliés
• Prise de position en faveur de l'approche Agile de la part des organismes faisant "autorité" en matière de gestion de projet informatique
– En 2012, le Gartner invite à abandonner le Cycle en V
46
Attention : 3 idées reçues !
• Mauvaise interprétation du 4ème principe (« Préférer l’adaptation au changement plutôt que suivre un plan »)
– C’est une erreur de conclure que « Sur un projet agile, il n'y a pas de
spécifications, pas de plan, ni de processus, pas d'outil et même pas de contrat »
• « Sur un projet agile, le client change d'avis tout le temps et on tourne en rond à faire et défaire des choses… »
– Personne n’a intérêt à procéder de cette manière
• « Un projet Agile ne fonctionne que sur des projets de développement web, qu'avec une dizaine de personnes maximum, qu'avec des super dév »
– Scale Agile : coordonner n équipes de 7 personnes, géographiquement éloignées
– Concerne tout type de projet 47
UML en Agile ?
Conception Agile… pour coder plus vite et mieux
Martin Fowler : ‘UML as a Sketch’
• 2 utilisations d’UML
– avant d’écrire le code pour accélérer le processus (forward-engineering) – Reverse-engineering à partir du code existant pour aider à le comprendre
• Utiliser ces 2 moyens sur des points techniques très limités
– Pas sur tout le code, ni pour la vision globale du projet
– Pour préciser un aspect, une façon de concevoir un point précis
– Moins de 10’, travail collaboratif, tableau blanc : informel et dynamique (pas d’AGL, no CASE tool)
http://martinfowler.com/bliki/UmlAsSketch.html
49
• Utiliser UML pour
– Expliquer aux autres membres de l’équipe comment vous voyez qu’une User Story fonctionne
• Ne pas passer trop de temps sur les diagrammes
– On n’a pas besoin de trop de détails
• Utiliser le moyen qui parle le plus pour discuter et choisir sa conception
– Diagramme UML en dessin libre sur tableau blanc
– Ce qui compte en Agile, c’est le code
UML & Scrum
50
• Les diagrammes UML les plus utiles :
– Diagramme des Cas d’Utilisation
• Pour se mettre d’accord sur les points d’entrée
• Sur types d’utilisateur à considérer (rôles)
– Parfois Diagramme d’activités
• Pour fixer le déroulement d’un Cas d’Utilisation (vision Utilisateur)
– Parfois Diagramme de Séquences
• Mettre au clair un aspect technique (objets)
– Diagramme de Classes
• Pour la BD, vérifier qu’on a pensé à tout
• Rétro engineering : comprendre un code, avoir une vue d’ensemble
UML & Scrum
51
Je retiens…
• La faiblesse des méthodes classiques est:
– leur manque de réactivité et
– leur mauvaise gestion de l’incertitude
• Les méthodes agiles ont été développées afin de répondre à ces problématiques. En effet, elles permettent de
– travailler en cycles courts
– d’intégrer des feedbacks réguliers des utilisateurs
• Cela permet d’adapter les priorités des fonctionnalités à développer entre chaque itération.
• Grâce aux feedbacks, l’équipe peut lever les incertitudes rencontrées et modifier rapidement ce qui ne convient pas
https://www.captainspoc.com/le-coin-des-experts/agilite-benefices-effet-mode/ 52
Ateliers : Je retiens…
• Atelier Carte :
– Les sur-spécifications ne donnent généralement pas de bons logiciels;
revenir à l’objectif recherché.
• Atelier Naufrage :
– Identifier les objectifs et les prioriser permet de mieux cibler le besoin.
53
54
Atelier Agile
55
