Découvrir l’Agilité

1. Découvrir l’Agilité

2. 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

3. qu'est-cequel'agilité ?

4. 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

5. Pourquoi Agile ? • En réaction des problèmes avec des approches ‘traditionnelles’ : Besoins Spécifications Conception Code Test

6. 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

7. Un projet informatique… la réalité • On ne sait pas estimer la charge restante 100% % Complété T

8. 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!

9. Agile : Un juste milieu Très réactive Réactivité Peu réactive Peu focalisé, aucune maitrise Focalisation Objectifs clairs Méthodes prédictives Absence de méthode

10. 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

11. Le manifeste Agile Personnes et interactions Processus et outils Plutôt que Un produit opérationnel Documentation exhaustive Plutôt que Plutôt que Collaboration avec le client Négociation d'un contrat Plutôt que Adaptation au changement Suivid'un plan

12. Libérer le génie humain pour l’auto-organisation dans un contexte qu’il peut maîtriser : • La taille de l’équipe est limitée • le domaine du problème est limité • Petites équipes autogérées • Portée fonctionnelle restreinte à un moment donné • Garder un rythme de travail soutenable • Avancement par itération

13. Expression des besoins Conception Développement Tests, recette & debugage

14. Les solutions Agiles Expression de besoins Conception Développement Tests, recette & debuggage i1 i2 i3 in

15. Les solutions Agiles • Toujours focalisées sur le produit final • Une vision commune pour l’équipe • la satisfaction du client • Découper le projet autrement • par fonctionnalité • Organiser en cycles de développement réduits • itérations

16. Les solutions Agiles • Collaboration avec le client Pourquoi on veut des contrats ? • Instaurer la confiance autrement • Eviter les effets pervers d’un contrat

17. Les solutions Agiles • Adaptables Réactives aux nouveaux besoins Réceptives aux nouvelles solutions • Prendre les décisions définitives le plus tard possible • De courtes itérations permettent de changer de direction sans laisser des éléments à moitié fait

18. 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

19. Exemple de méthode Agile Scrum

20. 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

21. 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

22. 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 !

23. 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

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

25. Exemple de méthode Agile ExtremeProgramming

26. ExtremeProgramming : 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.

27. ExtremeProgramming : 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 !

28. ExtremeProgramming : Valeurs • Feedback • Des tests unitaires, fonctionnels • Du client • Revue avec le client toutes les deux à trois semaines • De l’équipe • Grace à la communication continuelle

29. ExtremeProgramming : 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

30. ExtremeProgramming : 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

31. ExtremeProgramming : Pratiques • Tests • Unitaires • Intégration continue • Test-driven development • Conception incrémentale

32. Questions

33. Chris Ozanne chris@ozanneconsulting.com http://www.ozanneconsulting.com Arnaud Pasquiers Arnaud.pasquiers@twigly.com http://www.twigly.com