7. Project
Organisation de l’équipe
Cyril Couffignal
team
D
team
F
team
A
team
E
team
B
team
C
transverse
PO
Architect
QA lead
Sustaining
Functional-
referent
TECH
SUBJECTS
8. Organisation de l’équipe
Cyril Couffignal
Scrum Master
- point de contact / administratif
- une casquette interchangeable
- occupe 15~30% du temps
10. Cycle de vie et quotidien
La « matinale » : daily & steering
Cyril Couffignal
daily
Team A
daily
Transverse
daily
Team A
daily
Team A
steering
(scrum + some transverse)
10:00
(30 min)
10:30
(30 min)
11:00 Steering report
11. Cycle de vie et quotidien
Cyril Couffignal
Itération de 2 semaines :
- Lotissement des tâches
- Tâches, QA au fil de l’eau, CR
- Démo et QA collective
- Rétro
12. Cycle de vie et quotidien
Cyril Couffignal
Itération de 2 semaines :
- Lotissement des tâches
- Tâches, QA au fil de l’eau, CR
- Démo et QA collective
- Rétro
15. Cycle de vie et quotidien
Cyril Couffignal
Créativité et cohésion d’équipe :
- Hacking Week: 2 fois par an
- Team building
- Déplacements pour travail co-localisé
17. Communication
Cyril Couffignal
Sollicitation immédiate
Communication passive, archivée
Audio / vidéo
(MS Teams, Skype, Slack, partage d’écran..)
Chat textuel direct
(MS Teams, Skype, Slack, IRC …)
Chat textuel par canaux
(MS Teams, Skype, Slack, IRC …)
Page consultable
(Intranet, Wiki, Confluence …)
Communication directe basse priorité
(Emails …)
18. Méthodologie
Cyril Couffignal
Ce qui est important pour notre équipe:
- Communiquer
- Encourager les initiatives
- Tout le monde est acteur, propose, argumente
- Etre réactif et s’adapter au changement
Contexte:
me présente (axway lyon fr) / dev 15 ans xp / évolué en dev expert autonome , pas gérer les gens
n’aime pas trop l’excès de process -> préfère pragmatiques
Ce qui m’a poussé à faire cette conf:
Theme agile autres conf -> mon équipe approche différente
Pt de vue intérieur, dev, orga choisie par les dev
Partager retour d’xp
plan (présenter, détailler, puis parler de..)
anecdote: imaginon équipe agile rodée, dev, scrum master, po..
Scrum malade qq jours.. Attend retour
Scrum casse le genou .. 2 mois d’arret .. Comment remplacer temporairement? ..
Il revient, puis se fait l’autre genou! (véridique)
Grain de sable ds rouage de l’organisation
Ds notre équipe: chaque dev peut relais, d’ailleurs on tourne, suivant dispo et envies
(lire titre)
projet pure R&D, Peu de personnes (<10), proto, peu d’organisation (mais déjà sur 2 sites)
Produit vendu, demandes clientes, problèmes support, multi-équipes, 3 sites, 3 langues
Voyons ça en détail..
petites équipes (4 à 6 max): dev, dont 1 scrum
Commencé à 2 équipes: front/back, puis grossit -> augmente nombre équip pas taille
Chaque equip: multi-site (quasi), pas isoler les sites, meilleur cohésion globale
Chaque équipe : resp sujets
Composition: pas fixe, change 1/an
Change équipes: présente nouveau sujets (+ en cours) -> dev choissisent (compromis)
Tout le monde connait la roadmap, impliqué
petits changment cours d’année: volonté perso / démarrer nouveau sujet
exploratoir: hacker residence (temps limité)
on est flexible on s’adapte
Équipe: group éphémère, travaille sur un des sujets
On encourage à changer équipes: pas se lasser, répartir connaissances, pas d’isolement tech
des rôles transversal aux équipes (PO, architect, QA lead, Sustaining, func-referent, ..).
(8:00)
Role du scrum chez nous
Pas un role à temps plein!
Un dev, au cœur de l’équipe, égal aux autres (pas un chef d’équipe)
(lire slide)
Toute l’équipe participe (rédaction US, rétro, lancer réunion etc..) pas surcharger scrum
Ex: planing pocker, personne qui porte le sujet détaille (pas scrum)
Tout le monde est égal, à son mot à dire
(lire titre)
Peu de process =/= sans organisation
Bon d’avoir routine, automatisme
Mais savoir remettre en cause, proposer nouvelles idées
Daily: principe important: partager & remonter les infos, Pas noyer d’infos, créer du bruit
« standup meeting » like, 30 ’’ max
Chaque équipe gère comme il veut: problemes abordés, infos triés, partagés, remontés synthétiquement
Steering: 1 porte parole de chaque équipe (scrum),
Résumé écrit: redescend à tous (tout le monde doit le lire!) pas perte de temps
Concis, puis Lance réunions sur sujets ponctuels si besoins
Format changé plusieurs fois: + lisible + efficace - de bruit
Gestion du temps important, pas monoposer les gens
Historique: 2 équip (visu/logic) 1 grd réunion, maintenant daily/steering + efficace
[question, qui fait daily? Qui pense dure trop longtemps?]
(12:00)
IT 2 semaines, livraisons incrémentielles, réactif aux changements de prio, bugs .. (rien de nouveau ds l’agilité)
Lotir l’IT, planing pocker: tout le monde participe, souvent le dev qui porte le sujet mène le débat
-> pas le scrum, ni le PO
c’est une conversation, une négo
US proposés aussi par l’équipe (dev proactifs)
Pair programming
Encouragé, pas systématique, on adapte à la complexité
-> si pas à l’aise, on demande un binome (chacun fait comme il veut)
QA en interne
Par les dev (pas d’équipe QA)
dev: unit/int tests, autre dev: QA technic (CR) + fonctionnelle, passe la tache en done
(qui connait le périmetre fonctionnel et technique, les infos sont partagés)
QA collective en fin d’IT
Code review
En faire le +, débutant ont l’impression d’etre jugé -> puis devient un moyen de se protéger, d’avoir l’approbation des pairs
Demo
Avec tout le monde (les équipes + transverse+manager)
Voient l’avancement, questionnent, sera testé en wildtest
Infos clients, roadmaps, orga etc.. Partagés
Enregistré pour les absents
(réunion la + longue, borné à 2h)
QA collective
Par tout les dev, sur le prêt à être livré.
Animé par le QA lead: scénarios, wildtests, cibler new features..
aussi KTD, présentations tech
Fait le point sur les 2 sem passés
Pas systématique, mais très fréquent
Organisation libre, par léquipe, avec ou sans invité (transverse, autre équipe, manager…)
Pas d’organisateur externe (coach, poste dédié..)
Participants doivent etre à l’aise pour parler (animateur fait parti de l’équipe, pas forcément le scrum, on tourne)
Il participe aux débats, généralement secrétaire, prépare le support, lance le mouvement
-> les participants qui sont acteurs
Une retro des retros:
remonter actions prises par chaque équipe, et discuter des sujets transverses aux équipes (ex: Steering qui dure trop longtemps).
Support: document partagé collaboratif (google docs), puis publier en interne lisible par tous
exemples
Reflète la personnalité de l’équipe, différent d’un équipe à l’autre
(23:00)
HW: Pas nouveau, vecteur social, bouffé d’air, bonne ambianc
choix du sujet, équipe, vote à la fin, lot. Bonne partie réintégrée.
[question qui en fait?]
3 sites: importants de se voir physiquement de temps en temps.
Encourage les equipes à se retrouver + fois/an (car distribuées Lyon Paris Bucarest)
Rappel: pas isoler un site, intégration Roumains arrivée après
Évident, pas toujours simple, surtout équipe distribuée
(25:00)
(commencer lire slide)
Vocal: Bon casque micro (webcam si on veut) main libres!
Chat écrit: multi-tache, n’interromp pas la personne, choses en //, historique
mais des fois quiproquo, à lever rapidement en réunion vocal
(lire slide)
Fuseaux horaire (1h décalage): préciser la timezone (heure de rdv). Mieux: mettre les 2 horaires pour moins d’ambiguité.
Langue: francais roumain, anglais (langue communue).
Historiquement français, ne pas isoler les Roumains.
Doc écrit: Anglais (pour que tout le monde puisse relire, n’exclure personne).
Oral: on s’adapte, la langue commune.
cours d’Anglais payé par l’entreprise.
-> On perd quand même un peu, quand les personnes sont pas à l’aise en anglais, ils vont moins participer, plus se retenir.
[questions qui utilise outils chats, vocal, casque micro]
d’avoir des personnes proactives et autonomes. marchera pas avec gens attentistes, veulent pas prendre de décisions.
Anecdote: l’intégration d’une autre équipe , qqun voulait pisser du code, pas etre responsable de ses bugs ou tester
Dev d’une autre équipe en observation, surpris qu’on soit agile et qu’on ait des regles (mais on les choisis ou les change!)
Notes :
Piochez des idées, essayé et adaptez à votre équipe, il n’y a pas de recette toute faite qui marche.
Merci,
Questions (en direct, après, email..)