Téléchargé 11 fois
Agile talk 2017
- 1. Comment rester Agile dansune équipe multi-sites et multi-langues Cyril Couffignal
- 2. Introduction Motivations: - Partager mavision - Un retour d’expérience - Une approche pragmatique Cyril Couffignal
- 3. Plan - Organisation del’équipe - Cycle de vie et quotidien - Communication (inter-sites…) - Méthodologie adoptée Cyril Couffignal
- 4. Organisation de l’équipe 2008 Front/back CyrilCouffignal 5~9 personnes 30 ~ 35 personnes - Evolution historique 2017 Multi-équipes
- 5. Project Organisation de l’équipe CyrilCouffignal team D team F team A team E team B team C
- 6. Project Organisation de l’équipe CyrilCouffignal team D team F team A team E team B team C TECH SUBJECTS
- 7. Project Organisation de l’équipe CyrilCouffignal 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 CyrilCouffignal Scrum Master - point de contact / administratif - une casquette interchangeable - occupe 15~30% du temps
- 9. Cycle de vieet quotidien Cyril Couffignal
- 10. Cycle de vieet 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 vieet 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 vieet 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
- 13. Cycle de vieet quotidien Cyril Couffignal
- 14. Cycle de vieet quotidien Cyril Couffignal
- 15. Cycle de vieet quotidien Cyril Couffignal Créativité et cohésion d’équipe : - Hacking Week: 2 fois par an - Team building - Déplacements pour travail co-localisé
- 16.
- 17. Communication Cyril Couffignal Sollicitation immédiate Communicationpassive, 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 quiest important pour notre équipe: - Communiquer - Encourager les initiatives - Tout le monde est acteur, propose, argumente - Etre réactif et s’adapter au changement
- 19. Comment rester agile CyrilCouffignal « Soyez acteur de votre agilité » Fin ccouffignal@axway.com
Notes de l'éditeur
- #2 bonjour Expliquer rouages équipe 30 pers , 3 sites, 3 langues 2 fuseaux horaires
- #3 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
- #4 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
- #5 (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..
- #6 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
- #7 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
- #8 des rôles transversal aux équipes (PO, architect, QA lead, Sustaining, func-referent, ..). (8:00)
- #9 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
- #10 (lire titre) Peu de process =/= sans organisation Bon d’avoir routine, automatisme Mais savoir remettre en cause, proposer nouvelles idées
- #11 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)
- #12 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
- #13 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
- #14 exemples
- #15 Reflète la personnalité de l’équipe, différent d’un équipe à l’autre (23:00)
- #16 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
- #17 Évident, pas toujours simple, surtout équipe distribuée (25:00)
- #18 (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]
- #19 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!)
- #20 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..)