Methodes agile

Les méthodes agiles

UM2 –2011-2012

12011 - 2012 Les méthodes agiles – S. Mathon

2

Sommaire

� Introduction� L’origine des Méthodes Agiles� Le déroulement d’un projet Scrum


� 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

Les ratages et l’informatique

3

Une Histoire de bug


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


� 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 »

5

Un constat alarmant au niveau mondialSituation 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évuesType 2 : Projet terminé en retard, hors budget ou avec une limitation de fonctionnalitéType 3 : Projets abandonnés

Résultats 2009 : une nette amélioration

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

6

Les méthodes agiles – S. Mathon

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

7

Causes d’échec en informatiqueselon 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

8« Le chemin est long du projet à la chose» Molière


9

L’apparition des méthodes agiles


L’apparition des méthodes agiles

10

Manifeste des méthodes agiles

L'équipe « Personnes et interaction plutôt que processus et outils »

� Signé par 17 personnalités� 4 valeurs

Les méthodes agiles – S. Mathon

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

11

Méthodes agiles : les 12 principes

� Satisfaction client� Changement bienvenu� Livraisons fréquentes


� Livraisons fréquentes� Collaboration quotidienne� Motivation et encouragements� Communication face-à-face� Logiciel sert de mesure

12

Les 12 principes (suite)

� Rythme soutenable� Attention continue à la technique et à la

conception


conception� Simplicité� Auto-organisation� Ajustements continus

13

Exemples

� Scrum� Extreme programming (XP) � Rapid Application Development (RAD)


� Rapid Application Development (RAD)� Adaptive software development (ASD)� Crystal clear� Dynamic software development method

(DSDM)� Feature driven development

Scrum

Le déroulement

2011 - 2012 Les méthodes agiles – S. Mathon 14

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

15

� Ken Schwaber et Jeff Sutherland la formalisent en 1996

� SCRUM est un framework de méthodologie� SCRUM est un framework non prescriptif


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

16

� Product Owner


� 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

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

17

� 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


Planning

� Explication des règles� 2 min Création des équipes� 2 min Organisation de l’équipe

18

� 2 min Organisation de l’équipe� 1 min Estimation du temps� 2 min itération� 1 min debriefing de l’itérationAprès les 5 itérations : 10 min de

debriefing commun2011 - 2012 Les méthodes agiles – S. Mathon

19

Workflow Agile


Définitions

� Sprint : itération dans Scrum – 2 semaines à 1 mois� Scrum : mêlée quotidienne� Product Backlog : cahier des charges initial

20

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


21

Itératif vs Incrémental


Les règles fondamentales� Les itérations sont courtes : 2 semaines

à 1 mois maximum� Les itérations ne se chevauchent pas

22

� 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


Scrum

Le démarrage d’une version


Avoir la vision globale

� Comme pour toute méthode de gestion de projet, comprendre le contexte et les objectifs du projet.

24

objectifs du projet.� Déterminer les utilisateurs du projet� Plusieurs approches possibles :

� Document de Vision� Modèle Volere


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

25

� 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?


Le Product Backlog

� Ensemble des évolutions prévues pour la version, plus ou moins précises

� Un Backlog est vivant

26

� 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é


La User Story� Les User Stories sont des « histoires » � Avec :

� un acteurqui effectue une action

27

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


Exemple de Product Backlog

28

ID User Story Comment le démontrer

Valeur Estimation Sprint

001 Un <utilisateur> Soit sous forme Importance Effort pour Sprint


001 Un <utilisateur> fait une <action> dans un <objectif> donné

Soit sous forme de scénario, soit liste des exigences incontournables

Importance d’un point de vueutilisateur

Effort pour implémenter la US

Sprint dans lequel la US est prise en compte

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

29

� Fait par toute l’équipe


Backlog

2- Estimer les

stories

1- Définir le critère de fin

3- Durée des

sprints

5- Planifier la

release

4- Estimer la capacité de

l’équipe

Backlog

estimé

Plan de release

Problèmes classiques de Backlog

� Les problèmes classiques de gestion des exigences :� Stories exprimées sous forme de solution

30

� Stories exprimées sous forme technique� Ambigüité/flou� Manques/doublons/incompatibilité

� Product Backlog trop lourd� Stories trop grosses


L’estimation dans Scrum� Estimer la taille/difficulté plutôt que la

durée� Estimation en points = jours/hommes

idéaux

31

idéaux

� Estimer de façon relative, par rapport à une story connue

� Les estimations sont INDICATIVES� Cf Planning Poker

� http://www.planningpoker.com/detail.html2011 - 2012 Les méthodes agiles – S. Mathon

Exercice : la planification culinaire� Librement inspiré du Doggy Planning

http://tastycupcakes.org/2009/06/doggy-planning/L ’équipe estime le contenu du Backlog

32

� L ’équipe estime le contenu du Backlog� Planning Poker :

� 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, Pause


Backlog

� Votre Backlog contient les plats suivants :� Nouilles au beurre� Osso bucco� Gâteau au chocolat

33

� 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’estimation2011 - 2012 Les méthodes agiles – S. Mathon

Scrum : les sprints


Illustration VisualExplainer

La durée de sprint

� Durée fixe� Consensus entre

� le besoin de feedback/la motivation

35

� le besoin de feedback/la motivation � vs le coût lié au sprint/la disponibilité du

Product Owner

� Au minimum 4 sprints par version


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

36

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’importance2011 - 2012 Les méthodes agiles – S. Mathon

A préparer avant

� Le Product Backlog existe :� Les exigences/User stories sont listées� Le Product Owner a mis l’importance des

37

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


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

38

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


39

Le tableau blanc


Et les tests?

� Prévoir les tests d’acceptation dès la planification du sprint

� Le scénarios de tests permettent :

40

� 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


Mise en bouche : jeu du ballon

41

Mon cahier des charges : mon ballon


mon ballon

Règle du jeu

� Chaque équipe a 2 minutes pour créer le plus possible de ballons et me les amener

42

amener� Résultats et debriefing� 2ème itération


Scrum : en cours de sprint


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

44

� 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


Le Scrum Daily Meeting

� Faire le point sur les tâches depuis le dernier Scrum meeting

� S’attribuer de nouvelles tâches

45

� 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…)


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

46

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 pas2011 - 2012 Les méthodes agiles – S. Mathon

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?

47

� 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 »


Scrum : la revue de sprint


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

49

� 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


La préparation

� Tester ou faire tester les stories livrées� Préparer un plan de démonstration basé

sur les Stories livrées

50

sur les Stories livrées� Convier des invités éventuels� Installer sur une plateforme de

test/démonstration, avec des données significatives


Les participants

� Au minimum, toute l’équipe y compris Product Owner et Scrum Master

� Parfois les autres personnes intéressées

51

� Parfois les autres personnes intéressées� Marketing/commercial� Support� Éventuellement clients ou partenaires


Le contenu

� Le Product Owner émet des demandes de modification et recueille les feedbacks des participantsIl mettra ensuite à jour le Product Backlog et

52

� 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


La rétrospective

� Revenir sur le déroulement du sprint pour optimiser l’organisation

� Réunion suite à la réunion de fin de sprintBilan intermédiaire

53

� 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


Scrum : résumé des rôles


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

55

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

Le Scrum Master idéal� Bonne connaissance de Scrum� Comprend les aspects techniques� Communication

Bon guide, fait confiance

56

� Bon guide, fait confiance� Médiateur� Tenace� Transparent� Au service de l’équipe� Sait prendre des risques


Questions fréquentes

� Peut-on se passer de Scrum Master?� Le Scrum Master doit-il être le Chef de

Projet?

57

Projet?� Le Scrum Master peut-il venir en plus

du Chef de Projet?


Actions du Product Owner� Participe aux réunions

� De début de sprint� Quotidiennes, parfois

De fin de sprint

58

� 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


Le Product Owner idéal� Bonne connaissance du domaine métier� Maîtrise des techniques de définition de

produitCapacité à prendre des décisions rapidement

59

� 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


L’équipe

� Multi-disciplinaire� Esprit d’équipe� Pas d’élément perturbateur

60

� Pas d’élément perturbateur� Mieux vaut un correct niveau moyen

que des stars individuelles


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

61

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


Des pratiques supplémentaires

62

XP… ou eXtreme ProgrammingRien à voir avec Windows


XP et la gestion de projet

� Séance de Planification (Planning Game)

� Livraisons Fréquentes (Frequent Releases)

63

� 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


� Conception Simple (Simple Design) et code maintenable

� Re-factorisation de Code pratiquée sans relâche

� Tests de Recette (Acceptance Tests)

65

Les TDD� Ecrire les tests unitaires� Ecrire d’abord les tests unitaires� Processus itératif :

� Un test qui produit une erreur


� 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

66

Conception simple

� Conception architecturale simple� Pas de conception détaillée� Evitez d’anticiper toutes les évolutions


� 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

67

Refactoring

� Remanier le code pour le simplifier� Doit être pratiqué de façon permanente� Pallie à l’absence de conception initiale


� Pallie à l’absence de conception initiale� Ne pas hésiter à jeter et ré-écrire� Demande un sacré courage

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)

69

XP et l’équipe développement


70

Propriété collective du code

� Pas de répartition par module� Chaque développeur connaît TOUT le

code


code� Pas de panique en cas d’absence d’un

développeur� Facilite le refactoring

71

Convention de code

� Parce que le code appartient à tout le monde

� Parce que le code devient l’outil de


� Parce que le code devient l’outil de communication � Noms de fonctions parlants� Noms de variables clairs

� Le coach surveille aussi cette partie-là

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


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

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


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

74

Métaphore

� Vous ne développez plus un logiciel, mais un « bureau » ou une « Ferrari » ou une « maison »…


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

Kanban, Lean

Les « nouvelles » tendances


Agile = Lean?� Amélioration continue (Kaizen)� Elimination des gaspillages :

� production excessive,

76

� attentes,� transport et manutention inutiles,� tâches inutiles,� stocks,� mouvements inutiles� production défectueuse.


Kanban agile

77


http://henrik-kniberg.developpez.com/mattias-skarin/livre/scrum-kanban/?page=sommaire

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.

78

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.


Les apports de Kanban

� Obliger à résoudre les problèmes (sinon la chaîne se bloque)

� Mettre l’accent sur les goulets

79

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


Les dangers de Kanban

� Favoriser la vision à très court terme� Peu de principes définis, il faut donc

réfléchir au reste

80

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


Les idées reçues sur l’Agile

� Pas de documentation� Tout est défini, pas besoin de réfléchir à

l’organisation

81

l’organisation� L’équipe doit être autonome donc il ne

faut pas la diriger� Le client dirige l’équipe


La documentation

� Les problèmes de la documentation:� Specs difficiles à maintenir à jour� Coupe la communication

82

� 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


83


L’Agile dans l’entreprise

84

Toutes les entreprises peuvent-elles être agiles?

� Je suis une SSII� Je suis un éditeur de logiciel� Je développe mes logiciels internes


La culture d’entreprise

85


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

86

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


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

88

Bénéfices

� Chaque développeur est 7 fois plus productif avec le TDD

� Motivation des équipes, augmentation du niveau


� Motivation des équipes, augmentation du niveau

� Synergie � Qualité du logiciel lissée� Les retards ou problèmes sont détectés

tôt

Et la documentation?

� Idée reçue : Agile = pas de doc� Idée à retenir :

� Non à la doc comme « interface » de

89

� Non à la doc comme « interface » de communication

� Oui à la doc comme recueil de connaissance sur le projet et source d’amélioration continue


90

Les outils� Plateforme Eclipse� Gestion de configuration : SVN, CVS, GIT� Frameworks de Tests Unitaires : Junit,

CPPUnit…


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

L’Agile à Montpellier


XP et Scrum

� Tissu de PMEs/TPEs TIC� Agile = dynamisme et qualité des

versions

92

versions� eXtreme Programming pour les

entreprises naissantes� SCRUM a le vent en poupe� Agile Tour à Montpellier en 2011 pour la

première fois2011 - 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, XPBSD Concept – Editeur de logiciels de généalogie -


� BSD Concept – Editeur de logiciels de généalogie -Scrum

� IOcean - SSII – Scrum� Synapse – SSII – Scrum, XP

� La Poste!

94

L’Agile et les approches qualité


L’Agile et les approches qualité

95

La qualité des produits

� Les entreprises mal gérées dépensent 90% de leurs efforts en qualité dans le traitement des symptômesLes entreprises bien gérées dépensent 80%


� 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

96

Les Normes Qualité

� ISO 9001:2000 – par ISO � CMMi (Capability Maturity Model

Integration) – par le SEI


Integration) – par le SEI� Commandé par l’armée américaine� Le SEI est hébergé par la Carnegie Mellon

University

97

Domaines de processus CMMi


98

Bénéfices de CMMi niveau2

� Compréhension des besoins clients� Bonne préparation des projets� Bon suivi


� Bon suivi� Réduction des coûts de développement� Réduction des délais de livraison� Amélioration de la qualité du produit

99

Compatibilité avec l’Agile� Obligation de documentation

� Possibilité d’automatiser la production des documents

� Histoires utilisateurs � spécificationsAnalyse automatique du code � conception détaillée


� 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

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

100

� 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


Education

Methodes agile