Scrum/XP : Témoignage de 2 développeurs

1 513 vues

Publié le

Retour sur les étapes d'un projet Scrum et sur les pratiques XP à travers des expériences concrêtes : Réussites et Echecs
Nos "réglages Scrum" à travers les étapes d'un sprint : poker planning, daily scrum, démonstration, rétrospective
Les critères de ready et de done
le développement, l'ingénierie, la qualité : Jusqu’où sommes nous allé avec les pratiques XP ? Quels bénéfices apportés ? Quelles difficultés rencontrées ?
Le télétravail / Les équipes distantes : Avec une équipe basée sur 4 sites, comment nous sommes nous adaptés ?

Licensing Creative Commons by NC ND
http://creativecommons.org/licenses/by-nc-nd/2.0/fr/legalcode

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 513
Sur SlideShare
0
Issues des intégrations
0
Intégrations
320
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • 1 Title

    Keywords :
    - Bienvenue
    - Expérience projet Scrum XP
    - Scrum?
    - XP?

    Bienvenue à l'agile tour
    On va vous parler d'une expérience de projet agile sur laquelle on a tous le deux travaillé
    Pour commercer et pour adapter un peu le contenu de ce qu'on va dire, petit sondage :
    Qui connait Scrum ? => poker planning, daily scrum, sprint, product owner
    Qui a déjà pratiqué ?
    Qui connait les pratiques XP ? => pair programming, tdd

    Petite référence au livre Scrum XP from the trenches
  • 3 ans -> 2 en scrum
  • 4 Scrum

    Keywords :
    - Exemple : gestion d'utilisateur, gestion de groupe
    - Backlog
    - Poker planning
    - Découpage
    - Sprint : dépiler les US
    - Chaque jour on prend une tâche
    - Chaque jour on fait un daily : point de synchro
    - on a un livrable
    - on démontre ce qui est terminé
    - on fait une retro
    - on reprend le poker planning

  • 5 Poker planning

    Keywords :
    - Comprendre ce qu'il y a à faire : les fonctionnalités que le product owner souhaite
    - Comprendre les priorités
    - Evaluer ce qu'on peut faire au prochain sprint

  • 6 Poker planning LECON

    lire
    expliquer :
    - commence par une explication
    - échange de questiton réponse
    - évaluation : vote un effort (chiffrage)
    - désaccord : explication, recommence
  • US présentées priorisées.
    2 sprint d’avance
    Identification de plusieurs critères sur lequel on insistait systematiquement -> Mise en place des critères de ready

    US orientée Fonctionnalités -> Je suis webmaster, Je veux publier un produit, pour qu’il soit consultable

    Décrire les gestes métiers, ecrire des tests d’acceptance -> permet à l’équipe de mieux saisir et de mieux comprendre ce que veux le po

    Story board -> enchainement des ecran, identifier des complexiter (ajax, drag and drop, ecran lourd ....)
  • 8 La compréhension

    Objectif du PO : expliquer ce qu'il veut
    Objectif de l'équipe : comprendre ce qui doit être fait
    Objectif commun : lever les loups
    Le PO expose une US
    L'équipe pose des questions, le PO répond
    Question/Réponse
    1 personnes à la fois
    Tt le monde parle : adhésion
  • 9 Evaluation

    Compromis / Négociation
    Au début : on vote / revote / etc...
    On a appris à prendre la parole pour soulever un problème, une difficulté, etc
    On réfléchi assez vite
    Après On vote une fois, on fait une moyenne sauf objection

    Vote trop élevé :
    - le PO peut réévaluer sa priorité
    - on peut redécouper : enlever une partie complexe mais avec peu d'intérêt métier

    Fluidité qui s’installe avec le temps : ½ journée à ~2H

    Une fois le backlog de sprint constitué, on réalise un découpage en tâche
    On entamme le sprint
  • 10 Daily

    Chaque jour
    Réunion quotidienne
    Objectif : se synchroniser
    Savoir ou en est, soulever les problèmes, s'entre aider, ne pas rester bloquer
    Participent : l'équipe, le SM, le PO, tout autre personne qui veut s'informer
  • 11 Daily LECON

    lecture
    complément sur les discussions menée après :
    - par exemple si on soulève un problème pendant le daily,
    on ne va pas expliquer la cause d'une erreur Java ou essayer de résoudre le problème
    on propose un point après le daily avec les personnes interessées
  • On appliquait ce que dit scrum, mais on s’est rendu compte que c’était pas efficasse.
    Le “ce que j’ai fait hier” devenait plus un rapport d’activité,
    tendance à s’étaler, trop de choses étaient dites

    Impossible de retenir
    Conséquence les gens décrochent, impossible de tout retenir -> manque d’efficacité

    Transition sur la solution
  • Méthode miracle

    Solution mettre le focus sur l’objectif de la journée ->
    plus d’implication de la part des membres de l’équipe,
    plus d’écoute,
    plus d’efficacité

    A la fin daily 5 min en moyenne



  • 14 Horaire Durée

    N: Horaire : on avait une heure fixe 9h15
    il nous arrivait de le déplacer,le tout était d'en faire un par jour
    en cas de retard : on attend pas, le retardataire essayait d'envoyer
    son daily par texto ou par mail à quelqu'un

    ---------------------------------------

    Durée : Fausse problématique
    Ne pas se focaliser sur la durée, l’objectif c’est de se synchroniser,
    Si sentiment d’agacement, perte de concentration se poser la question sur la façon de faire le daily
  • 15 Démo

    Réunion qui cloture un sprint
    On annonce l'état du travail par rapport aux engagements
    On fait une démonstration de ce qui est termine
    Sont conviés : l'équipe qui dirige la démo avec le SM, les POs, tout autre personne !
    => client, direction, ...
  • 16 Démo LECON

    Moment d'échange : entre l'équipe et les POs mais aussi entre les POs et les clients
    tout le monde peut avoir des invités
  • Avant la demo petite préparation

    Preparation d’un jeu de données.
    Préparation d’un scénario de test
    Si pas fait la démo peut ne pas être intéressante.


    Celui qui présente une US, à participer à sa realisation.

    A chaque demo faire en sorte qu’une personne différence prépare et présente
  • Eviter d’avoir l’air d’une bande de gland : On assure
    Il peut y avoir des gens importants présent
    Infrastructure fiable, application déployé, matériel de démo (projo), salle, …, connexion
    On demande de ne plus toucher au serveur de démo, par de redeployment ni de tests dessus avant la démo
  • US : on déroule un process -> demo orienté metier.
    N’importe qui peut y assister, il faut que tout le monde comprenne

    TS : on essaie de montrer un résultat en restant accessible (exemple : tests unitaires vert / chiffre => couverture de code)
    On peut ajouter des informations techniques toujours compréhensible par un client final.
    => On a mis en place un infrastructure qui permet de tenir une charge de 1000 utilisateurs simultanés
  • Scrum dis pas de slide : Nous un slide de résumer, présenté par le scrum master
    Rapide aperçu du déroulement, de l’avanement et evenement
  • 21 Sprint

    Déroulement du sprint
    La manière dont on travaillait
    Dont on était organisait, les outils qu'on utilisait
  • 22 SPrint LECON

    Scrum ne cadre pas, on fait comme on veut et selon le contexte
    Corrolaire : on peut appliquer scrum dans différent contexte

    XP
    Intégration continue : déploiement régulier de l'application
    Un moyen supplémentaire d'éliminer les surprises
    On déploie très vite après un l'écriture d'une ligne de code
    On est capable de tester sur un environnement type
    On peut partager avec les POs
  • Objectif : dépiler les US 1 à 1 pour s’assurer d’en terminer / On essaie d’éviter de terminer avec toute les US fini à 90%

    Enjeu : Mettre un maximum d’effort sur 1 US, travailler ensemble et se séparer les tâches
    Comment faire ? => on se pose la question à chaque fois

    Exemple 1 : La conception puis en parallèle les implem, tests, javadoc, interfaces graphiques
    Exemple 2 : Un import : on se met d’accord sur un format, on peut partir sur les implems puis sur la préparation de jeu de tests, etc
  • TU et Test accpetance passer
    JAVADOC -> service avaient vocation à être utilisés par différentes bu
    Synthese des discussions
    Charte graphique -> respect button par exemple
  • Développement en Pair :
    Au début du sprint : modèle, interface
    Accueil d’un développeur sur un sujet non abordé (ex: nouveau membre d’équipe)
    Sujet complexe
  • 25 Env

    Maven
    sonar : nightly
  • 26 Déploiement

    Lorsqu'un build fonctionne bien
    A la demande, pour les démos, pendant le sprint pour tester avec le POs
    Pour faire des tests d'intégration
  • 27 Tests

    Contexte de socle : qualité nécessaire
    90 / 95% de couverture de code sur les services
    quasiment 0% sur les interfaces
    TDD pour ceux qui le souhaite
  • 30 Configuration

    5 sites
    on est aller chercher les compétences nécessaires ou elles étaient
  • 31 Scrum XP : LECON

    Ne le fait pas
    Proximité / Collaboration

    Notre enjeu : maintenir une proximité en s'appuyant sur une organisation et des outils
  • Permettre la mise a jout par tout le monde, Avant des soucis on ne savait pas qui prend quoi
    Difficile à synchroniser
  • Creation de salle
    Les équipes peuvent travailler dans des salle
    Créé de la proximité
    Tres facile a utiliser
  • Permet la cohésion, tjs plus conviviale qu’a travers un chat texte ou vocale
  • Scrum/XP : Témoignage de 2 développeurs

    1. 1. Scrum, XP : Témoignage de 2 développeurs
    2. 2. Charles Besselievre Nicolas Chapurlat  Développeurs Java  ~3 ans d ’expérience  Internet / Ecommerce / Multicanal @Copyright Nicolas Chapurlat & Charles Besselièvre Licensing Creative Commons by NC ND http://creativecommons.org/licenses/by-nc-nd/2.0/fr/legalcode
    3. 3. Régie sur 2 ans Internet / Multicanal Socle Groupe Scrum / XP 10 développeurs
    4. 4. SPRINT BACKLOG US US US PRODUCT BACKLOG US US US US POKER PLANNING DECOUPAGE EN TÂCHES DASHBOARD DONE IN PROGRESS TODO RELEASE DEMO RETRO DAILY SCRUM
    5. 5. POKER PLANNING
    6. 6. SCRUM dit : x Le PO présente les US prioritaires du backlog. x L’équipe doit comprendre le périmètre et les conditions de satisfaction. x L’équipe vote un effort à fournir. x S’il n’y a pas unanimité, la discussion reprend.
    7. 7. US US US US US US US US US US US US US US US US US US
    8. 8. DAILY
    9. 9. SCRUM dit : Réunion de 15 minutes maximum N’importe qui peut écouter L’équipe, le PO et le Scrum Master peuvent intervenir : x Qu'est-ce que j'ai fait hier ? x Qu'est-ce que je compte faire aujourd'hui ? x Quelles sont les difficultés que je rencontre ? Les discussions qui sortent de ce cadre sont menées après !
    10. 10. Hier j’ai fait, Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Morbi vel erat non mauris convallis vehicula. Nulla et sapien. Integer tortor tellus, aliquam faucibus, convallis id, congue eu, quam. Mauris ullamcorper felis vitae erat. Aujourd’hui je vais faire Aliquam convallis sollicitudin purus. Praesent aliquam, enim at fermentum mollis, ligula massa adipiscing nisl, ac euismod nibh nisl eu lectus. Fusce vulputate sem at sapien. Vivamus leo. Hier j’ai fait, Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Morbi vel erat non mauris convallis vehicula. Nulla et sapien. Integer tortor tellus, aliquam faucibus, convallis id, congue eu, quam. Mauris ullamcorper felis vitae erat. Aujourd’hui je vais faire Aliquam convallis sollicitudin purus. Praesent aliquam, enim at fermentum mollis, ligula massa adipiscing nisl, ac euismod nibh nisl eu lectus. Fusce vulputate sem at sapien. Vivamus leo. Hier j’ai fait, Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Morbi vel erat non mauris convallis vehicula. Nulla et sapien. Integer tortor tellus, aliquam faucibus, convallis id, congue eu, quam. Mauris ullamcorper felis vitae erat. Aujourd’hui je vais faire Aliquam convallis sollicitudin purus. Praesent aliquam, enim at fermentum mollis, ligula massa adipiscing nisl, ac euismod nibh nisl eu lectus. Fusce vulputate sem at sapien. Vivamus leo.
    11. 11. Hier, mon objectif était de massacrer l’équipe galloise. J’ai bien progressé mais je bute sur un problème, ils ont fait entrer tous les remplaçants. Avec l’aide d’un copain, mon objectif aujourd’hui sera de terminer le travail.
    12. 12. DURÉE HORAIRE
    13. 13. LA DÉMO
    14. 14. Scrum dit : x Ne démontrer que ce qui fonctionne x Consacrer peu de temps à sa préparation x Pas de slides x Insister sur le métier x Un moment d’échange x Maximum 4 heures
    15. 15. LE SPRINT
    16. 16. SCRUM ne cadre pas la réalisation XP dit : x Tests unitaires : TDD et très bonne couverture de code x Partage des connaissances : Pair programming avec binômes évoluant x Simplicité : Conception simple, Refactoring, Conventions, Standards x Intégration continue
    17. 17. Implémentation Javadoc Tests Interface Graphique TODO IN PROGRESS DONE
    18. 18. Tests Démo
    19. 19. TÉLÉTRAVAIL ÉQUIPES DISTANTES
    20. 20. LILLE VALENCIENNES NANTES RENNES TOULOUSE
    21. 21. Scrum recommande de ne pas le faire. XP recommande de ne pas le faire.
    22. 22. Chat vocal
    23. 23. L’abus d’alcool est dangereux pour la santé !

    ×