Meetup FSUG-FKUG - Scrumban : Retour d'éxpérience chez Mappy

940 vues

Publié le

Retour d'expérience de la mise en place de Scrumban chez Mappy

0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

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

Aucune remarque pour cette diapositive
  • Bienvenue
    Sujet de la présentation : passage du Scrum au Scrumban chez Mappy équipe mobile.
    Se présenter :
    François Auger Scrum master de l’équipe mobile Mappy depuis T4 / 2015
    Alexandre Billon Manager et Scrum master de l’équipe mobile Mappy en 2013 et 2014 / Facilitateur – coach agile chez Soat
  • Scrum en théorie :
    A chaque fin d’itération, nous devons disposer d’un incrément du produit qu’il est possible de mettre en production, non ?

    Un jour j'irai vivre en Théorie, car en Théorie tout se passe bien …
  • Organisation de la DT par équipe technique / compétences techniques

    Equipes techniques services et produits
    Cœur de métier création de la carte (DATA), recherche d’adresses et calcul d’itinéraires
    COPS / vues immersives
    BOSS / recherche de Point of interest POI (Back Offices Services)
    Web / applications Web + Web mobile
    EMB /Equipe Mobile Embarqué Equipes techniques services et produits
    Equipes spécialistes du développements => test AQL.

    Equipes techniques transverses :
    AQL (Assurance Qualité Logicielle)
    Infrastructure
    BI (Big Data)
  • EMB = 2 équipes et ½ : iOS, Android, et SAM serveur d’applications mobiles (Python / Tornado)
    4 Android et 6 iOS

    Et les produits :
    Mappy Maps iOS (iPhone / iPad)
    Mappy Maps Android
    SDK iOS et son application d’exemples => Solocal
    SDK Android et son application d’exemples => Solocal
  • Le développement d’application mobile est complexe et contraint. Il exige un haut niveau de qualité.
    Le mobile est un extension de l’utilisateur ce dernier ne tolère pas les pannes et souhaite des mises à jour régulière.
    L’application Mappy est connectée au service de la plateforme de services Mappy.

    Classement contraintes externes / internes
  • Fin 2012 / 1er trimestre 2013 => Refonte v4 + plateforme de services + SDK + application
    Itération de 2 semaines
    Utilisation du board classique : 1 board iOS et un board Android
    Sortie de tunnels de 9 à 12 mois. Les équipes sont plus petites 2 Android et 4 iOS (dont 1 SAM)
    Du point de vue de l’agilité tout est en place en terme de cérémonies (hormis les revues de sprint).
    L’équipe met en œuvre quelques pratiques XP : IC, TU / TF sur le serveur d’application mobile / livraison continue sur dev.
    Bus factor sur le développement SAM


  • 3 IT de dev pour 2 IT de tests / corrections / stabilisation

  • 2013 - releases trimestrielles :
    Grande qualité des rétrospectives notamment techniques qui tirent les évolutions sur le process.
    Evolutions des pratiques agiles :
    Le SM s’entête à rendre visible les anomalies avec un board dédié Board puis ajout du flux d’anomalies dans les boards respectifs => éponger la dette technique
    Identification du rôle nécessaire de testeur référent pour l’équipe mobile présent 2 ½ journée par semaine dans l’équipe
    Suppression du bus factor sur SAM : l’équipe choisie => 2 développeurs iOS et 1 Android montent en compétence et développent sur SAM
    Passage de 2 à 3 boards Android SAM et iOS
    => SAM mieux l’amener.



  • 2014 Suite des releases trimestrielles refonte iOS v5
    Ajout de cases à cocher sur les stories :
    jusqu’à 5 cases : assets dispos, TU, TF, Code Review, Tags, mini demo

    Apparition de :
    d’éléments de la notions de prêt assets …
    pratiques XP
    notion de terminé / validé sur les cartes


  • Ajout d’une ligne code review pour le flux des user stories / la case à cocher n’étant pas respectée… => pb de bande passante
    Et … pourquoi pas une colonne de plus => Definition of done => CD qui arrive.
  • Préparer le Continuous delivery pour 2015 :
    Passage en flux
    Testeur référent à 80% dans l’équipe qui participe à la DOD
  • Continuous delivery pour 2015 :
    Passage en flux
    Testeur référent à 80% dans l’équipe qui participe à la DOD

  • Defi 2015
    Cycle d 1 mois
    Raccourcir les temps de release
  • Pour assurer la qualité, test en continue
  • Private et public store
    Git flow
    jenkins
  • Travaile sur la DOR avec l équipe
    Qualité des stories en entrée
    Reduction du temps de sprint planning
  • Nouveaux board
    Organisé par ligne de devs
    Limite la ou c ’est nécessaire
    Visualisé les tests
    Test QA toujours géré par batch
  • Contexte plus simple : delai défini, scope variable
    SDK windows phone
    Sprint léger
    Pas d’estimation
  • Meetup FSUG-FKUG - Scrumban : Retour d'éxpérience chez Mappy

    1. 1. Mappy mobile Une brève histoire de boards De Scrum à Scrumban F. Auger & A. Billon
    2. 2. Petit rappel théorique …
    3. 3. Contexte DT Mappy • Le projet UrbanDive (Mappy « Street view ») introduit la mise en place de l’agilité et en particulier de Scrum à la direction technique • « Fusion » des équipes Mappy et UrbanDive => équipes Scrum WEB EMB BOSS CDMCOPS AQL INFRA BI
    4. 4. Mappy équipe mobile L’équipe mobile = 2 équipes et ½ : plateformes mobile + SAM Et 4 produits : • Mappy Maps iOS (iPhone / iPad) et Android • SDK iOS et Android et leurs applications d’exemples
    5. 5. Contraintes mobiles Internes Externes Disposer d’un store d’application Supporter un délai de re-livraison standard d’une semaine sur iOS Offrir un niveau de qualité irréprochable en production Gérer un parc hétérogène d’OS et de smartphones Ouvrir le réseau Wifi & 3G interne de tests pour accéder aux services Anticiper les évolutions rapides des devices et OS Gérer la rétro compatibilité / montée de versions Disposer des ressources graphiques pour les différents résolutions d’écrans Tester en conditions réelles / extérieures
    6. 6. Board fin 2012 Situation fin 2012 – T1 2013 / Refonte V4 (applications / SDK) Avec un board Scrum « classique » A faire En cours TerminéStories TâcheTâche Tâche TâcheTâche Tâche TâcheTâche Tâche Tâche Tâche Story Story Développements Développements MEPDéveloppements DéveloppementsDéveloppements Recette Recette Bloquants seuls Soumission Publication
    7. 7. Evolutions 2013 2013 Releases trimestrielles - évolutions v4 Développements Développements Développements Recette MEP Développements Développements Version 4.X+1 Version 4.X Soumission Publication
    8. 8. Evolutions 2013 TâcheTâche Tâche TâcheTâche Tâche TâcheTâche Tâche Tâche Tâche Story Story Priorité A faire En cours Terminé Anomalies Urgences Bug. Bug. Tâche Tâche Bug. Tâche
    9. 9. Evolutions 2014 La « carte » des user stories s’enrichie : REF # Cx 13 As a « user role » I want « function » so that « value » Assets Tags TU TF Code review Mini démo
    10. 10. Evolutions 2014 TâcheTâche Tâche TâcheTâche Tâche TâcheTâche Tâche Tâche Tâche Priorité A faire En cours Terminé Anomalies Urgences Bug. Bug. Tâche Tâche Tâche Code review Story Story Story Story
    11. 11. Fin 2014
    12. 12. Fin 2014
    13. 13. Pas-sage de Témoin
    14. 14. Evolutions 2015 2015 release mensuelle Développements Dev / Recette MEP Développements Version 5.X+1 Version 5.X Soumission Publication
    15. 15. Eat your own dog food - Version alpha : daily - Version beta : monthly - Version prod : monthly
    16. 16. Nos outils Stores Gestion de conf Integration continue
    17. 17. En Amont : DOR - Ce qu’on fait maintenant (Éléments graphiques, critéres d’acceptances...) - Ce qu’on fera plus tard (Tests QA en amont, Identifier les APis serveurs..) - Ce qu’on ne fera jamais (Les specs couvrent tous les cas, Architecture détaillée…) PO Devs Testeur + +
    18. 18. Agile Board En Cours Demo Code Review Test QAA faire Stories DefinitonofDone Definitionofready Bug. Bug. Stories Stories Stories Gestion par batchLimit max = 31 story ou bug / pers Bug. Bug. Tâche Tâche Test Urg ent Stories Stories
    19. 19. L’experience Full Kanban - #NoSprint - #NoEstimate - (toujours une retro) - Gain de temps - Adhésion des développeurs - Souple / flexible - Perte de visibilité pour le PO - Outils de visualisation plus difficiles
    20. 20. De Scrum à Scrumban Un passage « naturel » pour respecter la « promesse » de Scrum :  Livrer une application en production à la fin de chaque itération même dans un domaine aussi contraint que celui du développement mobile.  Pour apporter régulièrement de la valeur au produit donc aux utilisateurs Tout en continuant à s’améliorer ensemble :  Techniquement : en visualisant les pratiques XP  Process : en faisant apparaître les activités en amont et en aval

    ×