Projets terminés dans les temps, les. budgets et avec les fonctionnalités. prévues : 32%

Transcription

1 UM 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 1 2 Une Histoire de bug 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» 3 4 Par le Standish Group CHAOS Report ( 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ésultat des projets 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% 5 6 1

2 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 L informatique est partout et «facile» à mettre en œuvre Concurrence sur les prix (externalisation, délocalisations) Préservation de la qualité? Communication? Les défaillances ont des conséquences de plus en plus importantes Un projet logiciel doit être géré avec encore plus de méthode 7 8 L'immuabilité des spécifications et des besoins fonctionnels Ce qui sera délivré sera en partie obsolète L'effet tunnel Feedback trop tardif : toute modification va coûter très cher La sectorisation des intervenants Les équipes s'incriminent entre elles Insatisfaction des équipes On oublie où se trouve la valeur du projet Respect à la lettre des spécifications mal comprises, et qui changent On ne délivre pas assez de valeur au client Nécessité de documenter de façon détaillée tous les éléments du projet Les approches agiles «Il suffit de rajouter des programmeurs» loi de Brooks N*(N-1) canaux de communication «Pas la peine de tester, on gagnera du temps» «Si on travaille tous 70 heures/semaine pendant les 5 semaines qui nous restent, on est bons» Les approches agiles Les approches agiles

3 Signé par 17 personnalités 4 valeurs L EQUIPE L APPLICATION LA COLLABORATION LE CHANGEMENT Les personnes et les interactions sont plus importantes que les processus et les outils Un logiciel qui fonctionne prime sur de la documentation pléthorique La collaboration est plus importante que la négociation d un contrat La réactivité au changement passe avant le suivi d un plan Les approches agiles SATISFACTION CLIENT Satisfaire le client en livrant plus tôt et régulièrement des logiciels utiles, qui offrent un véritable valeur ajoutée. LOGICIEL SERT DE MESURE Mesurer la progression / l avancement avec le logiciel qui fonctionne. CHANGEMENT BIENVENU Accepter les changements, même tard dans le développement. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client. RYTHME SOUTENABLE Garder un rythme de travail soutenu et durable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant. LIVRAISONS FREQUENTES Livrer fréquemment une application qui fonctionne avec des cycles de quelques semaines à quelques mois et une préférence pour les cycles les plus courts. ATTENTION CONTINUE Etre attentif à l excellence technique et à la qualité de la conception tout au long du projet. COLLABORATION QUOTIDIENNE Collaborer quotidiennement entre clients et développeurs, tout au long du projet. SIMPLICITE La simplicité, c est-à-dire l art de minimiser la quantité de travail inutile, est essentielle. MENTS Bâtir le projet autour de personnes motivées en leur fournissant environnement et support, et en leur faisant confiance. MOTIVATION ET ENCOURAGE- AUTO- ORGANISATION Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées. COMMUNICATION DIRECTE Communiquer par des conversations en face à face est la méthode la plus simple et la plus efficace pour transmettre de l information. AJUSTEMENTS CONTINUS À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence Scrum Extreme programming (XP) Rapid Application Development (RAD) Feature driven development Et de plus en plus : Agile Lean, Kanban Le déroulement

4 Les Rôles 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 PLAN PRODUIT, PLAN DE VERSION Scrum Master PLANIFICATI ON Product Equipe de Owner réalisation Les Etapes CONCEPTION DEMONSTRATION TESTS & REALISATION INTEGRATION Utilisateurs LIVRAISON PRODUIT PARTIEL OPERATIONNEL SCRUM est un framework de méthodologie SCRUM est un framework non prescriptif PLAN ITERATION POINT QUOTIDIEN RETROSPECTIVE ITERATION : 2 à 4 semaines maximum Les approches agiles Les approches agiles 20 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 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 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 Les 3 piliers de SCRUM La transparence Langage commun et compréhension commune Pas de bouc émissaire L inspection Régulière mais pas trop fréquente L adaptation On ne laisse pas un problème perdurer Les itérations 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

5 Le démarrage d une version 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 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? 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é 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) ID User Story Comment le démontrer 001 Un <utilisateur> fait une <action> dans un <objectif> donné Soit sous forme de scénario, soit liste des exigences incontournables Valeur Estimation Sprint Importance d un point de vue utilisateur Effort pour implémenter la US Sprint dans lequel la US est prise en compte Les approches agiles Les approches agiles 30 5

6 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 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 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 Librement inspiré du Doggy Planning L équipe estime le contenu du Backlog Planning Poker : 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100,?, Pause 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

7 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 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 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) 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 Les approches agiles Les approches agiles 42 7

8 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 Les approches agiles Les approches agiles 44 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 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 ) 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 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»

9 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 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 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 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 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

10 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» 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 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? 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 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

11 Multi-disciplinaire Esprit d équipe Pas d élément perturbateur Mieux vaut un correct niveau moyen que des stars individuelles Echangent avec le responsable produit Participent et réagissent à la démonstration de l itération Réalisent la recette des livraisons le plus souvent possible Les utilisateurs peuvent être différents en fonction des itérations. Ils doivent être entre 3 et 5 Il est très important qu ils soient directement concernés par ce que l équipe leur présente durant la démonstration de l itération Ils doivent être motivés par ce rôle 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 Le client sait ce qu il veut Les développeurs savent comment l implémenter Rien ne change en cours de projet Le client découvre ce qu il veut Les développeurs découvrent comment l implémenter Beaucoup de choses changent en cours de projet Projets cycle en V Projets agiles 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 Les approches agiles

12 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 Les approches agiles Les approches agiles 68 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 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 «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 Cas pratique : Jeux agiles: Les approches agiles Les approches agiles 72 12

13 Cahier des Charges Objectif : passer le plus de balles possible Vous faites tous partie de la même équipe Entre chaque participant, la balle doit voler («airtime») 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 Explication des règles 2 min : Organisation initiale de l équipe Puis 5 fois (ou encore 5 itérations) : 1 min : Estimation du nombre de balles qui vont pouvoir être passées entièrement 2 min : passage de balles 1 min : debriefing de l itération par l équipe Après les 5 itérations : 10 min de debriefing commun Les seules règles sont celles écrites ci-dessus Le projet : votre client souhaite faire le Tour du Monde. Vous l aidez à mettre son projet en place. Votre équipe : 4 ou 5 personnes, choisissez le client. Ensemble vous écrivez le Backlog du projet sous forme de USER STORIES «l utilisateur» fait une «action» dans tel «objectif» Priorisez Vous avez ¼ d h pour écrire le Backlog complet Différencier l expression du besoin/envie (User Story : Ex : «le client visite le Taj Mahal» ou «le client voyage en bateau») de la tâche technique qui permet d y répondre (Ex : prendre un billet pour l Inde) Intérêt de l objectif : ex : «le client voyage en bateau pour avoir le temps d apprécier le paysage» est différent de «le client voyage en bateau parce qu il veut éviter les embouteillages» Ne pas chercher à tout détailler On garde ce qui est flou et moins important pour la fin 77 Mon backlog : Danois Chihuahua Hot-dog Boxer Caniche nain Yorkshire Bâtard Berger Kangaeru Estimer le backlog 78 13

14 De quoi parlons-nous : à quoi va servir l estimation? Quelle unité pour l estimation? Prendre un point de référence Ne pas estimer ce que vous ne comprenez pas Poser des questions sur ce que vous ne comprenez pas L estimation ne sera confirmée que par la pratique 2 approches Estimer la taille/difficulté plutôt que la durée Estimer de façon relative, par rapport à une story connue (= chiens) Estimation en points = jours/hommes idéaux (= caisses) Les estimations sont INDICATIVES On ne les vérifie pas à la fin du sprint Cf Planning Poker Valeurs : 0 0, ? Que se passe-t-il si on estime en heures/jours? Pour les méthodes classiques, Cf. Le mur d estimation : Wall Planning Poker timer-un-carnet-de-produit-complet-en-2- heures-wall-planning-poker/ La méthode «correction d examen» Backlog complet au début En démarrage d itération Possible en cours de projet pour l ensemble du backlog Premier sprint : correspond à la capacité réaliste (et non idéale) de l équipe Notion de vélocité : nombre de points livrés au précédent sprint Capacité : nb de jours/hommes x facteur de focalisation Facteur de focalisation = degré de concentration prévu de l équipe

15 Faites le plan de release de votre projet «Tour du Monde» Choisissez un thème de rétrospective parmi votre quotidien XP ou extreme Programming Rien à voir avec Windows Séance de Planification (Planning Game) Livraisons Fréquentes (Frequent Releases) Rythme Soutenable (Forty-hour Week) Client sur le Site (On-Site Customer) 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)

16 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 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 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 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) 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

17 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à 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 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 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 Les «nouvelles» tendances Amélioration continue (Kaizen) Elimination des gaspillages : production excessive, attentes, transport et manutention inutiles, tâches inutiles, stocks, mouvements inutiles production défectueuse

18 Visualisez le workflow : Divisez votre travail, décrivez chaque élément sur une fiche et mettez-la 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 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 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 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 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

19 Impossible d'afficher l'image. Votre ordinateur manque peut-être de mémoire pour ouvrir l'image ou l'image est endommagée. Redémarrez l'ordinateur, puis ouvrez à nouveau le fichier. Si le x rouge est toujours affiché, vous devrez peut-être supprimer l'image avant de la réinsérer. Je suis une SSII Je suis un éditeur de logiciel Je développe mes logiciels internes Les approches agiles 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 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 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

20 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 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 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 IGEOSS - Editeur de progiciel de modélisation géomécanique XP BSD Concept Editeur de logiciels de généalogie Scrum ARKADIN Editeur de logiciels de téléconférence IOcean - SSII Scrum Synapse SSII Scrum, XP La Poste!