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

No hay notas en la diapositiva.

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

chapurlatn

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