Les méthodes agiles UM2 2011-2012 1
2 Sommaire Introduction L origine des Méthodes Agiles Le déroulement d un projet Scrum Au démarrage d une version Au démarrage d une itération/sprint Le déroulement d une itération La fin d une itération Pour aller plus loin : extreme Programming
Les ratages et l informatique Une Histoire de bug 3
Un projet raté, c est un produit 4 qui Ne répond pas aux besoins A été livré trop tard A coûté trop cher N est pas fiable «Il est incroyablement difficile de réaliser dans les délais prévus des logiciels satisfaisant leurs cahiers des charges»
Un constat alarmant au niveau mondial Situation en 2002 5 Résultat des projets Par le Standish Group CHAOS Report (http://www.standishgroup.com) Type 1 : Projet terminé dans les temps, les budgets et avec les fonctionnalités prévues Type 2 : Projet terminé en retard, hors budget ou avec une limitation de fonctionnalité Type 3 : Projets abandonnés
Résultats 2009 : une nette amélioration 6 Projets terminés dans les temps, les budgets et avec les fonctionnalités prévues : 32% Projets terminés en retard, hors budget ou avec une limitation de fonctionnalité : 44% Projets abandonnés ou livrés mais jamais utilisés : 24% 2011-2012 Les méthodes agiles S. Mathon
Causes d échec en informatique selon le Standish Group 7 Manque de clarté ou mauvaise définition des besoins Evolution des spécifications Manque de réactivité Priorités non définies Manque de qualité du logiciel Conception trop ambitieuse Evolutions non prévues Rarement parce que la programmation est mauvaise
«Le chemin est long du projet à la chose» Molière 8
9 L apparition des méthodes agiles
10 Manifeste des méthodes agiles L'équipe Signé par 17 personnalités 4 valeurs L'application La collaboration L'acceptation du changement «Personnes et interaction plutôt que processus et outils» «Logiciel fonctionnel plutôt que documentation complète» «Collaboration avec le client plutôt que négociation de contrat» «Réagir au changement plutôt que suivre un plan» 2011-2012 Les méthodes agiles S. Mathon
Méthodes agiles : les 12 11 principes Satisfaction client Changement bienvenu Livraisons fréquentes Collaboration quotidienne Motivation et encouragements Communication face-à-face Logiciel sert de mesure
12 Les 12 principes (suite) Rythme soutenable Attention continue à la technique et à la conception Simplicité Auto-organisation Ajustements continus
13 Exemples Scrum Extreme programming (XP) Rapid Application Development (RAD) Adaptive software development (ASD) Crystal clear Dynamic software development method (DSDM) Feature driven development
Scrum Le déroulement 14
15 Scrum Les racines de Scrum se retrouvent dans la publication de Takeuchi et Nonaka dans "The New Product Development Game Ken Schwaber et Jeff Sutherland la formalisent en 1996 SCRUM est un framework de méthodologie SCRUM est un framework non prescriptif
16 Les rôles Scrum Master Responsable de faire appliquer par l équipe les valeurs et les pratiques de Scrum Facilite la résolution des problèmes Product Owner C'est le représentant des clients et des utilisateurs C'est lui qui donne les fonctionnalités à traiter, et qui prend les décisions importantes concernant l'orientation du projet Il gère le Backlog de Produit et le Release Plan Team Member Tous les autres
17 Pause : le jeu de la balle Chacun est membre d une équipe Entre chaque participant, la balle doit voler («air-time») Chaque balle doit être touchée par chaque membre de l équipe Vous ne pouvez pas passer la balle à votre voisin ou voisine de gauche ou de droite Chaque cycle de balle doit démarrer et se terminer par la même personne Une balle qui tombe par terre est perdue : elle doit recommencer le cycle Il y aura 5 itérations Les seules règles sont celles écrites ci-dessus
18 Planning Explication des règles 2 min Création des équipes 2 min Organisation de l équipe 1 min Estimation du temps 2 min itération 1 min debriefing de l itération Après les 5 itérations : 10 min de debriefing commun
19 Workflow Agile
20 Définitions Sprint : itération dans Scrum 2 semaines à 1 mois Scrum : mêlée quotidienne Product Backlog : cahier des charges initial User Story : terme extreme Programming, qui définit la manière d exprimer les attentes utilisateur Sprint Backlog : le contenu choisi pour un sprint Scrum daily meeting : réunion quotidienne de l équipe développement
21 Itératif vs Incrémental
22 Les règles fondamentales Les itérations sont courtes : 2 semaines à 1 mois maximum Les itérations ne se chevauchent pas Les itérations ont toujours la même durée La date de fin du sprint n est JAMAIS repoussée Les itérations s enchaînent en général sans délai
Scrum Le démarrage d une version 23
24 Avoir la vision globale Comme pour toute méthode de gestion de projet, comprendre le contexte et les objectifs du projet. Déterminer les utilisateurs du projet Plusieurs approches possibles : Document de Vision Modèle Volere
25 Objectifs du projet Résumer le projet en une phrase Quels sont les avantages «business» pour le client? Définir comment mesurer le succès du projet Le projet est-il réaliste/faisable? Est-ce que toutes les personnes impliquées l approuvent? Quelle est l importance du projet pour le client?
26 Le Product Backlog Ensemble des évolutions prévues pour la version, plus ou moins précises Un Backlog est vivant Parfois modifications quotidiennes Surtout en réunions de sprint Représentation sous forme de liste Importance de la priorité : donne l ordre de réalisation Le Backlog est partagé
27 La User Story Les User Stories sont des «histoires» Avec : un acteur qui effectue une action dans un objectif donné. Une User Story doit pouvoir être développée entièrement pendant une itération. Un Backlog contient également des Stories techniques ou méthodologiques (Ex : tests unitaires)
28 Exemple de Product Backlog ID User Story Comment le démontrer Valeur Estimation Sprint 001 Un <utilisateur> Soit sous forme Importance Effort pour Sprint fait une <action> d un point de implémenter dans un vue la US <objectif> donné utilisateur de scénario, soit liste des exigences incontournables dans lequel la US est prise en compte
Le Plan de Release : pour 29 garder le cap Répartition indicative des User Stories dans les sprints Prise en compte des dates fatidiques Fait par toute l équipe 1- Définir le critère de fin 3-Durée des sprints Backlog 2-Estimer les stories Backlog estimé 5-Planifier la release Plan de release 4-Estimer la capacité de l équipe
Problèmes classiques de 30 Backlog Les problèmes classiques de gestion des exigences : Stories exprimées sous forme de solution Stories exprimées sous forme technique Ambigüité/flou Manques/doublons/incompatibilité Product Backlog trop lourd Stories trop grosses
31 L estimation dans Scrum Estimer la taille/difficulté plutôt que la durée Estimation en points = jours/hommes idéaux Estimer de façon relative, par rapport à une story connue Les estimations sont INDICATIVES Cf Planning Poker http://www.planningpoker.com/detail.html
Exercice : la planification 32 culinaire Librement inspiré du Doggy Planning http://tastycupcakes.org/2009/06/dogg y-planning/ L équipe estime le contenu du Backlog Planning Poker : 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100,?, Pause
33 Backlog Votre Backlog contient les plats suivants : Nouilles au beurre Osso bucco Gâteau au chocolat Pizza au thon Waterzoi Ikita mashitsu Vous estimez le temps pour préparer chacun de ces plats Unité : le Miam 20 min d estimation
Scrum : les sprints Illustration VisualExplainer 34
35 La durée de sprint Durée fixe Consensus entre le besoin de feedback/la motivation vs le coût lié au sprint/la disponibilité du Product Owner Au minimum 4 sprints par version
La réunion de planification de 36 sprint 1- Le Product Owner présente l objectif du sprint et les Stories candidates 1bis La colonne «Comment le démontrer est remplie» 2- L équipe liste les tâches nécessaires (<1 jour) et affine l estimation 3- Accord sur le périmètre du sprint Consensus entre la capacité, la faisabilité et l importance
37 A préparer avant Le Product Backlog existe : Les exigences/user stories sont listées Le Product Owner a mis l importance des stories les plus importantes et sélectionné ses candidates Le Scrum Master a calculé la capacité du sprint (quelle quantité de stories peut être traitée)
38 Conditions Ailleurs que dans le bureau Tableau blanc Fixer la durée maximum à respecter : en général, 2*<durée du sprint (en semaines)> heures Ne pas commencer à résoudre les problèmes techniques, mais faire de la conception Poser les bonnes questions au Product Owner Garder du mou
39 Le tableau blanc
40 Et les tests? Prévoir les tests d acceptation dès la planification du sprint Le scénarios de tests permettent : De comprendre les Stories De préparer la recette de sprint Les tests sont effectués en cours de sprint, pas à la fin
41 Mise en bouche : jeu du ballon Mon cahier des charges : mon ballon
42 Règle du jeu Chaque équipe a 2 minutes pour créer le plus possible de ballons et me les amener Résultats et debriefing 2 ème itération
Scrum : en cours de sprint 43
44 Déroulement du sprint Chaque développeur s approprie des tâches des User Stories de l itération Premières tâches attribuées à la réunion de sprint Ensuite, au cours des réunions quotidiennes Tous les matins, réunion café/standup meeting/scrum meeting pour débloquer les problèmes et mesurer l avancement Au bout de l itération, seules les User Stories complètes sont livrées
45 Le Scrum Daily Meeting Faire le point sur les tâches depuis le dernier Scrum meeting S attribuer de nouvelles tâches Organiser le travail de la journée en cas d obstacle (besoin d expertise, de travailler à 2, problèmes de serveurs )
46 Daily Meeting : les principes Tous les matins Pas plus d 1/4 heure Personne ne dirige la réunion, même si le Scrum Master peut l animer Tout le monde participe Équipe (y compris Scrum Master) Product Owner au moins quelques fois par semaine Utilisation et mise à jour du tableau blanc L équipe peut faire appel à des experts D autres personnes peuvent y assister mais n interviennent pas
47 La notion de «fini» ou «done» Définir dès le départ ce que veut dire «fini» : Les stories : Est-ce que ça inclut la documentation? Est-ce que ça inclut des tests unitaires? Est-ce que ça inclut des tests d intégration/croisés? La version Une story en particulier : chaque story ne nécessite pas le même travail Permet d aborder la notion de «portée»
Scrum : la revue de sprint 48
49 Les principes A lieu le dernier jour du sprint Durée maximum : de 2 à 4 heures Prend en général la forme d une démonstration : Build avec les stories terminées Idéalement faite par le Product Owner ou un membre de l équipe
50 La préparation Tester ou faire tester les stories livrées Préparer un plan de démonstration basé sur les Stories livrées Convier des invités éventuels Installer sur une plateforme de test/démonstration, avec des données significatives
51 Les participants Au minimum, toute l équipe y compris Product Owner et Scrum Master Parfois les autres personnes intéressées Marketing/commercial Support Éventuellement clients ou partenaires
52 Le contenu Le Product Owner émet des demandes de modification et recueille les feedbacks des participants Il mettra ensuite à jour le Product Backlog et le Plan de Release, qui serviront à la planification du sprint suivant Les demandes de changement et les bugs sont priorisés et pas forcément pris en compte dans le sprint suivant
53 La rétrospective Revenir sur le déroulement du sprint pour optimiser l organisation Réunion suite à la réunion de fin de sprint Bilan intermédiaire Qu est-ce qui s est bien passé? Qu est-ce qui s est mal passé? Comment nous améliorer? Idéalement, brainstorming Choisir 1 amélioration pour le sprint à venir
Scrum : résumé des rôles 54
55 Actions du Scrum Master Veiller à ce que les pratiques Scrum soient appliquées Encourager l équipe et le Product Owner et les inciter à devenir autonomes Protéger l équipe des obstacles/interférences en cours de sprint Organiser et animer les réunions «Le Scrum Master est au service de l équipe» 2011 2012 Les méthodes agiles S. Mathon
56 Le Scrum Master idéal Bonne connaissance de Scrum Comprend les aspects techniques Communication Bon guide, fait confiance Médiateur Tenace Transparent Au service de l équipe Sait prendre des risques
57 Questions fréquentes Peut-on se passer de Scrum Master? Le Scrum Master doit-il être le Chef de Projet? Le Scrum Master peut-il venir en plus du Chef de Projet?
58 Actions du Product Owner Participe aux réunions De début de sprint Quotidiennes, parfois De fin de sprint À la rétrospective Est responsable du Backlog de Produit Répond aux questions sur le produit Définit les tests d acceptation Passe ou fait passer ces tests
59 Le Product Owner idéal Bonne connaissance du domaine métier Maîtrise des techniques de définition de produit Capacité à prendre des décisions rapidement Capacité à détailler quand il le faut Ouvert au changement mais sans changer d avis tout le temps Aptitude à la négociation Disponible pour le rôle
60 L équipe Multi-disciplinaire Esprit d équipe Pas d élément perturbateur Mieux vaut un correct niveau moyen que des stars individuelles
61 Ne pas oublier Ce n est pas parce que les rôles ont l air d être parfaitement définis que vous pouvez vous passer de les préciser au démarrage et en cours de projet Les pratiques ont l air d être définies mais laissent une certaine liberté : Faire du Scrum, c est appliquer tous ses principes, mais réfléchir dès que nécessaire à la façon de les appliquer
Des pratiques supplémentaires XP ou extreme Programming Rien à voir avec Windows 62
63 XP et la gestion de projet Séance de Planification (Planning Game) Livraisons Fréquentes (Frequent Releases) Rythme Soutenable (Forty-hour Week) Client sur le Site (On-Site Customer) 2011-2012 Les méthodes agiles Sandrine Mathon
64 XP et les développeurs Développement conduit par les Tests Unitaires (Unit Tests, Tests Driven Development) Conception Simple (Simple Design) et code maintenable Re-factorisation de Code pratiquée sans relâche Tests de Recette (Acceptance Tests)
65 Les TDD Ecrire les tests unitaires Ecrire d abord les tests unitaires Processus itératif : Un test qui produit une erreur Le code qui résout l erreur Un test qui produit une erreur Le code qui résout l erreur etc Les tests unitaires servent d outil de conception
66 Conception simple Conception architecturale simple Pas de conception détaillée Evitez d anticiper toutes les évolutions probables : de toute façon, vous vous trompez Ne définissez QUE ce dont vous avez besoin pour l itération
67 Refactoring Remanier le code pour le simplifier Doit être pratiqué de façon permanente Pallie à l absence de conception initiale Ne pas hésiter à jeter et ré-écrire Demande un sacré courage
68 XP et l équipe développements Propriété Collective du Code (Collective Code Ownership) Convention de Code (Coding Standard) Programmation En Binôme (Pair Programming) Intégration Continue (Continuous Integration) Métaphore (Metaphor)
69 XP et l équipe développement
70 Propriété collective du code Pas de répartition par module Chaque développeur connaît TOUT le code Pas de panique en cas d absence d un développeur Facilite le refactoring
71 Convention de code Parce que le code appartient à tout le monde Parce que le code devient l outil de communication Noms de fonctions parlants Noms de variables clairs Le coach surveille aussi cette partie-là
72 Programmation en binôme Première cause d échec : Le travail en binôme mal compris 2 développeurs côte-à-côte, pas toujours les mêmes Choisir les moments où le binôme est nécessaire Permet une meilleure intégration des nouveaux Favorise la propriété collective du code
73 Intégration continue Le code est compilé en permanence Ce qui est mis à l intégration doit être terminé Le client a accès au produit en permanence pour tester Certaines équipes XP ou Scrum interdisent les demandes de changement de la part du client au cours d une itération Intégration automatisée
74 Métaphore Vous ne développez plus un logiciel, mais un «bureau» ou une «Ferrari» ou une «maison» Pour la Ferrari, vous vous occupez de ses roues, de son moteur, de sa carrosserie Crée une complicité autour du produit
Kanban, Lean Les «nouvelles» tendances 75
76 Agile = Lean? Amélioration continue (Kaizen) Elimination des gaspillages : production excessive, attentes, transport et manutention inutiles, tâches inutiles, stocks, mouvements inutiles production défectueuse.
77 Kanban agile http://henrik-kniberg.developpez.com/mattias-skarin/livre/scrum-kanban/?page=sommaire
78 Kanban agile : les principes Visualisez le workflow : Divisez votre travail, décrivez chaque élément sur une fiche et mettezla au mur. Tracez des colonnes, donnez-leur le nom des étapes du workflow et placez y les éléments de travail. Limitez le TAF (travail à faire) : fixez des limites précises indiquant combien d'éléments peuvent être placés dans chaque étape du workflow. Mesurez et optimisez le temps de cycle (temps moyen pour traiter complètement un élément, appelé "lead time" en anglais), optimisez le processus pour que le temps de cycle soit aussi court et prévisible que possible.
79 Les apports de Kanban Obliger à résoudre les problèmes (sinon la chaîne se bloque) Mettre l accent sur les goulets d étranglement et encourager la collaboration pour les lever Permet de fluidifier le travail Mettre en exergue la notion de fini Est compatible avec Scrum
80 Les dangers de Kanban Favoriser la vision à très court terme Peu de principes définis, il faut donc réfléchir au reste Risque de prétexte pour ne rien organiser Impression de «chômage technique» en cas de blocage Et donc risque d abandon de l approche
81 Les idées reçues sur l Agile Pas de documentation Tout est défini, pas besoin de réfléchir à l organisation L équipe doit être autonome donc il ne faut pas la diriger Le client dirige l équipe
82 La documentation Les problèmes de la documentation: Specs difficiles à maintenir à jour Coupe la communication Agile ne veut pas dire «pas de doc» Oui à la doc comme recueil de connaissance sur le projet et source d amélioration continue
83 L Agile dans l entreprise
Toutes les entreprises peuvent-elles être agiles? 84 Je suis une SSII Je suis un éditeur de logiciel Je développe mes logiciels internes
85 La culture d entreprise
Tous les projets peuvent-ils être agiles? 86 Mon produit est un mélange d informatique et d électronique Petits projets d une ou 2 personnes Énormes projets avec des équipes de plus de 20 personnes : gros projets OpenSource Nécessite des concepts objets forts, une bonne connaissance technique, au moins 1 très bon développeur
87 Causes d échec Le laxisme: tout n est pas pré-mâché Le fanatisme Changement d état d esprit difficile Hostilité du management Le client n est pas disponible Agilité ne veut pas dire changement de priorité ou interruption toutes les 5mn Il faut trouver le bon coach/scrum master Technologie pas assez souple (pas d approche objet ) Mauvaise ambiance dans l équipe
88 Bénéfices Chaque développeur est 7 fois plus productif avec le TDD Motivation des équipes, augmentation du niveau Synergie Qualité du logiciel lissée Les retards ou problèmes sont détectés tôt
89 Et la documentation? Idée reçue : Agile = pas de doc Idée à retenir : Non à la doc comme «interface» de communication Oui à la doc comme recueil de connaissance sur le projet et source d amélioration continue
90 Les outils Plateforme Eclipse Gestion de configuration : SVN, CVS, GIT Frameworks de Tests Unitaires : Junit, CPPUnit Création de builds et fiches de livraison : Maven, Hudson Test de la couche graphique et applis WEB : Selenium, Squish Fit : framework de test collaboratif XPlanner : gestion de projet XP
L Agile à Montpellier 91
92 XP et Scrum Tissu de PMEs/TPEs TIC Agile = dynamisme et qualité des versions extreme Programming pour les entreprises naissantes SCRUM a le vent en poupe Agile Tour à Montpellier en 2011 pour la première fois
93 Quelques entreprises Agile IGEOSS - Editeur de progiciel de modélisation géomécanique XP NORMIND - Editeur de logiciel d aide à la décision Scrum, XP BSD Concept Editeur de logiciels de généalogie - Scrum IOcean - SSII Scrum Synapse SSII Scrum, XP La Poste!
94 L Agile et les approches qualité
95 La qualité des produits Les entreprises mal gérées dépensent 90% de leurs efforts en qualité dans le traitement des symptômes Les entreprises bien gérées dépensent 80% de leurs efforts en qualité dans la prévention Les coûts de prévention sont beaucoup moins importants que les coûts de détection et de correction
96 Les Normes Qualité ISO 9001:2000 par ISO CMMi (Capability Maturity Model Integration) par le SEI Commandé par l armée américaine Le SEI est hébergé par la Carnegie Mellon University
97 Domaines de processus CMMi
98 Bénéfices de CMMi niveau2 Compréhension des besoins clients Bonne préparation des projets Bon suivi Réduction des coûts de développement Réduction des délais de livraison Amélioration de la qualité du produit
99 Compatibilité avec l Agile Obligation de documentation Possibilité d automatiser la production des documents Histoires utilisateurs spécifications Analyse automatique du code conception détaillée Tests : tout est fait dans XP Principes fondamentaux semblables Difficultés La traçabilité des exigences Les CR de réunions PPQA
100 Références «Scrum», par Claude Aubry, DUNOD Gestion de projet extreme Programming Bénard, Bossavit, Medina, Williams Eyrolles extreme Programming, La Référence Kent Beck Campus Press http://www.agiletour.org/ Cas pratique : http://henrik-kniberg.developpez.com/livre/scrum-xp/ http://www.scrum.org/ http://www.infoq.com/minibooks/kanban-scrum-minibook http://blog.octo.com/index.php/2008/01/25/69-pourquoi-les-methodesagiles-peinent-elles-a-penetrer-lentreprise Jeux agiles: http://tastycupcakes.org