PRATIQUES DE L'AGILITÉ

Dimension: px
Commencer à balayer dès la page:

Download "PRATIQUES DE L'AGILITÉ"

Transcription

1 PRATIQUES DE L'AGILITÉ PABLO PERNOT SMARTVIEW https://speakerdeck.com/u/pablopernot Ce travail est sous licence : Creative Commons Attribution ShareAlike 3.0 Unported p e rn o t version décembre 2012

2 PROGRAMME JOUR 1 Les raisons et origines de l'agilité, valeurs & principes Filiation et comparaison des principales méthodes agiles : Lean, XP, Scrum, KanBan La pensée LEAN Respect des personnes Amélioration continue Pratiques d'estimation et de planification Estimation, Planification Cycle de vie / Itérations Conception émergente Ateliers : Planning poker, Wall planning poker, Marshmallow challenge Pratiques quotidiennes et Pilotage Visualisation et "radiateurs" d'information Les burndown/up charts Les standups SCRUM Aperçu de Scrum, Les acteurs de Scrum Développement itératif Timebox Communication, interaction Atelier : Scrum from hell Pratiques de fin d'itération et de cycle Les revues Les rétrospectives Atelier : Coin Toss, Offing the offsite Pratiques d'expression du besoin Délivrer de la valeur Les User Stories Personas Backlog Notion de "fini" JOUR 2 Atelier : Speedboat EXTREME PROGRAMMING Ateliers : Prune the tree, Open ended specifications, Backlog Les pratiques d'ingénierie Dette technique Feeback Tests automatisés Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 2

3 PROGRAMME JOUR 3 EXTREME PROGRAMMING Pratiques d'ingénierie (suite) Refactoring Pair programming Intégration continue Atelier : XP Game KANBAN Une marque de maturité? Evolution de certaines pratiques Mise en oeuvre de Kanban Visualiser le flux Classes de service Débats autour de Kanban Atelier : KanBan Game Pratiques de l'entreprise agile Passage à l'agilité, Conduite du changement Scalabilité, Management, Contractualisation Atelier : leadership Conclusion Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 3

4 PRÉSENTATIONS Connaissez vous les méthodes agiles? Avez vous lu des livres sur les méthodes agiles? Votre organisation implémente t elle déjà une méthode agile? Comment travaillez vous actuellement sur vos projets? Pourquoi marchent ils? Pourquoi échouent ils? Quels sont les problèmes auxquels vous êtes régulièrement confrontés? Avez vous cherché des pistes d'améliorations? Pourquoi souhaitez vous implémenter l'agilité au sein de votre organisation? Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 4

5 L'AGILITÉ AUJOURD'HUI Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 5

6 LES RAISONS DE L'AGILITÉ Le fameux rapport Chaos du Standish Group... Principales causes des échecs Mauvaise compréhension du besoin : 51% Estimation et planification déficiente : 48% Technologies mal maîtrisées : 45% Facteurs clefs du succès Implication des utilisateurs Soutien par le management Objectifs business clair Périmètre optimisé Un constat sévère 64% des fonctionnalités développées sont peu ou pas utilisées... Source : Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 6

7 LE CYCLE EN V, TRADITIONNEL, ET WATERFALL Mais qu'est ce qui ne fonctionne pas avec ce modèle? Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 7

8 LA FIN DU CYCLE EN V CLASSIQUE L'immuabilité des spécifications et des besoins fonctionnels Ce qui sera délivré sera en partie obsolète, pensez aux marines! ** L'effet tunnel! Feedback trop tardif : toute modification va coûter très cher La sectorisation des intervenants Les équipes s'incriminent entre elles Insatisfaction des équipes On oublie où se trouve la valeur du projet et on se concentre sur le respect à la lettre des spécifications (or elles sont souvent mal comprises, et surtout elles changent!) et de la documentation On ne délivre pas assez de valeur au client Nécessité de documenter de façon détaillée tous les éléments du projet ** Source : Mary Poppendieck, Lean Software Development, an agile toolkit Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 8

9 4 VALEURS AGILES Pour répondre à ce problème est créé en 2001 le manifeste Agile. Rédige par 17 experts qui se dressent contre l'échec des cycles en cascade, Il propose 4 valeurs fondamentales, et 12 principes La réactivité face au changement plutôt que le suivi d'un plan l interaction avec les personnes plutôt que les processus et les outils un produit opérationnel documentation pléthorique plutôt qu une La collaboration avec le client plutôt que la négociation de contrat On parle de rituels, la photo du manifeste parait mystique, mais ce n'est pas une secte! ) Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 9

10 LES 12 PRINCIPES DE L'AGILITÉ 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 experts métier 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 pour transmettre l'information est une conversation en face à face. Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 10

11 LES 12 PRINCIPES DE L'AGILITÉ 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. Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 11

12 LES MÉTHODES AGILES SONT MATURES Plusieurs méthodes : XP, SCRUM, LEAN, etc. Plus de 10 ans d'expérience Une méthodologie reconnue : par Google, Yahoo, Nokia, Microsoft, IBM, Oracle, MySpace, Adobe... En 2008, l'étude du drdobbs.com indique que 69% des entreprises font de l'agile, et parmi celles qui ne font pas d'agile, 15% d'entre elles estiment démarrer l'année suivante * Etude Agile Adoption Rate Survey Results: February ** 3rd Annual Survey 2008 "The state of Agile development Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 12

13 BÉNÉFICES PROPOSÉS PAR L'AGILITÉ Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 13

14 POURQUOI CELA MARCHE? Priorité à ce qui a le plus de valeur, à ce qui est le plus important Démarche itérative, incrémentale et adaptative Des interactions et de la communication Un outillage compact et rapidement assimilable De la visibilité De la motivation et de la satisfaction dans les équipes Un produit opérationnel très tôt Une réactivité face au changement Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 14

15 MAIS CE N'EST PAS L'absence de règle : La discipline est indispensable Les processus sont indispensables L'absence de documentation Il faut des spécifications si elles ont de la valeur Magique Cela ne fonctionne pas dans tous les contextes Il n'y a pas de checklist Scrum! Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 15

16 LA PENSÉE LEAN Le modèle de production Toyota Amélioration continue Respect des personnes Remettre tout en cause Embrasser le changement Source : La base de la méthode Toyota est de ne pas se satisfaire du statu quo, vous devez constamment vous poser la question : «Pourquoi faisons nous ça?». Source : aimetti.fr/dotclear/index.php?post/2011/08/24/lean Primer Taiichi Ohno Une philosophie Respect des employés Une utilisation de toutes les compétences des employés Donner des responsabilités et avoir confiance dans les employés Source : Mary Poppendieck, Lean Software Development Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 16

17 Source : aimetti.fr/dotclear/index.php?post/2011/08/24/lean Primer LES PILIERS DU LEAN : RESPECT DES PERSONNES Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 17

18 LES PILIERS DU LEAN : AMÉLIORATION CONTINUE Allez & Observez Plein de mots japonais pour briller en société (ou faire consultant) Kaizen Shu Ha Ri Valeur Gaspillage Petits ajustements incessants Kaizen : amélioration continue Gemba : Là où se trouve la réalité Muda : forme de gaspillage Kanban : fiche, étiquette Yokoten : Diffusion horizontale des connaissances Jidoka : automatisation avec une touche humaine Obeya : grande salle (war room des projets agiles...) g/wiki/roue_de_de ming Source : aimetti.fr/dotclear/index.php?post/2011/08/24/lean Primer Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 18

19 ELIMINER LES SOURCES DE GASPILLAGE Source : Mary Poppendieck, Lean Software Development Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 19

20 PRINCIPES LEAN Optimiser le système dans son ensemble Approche à long terme. Management visuel simple Travailler en mode flux Cycle court Livrer rapidement Visibilité régulière Responsabiliser l'équipe Technologie éprouvée Construire de la qualité intrinsèque Résoudre les problèmes Décider le plus tard possible Reporter la décision "Last Responsible Moment" Eliminer les gaspillages Montrer le plus tôt possible Lisser le travail Maîtriser les standards Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 20

21 LEAN, XP, SCRUM, KANBAN LEAN Extreme Programming Pratiques d'ingénierie logicielles SCRUM Framework de développement logiciel KANBAN Système de gestion de flux de production Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 21

22 DES FAÇONS DE FAIRE PLUS OU MOINS NORMATIVES Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 22

23 LES VALEURS DE XP Communication Simplicité Feedback Courage Respect Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 23

24 LES VALEURS DE SCRUM Transparence Inspection Adaptation Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 24

25 ABORDER L'AGILITÉ ET SA MISE EN OEUVRE SHU : Apprendre les fondamentaux HA : Trouver les exceptions, trouver de nouvelles approches RI : Tout redevient permis (on oublie la règle initiale, qui est digérée) Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 25

26 HUM HUM Habituellement A ce moment dans la formation on m'indique que c'est un peu le monde des bisounours l'agile... passons à la pratique a des choses plus concrêtes Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 26

27 DU DÉVELOPPEMENT ITÉRATIF : ATELIER "COIN TOSS" atelier " "COIN TOSS Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 27

28 DU DÉVELOPPEMENT ITÉRATIF Source: The New New Product Development Game, Hirotaka Takeuchi and Ikujiro Nonaka, Harvard Business Review, January Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 28

29 QU'EST CE QU'UNE "BOITE DE TEMPS"? (TIMEBOX) La répétition d'une cadence bien maîtrisée Yesterday weather? daysweather.html Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 29

30 LES TIME BOXES DANS SCRUM Sprint Habituellement entre 2 et 4 semaines. Sprint Planning Meeting Pour 2 à 3 semaines de sprint : généralement 1 journée, dont la moitié pour définir le contenu du sprint, et l'autre moitié pour définir comment les fonctionnalités sélectionnées vont être développées. Sprint review Généralement 4h< (la moitié de la durée du Sprint Planning Meeting). Plutôt 1 à 2h. Sprint retrospective Généralement 4h< (la moitié de la durée du Sprint Planning Meeting). Plutôt 1 à 2h. Daily Scrum 15Mn Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 30

31 WORKSHOP : "OFFING THE OFFSITE CUSTOMER" atelier ffsite" "Offing the o Source : James Shore Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 31

32 MODES DE COMMUNICATION Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 32

33 MISE EN PLACE D'UN PROJET SCRUM Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 33

34 LES ACTEURS SCRUM Pig & Chicken Entre les parties prenantes (stakeholders) et l'équipe Scrum, l'engagement est fondamental différent. Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 34

35 LE "PRODUCT OWNER" Décide des fonctionnalités du produit Décide des dates de disponibilité des versions et de leurs contenus Responsable de la valeur du produit Priorise les fonctionnalités du produit en fonction de leurs valeurs ajoutées, du retour sur investissement, de leurs valeurs Accepte ou rejette les résultats produits par l'équipe Il doit être légitime et avoir assez de pouvoir pour pouvoir trancher quand cela est nécessaire (ce n'est pas un comité, c'est une seule personne) Il doit être disponible et impliqué sur le projet (présence lors du sprint planning meeting, de la démo, de la rétrospective, des daily scrum) Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 35

36 L'ÉQUIPE Généralement entre 5 et 9 membres (3 et 4 c'est bien, mais l'équipe doit être assez autonome (cross functionnality) Hétérogène (elle mêle architecte, développeur, testeur, analystes, graphistes, etc.) Donne son accord aux objectifs de chaque itération Spécifie les résultats à réaliser, elle s'engage et est responsable Fonctionne de manière empirique et a le droit de faire tout ce qu'elle souhaite pour atteindre l'objectif de l'itération Autonome, elle fonctionne en autogestion L'agile pense que nous sommes intelligents Stable Présente les résultats du travail de chaque itération au Product Owner Il s'agit de résultats d'équipe Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 36

37 L'ÉQUIPE inspiré de there was management.html Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 37

38 L'ÉQUIPE : MODÈLE DE TUCKMAN Forming (formation de l'équipe) Découverte et formation de l'équipe, définition des objectifs, Storming Confrontation et affrontement Norming L'équipe apprend à travailler ensemble Performing L'équipe fonctionne comme une unité très performante agile le modele tannenbaum schmidt/ Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 38

39 L'ÉQUIPE : MODÈLE DE TANNENBAUM & SCHMIDT 1. Le manager décide et annonce la décision 2. Le manager décide et vend la décision au groupe 3. Le manager présente la décision avec des idées générales et invite à la réflexion 4. Le manager suggère une décision et invite à la réflexion 5. Le manager présente la situation, écoute les suggestions et décide 6. Le manager présente la situation, défini les contraintes et demande à l équipe de décider 7. Le manager permet à l équipe d identifier le problème, développer les options, décider de la solution. Le manager est informé des contraintes par l équipe. agile le modele tannenbaum schmidt/ Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 39

40 LE "SCRUMMASTER" S'assure que Scrum est bien appliqué S'assure que l'équipe est opérationnelle et productive (et en bonne santé) Facilite la coopération entre les différents acteurs (de l'équipe scrum ou des parties prenantes) S'assure que rien ne gène l'avancée du travail, le cas échéant essaye de trouver la solution pour lever les blocages, obstacles visibles ou invisibles. Réduit au maximum les perturbations extérieures avec l'équipe Scrum Communique avec le management S'assure que la qualité du produit n'est jamais remise en cause Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 40

41 ATELIER : "PRUNE THE TREE" atelier ee" " P r u n e th e tr Source : the product tree/ Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 41

42 DÉLIVRER DE LA VALEUR La force de Scrum et de l'agile est de délivrer d'abord et avant toute chose ce qui a le plus de valeur (retour sur investissement). Cette valeur peut être dans certains cas estimée (en monnaie). Le Product Owner définit dans un premier temps une vision, une épopée concernant le produit. Puis il décline features/thèmes, cas d'utilisation ou histoires d'utilisateurs (User Story). r Brainsto ming s uvelle o n e n u ur version Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 42

43 DÉFINITION DU BESOIN Source : Mountain Goat Software ADP09 Introduction to User Stories.pdf Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 43

44 ATELIER : "OPEN ENDED SPECIFICATIONS" atelier ations" ic if c e p s d e d "O p en en Source : The power of open ended requirements Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 44

45 ITERATING VERSUS INCREMENTING Source : Jeff Patton Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 45

46 USER STORIES Les histoires utilisateurs (user story) ne sont pas des cas d'utilisations (use case) «Une user story (histoire utilisateur) est une exigence logicielle formulée en une ou plusieurs phrases dans le langage de tous les jours ou celui lié au métier de l utilisateur. Les user stories sont utilisées dans le développement logiciel dit Agile comme spécifications (en même temps que les tests d acceptance). Le formalisme est limité à un carte de type post it.» (wikipedia) Les User Story encouragent à ne pas entrer dans le détail tant que cela n'est pas nécessaire. Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 46

47 USER STORIES Ron Jeffries propose une règle des 3C pour gérer les User Story Card L'histoire est écrite sur une carte de taille assez réduite. Ces fiches peuvent être annotées (estimation, etc.) Conversation Les détails de l'histoire seront exprimés lors de conversation avec le Product Owner Confirmation Des tests d'acceptation sont consignés avec l'histoire pour valider qu'elle a été réalisée correctement. Source : Ron Jeffries Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 47

48 USER STORIES Une User Story se base sur la syntaxe suivante : En tant que <rôle>, je peux <besoin> de façon à <bénéfice> Une bonne user story sera : compacte, testable, estimable, portera de la valeur, négociable, indépendante. Elle sera comprise par toute la population qui gravite autour et dans le projet Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 48

49 USER STORIES : L'ACRONYME "INVEST" I N V E S T Independant (indépendante) Negotiable(négotiable) Valuable (avec de la valeur) Estimable Sized to fit (assez petite) Testable Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 49

50 USER STORIES Source : Mountain Goat Software ADP09 Introduction to User Stories.pdf Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 50

51 USER STORIES Lors des conversations autour des «User Story», celles ci pourront être redéfinies en Story plus fines. Source : Mountain Goat Software ADP09 Introduction to User Stories.pdf Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 51

52 USER STORIES Découper les user stories : Workflow steps (par étape) Business rule variations (par règle métiers) Major effort (par taille d'effort) Simple / Complex (approche du simple au complexe) Variations in data (variations dans les données) Data entry methods (façon d'intégrer les données) Defer performance (retarde la question des performances) Operations (CRUD) (par opérations) Break out a spike (analyser une piste) Source : for splitting user stories/ Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 52

53 USER STORIES & TESTS D'ACCEPTATION Lors des conversations autour des «User Story» il faudra préciser les tests d'acceptation qui permettront de valider en partie que la Story a bien été réalisée Source : Mountain Goat Software ADP09 Introduction to User Stories.pdf Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 53

54 ECRIRE LES ATDD AVEC DU GHERKIN Le Gherkin est un langage très simple pour formaliser et unifier l'écriture de vos tests d'acceptation. D'autant qu'il pourra à terme être utilisé par des outils qui vont permettre d'automatiser ces tests, ou du moins fournir facilement une enveloppe de tests (specflow, cucumber, jbehave, etc.) Etant donné la page d 'accueil du site avec u n bouton «enregistrez Quand je clique sur le vous» bouton «enregistrez vo u s» Alors j'arrive sur le form ulaire d'enregistremen t Etant donné le formula ire d'enregistrement Quand je m'enregistre Alors je reçois un ema il de demande de con firmation Et cet contient u n lien de confirmation Etant donné un lie n dynamique sur une page de con d'enregistrement firmation Quand j'accède à la p age mon enregistreme nt est confirmé Alors je reçois un ema il de confirmation d'en registrement Et je peux désormais me connecter au site Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 54

55 USER STORIES & PERSONAS Il est souvent bienvenu de définir et de discuter des rôles (on dit des "personas" / personnages) du projet. Certains poussent le «vice» à les nommer, fabriquer des photos, décrire leur caractère. L'utilisateur devient réel : on commence à concevoir le produit comme une réponse à un vrai besoin, à une vraie nécessité. Pour cela ne dites donc plus systématiquement «l'utilisateur» mais le «responsable des ventes», «la personne qui voyage beaucoup», etc. Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 55

56 USER STORIES & PERSONAS Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 56

57 DÉFINITION DU BESOIN : LE PRODUCT BACKLOG La liste de tous les besoins exprimés que le Projet a pour cible Une rencontre entre les besoins métiers et le point de vue technique Exprimé de façon à mettre en évidence la valeur apportée par chaque composant (User Story) Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 57

58 PRODUCT BACKLOG ICEBERG Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 58

59 PRODUCT BACKLOG Priorisé par le Product Owner, repriorisé en début de chaque sprint, ou à tout moment Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 59

60 ATELIER : DÉFINIR UN BACKLOG atelier Backlog Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 60

61 NOTION DE "FINI" / DONE Cette notion a pour objectif de fixer le niveau de qualité attendu, et ce dans tous les cas de figure. C'est une condition pour dire qu'une user story est finie. Cette notion doit être partagée et connue de tous (au mieux on l'affiche sur les radiateurs d'informations!) Généralement elle est partagée (au moins un tronc commun) entre les différents projets, au niveau de l'entreprise Cette notion est très liée à la notion de test (unitaire et d'acceptation) mais il faut la traiter de façon verticale : pas uniquement le côté code, ou architecture, ou ergonomique, etc. La notion de «done» implique plusieurs couches : technique, métiers, IHM, documentation, etc Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 61

62 NOTION DE "FINI" / DONE Définissez les rôles d'un projet Quelle serait la notion de «fini» pour chacun de ces rôles? Quelle serait la notion de «fini» sur le projet Scrum de cette équipe? Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 62

63 PRATIQUES DU DEV. ITÉRATIF : LES ITÉRATIONS OU SPRINTS On parlera de Sprint ou d'itération Il dure entre 2 semaines ou 1 mois selon les équipes, mais sa durée ne varie plus dans un même projet. Une durée de 2 semaines facilite la prise en main de Scrum car elle donne de la visibilité à intervalle resserré. Il faut décomposer les tâches de façon à ce qu'elles durent un jour maximum pour assurer de la visibilité sur l'avancement Si en cours de Sprint l'équipe souhaite changer la priorité (sortir une story, en intégrer une nouvelle en provenance du Product Backlog) c'est toujours le Product Owner qui aura le dernier mot Concernant le Sprint Backlog c'est l'équipe qui s'auto organise Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 63

64 LE SPRINT PLANNING Le Sprint Planning permet de définir le Sprint Backlog Le Sprint Backlog est un sous ensemble du Product Backlog Le Sprint Backlog correspond à un accord mutuel entre le Product Owner et l'équipe mais c'est le Product Owner qui a le dernier mot. Le Sprint Planning se découpe en deux étapes Définition du contenu du Sprint (quoi?) Estimation et découpage en tâches du contenu du Sprint (comment?) Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 64

65 LE SPRINT PLANNING : QUOI? En fonction de la dernière revue de sprint, de la dernière rétrospective, d'autres informations, le ScrumMaster aura pris soin de sensibiliser le Product Owner à valider ou à re prioriser le Product Backlog avant cette réunion Le Product Owner présente le Product Backlog à l'équipe L'équipe estime quelles «user story» (dans l'ordre des priorités) elle est susceptible d'intégrer (la vélocité est une indication forte). Elle s'engagera là dessus L'équipe peut proposer et justifier un ordonnancement du Product Backlog différent mais c'est le Product Owner qui aura le dernier mot. On peut dans cette phase estimer les User Story qui ne le sont pas encore (on va travailler généralement sur 60/70% du Product Backlog) On n'assigne jamais une User Story à l'équipe, c'est l'équipe qui définit son propre potentiel et qui s'auto organisera quand à l'affectation des tâches Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 65

66 LE SPRINT PLANNING : QUOI? Objectif Cette première partie de «Sprint Planning» est aussi le moment où l'on défini le but du Sprint, son Leitmotiv, son objectif, sa cible. Par exemple : «Mise en œuvre du système de réservation en ligne des croisières» ou «Réalisation des échanges entre le site web et l'erp concernant les réservations en lignes» Cet objectif doit être l'élément indispensable à atteindre pour que l'on puisse considérer que le sprint est une réussite. Si des arbitrages doivent avoir lieu durant le Sprint, c'est souvent l'objectif du print qui permettra de faire pencher la balance. Engagement La fin de cette première partie de Sprint Planning se conclue avec l'engagement de l'équipe sur un périmètre. Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 66

67 LE SPRINT PLANNING : COMMENT? La seconde partie du Sprint Planning consiste à découper les User Story en tâches. Il est nécessaire de discuter du contenu de chaque Story et de l'intérêt de chaque tâche Il ne faut pas oublier les tâches de spécifications, de documentation, de test, etc. Tout ce qui est nécessaire pour la Story soit achevée convenablement (voir la notion de «done» (fini)). On peut ajouter des tâches sans Story (bugs, etc.) mais essayez plutôt d'ajouter des Story de type «process» ou «system» (afin que la vélocité reste au plus juste) Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 67

68 LE SPRINT PLANNING : COMMENT? Les tâches sont estimées (ou pas) en heures selon la maturité de l'équipe (on peut se passer de l'estimation). On peut aussi estimer les tâches en point (avec un nouveau planning poker, mais c'est relativement rare et très chronophage) L'estimation d'une tâche en heure ne devrait pas dépasser 1 jour de façon à pouvoir rapidement détecter les dérives le cas échéant Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 68

69 ITÉRATION : FIN EXCEPTIONNELLE? DE STABILISATION? SPRINT 0? Le Sprint peut être annulé Il n'a plus de valeur! Il est impossible de le réussir Seul le Product Owner peut annoncer l'annulation et la fin du Sprint (mais l'équipe ou le management peuvent essayer de le convaincre) Les «user stories» estimées «finies» sont auditées Tous les «user stories» non achevées sont replacées dans le Product Backlog Existe des «sprint de stabilisation»? Qu'est ce qu'un Sprint 0? Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 69

70 PRATIQUES D'ESTIMATION L'estimation est collective, c'est l'équipe qui la réalise mais en conversant avec le Product Owner et le Scrummaster L'estimation est exprimée en «story point» à partir d'un planning poker, soit exprimés en «jour idéaux». Je préconise le planning poker car toute notion de durée (jour) vient troubler la réflexion. Des fois on utilise même des «points animaux» ou des tailles de tee shirt... L'estimation est relative : une «story» par rapport aux autres (triangulation) Attention de bien prendre en compte tout ce qui a été prévu par «done» En fonction de l'estimation réalisée sur des story il se peut que le Product Owner re priorise son Product Backlog Estimation de la complexité, de la durée des tâches à accomplir, de la prise de risque, etc. Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 70

71 PRATIQUES D'ESTIMATION Point de Story Mesure un effort Relatifs jamais absolus Difficile à faire comprendre au management Jours idéaux Mesure une durée Devraient être relatifs les jours ideaux : à ne pas utiliser! juste un rappel historique. Plus aisés à expliquer aux personnes externes On les raccroche trop à une notion de calendrier Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 71

72 LE "PLANNING POKER" Chaque personne possède un jeu de planning poker Le Product Owner décrit la Story devant être estimée On discute de la story Tout le monde propose sa mise simultanément Si toutes les estimations convergent, c'est ok Si les estimations ne convergent pas, les discussions reprennent, notamment entre les deux personnes ayant les plus grands écarts de point. Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 72

73 LE "PLANNING POKER" Ca marche Car ceux sont les gens qui réaliseront la tâche qui l'estiment! Le planning poker nécessite que l'on justifie les points que l'on attribue Propose un étalonnage assez réduit qui limite les erreurs (si une Story est trop grosse, on la découpe en plusieurs Story) Les valeurs sont relatives Les valeurs sont pré définies (on ne chipote pas...) Tout le monde a son mot à dire (parmi l'équipe) C'est rigolo Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 73

74 UNE ALTERNATIVE LE "WALL PLANNING POKER" On positionne les stories par comparaison en colonne sur un mur On affecte les points ensuite C'est très rapide et on oubli toute valeur numérique! Mais l'investissement n'est pas forcément égal entre tous les participants Ma recommandation : faire des wall planning poker hors des sprints planning pour faire des estimations assez loin dans le temps ou initier un projet, utiliser le planning poker lors des sprint planning. Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 74

75 ATELIER : PLANNING POKER ET WALL PLANNING POKER ateliers ker Planning Po g P o ker Wall Plannin Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 75

76 PRATIQUE DE PLANIFICATION : LA "VÉLOCITÉ" Est calculée à la fin du sprint (itération) C'est la somme des points des «Story» qui ont été acceptées pour la démo La régularité de la courbe de la vélocity est signe du respect de la qualité, ou de la stabilité de l'environnement (et la stabilité de l'environnement mène au respect de la qualité) Si on décide de rompre avec la qualité pour améliorer la vélocité (fin des tests, etc.) on va améliorer celle ci temporairement puis décliner vers un «noyau foutu». C'est la notion de dette technique. Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 76

77 PLANIFICATION DE RELEASES Une version de produit à une «release» et à un product backlog Une «release» contient plusieurs sprints (itérations) Chaque sprint possède une vélocité La vélocité est une valeur (non relative à une durée comme jour ou heure) que l'on déduit en additionnant la vélocité de chaque story (nous verrons comment nous calculons la vélocité plus loin) Chaque sprint est «time boxé» (disons 3 semaines) L'équipe est sensée être pérenne et donc la vélocité devrait donc peu ou proue rester la même par sprint Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 77

78 PLANIFICATION DE RELEASES Source : Mountain Goat Software Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 78

79 PLANIFICATION DE RELEASES On sait donc calculer le nombre de sprints nécessaires pour atteindre la fin de la release. La fin de la release cela peut être Le Product Backlog est vide (rarement le cas...) Une date prédéfinie La fin du budget Assez de valeur produite Etc. Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 79

80 PLANIFICATION DE RELEASES Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 80

81 PLANIFICATION DE RELEASES Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 81

82 RELEASE PLANIFICATION Source : Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 82

83 ATELIER : "MARSHMALLOW CHALLENGE" atelier allenge" h c w o ll a m h " Ma r s Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 83

84 RADIATEURS D'INFORMATION Ils permettent de suivre de façon collective, interactive, et simple l'avancée du sprint, et du projet Ils engagent et motivent l'équipe La mise à jour est quasi en temps réel Ils doivent être visibles par tous (autant par l'équipe que par les parties prenantes). Toutes les informations clefs sont rassemblées en un seul lieu Ps : attention aux coups de vent, aux ménages le soir, aux post it défectueux que l'on retrouve au sol... Astuce : prendre en photo le radiateur au jour le jour Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 84

85 RADIATEURS D'INFORMATION Source : SCRUM & XP FROM THE TRENCHES Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 85

86 RADIATEURS D'INFORMATION Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 86

87 BURNDOWN CHARTS Les burndown charts montrent l'avancement du projet Il existe 2 types de burndown chart : celui de la release, celui du sprint Celui de la release se base sur les points de story Celui du sprint peut se baser : Sur les heures Sur les points affectés aux tâches Sur le nb de tâches restantes L'avancée du projet est collective Les burndown charts doivent être visibles par tous (autant par l'équipe que par les parties prenantes). Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 87

88 BURNDOWN CHARTS Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 88

89 BURNDOWN & BURNUP CHARTS Un burndown de points tâches et un burnup de points "story" qui se croisent. Une bonne pratique. Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 89

90 BURNDOWN CHARTS Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 90

91 PRATIQUE QUOTIDIENNE : LE "DAILY SCRUM" Il dure ~ 15 mn, il a lieu tous les jours, tout le monde est débout (standup meeting), chacun y répond à 3 questions Qu'est ce que tu as réalisé hier? Quelles sont tes tâches aujourd'hui? Est ce que quelque chose te gène dans la réalisation de tes tâches? Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 91

92 PRATIQUE QUOTIDIENNE : LE "DAILY SCRUM" Ou "Daily Standup" Il donne de la visibilité à toute l'équipe sur l'ensemble des travaux à intervalles réguliers Il devrait se dérouler systématiquement à la même heure et dans le même lieu C'est l'outil de l'équipe, le ScrumMaster, le Product Owner sont optionnels. Le ScrumMaster doit cependant s'assurer que le Daily Scrum se déroule comme convenu mais il doit se faire discret lors du StandUp. Le Product Owner peut profiter de ce moment pour suivre l'avancement du projet. Les parties prenantes peuvent assister mais ne doivent pas intervenir. Seuls les membres de l'équipe peuvent parler. Il faut trouver un lieu tranquille mais proche des «radiateurs d'informations» Le Daily Scrum se déroule impérativement debout. Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 92

93 PRATIQUE QUOTIDIENNE : LE "DAILY SCRUM" Il améliore la communication et permet d'éviter d'autres réunions (mais son sujet ne doit pas dévier). Chacun doit s'exprimer brièvement car le Daily Scrum est «Timeboxé» à 15mn. Attention de ne pas dévier sur des conversations annexes (règlement d'un point technique complexe, modification des priorités, etc.), ni de régler lors du point les problèmes, il s'agit de les repérer pour les régler ultérieurement. Chacun s'engage, car l'équipe est responsable. On ne fait pas de compte rendu au Product Owner ou au ScrumMaster (d'ailleurs ces deux rôles ne sont peut être pas présents) Ce n'est pas non plus le lieu des règlements de compte (l'équipe doit comprendre qu'elle doit s'unir pour réussir) Par moment quand un Daily Scrum dérape le ScrumMaster peut se tourner face au mur et appuyant ses mains contre celui ci («spread eagle») pour indiquer que ce qui se déroule est inutile et n'est pas le but du Daily Scrum. Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 93

94 ATELIER : "SCRUM FROM HELL" atelier Hell" " S c r u m fr o m Source : Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 94

95 REVUE DE SPRINT On présente le résultat du Sprint (toutes les User Story achevées) C'est le moment durant lequel le Product Owner et les parties prenantes (stakeholders) inspectent le produit en détails en fonction de l'objectif du Sprint et la vision du produit et prennent les décisions d'adaptation nécessaires à la réussite de l'objectif du projet. Il peut y avoir de nombreux invités à cette occasion Il faut préparer la réunion (scénariser) et rappeler les objectifs du Sprint en premier lieu A la fin de la démo on peut calculer la vélocité effective du Sprint et donc réajuster le plan de release A la fin de la démo le Product Backlog est actualisé (User Story achevées, nouvelles User Story émergentes, anomalies, etc.) Les BurndownChart sont réinitialisés ou remis à jour Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 95

96 RÉTROSPECTIVE Elle est là pour améliorer les processus (identifier les axes d'amélioration, capitaliser sur les bonnes pratiques), faire un état des lieux du sprint qui vient de s'achever Comment améliorer les choses? Qu'est ce qui a bien fonctionné? Qu'est ce qui a mal fonctionné? Comment résoudre les problèmes que nous voyons apparaître? Il faut préparer une rétrospective (la préparation peut durer aussi longtemps que la rétrospective elle même) C'est le ScrumMaster qui va faciliter et organiser cette réunion C'est le ScrumMaster qui devrait savoir si une amélioration est réellement nécessaire ou pas, il ne va pas choisir mais il sera un arbitre déterminant. A la fin de la rétrospective on a un plan d'action Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 96

97 ATELIER : "RETROSPECTIVE : SPEED BOAT" atelier b o at d e e p s & e iv R é tr o s p e c t Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 97

98 LES 5 POURQUOI L'obstacle n'est pas toujours celui que l'on croit : Concept des 5 pourquoi Le «Washington Monument» s'érode et la firme responsable du ciment ne réussit pas à en trouver la cause («root cause analysis»). Pourquoi le bâtiment se désagrège t il? Parce que l'on y applique trop de produits chimiques Pourquoi applique t on trop de produits chimiques? Pour nettoyer les crottes de pigeons! Pourquoi y a t il autant de pigeons? Car ils mangent les insectes sur le bâtiment! Pourquoi y a t il autant d'insectes? A cause de la lumière! Solution : Réduire les horaires d'éclairages du Monument... Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 98

99 QUELQUES QUESTIONS Faites 2 groupes et travaillez chacun sur ces deux sujets avec l'aide des "5 pourquoi", observons les résultats Il y a souvent trop de recettes à réaliser à la fin de chaque sprint! Le product owner n'est pas assez présent avec l'équipe! Le daily stand up n'est jamais achevé! Il n'y a pas assez de développeurs/testeurs dans l'équipe! On dépend trop de développeurs externes à l'équipe! On travaille sur trop de projets! Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 99

100 PRATIQUES D'INGENIERIE : EXTREME PROGRAMMING Scrum et XP devraient dans la pluspart des projets informatiques être indissociables Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 100

101 DETTE TECHNIQUE Astérix chez les hélvètes, Uderzo & Goscinny Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 101

102 DETTE TECHNIQUE Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 102

103 FEEDBACK : COÛT DU CHANGEMENT Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 103

104 FEEDBACK, FEEDBACK Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 104

105 SIMPLICITÉ La complexité ne doit pas s imposer Le Mythe de l ultra générique Optimisations de performance inutiles Etc. C est la simplicité qui doit s imposer pas la facilité! Différence : la qualité n est pas négociable! Mais On favorise l émergence Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 105

106 SIMPLICITÉ YAGNI You ain't gonna need it KISS Keep it simple stupid DRY Don t repeat yourself Fail Fast Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 106

107 COURAGE & RESPECT Quel niveau de confiance j accorde à mes partenaires? De 1 à 5 1 : je n ai aucune confiance 5 : j ai une confiance aveugle Comment je juge le niveau de confiance que m accordent mes partenaires? A quel point suis je à l aise pour parler à mes partenaires des problèmes et points de blocage que je rencontre? Vous êtes Scrummaster l'un des membres de l'équipe vient voir pour expliquer qu'il ne supporte plus une personne de l'équipe pour telle ou telle raison, quel serait votre positionnement? Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 107

108 FOCUS SUR DES PRATIQUES : PAIR PROGRAMMING Idées reçues Les managers voient cela comme une perte de temps Les développeurs ont été éduqués pour travailler de façon isolée Certains Senior pensent que travailler ainsi va les ralentir, ou que cela va compliquer les choses Mais il apparaît que : Cela facilite le transfert de connaissance (sans que chacun perde sa spécialité) La qualité du code est drastiquement améliorée (c'est la meilleure revue possible) : beaucoup d'anomalies pernicieuses chronophages détectées ensuite les débutants sont incorporés sans problème La productivité est a minimum égale, souvent meilleure Les gens ont plaisir à faire du pair programming Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 108

109 FOCUS SUR DES PRATIQUES : TESTS AUTOMATISÉS Un développement est moderne et mature si il automatise ses tests Permet d'avoir des garanties sur la qualité du code Permet aux développeurs de se partager le code sans risque, sans crainte Les tests peuvent servir de documentation Erèirra ne recnava Test Driven Development Définir l'object Ecrire le test et le faire échouer Ecrire le code Le test fonctionne Le TDD propose une alliance entre les deux éléments pour lesquels on observe le plus de réticence sur le terrain de la part des développeurs conceptualiser et découper son développement faire des tests Un exemple de Test Driven Development proposé par pytddmon Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 109

110 FOCUS SUR DES PRATIQUES : REFACTORING Extreme Programming Explained, embrace change, Kent Beck Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 110

111 FOCUS SUR DES PRATIQUES : REFACTORING Refactoriser c'est changer un logiciel de façon à ce que comportement ne varie pas mais que sa structure interne soit meilleure On ne décide pas de refactoriser, c'est un travail sous jacent, constant. Penser le code comme devant/pouvant être revisé Ne pas développer des choses inutiles Ne pas développer des choses trop complexes L'un des objectifs du refactoring est de rendre le code plus lisible, plus compréhensible, plus abordable pour le développeur suivant Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 111

112 FOCUS SUR DES PRATIQUES : REFACTORING Modularisez! void printowing(double amount) { printbanner() } //print details WriteLine("name:" + _name) WriteLine("amount" + amount) Inline Method, Replace method with method object Hide delegate etc.. void printowing(double amount) { printbanner() printdetails(amount) } void printdetails(double amount) { WriteLine("name:" + _name) WriteLine("amount" + amount) } "Refactoring Tips by Martin Fowlers", Igor Crvenov Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 112

113 FOCUS SUR DES PRATIQUES : REFACTORING Quand refactoriser? Quand vous ajoutez une fonction Quand vous corrigez une anomalie Quand vous faîtes une revue de code... Et avant de refactoriser il faut une solide suite de tests pour ne pas introduire d'anomalies Quand ne pas refactoriser? Quand le code est dans un trop mauvais état et qu'il faut tout reprendre Quand une deadline approche et que l'effort de refactorisation n'a plus assez de valeur "Refactoring Tips by Martin Fowlers", Igor Crvenov Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 113

114 FOCUS SUR DES PRATIQUES : INTÉGRATION CONTINUE Quelques règles : n 1 : la première des priorités est de réparer le build cassé Pas de fatalité! Rigueur! Exécution toutes les nuits! A chaque commit de code!! Attention à la lenteur du build!!! Gestion des versions avec des équipes multiples version control Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 114

115 FOCUS SUR DES PRATIQUES : INTÉGRATION CONTINUE Il est nécessaire de déployer une plate forme d'intégration continue de type Jenkins/Hudson, Sonar, TFS, etc. Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 115

116 FOCUS SUR DES PRATIQUES : INTÉGRATION CONTINUE Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 116

117 ATELIER "XP GAME" atelier "X P G am e" Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 117

118 UNE MARQUE DE MATURITÉ? KANBAN David Anderson : "Scrum ne règle pas tous les problèmes, ni ne s'applique dans toutes les situations" (est ce vrai?) Peut on faire du scrum avec la "Care & Maintenance"? Le support? Le HelpDesk? Gestion des services IT? Lié à "DevOps"? Pour embrasser l'intégralité de ce qui est réalisé? Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 118

119 KANBAN Visualiser le flux Limiter le travail en cours (Work in Progress) Gérer le flux Focus sur la qualité Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 119

120 ht t p: / MISE EN OEUVRE DE KANBAN / blog. e/ hen s crisp. r i kkn i b e rg / 2009 / 04/ 0 3/ ht ml Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 120

121 MISE EN OEUVRE DE KANBAN Apprenez à connaitre votre système Identifiez et priorisez vos sources Définissez votre processus Concevez votre tableau de flux Définissez les limites Décidez des rôles Décidez des réunions aimetti.fr/dotclear/public/traductions/demarrer en kanban.pdf Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 121

122 RÉUNIONS POUR KANBAN Réunion de définition, d'expression du besoin Réunion quotidienne Réunion d'apprentissage, d'amélioration continue et d'analyse du feedback aimetti.fr/dotclear/public/traductions/demarrer en kanban.pdf Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 122

123 VISUALISER LE FLUX cumulative flow diagrams cfd Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 123

124 VISUALISER LE FLUX Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 124

125 VISUALISER LE FLUX Trop de travail à faire signifie probablement : vous ne finissez pas ce qui est engagé une étape ultérieure ne peut pas intégrer votre travail Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 125

126 flow diagrams/ VISUALISER LE FLUX Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 126

127 VISUALISER LE FLUX Mieux! cumulative flow diagrams cfd Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 127

128 VISUALISER LE FLUX : DÉFINITION DE CLASSE DE SERVICE anderson kanban at q con Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 128

129 QUELQUES DÉBATS SUR KANBAN Points de vigilance Kanban est il "people friendly"? Kanban permet il un véritable changement? N'est il pas trop statique, trop conforme? Kanban est il Scrum sans itération? Faut il avoir fait du scrum avant de passer à Kanban? Est ce que les estimations sont une perte de temps? David Anderson décrit Kanban comme "proposant un changement évolutif plutôt qu'une révolution (comme agile)" Software Enginering Radio, Podcast, Francfort, Germany anderson kanban at q con Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 129

130 ATELIER : KANBAN GAME atelier me" "K an b an G a Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 130

131 TRANSITION AGILE EN ENTREPRISE : ADAPT Awareness Desir Ability Promotion Transfer L'agile est avant tout un processus de conduite du changement Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 131

132 MANAGEMENT & CONDUITE DU CHANGEMENT En introduisant Scrum dans votre société vous allez bousculer les habitudes, provoquer le changement, attention d'être attentif aux facteurs bloquants Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 132

133 GÉRER LE CHANGEMENT L'agile, surtout Scrum, va mettre en évidence les problèmes et les dysfonctionnement. Il joue le rôle d'un révélateur. Il devient donc aussi une cible idéale. A chaque fois que vous abandonnez ou détournez une pratique Scrum pour vous conformer à l'entreprise (ou pour faciliter son adoption) vous perdez de la valeur (vous devenez des «ScrumBut») Il faut donc l'éviter autant que possible C'est toujours le signe d'une défaillance de fonctionnement de l'entreprise et autant s'attaquer à la source Ken Schwaber estime que seulement 35% des entreprises qui essayent Scrum réussissent. Pourquoi les autres échouent? Car elles refusent de régler les problèmes que Scrum rend visibles. Cependant Un bon ScrumMaster est un ScrumMaster vivant, un ScrumMaster mort Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 133

134 GÉRER LE CHANGEMENT : MOTIVATION C'est toujours plus simple de démarrer avec un nouveau projet (que de reprendre un projet avec des millions de lignes de code et une base clients énorme) Scrum apporte motivation et implication à l'équipe (si ce n'est pas le cas cela le ScrumMaster devrait s'alerter) Se réferer à l'étude : Enquête Nationale Méthodes Agiles Juin Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 134

135 GÉRER LE CHANGEMENT : DIFFICULTÉ Se réferer à l'étude : Enquête Nationale Méthodes Agiles Juin Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 135

136 FACE AU STRESS Dès que le stress va monter les bonnes pratiques et les bonnes volontés vont disparaître et les mauvaises habitudes revenir au galop Dans des phases de stress vous devez être attentif à ne pas : Retomber dans un schéma de type Waterfall Retomber dans un schéma de type «commande et contrôle» (rappelez vous l'équipe est autonome et autogérée). Se voiler la face et dire oui à ce qui est impossible à réaliser dans les conditions proposées (durée, équipe, etc.) Cacher la réalité en se disant que cela va se résoudre La qualité ne doit jamais être remise en cause («j'arrête la documentation», «j'arrête les tests pour gagner du temps»). Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 136

137 GÉRER LE CHANGEMENT Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 137

138 GÉRER LE CHANGEMENT Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 138

139 CONTRACTUALISATION Scrum fonctionne généralement avec des contrats de type «régie» (time & material) La difficulté est d'adapter les habitudes françaises du mode de contractualisation au forfait (fixed price) à la souplesse proposée par Scrum. C'est encore plus dur avec les appels d'offres publics C'est souvent un risque que l'organisation décide de prendre (de gérer le forfait avec SCRUM) Mode dégradé : sans pouvoir se permettre de modifier le périmètre mais en exploitant la priorisation, les rétrospectives fréquentent auprès du client Mode très dégradé : uniquement la partie réalisation sans nécessairement que le client soit au courant (mais ce n'est plus vraiment du Scrum) Le point de vue du juriste associes.com/fr/page methodes agiles.html Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 139

140 CONTRACTUALISATION : CONTRAT AVEC CHANGEMENT GRATUIT Jeff Sutherland, l'un des pères de Scrum, propose le concept de «changement gratuit» On définit un contrat avec un périmètre et un prix fixe (forfait / fixed price). On propose une enveloppe supplémentaire en mode régie (time & material) qui sera déclenchée si la clause de changement gratuit échoue. On introduit une clause de changement gratuit Pour que cette clause soit valide le client doit s'engager à travailler avec l'équipe Scrum (Product Owner ou autres). Si il ne respecte pas cette clause l'enveloppe supplémentaire sera utilisée en cas de variation. Si il respecte cette règle le client peut effectuer des changements dans le périmètre : Le changement des priorités est possible Il peut enlever des «features» et en ajouter de nouvelles (estimation égale) à la fin de chaque sprint. Source : For Nothing And Your Changes For Free (Jeff Sutherland) Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 140

141 MONEY FOR NOTHING Source : For Nothing And Your Changes For Free (Jeff Sutherland) Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 141

142 LE PROJET PILOTE? Source : Mountain Goat Software attributes of the ideal pilot project «Don t start with an initial learning project that is of marginal importance. Start on a project that is absolutely critical to your company otherwise it will be too difficult to implement all the hard things Scrum will ask of you». Jim Highsmith, Agile Software Development Ecosystems. Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 142

143 MANAGEMENT AGILE Acteur du changement, initiateur, constructeur de l'organisation Mène les questions de recrutement et de rétribution. Fournit les ressources. Responsable des Product Owner (Donne son avis au Product Owner concernant la stratégie et la vision du produit, et donne son avis au Product Owner sur l'organisation et l'orientation du Product Backlog) Vient aider les équipes pour supprimer les obstacles qui pourraient les gêner. Aide les ScrumMasters à protéger les équipes des perturbations extérieures Il aide l'équipe si elle a un besoin ponctuel (support technique) Coordinateur (entre différentes strates de la société) Source : Le rôle du manager dans Scrum, Agile Gathering 2007 Traduit par Fabrice Aimetti aimetti.fr/dotclear/public/mes documents/role des Managers En Scrum.pdf Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 143

144 MANAGEMENT AGILE «the Team will not begin to self organize until everyone outside the Team stops micromanaging them." Pete Deemer, Manager 2.0: The Role of the Manager in Scrum manager the role of the manager in scrum Il ne doit plus y avoir de vision «top / down». Le manager doit constamment rappeler à l'équipe qu'elle est le responsable (chassez la naturel il revient au galop! Le «muscle memory» de Ken Schwaber) Le manager est plus un «mentor» qu'une «nounou». La gestion des individualités a disparu. Il faut revoir le plan de commissionnement au niveau de l'équipe et du projet! Source : Le rôle du manager dans Scrum, Agile Gathering 2007 Traduit par Fabrice Aimetti aimetti.fr/dotclear/public/mes documents/role des Managers En Scrum.pdf Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 144

145 ATELIER "LEADERSHIP" atelier " "Leadership Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 145

146 RESPONSABILITÉ Christopher Avery Responsability Process process Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 146

147 SCALABILITÉ : SCRUM DE SCRUM Permet de répondre aux problématiques des projets avec plusieurs équipes. Chaque jour après le Daily Scrum le représentant de chaque équipe s'assemble pour un «scrum de scrum». Cela fonctionne comme un daily scrum mais avec un niveau d'analyse différent : qu'a fait l'équipe, que fait elle aujourd'hui, quels problèmes rencontre t elle? (Mike Cohn suggère des meetings moins fréquents mais plus long) Le risque est que le représentant de chaque équipe ne soit pas en mesure de bien décrire l'activité de son équipe (mémoire, précision, etc.) Ken Schwaber préconise l'obligation à toutes les équipes de fournir un résultat lors des revues de sprint et de l'intégrer de façon à ce que le Product Owner puisse valider convenablement le résultat. L'idée derrière les scrums de scrum est de décentraliser chaque unité de productivité de façon à ce qu'elle s'auto organise. Mais de recomposer une action globale au travers de la méthode agile : inspection, adaptation, transparence. Source : ken Schwaber, Mike Cohn evolution and importance of the scrum of scrums/ Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 147

148 SCALABILITÉ : SCRUM DE SCRUM Source : Mountain Goat Software Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 148

149 PRODUCT OWNER DANS L'ENTREPRISE Comme les "scrum de scrums", les product owners peuvent se synchroniser régulièrement pour aborder les questions de stratégie plus globale. Source :http://www.romanpichler.com/blog/roles/scaling the product owner/ Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 149

150 PRODUCT OWNER DANS L'ENTREPRISE Source :http://www.romanpichler.com/blog/roles/scaling the product owner/ Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 150

151 QUELQUES RAPPELS : SCRUM MIND MAP aimetti.fr/dotclear/index.php?post/2009/07/12/small and Funny Scrum Mindmap Droits : / CC BY 2.0 Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 151

152 Source : QUELQUES RAPPELS : XP SUR UNE PAGE Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 152

153 QUELQUES RAPPELS : POINTS DE VIGILANCE Stabilité de l'équipe Protection de l'équipe vis à vis des parties prenantes (stakeholders) Contractualisation Responsabilisation du product owner et de l'équipe de développement Plus de chef de projet mais un ScrumMaster (facilitateur) L'agile est simple à appréhender mais il n'est pas simple à déployer Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 153

154 RESSOURCES : LIENS EN (Tobias Mayer) EN EN vs Scrum.pdf EN EN (Mike Cohn) EN & (Oana Juncu) [Convergences!] (Claude Aubry) FR (Thierry Cros) FR (Jérôme Avoustin) FR [SmartView!] (Ken Schwaber Scrum Google Talk) EN (Bob Marshall) EN EN EN Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 154

155 RESSOURCES : LIENS (Lean from the trenches) (David Anderson) (Martin Fowler) (Brian Marick) (Jim Highsmith) Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 155

156 RESSOURCES : LIVRES Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 156

157 RESSOURCES : LIVRES Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 157

158 RESSOURCES : OUTILS Rappelez vous que rien ne vaut l'interaction, la visibilité, etc. Le mur, les post it, la patafix, les tableaux blancs seront toujours vos meilleurs outils. Les outils agiles devraient utilisés : Pour consolider les informations Pour éventuellement servir au sein d'équipes distribuées Outils Redmine, Trac Icescrum, Kunagi Mingle (Thought works) Rally software, Version One, Pivotal Tracker Jira/Greenhopper (Atlassian) Agile Zen, Kanbanery Creative Commons Attribution ShareAlike 3.0 Unported License Pablo 158

159 QUESTIONS / RÉPONSES PABLO PERNOT SMARTVIEW https://speakerdeck.com/u/pablopernot p e rn o t Ce travail est sous licence : Creative Commons Attribution ShareAlike 3.0 Unported License 3.0 Unported License Pablo 159 Creative Commons Attribution ShareAlike

Yassine ZAKARIA SÉMINAIRE : MÉTHODES AGILES

Yassine ZAKARIA SÉMINAIRE : MÉTHODES AGILES Yassine ZAKARIA SÉMINAIRE : MÉTHODES AGILES Quelques constats Etude du Standish Group Seul 1/3 des projets informatiques sont qualifiés de succès 50 % sont livrés et opérationnels, mais sont sortis du

Plus en détail

Conduite de projets SI. Les méthodes «Agiles» N QUAL/1995/3660e ORESYS

Conduite de projets SI. Les méthodes «Agiles» N QUAL/1995/3660e ORESYS Conduite de projets SI Les méthodes «Agiles» N QUAL/1995/3660e ORESYS Agilité : de quoi parle-t-on? Agilité de l entreprise Urbanisme Architectures SOA Agilité du SI ERP Plateformes applicatives agiles

Plus en détail

Méthodes Agiles et gestion de projets

Méthodes Agiles et gestion de projets Méthodes Agiles et gestion de projets Eric LELEU Consultant Solutions Collaboratives Contact ericleleu@nordnet.fr Site Personnel http://home.nordnet.fr/~ericleleu Blog http://ericleleu.spaces.live.fr La

Plus en détail

Règles d engagement. Présentation Diapositives Bibliographie Questions Les vertus de la marche

Règles d engagement. Présentation Diapositives Bibliographie Questions Les vertus de la marche Règles d engagement Présentation Diapositives Bibliographie Questions Les vertus de la marche Plan Rappels sur l agilité Scrum : une implantation de l agilité Scrum ou XP? Conclusion Historique sélectif

Plus en détail

25/12/2012 www.toubkalit.ma

25/12/2012 www.toubkalit.ma 25/12/2012 www.toubkalit.ma 1 Définition Exemple des méthodes agiles Valeurs Principes Le cycle itératif et incrémental (Itération/Sprint) Schéma de travail Méthode Scrum. Méthode XP (Extreme programming).

Plus en détail

Gestion de projet Agile. STS IRIS Module 4.2 - «Gérer et organiser un projet informatique»

Gestion de projet Agile. STS IRIS Module 4.2 - «Gérer et organiser un projet informatique» Gestion de projet Agile Module 4.2 - «Gérer et organiser un projet informatique» Sommaire Introduction Principes et méthodes Agiles Scrum 2 Introduction Gestion de projet : démarche structurante assurant

Plus en détail

Scrum + Drupal = Julien Dubois

Scrum + Drupal = Julien Dubois Pourquoi j aime Scrum Pourquoi Scrum et Drupal sont faits pour s entendre Scrum + Drupal = Julien Dubois Happyculture.coop De quoi allons-nous parler? 1. Que sont les méthodes agiles? 2. Présentation de

Plus en détail

Scrum Une méthode agile pour vos projets

Scrum Une méthode agile pour vos projets Avant-propos 1. Objectif du livre 17 2. Notre démarche 17 3. Structure du livre 18 4. Remerciements 20 Scrum, une méthode agile avant tout 1. Le grand départ 21 2. La gestion de projet informatique 22

Plus en détail

Topologie du web - Valentin Bourgoin - http://www.valentinbourgoin.net. Méthodes agiles & SCRUM

Topologie du web - Valentin Bourgoin - http://www.valentinbourgoin.net. Méthodes agiles & SCRUM Méthodes agiles & SCRUM 1/ Pourquoi les méthodes agiles? Définition d une méthode agile. Fondamentaux. Quand les utiliser? 2/ SCRUM En quoi est-ce une méthode agile? Sprints et releases. Le Product Owner.

Plus en détail

Scrum - Tour d'horizon de la méthode

Scrum - Tour d'horizon de la méthode Scrum - Tour d'horizon de la méthode Agenda Agilité Scrum Pilotage d'un projet agile selon Scrum Contractualisation Forces & questions ouvertes 2 Les méthodes agiles Méthodes de développement d'applications

Plus en détail

Certification Scrum Master

Certification Scrum Master avec Jeff Sutherland Les méthodes Agiles représentent indéniablement une approche nouvelle et différente dans la conduite de projets. Au lieu de suivre un plan à la lettre en assignant des tâches à une

Plus en détail

Les méthodes Agiles Introduction. Intervenant : Tremeur Balbous tremeur@agilegardener.com http://www.agilegardener.com/ 04/09/2008

Les méthodes Agiles Introduction. Intervenant : Tremeur Balbous tremeur@agilegardener.com http://www.agilegardener.com/ 04/09/2008 Les méthodes Agiles Introduction Intervenant : Tremeur Balbous tremeur@agilegardener.com http://www.agilegardener.com/ 04/09/2008 Les méthodes Agiles Le contexte Le Manifeste Agile Une tentative de définition

Plus en détail

Méthodes de développement

Méthodes de développement 1 / 9 Méthodes de développement Méthodes agiles 1 - Introduction... 2 2 -Le manifeste agile et les méthodes agiles... 2 2.1 Le manifeste agile... 2 2.2 Les méthodes agiles... 3 3 - Caractéristiques communes

Plus en détail

Scrum et l'agilité des équipes de développement

Scrum et l'agilité des équipes de développement NormandyJUG Scrum et l'agilité des équipes de développement Par Dimitri Baeli & Nicolas Giard 23 Février 2010 Présentation des intervenants Dimitri Baeli http://twitter.com/dbaeli VP Quality Enterprise

Plus en détail

Agile 360 Product Owner Scrum Master

Agile 360 Product Owner Scrum Master Agile 360 Product Owner Scrum Master Lead Technique Equipe Agile Conception Agile Leadership Agile Software Craftmanship Test Driven Development Catalogue 2013 Liste des formations Formation Agile 360

Plus en détail

Les mécanismes d'assurance et de contrôle de la qualité dans un

Les mécanismes d'assurance et de contrôle de la qualité dans un Les mécanismes d'assurance et de contrôle de la qualité dans un projet Agile SPIN de Montréal - ETS 5 mars 2012 Qui sommes nous? mathieu boisvert Coach Agile Chargé de cours Co auteur d un livre avec Sylvie

Plus en détail

Les méthodes itératives. Hugues MEUNIER

Les méthodes itératives. Hugues MEUNIER Les méthodes itératives Hugues MEUNIER INTRODUCTION. Toute les méthodes ont le même but : la maîtrise du budget, du planning et de la qualité des projets de développement informatique Plusieurs approches

Plus en détail

Introduction à l Agile (22/01/2012)

Introduction à l Agile (22/01/2012) Introduction à l Agile (22/01/2012) OCTO 2012 50, avenue des Champs-Elysées 75008 Paris - FRANCE Tél : +33 (0)1 58 56 10 00 Fax : +33 (0)1 58 56 10 01 www.octo.com 1 Plan! Qui suis-je?! Quelques notions

Plus en détail

Méthodes agiles. www.businessinteractif.com CONSEIL & DÉVELOPPEMENT DE SOLUTIONS E-BUSINESS. Jean-Louis Bénard jlb@businessinteractif.

Méthodes agiles. www.businessinteractif.com CONSEIL & DÉVELOPPEMENT DE SOLUTIONS E-BUSINESS. Jean-Louis Bénard jlb@businessinteractif. Méthodes agiles www.businessinteractif.com Jean-Louis Bénard jlb@businessinteractif.fr CONSEIL & DÉVELOPPEMENT DE SOLUTIONS E-BUSINESS 0 20 mai 2002 Sommaire Méthodes agiles : une réponse à un malaise?

Plus en détail

backlog du produit Product Owner

backlog du produit Product Owner Méthodes agiles : Définition: selon Scott Ambler «Une méthode agile est une approche itérative et incrémentale pour le développement de logiciel, réalisé de manière très collaborative par des équipes responsabilisées

Plus en détail

AGILITÉ ET PROJETS AVEC SCRUM

AGILITÉ ET PROJETS AVEC SCRUM AGILITÉ ET PROJETS AVEC SCRUM ENSIMAG 2014 Jean-François Jagodzinski @jfjago www.agilessence.fr 1 Jean-François Jagodzinski - Coach Formateur et accompagnateur d équipes agiles Site -> http://www.agilessence.fr

Plus en détail

Christophe Leroy Marc Lainez. L Agilité est-elle soluble dans la culture francophone?

Christophe Leroy Marc Lainez. L Agilité est-elle soluble dans la culture francophone? Christophe Leroy Marc Lainez L Agilité est-elle soluble dans la culture francophone? Le Manifeste Agile http://agilemanifesto.org/ 2 Les 4 valeurs Agiles Equipe Personnes et interactions plutôt que processus

Plus en détail

Utilisation des techniques Kanban pour maîtriser le développement incrémental. Jeff Patton AgileProductDesign.com jpatton@acm.org

Utilisation des techniques Kanban pour maîtriser le développement incrémental. Jeff Patton AgileProductDesign.com jpatton@acm.org Utilisation des techniques Kanban pour maîtriser le développement incrémental Jeff Patton AgileProductDesign.com jpatton@acm.org Téléchargez cette présentation sur : www.agileproductdesign.com/downloads/patton_kanban.ppt

Plus en détail

Agile Maroc 24 Novembre 2010. Méthodes agiles. Thierry Cros. http://etre-agile.com. Agile Maroc 24 novembre 2010

Agile Maroc 24 Novembre 2010. Méthodes agiles. Thierry Cros. http://etre-agile.com. Agile Maroc 24 novembre 2010 Agile Maroc 24 Novembre 2010 Méthodes agiles Thierry Cros 1 Thierry Cros 10 ans déjà... 2010 Création Extreme Programming France 2009 SigmaT Les Agilistes Toulousains 2010 Membre de «Fédération Agile»

Plus en détail

XP : plus qu'agile. Extreme Programming v2 et Développement Responsable. Thierry Cros

XP : plus qu'agile. Extreme Programming v2 et Développement Responsable. Thierry Cros XP : plus qu'agile Extreme Programming v2 et Développement Responsable Thierry Cros Retrouvez cette présentation sur le site http://thierrycros.net Licence CC-BY-NC-SA XP : plus qu'agile Pourquoi XP Installer

Plus en détail

Retour d expérience implémentation Scrum / XP

Retour d expérience implémentation Scrum / XP Retour d expérience implémentation Scrum / XP Bruno Orsier Octobre 2008 p.1 Bruno Orsier, Agile Tour 2008 Grenoble Plan Qui sommes nous? Pourquoi Scrum/XP? Historique de la mise en œuvre Bilan Sondage

Plus en détail

Soyez agile. Dans l industrie du logiciel, la. De plus chaque projet informatique

Soyez agile. Dans l industrie du logiciel, la. De plus chaque projet informatique Soyez agile Dans l industrie du logiciel, la gestion de projet est confrontée à de nombreux défis. Le principal est de pouvoir assurer l adéquation d un produit et de ses fonctionnalités avec les besoins

Plus en détail

Gestion de Projet Informatique

Gestion de Projet Informatique Gestion de Projet Informatique Partie 3 : Cycles de vie de projet Licence d'informatique 3 ième Année Tianxiao Liu Université de Cergy-Pontoise 1 GPI T. LIU The earliest moment is when you think it is

Plus en détail

LEAN SOFTWARE DEVELOPMENT. La vision de Mary et Tom Poppendieck

LEAN SOFTWARE DEVELOPMENT. La vision de Mary et Tom Poppendieck LEAN SOFTWARE DEVELOPMENT La vision de Mary et Tom Poppendieck Plan de la présentation 1. Introduction 2. Concept 1 : Eliminer les Gaspillages 3. Concept 2 : Améliorer le Système 4. Concept 3 : Embarquer

Plus en détail

GESTION DE PROJET SÉANCE 2 : LES CYCLE DE VIE D'UN PROJET

GESTION DE PROJET SÉANCE 2 : LES CYCLE DE VIE D'UN PROJET GESTION DE PROJET SÉANCE 2 : LES CYCLE DE VIE D'UN PROJET 1 Tianxiao LIU Licence Professionnelle Réseaux & Sécurité Université de Cergy-Pontoise http://depinfo.u-cergy.fr/~tliu/lpg.php PLAN Objectif et

Plus en détail

Les méthodes Agiles. Introduc)on aux méthodes Agiles Exemple : Scrum

Les méthodes Agiles. Introduc)on aux méthodes Agiles Exemple : Scrum Les méthodes Agiles Introduc)on aux méthodes Agiles Exemple : Scrum Défini)on de base Les méthodes Agiles sont des procédures de concep)on de logiciel qui se veulent plus pragma)ques que les méthodes tradi)onnelles

Plus en détail

Guide de Préparation. EXIN Agile Scrum. Foundation

Guide de Préparation. EXIN Agile Scrum. Foundation Guide de Préparation EXIN Agile Scrum Foundation Édition Décembre 2014 Droits d auteur 2014 EXIN Tous droits réservés. Aucune partie de cette publication ne saurait être publiée, reproduite, copiée, entreposée

Plus en détail

Scrum. Description. Traduit en langue française par Bruno Sbille et Fabrice Aimetti - Avril 2014 - Trad FR v1.1

Scrum. Description. Traduit en langue française par Bruno Sbille et Fabrice Aimetti - Avril 2014 - Trad FR v1.1 Scrum Description Traduit en langue française par Bruno Sbille et Fabrice Aimetti - Avril 2014 - Trad FR v1.1 V 2012.12.13 2014 Scrum Alliance,Inc 1 Les principes de Scrum Les Valeurs du Manifeste Agile

Plus en détail

Maîtrise d ouvrage agile

Maîtrise d ouvrage agile Maîtrise d ouvrage agile Offre de service Smartpoint 17 rue Neuve Tolbiac 75013 PARIS - www.smartpoint.fr SAS au capital de 37 500 - RCS PARIS B 492 114 434 Smartpoint, en quelques mots Smartpoint est

Plus en détail

CHAPITRE 3 : LES METHODES AGILES?

CHAPITRE 3 : LES METHODES AGILES? CHAPITRE 3 : LES METHODES AGILES? UE Gestion de Projet Master 1 STIC 2014/2015 Céline Joiron 2 Introduction Après avoir présenté les cycles de vie «classiques» de la gestion de projet L objectif de ce

Plus en détail

Plan. 1 Cycles de développement. 2 Méthodes agiles, principes généraux. 3 Comment se passe un Sprint?

Plan. 1 Cycles de développement. 2 Méthodes agiles, principes généraux. 3 Comment se passe un Sprint? Plan nitiation au Génie Logiciel Cours 5 ntroduction au π développement agile T. Genet (genet@irisa.fr) (STC/RSA) GEN-5 1/ 28 T. Genet (genet@irisa.fr) (STC/RSA) GEN-5 2/ 28 Bibliographie Plan L informatique

Plus en détail

Scrum. ... pour des projets informatiques agiles. Pascal Lando Certified Scrum product owner

Scrum. ... pour des projets informatiques agiles. Pascal Lando Certified Scrum product owner Scrum... pour des projets informatiques agiles Pascal Lando Certified Scrum product owner e-merchant Laboratoire Mis IUP Miage d Amiens pascal.lando@u-picardie.fr 2 octobre 2013 Ceci n est pas un cours

Plus en détail

Formation AME. Développement Logiciel Agile

Formation AME. Développement Logiciel Agile Formation AME Les évolutions que connaissent les différents domaines de l énergie (Recherche et développement, réglementation, processus de maitrise de la demande d énergie, techniques d exploitation des

Plus en détail

Programmation Agile Mise en oeuvre via Scrum et l'extreme Programming (XP)

Programmation Agile Mise en oeuvre via Scrum et l'extreme Programming (XP) Programmation Agile Mise en oeuvre via Scrum et l'extreme Programming (XP) B. Mermet 2010 Plan La programmation Agile et L'artisanat du logiciel Mise en œuvre avec Scrum Mise en œuvre avec l'extreme Programming

Plus en détail

Jean-Pierre Vickoff www.vickoff.com

Jean-Pierre Vickoff www.vickoff.com Techniques du futur Agile Communication - Architecture - Méthode Vers une approche Agile de 3 ème génération Jean-Pierre Vickoff www.vickoff.com Protocole de séance : Précisions techniques immédiates possibles

Plus en détail

Alignement avec les métiers par le test fonctionnel et d acceptation en projets agiles

Alignement avec les métiers par le test fonctionnel et d acceptation en projets agiles Alignement avec les métiers par le test fonctionnel et d acceptation en projets agiles Laurent PY CEO, Smartesting Laurent.py@smartesting.com @py_laurent www.smartesting.com Guillaume Coquelle Testeur,

Plus en détail

Le rôle du coach Agile et son apport pour le projet

Le rôle du coach Agile et son apport pour le projet Le rôle du coach Agile et son apport pour le projet Franck Beulé Soirée du 4 novembre 2013 Chez Google 45 Sommaire Qu est- ce qu un coach Agile? Que s interdit- il? Ce qu il fait Ses points d anenoon Des

Plus en détail

TDD Agilité et Kanban Planning Poker

TDD Agilité et Kanban Planning Poker TDD Agilité et Kanban Planning Poker Philippe Collet Licence 3 Informatique S6 2013-2014 http://deptinfo.unice.fr/twiki/bin/view/linfo/projetdelicence201314 Plan r TDD r XP r Scrum r Kanban r Planning

Plus en détail

Agile @ Germe Grenoble 4 22/06/2012. Intervenant: Bruno Sbille

Agile @ Germe Grenoble 4 22/06/2012. Intervenant: Bruno Sbille Agile @ Germe Grenoble 4 22/06/2012 Intervenant: Bruno Sbille 1 Agile @ Germe 2 Bruno Sbille Blog Agile: http://brunosbille.com Coach & Formateur Blog Coaching Personnel: http://brunosbille.com/coachdevie

Plus en détail

Introduc)on à l Agile

Introduc)on à l Agile Introduc)on à l Agile 1 D où je viens Études M2 info : Paris Diderot (2009) MS Management de Projets Technologiques : ESSEC / Telecom Paris (2010) Aujourd hui Consultant à OCTO Technology (Conseil en SI)

Plus en détail

Formation Scrum. 2 jours

Formation Scrum. 2 jours 2 jours +33 6 08 34 63 55 laurent@morisseauconsulting.com SARL unipersonnelle au capital de 3500 - N SIRET : 508 068 590 00019 Code APE 6202A Sommaire 1 Contexte de la formation... 3 2 Le formateur...

Plus en détail

Les Bonnes PRATIQUES DU TEST LOGICIEL

Les Bonnes PRATIQUES DU TEST LOGICIEL Les Bonnes PRATIQUES DU TEST LOGICIEL SOMMAIRE Qu est-ce que le test logiciel? Pourquoi le test est-il un maillon crucial de l ingénierie logicielle? Quels sont les différents types de tests? Qu est-ce

Plus en détail

Estimer et mesurer la performance des projets agiles avec les points de fonction

Estimer et mesurer la performance des projets agiles avec les points de fonction Estimer et mesurer la performance des projets agiles avec les points de fonction Radenko Corovic, MBA radenko.corovic@rsmtechno.ca 1. Introduction Les méthodes agiles de développement des systèmes ont

Plus en détail

Méthodologies SCRUM Présentation et mise en oeuvre

Méthodologies SCRUM Présentation et mise en oeuvre Méthodologies SCRUM Présentation et mise en oeuvre Réalisé par Istace Emmanuel (Manu404) pour la communauté Hackbbs Document sous license GFDL (Licence de documentation libre GNU) http://www.gnu.org/licenses/licenses.fr.html

Plus en détail

Le Product Owner Clé de voute d un projet agile réussi

Le Product Owner Clé de voute d un projet agile réussi Le Product Owner Clé de voute d un projet agile réussi Cédric Pourbaix - EFIDEV Qui est le product owner? SM PO Scrum Team Qui est le product owner? SM PO Scrum Team Qui est le product owner? marketing

Plus en détail

EXIN Agile Scrum Master

EXIN Agile Scrum Master Guide de préparation EXIN Agile Scrum Master Édition de juillet 2015 Copyright 2015 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing

Plus en détail

Formation agile. Formation agile Created on 24 janv. 2012 Edited on 29 févr. 2012. Page 1 sur 16

Formation agile. Formation agile Created on 24 janv. 2012 Edited on 29 févr. 2012. Page 1 sur 16 Formation agile Page 1 sur 16 1. Qui sommes-nous?... 3 1.1. Pierre-Emmanuel Dautreppe... 3 1.2. Norman Deschauwer... 3 1.3. L association DotNetHub... 3 2. Introduction... 5 3. Agile Manifesto... 6 4.

Plus en détail

Développement itératif, évolutif et agile

Développement itératif, évolutif et agile Document Développement itératif, évolutif et agile Auteur Nicoleta SERGI Version 1.0 Date de sortie 23/11/2007 1. Processus Unifié Développement itératif, évolutif et agile Contrairement au cycle de vie

Plus en détail

L'agilité appliquée à nous-mêmes. Philippe Krief, PhD Development Manager IBM France Lab

L'agilité appliquée à nous-mêmes. Philippe Krief, PhD Development Manager IBM France Lab L'agilité appliquée à nous-mêmes Philippe Krief, PhD Development Manager IBM France Lab Agenda Où en était l équipe RPP il y a 24 mois Réorganisation de l équipe et du projet autour de Scrum et de RTC

Plus en détail

CATALOGUE)FORMATION)2015)

CATALOGUE)FORMATION)2015) CATALOGUE)FORMATION)2015) Intitulé(de(formation( Code( Agiliser)vos)processus) F010$ Fondamentaux)du)Lean) F021$ Résolution)de)problème) F022$ Lean)Six)Sigma) F023$ Mesures)et)indicateurs) F030$ Assurance)qualité,)vérification,)validation)

Plus en détail

Cours Ephec Niv. 2 : Technique et gestion de projet. Par Monsieur Bertieaux Année Académique 2014-2015. Quelles sont les 4 valeurs Agiles?

Cours Ephec Niv. 2 : Technique et gestion de projet. Par Monsieur Bertieaux Année Académique 2014-2015. Quelles sont les 4 valeurs Agiles? Cours Ephec Niv. 2 : Technique et gestion de projet Par Monsieur Bertieaux Année Académique 2014-2015 Réponse aux questions du cours, slide Cours 2_2_Scrum Quelles sont les 4 valeurs Agiles? 1. «Les personnes

Plus en détail

Le Product Backlog, qu est ce c est?

Le Product Backlog, qu est ce c est? Le Product Backlog, qu est ce c est? Ludovic Larché Agile Tour 2012 à Rennes le 4 octobre 2012 Sommaire > Rappels théoriques : qu est ce qu un Product Backlog? > Le Product Backlog n est pas seul! > Techniques

Plus en détail

Tuesday, October 20, 2009. Nantes

Tuesday, October 20, 2009. Nantes Tuesday, October 20, 2009 Nantes Retour d'expérience SCRUM/XP dans un contexte CMMI-DEV niveau 2 SM CMM Integration, IDEAL, and SCAMPI are service marks of Carnegie Mellon University. Capability Maturity

Plus en détail

Reddition de compte et Agilité. Présenté par Jean-René Rousseau Agile Québec Septembre 2011

Reddition de compte et Agilité. Présenté par Jean-René Rousseau Agile Québec Septembre 2011 Reddition de compte et Agilité Présenté par Jean-René Rousseau Agile Québec Septembre 2011 Qui suis-je Jean-René Rousseau jrrousseau@pyxis-tech.com Coach Agile à Pyxis www.pyxis-tech.com/accompagnement

Plus en détail

Formation pour Product Owner

Formation pour Product Owner 2 jours +33 6 08 34 63 55 laurent@morisseauconsulting.com SARL unipersonnelle au capital de 3500 - N SIRET : 508 068 590 00019 Code APE 6202A Sommaire 1 Contexte de la formation... 3 2 Le formateur...

Plus en détail

INF2015 Développement de logiciels dans un environnement Agile Examen final hiver 2015

INF2015 Développement de logiciels dans un environnement Agile Examen final hiver 2015 INF2015 Développement de logiciels dans un environnement Agile Examen final hiver 2015 Question #1 Quelle technique de mise sous test devons-nous utiliser si nous voulons simuler le comportement d'une

Plus en détail

Planifier son projet avec SCRUM

Planifier son projet avec SCRUM Avec SCRUM l estimation de la taille du projet est collective. C est l équipe présente qui estime taille et la durée du projet. L estimation se base sur la capacité de l équipe : la vélocité. La vélocité

Plus en détail

Méthode Agile de 3 ème génération. 2008 J-P Vickoff

Méthode Agile de 3 ème génération. 2008 J-P Vickoff PUMA Essentiel Méthode Agile de 3 ème génération 1 Structure de la présentation PUMA Essentiel méthode Agile de 3 ème génération Quelques principes Agiles Principales pratique Agile de pilotage Structure

Plus en détail

REX Scrum : Cas concrets, problématiques et solutions mises en œuvre. Retour d'expériences - Cas concrets 1

REX Scrum : Cas concrets, problématiques et solutions mises en œuvre. Retour d'expériences - Cas concrets 1 REX Scrum : Cas concrets, problématiques et solutions mises en œuvre Retour d'expériences - Cas concrets 1 Sogeti dans le monde Plus de 20 000 professionnels dans le monde Norvège : 50 Suède: 1 000 USA:

Plus en détail

GESTION DE PROJET : LA METHODE AGILE

GESTION DE PROJET : LA METHODE AGILE GESTION DE PROJET : LA METHODE AGILE Le SCRUM est une méthode de gestion de projet. Elle a pour but d améliorer la productivité des équipes. Ce terme est inspiré du terme Scrum en rugby qui désigne une

Plus en détail

AGILE et le PMO. Conférence présentée à Agile Montréal 12 septembre 2013. Stéphane Lecuyer & Frédérick H. Stoltz

AGILE et le PMO. Conférence présentée à Agile Montréal 12 septembre 2013. Stéphane Lecuyer & Frédérick H. Stoltz AGILE et le PMO Conférence présentée à Agile Montréal 12 septembre 2013 Stéphane Lecuyer & Frédérick H. Stoltz 1 Qui sommes-nous? Frédérick H. Stoltz, PMP, ITIL Parallèlement à son engagement en tant que

Plus en détail

Modèle de changement d organisation. Leanpizza.net présente. Petit Guide Rapide du jeu de cartes Modèle de Changement d Organisation

Modèle de changement d organisation. Leanpizza.net présente. Petit Guide Rapide du jeu de cartes Modèle de Changement d Organisation Guide rapide Leanpizza.net présente Petit Guide Rapide du jeu de cartes Modèle de Changement d Organisation v1.0 Rédacteur : Olivier Lafontan Traduction : Yannick Quenec hdu Date : 29 juin 2010 - Guide

Plus en détail

Gestion de Projet Agile

Gestion de Projet Agile Gestion de Projet Agile De la vision aux tests Tianxiao.Liu@u-cergy.fr Université de Cergy-Pontoise Master SIC/ISIM 2 ième Année 1 Plan Vision et features du projet User story (ou story) Décomposer les

Plus en détail

Introduction à l'agilité

Introduction à l'agilité Introduction à l'agilité ENSMSE - 22 novembre 2013 @agnes_crepet Qui suis-je? Agnès Crépet @agnes_crepet agnes@ninja-squad.com Java/JEE Architecte & Java Champion Laboratoires Boiron Ninja Squad Java User

Plus en détail

Approches Agiles pour éditeurs logiciels

Approches Agiles pour éditeurs logiciels Approches Agiles pour éditeurs logiciels Avril 2012 2012-04- 05 Larmor Valley 2 Agenda Approches Agiles pour éditeurs logiciels Intérêts Freins ProposiBons Bienvenu(e)s! 3 S'informer Découvrir Offre Communautaire

Plus en détail

Introduction Les processus traditionnels extreme Programming Conclusion. extreme Programming. vers plus d agilité. F. Miller francois.miller@inpg.

Introduction Les processus traditionnels extreme Programming Conclusion. extreme Programming. vers plus d agilité. F. Miller francois.miller@inpg. vers plus d agilité F. Miller francois.miller@inpg.fr FC INPG Octobre 2008 - version 1.0 Introduction Contexte Le monde bouge économie des moyens (humains, financier,...) ; recherche de plus d efficacité

Plus en détail

LA MÉTHODE AGILE VS LE CYCLE EN V UNE RÉVOLUTION DANS LA GESTION DE PROJET. Franck BEULÉ

LA MÉTHODE AGILE VS LE CYCLE EN V UNE RÉVOLUTION DANS LA GESTION DE PROJET. Franck BEULÉ LA MÉTHODE AGILE VS LE CYCLE EN V UNE RÉVOLUTION DANS LA GESTION DE PROJET Franck BEULÉ 18 avril 2012 Bienvenue L'hôte de ce soir Franck BEULÉ Chef de Projet senior Chez Vision IT Group depuis 2 ans Actuellement

Plus en détail

Responsables produit managers

Responsables produit managers Responsables produit &quelques managers pas de plus Pablo Pernot version 2013-1-1 Pablo Pernot - 2013 - Creative Commons Attribution-ShareAlike 3.0 Unported License http://creativecommons.org/licenses/by-sa/3.0/

Plus en détail

Les Méthodes Agiles. description et rapport à la Qualité. Benjamin Joguet Rémi Perrot Guillaume Tourgis

Les Méthodes Agiles. description et rapport à la Qualité. Benjamin Joguet Rémi Perrot Guillaume Tourgis Les Méthodes Agiles description et rapport à la Qualité Benjamin Joguet Rémi Perrot Guillaume Tourgis 1 Plan Présentation générale d'agile Qu'est ce qu'une méthode Agile? Le manifeste Les valeurs Les principes

Plus en détail

LES tests d'acceptation

LES tests d'acceptation dans la série : b.d. agile! Idée et dessins par Anis berejeb : www.berejeb.com LES tests d'acceptation reflexions, experimentations... réussites et échecs... apprentissage et amelioration. à Partager avec

Plus en détail

Fondateur d Agile Impulse 06 29 95 14 53 nicolashennion@agileimpulse.com. Support disponible sur agileimpulse.com/formation/scrumssii2j.

Fondateur d Agile Impulse 06 29 95 14 53 nicolashennion@agileimpulse.com. Support disponible sur agileimpulse.com/formation/scrumssii2j. SCRUM AU QUOTIDIEN EN SSII Nicolas Hennion Fondateur d 06 29 95 14 53 nicolashennion@agileimpulse.com Support disponible sur agileimpulse.com/formation/scrumssii2j.pdf ( ) Il existe des projets informatiques

Plus en détail

Les méthodes Agile. Implication du client Développement itératif et incrémental

Les méthodes Agile. Implication du client Développement itératif et incrémental Les méthodes Agile Simon ALEXANDRE - CETIC Plan Overview Agile ne signifie pas Agile signifie Objectifs poursuivis Pourquoi les méthodes Agile apparaissent-elles? Principales causes des échecs de projets

Plus en détail

Pablo Pernot - 2013 - Creative Commons Attribution-ShareAlike 3.0 Unported License http://creativecommons.org/licenses/by-sa/3.

Pablo Pernot - 2013 - Creative Commons Attribution-ShareAlike 3.0 Unported License http://creativecommons.org/licenses/by-sa/3. Optimiser la valeur "Value Stream Mapping" "Root Causes Analysis" "A3 Report" http://creativecommons.org/licenses/by-sa/3.0/ 1/17 Lean Software Development, Mary Poppendieck Lean Thinking, Womack & Jones

Plus en détail

Support Agile avec Kanban quelques trucs et astuces par Tomas Björkholm

Support Agile avec Kanban quelques trucs et astuces par Tomas Björkholm Support Agile avec Kanban quelques trucs et astuces par Tomas Björkholm Avant-propos Il y a un an, j'ai animé un atelier au Scrum Gathering de Stockholm sur le Support Agile. Depuis, j'ai reçu plusieurs

Plus en détail

XEBIA DÉVELOPPEMENT OFFSHORE DISTRIBUÉ EN MÉTHODES AGILES. CAS CLIENT : CoachClub

XEBIA DÉVELOPPEMENT OFFSHORE DISTRIBUÉ EN MÉTHODES AGILES. CAS CLIENT : CoachClub XEBIA DÉVELOPPEMENT OFFSHORE DISTRIBUÉ EN MÉTHODES AGILES CAS CLIENT : CoachClub Le métier de CoachClub CoachClub est le premier site vidéo de Coaching Sportif personnalisé. Mis au point par des professionnels

Plus en détail

Scrum et itk : adaptation de la méthode au développement d OAD. D après Henrik Kniberg Scrum et XP depuis les tranchées

Scrum et itk : adaptation de la méthode au développement d OAD. D après Henrik Kniberg Scrum et XP depuis les tranchées Scrum et itk : adaptation de la méthode au développement d OAD D après Henrik Kniberg Scrum et XP depuis les tranchées LES MÉTHODES AGILES Méthodes classiques client IKK!! #@??? client IK K Définition

Plus en détail

INTRODUCTION À LA GESTION DE PROJET AGILE (BACKLOG, TABLEAUX DE BORD, BURNDOWN, PLANIFICATION D ITERATIONS)

INTRODUCTION À LA GESTION DE PROJET AGILE (BACKLOG, TABLEAUX DE BORD, BURNDOWN, PLANIFICATION D ITERATIONS) INTRODUCTION À LA GESTION DE PROJET AGILE (BACKLOG, TABLEAUX DE BORD, BURNDOWN, PLANIFICATION D ITERATIONS) 1 Introduction à la gestion de projet Agile Sommaire AVERTISSEMENT... 2 APERÇU... 3 EXERCICE

Plus en détail

Les quatre chantiers :

Les quatre chantiers : Tweet Voir aussi : Les programmes de performance, La méthode Kaizen, Le Lean en 10 points. Le Lean est une démarche systématique dont l'objectif est d'éliminer toutes les sources de gaspillages dans les

Plus en détail

Scrum Planification, Estimation, Risques

Scrum Planification, Estimation, Risques Pierre Vachon, MBA, CSP, CSM blog.lmrtechnologies.com Scrum 1 Planification, Estimation, Risques Pierre Vachon 15+ ans en informatique 5 ans d Agilité (Scrum, XP, Kanban) Canada, États-Unis, France Ford,

Plus en détail

Avant propos. Parcours de lecture : combien de sprints vous faut il?

Avant propos. Parcours de lecture : combien de sprints vous faut il? Avant propos Depuis plus d une dizaine d années, je conseille des entreprises et je forme des étudiants sur les méthodes itératives et agiles. Depuis cinq ans, cet effort porte presque exclusivement sur

Plus en détail

Feature Team Primer. par Craig Larman et Bas Vodde. Version 1.2

Feature Team Primer. par Craig Larman et Bas Vodde. Version 1.2 ÉQUIPE FEATURE par Craig Larman et Bas Vodde Version 1.2 Les Équipes Feature 1 et les Domaines Fonctionnels 2 sont des éléments essentiels pour dimensionner le développement en mode agile et lean. Ces

Plus en détail

UML est-il soluble dans les méthodes agiles?

UML est-il soluble dans les méthodes agiles? Pascal ROQUES Valtech Training UML est-il soluble dans les méthodes agiles? octobre 07 Résumé On entend beaucoup parler actuellement de deux approches ayant l'air fondamentalement opposées : l'approche

Plus en détail

Présentation UBO 12/2008 Présentation des méthodes agiles

Présentation UBO 12/2008 Présentation des méthodes agiles Gestion de projet Vers les méthodes agiles Des approches prédictives aux méthodes agiles appliquées avec SCRUM Présentation UBO 12/2008 Présentation des méthodes agiles Partie 1 : La société Altran Altran

Plus en détail

XP : ce célèbre inconnu

XP : ce célèbre inconnu XP : ce célèbre inconnu Extreme Programming Thierry Cros http://etre-agile.com 1 XP : plus qu'agile Pourquoi XP Installer XP Rôles et Cycle de Vie Pratiques : Coder et livrer Développement Responsable

Plus en détail

Informatiques. Module : Outils RAD

Informatiques. Module : Outils RAD Management de Projets Informatiques Module : Outils RAD Niveau : S4 du L2/ISIL Génie Logiciel Le terme génie logiciel (en anglais software engineering) désigne l'ensemble des méthodes, des techniques et

Plus en détail

Scrum Le guide pratique de la méthode agile la plus populaire 3 e édition Claude Aubry 320 pages Dunod, 2013

Scrum Le guide pratique de la méthode agile la plus populaire 3 e édition Claude Aubry 320 pages Dunod, 2013 Scrum Le guide pratique de la méthode agile la plus populaire 3 e édition Claude Aubry 320 pages Dunod, 2013 Illustration de couverture : Clément Pinçon Dunod, Paris, 2014 ISBN 978-2-10-071038-6 Préface

Plus en détail

Cours Gestion de projet

Cours Gestion de projet Cours Gestion de projet Méthodes de conduite de projet Version Date Auteur V1.8 Septembre 2007 Pascal HEYER 1 Méthodes de conduite de projet Ce document est publié sous la licence libre Creative Commons-BY-NC-SA

Plus en détail

Vision Produit. Un sacré attracteur pour une équipe auto-organisée. Thierry Cros

Vision Produit. Un sacré attracteur pour une équipe auto-organisée. Thierry Cros Vision Produit Un sacré attracteur pour une équipe auto-organisée Thierry Cros Sommaire Attracteur et équipe auto-organisée Vision Produit Contenu Qui fait quoi? Formats Vision : un sacré attracteur http://etre-agile.com

Plus en détail

Gestion de Projet Agile

Gestion de Projet Agile Gestion de Projet Agile Planification et Estimation Sprint 0 Tianxiao.Liu@u-cergy.fr Université de Cergy-Pontoise Master SIC/ISIM 2 ième Année Plan Introduction Motivation : pourquoi planifier & estimer?

Plus en détail

SCRUM BUT, LE LIVRE BLANC. De la problématique de mener un projet AGILE dans une organisation classique

SCRUM BUT, LE LIVRE BLANC. De la problématique de mener un projet AGILE dans une organisation classique SCRUM BUT, LE LIVRE BLANC De la problématique de mener un projet AGILE dans une organisation classique Résumé Alors que les demandes de conduite de projet en AGILITE sont de plus en plus fréquentes, les

Plus en détail

GL - 2 2.2 Processus de développement Cycles de vie

GL - 2 2.2 Processus de développement Cycles de vie GL - 2 2.2 Processus de développement Cycles de vie Lydie du Bousquet Lydie.du-bousquet@imag.fr En collaboration avec J.-M. Favre, Ph. Lalanda, I. Parissis, Y. Ledru 1 Plan Introduction Modèles en cascade

Plus en détail

La solution IBM Rational pour une ALM Agile

La solution IBM Rational pour une ALM Agile La solution IBM pour une ALM Agile Utilisez votre potentiel agile Points clés Adopter l'agilité à votre rythme Supporter une livraison multiplateforme Intégrer la visibilité Démarrer rapidement Que votre

Plus en détail

Testeur Agile Niveau Fondation 2014 - Bertrand Cornanguer, Vice-chair Agile tester WG

Testeur Agile Niveau Fondation 2014 - Bertrand Cornanguer, Vice-chair Agile tester WG Testeur Niveau Fondation 2014 - Bertrand Cornanguer, Vice-chair tester WG Enquêtes 2013 sur l Agilité Seriez-vous interessé par la certification Testeur? Enquête ISTQB (70 pays juin octobre 2013) Ingénieurs

Plus en détail