Dcouvrir lAgilit 2011 Chris Ozanne et Arnaud Pasquiers

Découvrir l’Agilité © 2011 Chris Ozanne et Arnaud Pasquiers

Arnaud Pasquiers – Consultant indépendant – Twigly Technologies : logiciel de gestion des temps – Pratique l’Agilité depuis deux ans Chris Ozanne – Consultant indépendant – Spécialisé en architecture et développement JEE et méthodes Agiles – Certifié Scrum Master depuis quatre ans © 2011 Chris Ozanne et Arnaud Pasquiers

QU'EST-CE QUE L'AGILITÉ ? © 2011 Chris Ozanne et Arnaud Pasquiers

Agile • Approche réactive et itérative d’organisation de travail • Focalisée sur la fonctionnalité et satisfaction client • Construit en adéquation avec les capacités et limites humaines © 2011 Chris Ozanne et Arnaud Pasquiers

Pourquoi Agile ? • En réaction des problèmes avec des approches ‘traditionnelles’ : Besoins Spécifications Conception Code Test © 2011 Chris Ozanne et Arnaud Pasquiers

Les constats • Les meilleures idées ne viennent pas forcément au début du projet – Il est plus facile de construire par étape que tout imaginer dès le début • Les besoins peuvent évoluer pendent le projet • Le formalisme n’est pas naturel • Chiffrages et Reste à Faire sont difficiles à évaluer © 2011 Chris Ozanne et Arnaud Pasquiers

Un projet informatique… la réalité • On ne sait pas estimer la charge restante 100% % Complété T © 2011 Chris Ozanne et Arnaud Pasquiers

Problèmes avec cascade • Les méthodes prédictives fonctionnent bien, à condition d’avoir: – Stabilité et prévisibilité – Communication et compréhension parfaite – Choix parfaits dès le départ Ø Aucun humain! © 2011 Chris Ozanne et Arnaud Pasquiers

Agile : Un juste milieu Très réactive Peu focalisé, aucune maitrise Absence de méthode Réactivité Peu réactive Focalisation Objectifs clairs Méthodes prédictives © 2011 Chris Ozanne et Arnaud Pasquiers

Agile : Une catégorie de méthodes • ‘Agile’ regroupe plusieurs méthodologies : – Scrum – Extreme Programming (XP) – DSDM – Crystal –… • Notion officialisée en 2001 avec le Manifeste Agile © 2011 Chris Ozanne et Arnaud Pasquiers

Le manifeste Agile Personnes et interactions Plutôt que Un produit opérationnel Plutôt que Processus et outils Documentation exhaustive Collaboration avec le client Plutôt que Négociation d'un contrat Adaptation au changement Plutôt que Suivi d'un plan © 2011 Chris Ozanne et Arnaud Pasquiers

Le manifeste Agile • Libérer le génie humain Personnes et interactions Plutôt que Processus et outils pour l’auto-organisation dans un contexte qu’il peut maîtriser : Documentation • La taille de l’équipe est Un produit opérationnel Plutôt quelimitée exhaustive • le domaine du problème est limité Collaboration Plutôt que Négociation d'un contrat avec le client ØPetites équipes autogérées ØPortée fonctionnelle restreinte à un moment donné Adaptation au ØGarder un rythme de travail soutenable Suivi d'un plan Plutôt que changement ØAvancement par itération © 2011 Chris Ozanne et Arnaud Pasquiers

Le manifeste Agile Personnes et interactions Un produit opérationnel Collaboration avec le client Adaptation au changement Expression des besoins Plutôt que Processus et outils Documentation exhaustive Plutôt Développement que Tests, recette & debugage Plutôt que Négociation d'un contrat Plutôt que Suivi d'un plan © 2011 Chris Ozanne et Arnaud Pasquiers

Les solutions Agiles Le manifeste Agile Personnes et interactions Plutôt que Processus et outils Expression de besoins Conception Un produit opérationnel Collaboration avec le client i 1 Adaptation au changement Documentation Plutôt que Développement exhaustive Plutôt que Tests, recette Négociation & debuggage d'un i 2 i 3 contrat in Plutôt que Suivi d'un plan © 2011 Chris Ozanne et Arnaud Pasquiers

Les solutions Agiles Le manifeste Agile • Toujours focalisées sur le produit final Plutôt pour que Personnes et interactions Processus et outils ØUne vision commune l’équipe Ø la satisfaction du client ØDécouper le projet autrement Documentation Un produit opérationnel Plutôt que exhaustive Ø par fonctionnalité ØOrganiser en cycles de développement réduits Collaboration Ø itérations Plutôt que Négociation d'un contrat avec le client Adaptation au changement Plutôt que Suivi d'un plan © 2011 Chris Ozanne et Arnaud Pasquiers

Les solutions Agiles Le manifeste Agile • Collaboration avec le client que Personnes et interactions Processus et outils Pourquoi on veut des. Plutôtcontrats ? Documentation Instaurer la confiance autrement Un produit opérationnel Plutôt que exhaustive - Eviter les effets pervers d’un contrat Collaboration avec le client Plutôt que Négociation d'un contrat Adaptation au changement Plutôt que Suivi d'un plan © 2011 Chris Ozanne et Arnaud Pasquiers

Les solutions Agiles Le manifeste Agile • Adaptables Plutôt que Personnes et interactions Processus et outils Réactives aux nouveaux besoins Réceptives aux nouvelles solutions Un produit opérationnel Plutôt que Documentation exhaustive - Prendre les décisions définitives le plus tard possible - De courtes itérations permettent de changer de Collaboration Plutôt que Négociation d'un direction sans laisser des éléments à moitié faitcontrat avec le client Adaptation au changement Plutôt que Suivi d'un plan © 2011 Chris Ozanne et Arnaud Pasquiers

Agile : Planification • L’estimation de charge est difficile, mais les courtes itérations nous aident – On est plus précis sur les petites tâches – Feedback très rapide – Plus facile à s’adapter face aux dérives, surprises © 2011 Chris Ozanne et Arnaud Pasquiers

Exemple de méthode Agile SCRUM © 2011 Chris Ozanne et Arnaud Pasquiers

Scrum : Caractéristiques • Produire le maximum de valeur pour le minimum de coût • Besoins capturés dans un backlog de produit priorisé par une personne • Cycles de développement de 2 à 4 semaines (Sprints) ; équipes autogérées • Mêlée quotidienne © 2011 Chris Ozanne et Arnaud Pasquiers

Scrum : Les Acteurs • Product Owner – Porteur de la vision globale du produit – Gère le Backlog du Produit – Défini des priorités – Accepte ou Rejette les livrables © 2011 Chris Ozanne et Arnaud Pasquiers

Scrum : Les Acteurs • Scrum Master – Veille au bon fonctionnement de l’équipe • Enlève les obstacles – Gardien des pratiques de Scrum – Serviteur de l’équipe - Facilitateur – N’est pas un chef de projet ! © 2011 Chris Ozanne et Arnaud Pasquiers

Scrum : Les Acteurs • L’équipe – 5 à 9 personnes – Autogérée ; les décisions sont prises collectivement – Contient toutes les compétences nécessaires pour terminer le sprint – Ne change pas pendant un Sprint © 2011 Chris Ozanne et Arnaud Pasquiers

Le processus Scrum Mêlée quotidienne Estimation quotidienne Sprint Burndown Chart Créer Backlog du produit • un 15 minutes, tous les jours Visualisation de l'état du projet sous la forme Planification du Sprint Backlog du produit • Trois questions pour chacun tableau • d'un Par. Revue analogie de préférence du sprint 24 heures • Les tâches à faire • Qu’avez-vous fait hier • L'intuition est acceptable ! Rétrospective du sprint • • Les Géré par le Product Owner Réunion tâchesde enl’équipe cours : décisions collectives • Qu’allez-vous faire aujourd’hui • Planning Poker • • les Liste de tout cepour qui va entrainer du tâches Définir unterminées objectif le sprint • Présentation desleaders nouveautés • Quels sont vos problèmes • Choisir Eviter l'influence des d'opinion • travail des éléments du Backlog de produit pour l’équipe • • Uniquement l’équipe Tout le monde est invité • Collégialité mettre dans ledebacklog du sprint • • Constat ce qui asemaines bien oupas moins bien Appréciation de la valeur apportée Toute l’équipe participe – juste le Scrum 2 – 4 Recherche du consensus, et de la propriété • • • Chaque élément est découpé en taches Mettre à !jour Backlog du Sprintqui sont marché dans le l’organisation Master par l’élément collectiveen desheures estimations estimées (max 2 pour jours)le Sprint -> • Le • • reste à faire total Informel Chiffré de imprécise • La conception defaçon haut niveau est abordée burndown chart User Stories • Les • tâches ne sont pas nominatives Backlog du sprint Produit © 2011 Chris Ozanne et Arnaud Pasquiers

Exemple de méthode Agile EXTREME PROGRAMMING © 2011 Chris Ozanne et Arnaud Pasquiers

Extreme Programming : Caractéristiques • Méthodologie de développement basée sur des valeurs, principes et pratiques • Propose des pratiques d’ingénierie comme le binomage et TDD. © 2011 Chris Ozanne et Arnaud Pasquiers

Extreme Programming : Valeurs • Communication – Entre les membres de l’équipe – Verbale – Facilité par colocalisation de l’équipe • Simplicité – Cherche la solution la plus simple qui convient au problème du jour. • Le refactoring n’est pas un échec, mais une étape normale ! © 2011 Chris Ozanne et Arnaud Pasquiers

Extreme Programming : Valeurs • Feedback – Des tests unitaires, fonctionnels – Du client • Revue avec le client toutes les deux à trois semaines – De l’équipe • Grace à la communication continuelle © 2011 Chris Ozanne et Arnaud Pasquiers

Extreme Programming : Valeurs • Courage – De s’attaquer aux problèmes tout de suite – D’appliquer les valeurs XP – De jeter du code lorsque nécessaire • Respect – Tous les membres de l’équipe apportent quelque chose, peu importe leurs années d’expérience © 2011 Chris Ozanne et Arnaud Pasquiers

Extreme Programming : Pratiques • Pair programming – Partage des idées, bonnes pratiques – Partage des expériences – Partage des compétences • Le code appartient à tout le monde – Règles de codage – Utilisation de patterns, métaphores © 2011 Chris Ozanne et Arnaud Pasquiers

Extreme Programming : Pratiques • Tests – Unitaires – Intégration continue – Test-driven development • Conception incrémentale © 2011 Chris Ozanne et Arnaud Pasquiers

QUESTIONS © 2011 Chris Ozanne et Arnaud Pasquiers

Chris Ozanne chris@ozanneconsulting. com http: //www. ozanneconsulting. com Arnaud Pasquiers Arnaud. pasquiers@twigly. com http: //www. twigly. com © 2011 Chris Ozanne et Arnaud Pasquiers