Methodes agile

Methodes agile
Les méthodes agiles UM2 –2011-2012 2011 - 2012 Les méthodes agiles – S. Mathon 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 2011 - 2012 Les méthodes agiles – S. Mathon
Les ratages et l’informatique Une Histoire de bug 2011 - 2012 Les méthodes agiles – S. Mathon 3
4 Un projet raté, c’est un produit 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 » 2011 - 2012 Les méthodes agiles – S. Mathon
5 Un constat alarmant au niveau mondial Situation en 2002 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 2011 - 2012 Les méthodes agiles – S. Mathon
6 Résultats 2009 : une nette amélioration 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
7 Causes d’échec en informatique selon le Standish Group 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 2011 - 2012 Les méthodes agiles – S. Mathon
« Le chemin est long du projet à la 8 chose» Molière 2011 - 2012 Les méthodes agiles – S. Mathon
9 L’apparition des méthodes agiles 2011 - 2012 Les méthodes agiles – S. Mathon
10 Manifeste des méthodes agiles Signé par 17 personnalités 4 valeurs L'équipe « Personnes et interaction plutôt que processus et outils » L'application « Logiciel fonctionnel plutôt que documentation complète » La collaboration « Collaboration avec le client plutôt que négociation de contrat » L'acceptation du changement « Réagir au changement plutôt que suivre un plan » 2011 - 2012 Les méthodes agiles – S. Mathon
11 Méthodes agiles : les 12 principes Satisfaction client Changement bienvenu Livraisons fréquentes Collaboration quotidienne Motivation et encouragements Communication face-à-face Logiciel sert de mesure 2011 - 2012 Les méthodes agiles – S. Mathon
12 Les 12 principes (suite) Rythme soutenable Attention continue à la technique et à la conception Simplicité Auto-organisation Ajustements continus 2011 - 2012 Les méthodes agiles – S. Mathon
13 Exemples Scrum Extreme programming (XP) Rapid Application Development (RAD) Adaptive software development (ASD) Crystal clear Dynamic software development method (DSDM) Feature driven development 2011 - 2012 Les méthodes agiles – S. Mathon
Scrum Le déroulement 2011 - 2012 Les méthodes agiles – S. Mathon 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 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
19 Workflow Agile 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
21 Itératif vs Incrémental 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
Scrum Le démarrage d’une version 2011 - 2012 Les méthodes agiles – S. Mathon 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 2011 - 2012 Les méthodes agiles – S. Mathon
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? 2011 - 2012 Les méthodes agiles – S. Mathon
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é 2011 - 2012 Les méthodes agiles – S. Mathon
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) 2011 - 2012 Les méthodes agiles – S. Mathon
28 Exemple de Product Backlog ID User Story Comment le Valeur Estimation Sprint démontrer 001 Un <utilisateur> Soit sous forme Importance Effort pour Sprint fait une <action> de scénario, soit d’un point de implémenter dans dans un liste des vue la US lequel la <objectif> donné exigences utilisateur US est incontournables prise en compte 2011 - 2012 Les méthodes agiles – S. Mathon
29 Le Plan de Release : pour 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 3- Durée des de fin sprints Plan de release 2- Estimer les 5- Planifier la Backlog stories Backlog release estimé 4- Estimer la capacité de l’équipe 2011 - 2012 Les méthodes agiles – S. Mathon
30 Problèmes classiques de 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 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
32 Exercice : la planification 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 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
Scrum : les sprints Illustration VisualExplainer 2011 - 2012 Les méthodes agiles – S. Mathon 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 2011 - 2012 Les méthodes agiles – S. Mathon
36 La réunion de planification de 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 2011 - 2012 Les méthodes agiles – S. Mathon
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) 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
39 Le tableau blanc 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
41 Mise en bouche : jeu du ballon Mon cahier des charges : mon ballon 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
Scrum : en cours de sprint 2011 - 2012 Les méthodes agiles – S. Mathon 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 2011 - 2012 Les méthodes agiles – S. Mathon
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…) 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
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 » 2011 - 2012 Les méthodes agiles – S. Mathon
Scrum : la revue de sprint 2011 - 2012 Les méthodes agiles – S. Mathon 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 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
Scrum : résumé des rôles 2011 - 2012 Les méthodes agiles – S. Mathon 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 2011 - 2012 Les méthodes agiles – S. Mathon
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? 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
60 L’équipe Multi-disciplinaire Esprit d’équipe Pas d’élément perturbateur Mieux vaut un correct niveau moyen que des stars individuelles 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
Des pratiques supplémentaires XP… ou eXtreme Programming Rien à voir avec Windows 2011 - 2012 Les méthodes agiles – S. Mathon 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) 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
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) 2011 - 2012 Les méthodes agiles – S. Mathon
69 XP et l’équipe développement 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
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à 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
Kanban, Lean Les « nouvelles » tendances 2011 - 2012 Les méthodes agiles – S. Mathon 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. 2011 - 2012 Les méthodes agiles – S. Mathon
77 Kanban agile http://henrik-kniberg.developpez.com/mattias-skarin/livre/scrum-kanban/?page=sommaire 2011 - 2012 Les méthodes agiles – S. Mathon
78 Kanban agile : les principes 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. 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
83 L’Agile dans l’entreprise 2011 - 2012 Les méthodes agiles – S. Mathon
84 Toutes les entreprises peuvent-elles être agiles? Je suis une SSII Je suis un éditeur de logiciel Je développe mes logiciels internes 2011 - 2012 Les méthodes agiles – S. Mathon
85 La culture d’entreprise 2011 - 2012 Les méthodes agiles – S. Mathon
86 Tous les projets peuvent-ils être 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 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
L’Agile à Montpellier 2011 - 2012 Les méthodes agiles – S. Mathon 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 2011 - 2012 Les méthodes agiles – S. Mathon
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! 2011 - 2012 Les méthodes agiles – S. Mathon
94 L’Agile et les approches qualité 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
97 Domaines de processus CMMi 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
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 2011 - 2012 Les méthodes agiles – S. Mathon
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-methodes- agiles-peinent-elles-a-penetrer-lentreprise Jeux agiles: http://tastycupcakes.org 2011 - 2012 Les méthodes agiles – S. Mathon

Methodes agile

Check these out next

Methodes agile

Recommandé

Contenu connexe

Présentations pour vous(20)

Similaire à Methodes agile(20)

Dernier(20)

Methodes agile