Présentation effectuée par Charles-André Bouchard, dans le cadre du cours LOG3000 conduit par Mathieu Lavallée, à Polytechnique, mardi le 22 novembre 2016.
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 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
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
9. 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
10. 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
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
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 »
19. 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 »!
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é
25. Gestion du backlog et du flux de travail
Gratuit ou abordable
• Tableau et post-its
• easyBacklog
• Hansoft A³
Payant
• Atlassian JIRA
• Axosoft
• Blossom
29. 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!
30. Comment prioriser un backlog?
• Par risque?
• Par urgence?
• Par coût de délai?
Assurez-en la constance, la transparence et la maintenance!
31. 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é!
32. 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
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)