L'Agilité chez GEE Montréal

L’Agilité chez GEE Montréal

Charles-André Bouchard, B. ing.Product Owner – IFE – GEE Montréal

[email protected]

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

L’Agilité logicielle, concrètement

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

Charles-Andre Bouchard

Demander à l'auditoire leur propre définition avant de procéder.

Comparatif avec le dé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


Mettre l'accent sur la comparaison entre le waterfall et l'agile. Les précisions sur chacune des caractéristiques viendront après.

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


Exemples de facilités pour agir : les itérations réduisent le temps nécessaire pour obtenir un feedback.Disponibilité : les cérémonies Scrum.

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


Léger : rappeler le manifeste Agile (communication sur documentation)Souple : notion de négociation avec les stakeholders.

Autobiographie de l’équipe Productivité

Bref aperçu de GEE 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

http://www.geemedia.com/

Le noyau de Productivité

• 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


Mentionner que ces préceptes sont ceux qui ont persévéré au cours des trois versions de l'équipe.

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


Souligner que les vieilles applications n'avaient pas plus que 5 ans, donc que la notion de "legacy" n'est pas nécessairement temporelle.Préciser que ce fut mon année la plus formative en Agile/Scrum.

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


Préciser que ce fut une année d'endurcissement et d'expériences, avec un roulement de personnel plus élevé.Préciser que ce fut l'année de ma transition de développeur à PO.

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


Préciser qu'il s'agit d'une année de défi, considérant les priorités multiples et le manque de personnel.Souligner que la communication et la priorisation efficaces en deviennent encore plus importants.

« S’agiliser » : mythes et pièges

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


Les méthodes Agiles servent à optimiser l'ingénierie logicielle.Le soutien des gestionnaires non-techniques est apprécié, mais cela ne doit pas sombrer dans de l'interventionnisme.P#1: Les "pas trop" signifient que l'équipe et le projet doivent avoir une importance pour que les gens prennent la démarche à coeur, mais sans condamner l'équipe en cas de problèmes majeurs.P#2: différentes personnes travaillent différemment et auront des réactions différentes à l'Agilité. Rappeler que l'Agilité se base sur la "vraie vie".

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


P#1: on "s'agilise" pour réduire l'inefficacité des activités et des transitions entre activités.P#2: insister sur le fait que l'Agilité donc plus de pouvoir aux développeurs, donc plus de responsabilité. Ce n'est PAS fait pour ceux qui veulent "se la couler douce".

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 »


P#1 : Le PO ne gère pas son équipe dans le contexte de la cellule Scrum ou Kanban; il gère le produit.P#2: Il faut laisser l'équipe accumuler assez de données pour obtenir un portrait de sa vélocité.

Scrum, Kanban… Scrumban?

Quelques clarifications…

• Il n’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 »!


Exemples de divergences :- Lors de la fondation d'une nouvelle équipe Agile, bien souvent, il y aura un Scroduct Ownster.- Connaissance de soi = self-awareness. "Qu'est-ce qu'on essaie de faire?" "Comment on travaille présentement?" "Quels sont nos bons et mauvais coups?"

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)


Le but est de montrer qu'il y a des similitudes entre les deux méthodologies principales. Si les étudiants sont déjà au courant, passer vite là-dessus.

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


Ajouter que pour une équipe nouvelle et peu expérimentée, Scrum est rassurant, au prix d'un peu de souplesse.

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é


Préciser que Kanban est moins "perturbant" lorsqu'amené dans une équipe existante et/ou dans un contexte chaotique.

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é


Passer assez rapidement sur Scrumban, afin de donner plus de place à la suite.Se servir de cette diapo pour montrer qu'il faut être agile au sujet de l'Agilité.

Les outils essentiels

Gestion du backlog et du flux de travail

Gratuit ou abordable• Tableau et post-its

• easyBacklog

• Hansoft A³

Payant• Atlassian JIRA

• Axosoft

• Blossom


Préciser que les outils en souligné sont ceux avec lesquels j'ai personnellement travaillé, tandis que les autres sont des suggestions prudentes.Encourager les étudiants à essayer plusieurs outils dans des phases de test, pour des preuves de concept. Contrebalancer en mentionnant qu'il est préférable d'utiliser avec constance un outil imparfait que de sauter d'outil en outil.Mentionner que chacune des trois catégories d'outils pourrait faire l'objet d'une présentation complète.Concernant le backlog : choisir l'outil qui permet à l'équipe la meilleure maintenance, le plus de transparence et de complétude.

Intégration continue

Gratuit ou abordable• Jenkins

• BuildBot

Payant• QuickBuild

• Team Foundation Server

• BuildMaster


Concernant l'intégration continue : pour se laisser le plus de temps et d'esprit à l'évolution agile, il importe d'implémenter ces outils le plus tôt possible.Parallèlement, c'est plus difficile à implémenter après-coup.

Documentation

Gratuit ou abordable• MediaWiki

• DokuWiki

Payant• Atlassian Confluence

• Jive


Un wiki permet de centraliser toute la documentation au sujet d'un produit, que ce soit de la documentation d'usage ou de la documentation technique.C'est un des outils qui donne le plus de crédibilité à une équipe Agile et qui rassurer les parties prenantes.

Discussion ouverte

Que faire avec l’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!


Piège à éviter : estimer les tâches "parce que".Demander à l'auditoire leurs expériences avec les estimés.

Comment prioriser un backlog?

• Par risque?

• Par urgence?

• Par coût de délai?

Assurez-en la constance, la transparence et la maintenance!


Demander à l'auditoire comment ils priorisent de leur côté, et les irritants rencontrés.L'estimation par coût de délai et par temps de développement permet davantage de métriques, mais requiert plus de temps et d'expérience.

Quelle est la place 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é!


Demander à l'auditoire comment ils assurent le QA dans leurs produits.Préciser l'importance de formaliser le processus de QA, car cela peut donner confiance aux parties prenantes.

Autres questions?

• Tests unitaires

• 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

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

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://books.google.ca/books?id=Y6oKCgAAQBAJ&num=19



https://www.amazon.ca/Agile-Product-Management-Scrum-Customers/dp/0321605780

https://books.google.ca/books?id=ik0qCTVzl44C&num=19&source=gbs_book_similarbooks

http://www.scrumguides.org/scrum-guide.html

Merci de votre attention!

L'Agilité chez GEE Montréal

Software

Transcript of L'Agilité chez GEE Montréal