Le document présente une analyse des méthodes agiles, soulignant leur importance face aux défis des approches classiques dans le développement logiciel. Il décrit le Manifeste Agile et ses valeurs fondamentales, ainsi que des méthodologies spécifiques telles que Scrum et leur application dans divers contextes. Enfin, il aborde les aspects contractuels associés aux méthodes agiles et les implications pour les relations client-fournisseur.

1. 2009 David Brocard - reproduction soumise à autorisation Les Méthodes Agiles Présentation AnnexEthique David Brocard - Consultant Indépendant http://davidbrocard.org

2. David Brocard - reproduction soumise à autorisation 2009 Sommaire Origine et raison d'être Le Manifeste Agile De la Valeur… Scrum Aspect Contractuels

3. David Brocard - reproduction soumise à autorisation 2009 Origine et raison d'être Les Méthodes Agiles

4. Constats Bilan de réussites des projets informatiques En cause : l’opportunité des projets, la conformité aux besoins, les technologies…mais aussi les méthodes David Brocard - reproduction soumise à autorisation 2009 Origine et raison d'être

5. Constats David Brocard - reproduction soumise à autorisation 2009 Origine et raison d'être

6. La non-qualité David Brocard - reproduction soumise à autorisation 2009 Agile : Etat des lieux – La non qualité temps Origine et raison d'être Produit désiré Produit spécifié Insatisfaction Luxe Produit livré Qualité du produit Non-conformité Gaspillage

7. Constats David Brocard - reproduction soumise à autorisation 2009 Origine et raison d'être

8. Constat des approches classiques David Brocard - reproduction soumise à autorisation 2009 Origine et raison d'être Besoin impossible à définir de manière exhaustive en début de projet Grand nombre de documents, efficacité relative Grand nombre de procédures, difficultés de compréhension et de mise en oeuvre Incapacité à suivre l’évolution du marché Cycles projet hérités de l’industrie lourde

9. Facteur clé d'échec David Brocard - reproduction soumise à autorisation 2009 Le manque de communication à tout niveau Une mauvaise compréhension des besoins L’insuffisance de l’architecture L’absence de maturité des outils utilisés La mauvaise formation des personnes Le cadre contractuel inadapté L’insuffisance des tests Les effets Tunnel Origine et raison d'être

10. Héritage et nouvelle voie Mimétisme des disciplines de l'ingénierie pour organiser le développement logiciel MAIS La division du travail ne fonctionne pas (Le mythe du mois-homme - F.Brooks – 1975) Les problèmes sont plus sociologiques que technologiques (Peopleware – DeMarco/Lister – 1987) David Brocard - reproduction soumise à autorisation 2009 Origine et raison d'être

11. Le logiciel : une discipline singulière David Brocard - reproduction soumise à autorisation 2009 Origine et raison d'être Flexibilité de gestion Discipline peu taylorisable, peu prédictive Possibilités fonctionnelles importantes Instabilité de l'environnement technologique Besoins apparaissant après les tests Marché exigeant, en tension permanente Difficulté des fournisseurs de services à s’engager au forfait

12. Spécificités du projet Web Vous parliez de logiciel… … mais on n’est pas des développeurs (ou presque?) C’est le Graphisme qui est déterminant Chaque Ergonomie est singulière Communication/Image de marque On travaille aussi pour des Institutionnels Peu (pas) d’outils pour tests automatisés

13. David Brocard - reproduction soumise à autorisation 2009 Le Manifeste Agile Les Méthodes Agiles

14. Le Manifeste Agile David Brocard - reproduction soumise à autorisation 2009 Les quatre valeurs fondamentales Agiles sont : L’interaction avec les personnes > les processus et les outils Un produit opérationnel > la documentation La collaboration avec le client > la négociation de contrat La réactivité face au changement > suivi d'un plan http:// agilemanifesto.org / (2001) ‏ Le Manifeste Agile

15. Les 12 principes David Brocard - reproduction soumise à autorisation 2009 Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles . Le changement est accepté, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client. Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte . Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet. Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail . La méthode la plus efficace de transmettre l'information est une conversation en face à face . Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet. Les processus agiles promeuvent un rythme de développement soutenable . Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment. Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité. La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle. Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-organisent . À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace , puis accorde et ajuste son comportement dans ce sens. Le Manifeste Agile Sites

16. Des définitions de l'agilité « L'agilité est une combinaison de flexibilité, pour les changements attendus, et d'adaptabilité, pour les changements inattendus » « Bonnes pratiques poussées à fond » Itération courte, Estimation relative, Pilotage par les tests, Intégration continue, Analyse et adaptation continue... David Brocard - reproduction soumise à autorisation 2009 Le Manifeste Agile « Command and control » « Self organisation » Contrôle projet Pilotage Contrôle qualité Tests

17. Les différentes méthodes Les plus populaires (et de loin) : Scrum (1986) Extreme Programming (1996) Lean Software Development (2002) Lean Manufacturing (1995) (Toyota Production System - 1948-1975) Les moins utilisées : Adaptiive Software Development (1999) Crystal Clear DSDM, Dynamic System Development Method (1996) Feature Driven Development Les “pas tout à fait” agiles : RAD (fin des années 80) RUP (1995) David Brocard - reproduction soumise à autorisation 2009 Cartographie des méthodes

18. David Brocard - reproduction soumise à autorisation 2009 De la Valeur… Les Méthodes Agiles

19. Valeur ? David Brocard - reproduction soumise à autorisation 2009 De la Valeur… c Méthodes agiles : Maximiser la valeur Prix de vente unitaire ? Retour sur investissement (ROI) ? Valeur Actuelle Nette (VAN) ? Utilité ? Autres ? Conformité à un règlement, graphisme, ergonomie etc Développement personnel : humain et technique ? Développement de l’organisation : revenus, capital « connaissance », optimisation ?

20. Cycle en V David Brocard - reproduction soumise à autorisation 2009 De la Valeur…

21. Livraison par lots David Brocard - reproduction soumise à autorisation 2009 De la Valeur…

22. Itératif David Brocard - reproduction soumise à autorisation 2009 c De la Valeur…

23. Itératif avec priorités David Brocard - reproduction soumise à autorisation 2009 c De la Valeur…

24. Agile David Brocard - reproduction soumise à autorisation 2009 c c c De la Valeur…

25. Utilisation de Scrum Utilisé par : des éditeurs des start up des développements internes des forfaits etc Utilisé pour : des logiciels critiques des applications financières des IDE des systèmes hautes disponibilité des applications web innonvantes etc Scrum

26. Quelques principes Equipe auto-organisée Avancement du produit par une série de « sprints » d’un mois Exigences définies comme des éléments d’une liste appelée « backlog du produit » Indépendant des pratiques d’ingénierie Utilisation de règles génériques permettant de créer un environnement agile pour un projet Dimensionnement de 2 à 15 personnes Scrum

27. Cycle de vie Scrum

28. Sprints (Itérations) Time boxes Sélection d’item à produire Produit (partiel) conçu, codé, testé et démontré => Potentiellement déployable Doit permettre de différer la prise en compte de changements Pratiques d’ingénierie logicielle TDD, Refactoring, Intégration continue etc Boucle d’amélioration continue Scrum

29. Rôles Product Owner Représente le produit Décompose les exigences Définit les priorités Définit les critères de satisfaction Fait partie intégrante de l’équipe Prononce l’acceptation des itérations Scrum Master “ Management” du projet Fait appliquer la méthode Développe l’autonomie Organise et anime le cérémonial Elimine les obstacles et protége Concentré sur l’objectif => valeur Peu directif Equipe de développement Polyvalente Membres à plein temps sur le projet, de préférence Auto organisée Responsabilisée Stable pendant une itération Scrum

30. Donnant-donnant Droit du Client Disposer d’un plan global Obtenir le plus de valeur à chaque semaine de développement Changer les demandes, les priorités Apprécier les progrès Etre informé des changements à temps Scrum Droit du développeur Conna î tre les demandes et leurs priorit é s Fournir un travail de qualit é permanent Demander et recevoir de l ’ aide Accepter les responsabilit é s Estimer les tâches et le faire autant que n é cessaire

31. Cérémonial Artefacts Backlog de produit Plan de version Plan d’itération Burndown de version Burndown d’itération Réunions Planification de version Planification d’itération Mêlée quotidienne Revue d’itération Rétrospective Scrum

32. David Brocard - reproduction soumise à autorisation 2009 Aspects Contractuels Les Méthodes Agiles

33. Cône d’incertitude Cône d’incertitude Aspects Contractuels

34. Encore douloureux ! Principalement au forfait mais inadapté Forfait Impossible de s’engager sur un périmètre fixé Gros impact sur la qualité Régie Mieux adapté mais pas dans l”air du temps” Risque de dérive budgétaire Actuellement Aspects Contractuels

35. Engagement de productivité ou de vélocité Après phase exploratoire Engagement au sprint “ Money for nothing” Possibilité de s’arr êter à 80% de la valeur produite en payant 20% du budget restant au fournisseur ROI doit être calculable Très embryonnaire en France A venir Aspects Contractuels

36. Source : Serge Beaumont, Xebia Nouvelle Donne Calibration (env 3 iter) Engagement (FP, TM etc) sur {Vision/Backlog/Velocité} Aspects Contractuels

37. Convaincre les achats… Le new deal Privilégier les fournisseurs d’après leur qualité technique et leur capacité à l'agilité Réaliser plus rapidement des applications ayant le maximum de valeur métier Pistes Aspects Contractuels Client: Obtenir plus de valeur en dépensant moins Fournisseur: gagner plus d'argent en réalisant assez tôt les fonctions utiles amenant de la valeur à son client Source - http://www.sigmat.fr/dotclear/index.php?post/2009/04/10/Quel-projet-pour-mon-contrat