Télécharger pour lire hors ligne
![Références
• The Scrumban [R]Evolution
• Par Ajay Reddy, publié chez Addison-Wesley Professional, 2015
• Agile Product Management with Scrum
• Par Roman Pichler, publié chez Addison-Wesley Professional, 2010
• The Clean Coder
• Par Robert C. Martin, publié chez Prentice Hall, 2011
• The Scrum Guide
• Par Ken Schwaber et Jeff Sutherland, 2016
• Images et dessins
• Par les internets (rien de tout cela ne m’appartient)](https://image.slidesharecdn.com/agilitegeemontreal-161125000030/75/L-Agilite-chez-GEE-Montreal-34-2048.jpg)
L'Agilité chez GEE Montréal
- 1. L’Agilité chez GEEMontréal Charles-André Bouchard, B. ing. Product Owner – IFE – GEE Montréal charles-andre.bouchard@geemedia.com
- 2. Dans cette présentation… •L’Agilité logicielle, concrètement • Autobiographie de l’équipe Productivité • « S’agiliser » : mythes et pièges • Scrum, Kanban… Scrumban? • Les outils essentiels • Discussion ouverte
- 3.
- 4. Qu’est-ce qu’être «agile »? • Selon Wikitionnaire : « qui a des facilités pour agir ou se mouvoir, dispos, léger, souple. » • Quatre caractéristiques : • Facilités pour agir • Dispos • Léger • Souple
- 5. Comparatif avec ledéveloppement en cascade Cascade • Facilités pour agir? • Rôles statiques et restreints • Attente inévitable entre les étapes • Dispos? • Artéfacts éparpillés • État d’avancement réservé au gestionnaire de projet • Léger? • Documentation lourde et exhaustive • Déploiements massifs et risqués • Souple? • Retours en arrière coûteux • Requis coulés dans le béton Agile • Facilités pour agir • Minimiser les obstacles au développement • Dispos • Favoriser l’amélioration continue et l’introspection • Léger • Prioriser l’efficacité et le savoir- faire • Souple • Accepter le changement et les imprévus
- 6. Ce que l’Agilitésignifie en logiciel (1) • Facilités pour agir • Minimiser les obstacles au développement • Délais d’opinion • Assurance-qualité • Démarche de déploiement • Dispos • Favoriser l’amélioration continue et l’introspection • Revues itératives • Rétrospectives périodiques • Métriques
- 7. Ce que l’Agilitésignifie en logiciel (2) • Léger • Prioriser l’efficacité et le savoir-faire • Intégration continue • Priorisation des tâches • Notifications automatisées • Souple • Accepter le changement et les imprévus • Demandes urgentes • Variation des priorités • Roulement du personnel
- 8. Autobiographie de l’équipeProductivité
- 9. Bref aperçu deGEE Montréal • Global Eagle Entertainment : leader mondial en divertissement et en connectivité pour les passagers aériens et maritimes • ~20 bureaux • ~60 pays desservis • ~1000 employés • http://www.geemedia.com • Équipes Agiles de IFE • Productivité • Framework • Développement
- 10. Le noyau deProductivité • Agir en tant que pionniers de l’Agilité dans le département d’In- Flight Entertainment (IFE) • Comprendre les processus d’IFE et les centraliser dans une solution unifiée • Optimiser la productivité d’IFE
- 11. Productivité 1.0 :2014-2015 • Mandat : remplacer les solutions désuètes de gestion du catalogue de jeux et des livraisons par une solution Web moderne • Des solutions vieilles, mais surtout développées en solo • Une nouvelle équipe • 1 directeur / Product Owner • 1 Scrum Master • 5 développeurs • Liberté de choix • Méthodologies • Technologies
- 12. Productivité 2.0 :2015-2016 • Mandat : intégrer la gestion des facturations à « Firefly », la solution Web précédemment implémentée • Une équipe reconstruite • 1 Product Owner • 1 Scrum Master • 1 expert QA • 3 à 5 développeurs • Évolution de l’équipe 1.0 • Expérimentation de changements au Scrum • Mise à jour et amélioration des technologies
- 13. Productivité 3.0 :2016- • Mandat : optimiser Firefly et y intégrer les processus de GEE Mumbai • Une équipe réduite • 1 Product Owner • 1 expert QA • 2 développeurs • Évolution de l’équipe 2.0 • Transition de Scrum à Scrumban • Optimisations technologiques
- 14. « S’agiliser »: mythes et pièges
- 15. Mythe #1 :« C’est tout ou rien! » • ABSOLUMENT FAUX! • Piège #1 : transformer un département/une entreprise d’un seul coup • Choisir une équipe expérimentée… mais pas trop • Choisir un projet important… mais pas trop • Piège #2 : appliquer la même méthodologie à toutes les équipes • Adapter la méthodologie au contexte de l’équipe • Prendre en compte les préférences des individus
- 16. Mythe #2 :« C’est plus facile qu’en cascade! » • TOUT LE CONTRAIRE! • Piège #1 : assumer que « s’agiliser » consiste à éliminer des étapes • Comprendre l’importance des cérémonies régulières et rigoureuses • Inciter à la participation de tous et chacun au processus • Piège #2 : ignorer les grandes responsabilités d’une équipe Agile • Communiquer clairement avec les parties prenantes • Accepter les suggestions et la critique
- 17. Mythe #3 :« Un P.O. et un P.M., c’est pareil! » • SURTOUT PAS! • Piège #1 : se mettre à assigner les développeurs et les technologies • Suggérer plutôt qu’imposer • Comparer les opinions et viser le consensus • Piège #2 : imposer une cadence à l’équipe • Établir dès le début les métriques simples et efficaces • Laisser les métriques « donner le ton »
- 18.
- 19. Quelques clarifications… • Iln’existe pas de méthodologie « meilleure » que les autres. • La vraie vie ne correspond pas à un Scrum ni à un Kanban « purs ». • La clé : maximiser la connaissance de « soi »!
- 20. Mini-comparatif des méthodologies Scrum •Itérations périodiques (sprints) • Estimés pondérés (story points) • Augmentation de la vélocité Kanban • Parutions circonstancielles (releases) • Mesure du travail en cours (work in progress / « WIP ») • Réduction du délai de mise en œuvre (lead time)
- 21. Considérez Scrum si… •Vous formez une équipe composée d’un Product Owner, un Scrum Master et 5 +/- 2 développeurs • Votre équipe s’occupe la majorité du temps d’un seul projet • Vos parties prenantes sont peu disponibles • Votre volume d’interruptions est généralement bas *sabre laser non inclus
- 22. Considérez Kanban si… •Vous formez une équipe composée d’un Product Owner et de 2 à 4 développeurs, dont un sera le Kanban Master • Votre projet comporte plusieurs parties prenantes et plusieurs sous-projets • Vos parties prenantes sont aisément accessibles • Votre volume d’interruptions est généralement élevé
- 23. Qu’est-ce que Scrumban? •C’est une approche innovatrice qui applique une « couche » Kanban à une « fondation » Scrum • Le principe des sprints est adapté au débit de production réel de l’équipe • L’estimation des tâches est remplacée par une analyse statistique du flux de travail • Intéressant… pour une équipe ayant de l’expérience en Agilité
- 24.
- 25. Gestion du backloget du flux de travail Gratuit ou abordable • Tableau et post-its • easyBacklog • Hansoft A³ Payant • Atlassian JIRA • Axosoft • Blossom
- 26. Intégration continue Gratuit ouabordable • Jenkins • BuildBot Payant • QuickBuild • Team Foundation Server • BuildMaster
- 27. Documentation Gratuit ou abordable •MediaWiki • DokuWiki Payant • Atlassian Confluence • Jive
- 28.
- 29. Que faire avecl’estimation des tâches? • Estimer en heures? • Estimer en story points? • Estimer en story points d’abord, ensuite en heures? • Ne pas estimer? Expérimentez et adoptez la méthode la plus utile!
- 30. Comment prioriser unbacklog? • Par risque? • Par urgence? • Par coût de délai? Assurez-en la constance, la transparence et la maintenance!
- 31. Quelle est laplace du QA en Agile? • À un moment précis d’un sprint? • Dans des sprints dédiés? • Entièrement hors du flux de production? • Effectué par les développeurs eux-mêmes? Peu importe, tant que vous assurez efficacement la qualité!
- 32. Autres questions? • Testsunitaires • Cérémonies Scrum / Kanban • Planification de sprints/releases • Rétrospectives d’équipe • Définition d’un backlog item • Décisions architecturales • Soutien aux usagers • Analyse des besoins
- 33. L’essentiel à retenir •Les principes de l’agilité : • Facilité à agir • Légèreté • Disponibilité • Souplesse • L’importance de l’automatisation, des métriques et des rétrospectives • La nécessité d’être humble, curieux et transparent
- 34. Références • The Scrumban[R]Evolution • Par Ajay Reddy, publié chez Addison-Wesley Professional, 2015 • Agile Product Management with Scrum • Par Roman Pichler, publié chez Addison-Wesley Professional, 2010 • The Clean Coder • Par Robert C. Martin, publié chez Prentice Hall, 2011 • The Scrum Guide • Par Ken Schwaber et Jeff Sutherland, 2016 • Images et dessins • Par les internets (rien de tout cela ne m’appartient)
- 35. Merci de votreattention!