Qui sommes nous? Richard: Directeur TI, commerce électronique et développement chez Transat. Transat, est un voyagiste intégré, spécialiste du voyage vacances. Établie au Canada et présente dans plusieurs pays, depuis plus de 25 ans. Samir: Président de Sabbel Conseil, firme offrant des services dans le développement Web et Agile Ayant participé activement à l architecture et au développement des plateformes web de Transat depuis 2008. 1
Transat fait du développement agile depuis 2008. Nous avons adopté cette pratique à l occasion d une refonte du site web www.airtransat.ca. Site transactionnel générant plusieurs 100M$. Au début, le contexte était simple, nous avions un seul projet, un seul objectif. Cette refonte a été réalisée en 8 mois de développement et fût un succès. Suite à la première livraison en 2008, la solution WEB, qui était, au début, en mode projet, est passée en mode opérationnel auquel nous avons ajouté, à l occasion, une multitudes de projets. Il pouvait y avoir jusqu à 2 ou 3 projets en même temps en plus des activités opérationnels quotidienne normale. De plus, au fil du temps, la solution WEB déployée simplement sur www.airtransat.ca fut réutilisé sur les autres sites de la famille Transat, tel que www.vacancestransat.com et www.nolitours.com. Ce qui a encore une fois complexifié l écosystème. Par-dessus tout ceci, ce mode de développement agile a dû être inséré dans le processus de livraison d un groupe TI d une entreprise de plus de 5000 employés 2
dont 200 en TI. Autrement dit, dans un processus parfois lourd et pas nécessairement agile. On pourrait dire que nous étions agile pendant la phase de développement mais pas durant les phases précédant ou suivants le développement. Bref, à la fin 2014, le cycle de livraison de la plateforme WEB était devenu complexe à gérer et comportait beaucoup de tâches apportant peu ou pas de valeur à l entreprise! Un réalignement s imposait! 2
Donc en 2014, Transat se donne pour mission de simplifier son cycle de livraison WEB. En résumé, de 2008 à 2014 nous avons optimisé la façon dont ont faisait le développement en ajoutant de l agilité, maintenant on se donne pour mission de revoir le cycle complet en ajoutant un peu de Lean à tout ceci. Le Lean pour nous c est la réduction ou l élimination des tâches, souvent répétitives, tout au long du processus qui apporte pas de valeur à la solution. Pourquoi sommes nous ici? Samir et moi avons pensé qu il serait intéressant de partager avec vous notre expérience d optimisation/simplification du cycle de livraison WEB chez Transat. Cette activités est actuellement en cours depuis maintenant plus de 11 mois. Dans un premier temps nous allons vous expliquer pourquoi un peu de Lean était necessaire et ensuite nous allons vous démontrer comment nous avons procéder. En espérant que certains éléments que vous allez voir dans cette présentation pourront s appliquer à vous également! 3
Voici à quoi pouvait ressembler, schématiquement, ce cycle de livraison avant janvier 2015 Au début, en 2008! 1 projet 1 backlog 1 date de livraison 1 branche Forme une équipe SCRUM Demande si un environnement est disponible ou en monte 1 déploiement manuel (long), demande a un admin Fin du DEV = on passe aus tests (QA/UAT) Forme une équipe de test (QA/UAT) Monte 1 environnement demande a un admin Fin des tests (QA/UAT) = une MEP On remplie un formulaire de demande de MEP On réserve les ressources nécessaire Et On déploie! Ici, c était la version simple! On continue Plusieurs projets/initiatives = 4
#backlog = #dates de livraisons = #branches = #équipes scrum = #environnements = #équipes de tests = #environnements de tests = #MEP = #demandes de MEP = #réservation de ressources = Finalement, #rétrofit sur plusieurs branches! Les bugs étaient souvent trouvés tard dans le processus. La vie était beaucoup moins belle maintenant! Anecdote: Nous avons eu un bug (P1) en production. La création des environnements nécessaires pour corriger le bug nous avait pris 1 journée et demie environs alors que la correction du bug lui-même était une question de 2h. On voyait bien que nous avions un problème auquel il fallait remedier. 4
- Méthode scientifique basée sur les mesures des résultats - On regarde ce qui ne va pas et on fait des hypothèses toujours avec le concours des développeurs et autres personnes directement impliquées - On expérimente des solutions et on mesure les résultats. - On rectifie le tir et on continuer soit à améliorer, laisser tomber ou encore prendre de nouvelles initiatives 5
Sur le long terme, nous avons catégorisé les bugs en 3 catégories simples: fonctionnels, régression et faux bugs. Nous suivons l évolution de ces types de bugs; nous suivons l évolution des chiffres pour voir si la qualité s améliore ou pas et aussi selon les types de bugs qui augmentent, on prend des actions pour les diminuer; par exemple, au début nous avions beaucoup de bugs de régressions, nous avons donc pris la décision de faire des tests UI automatisés (on parlera plus tard de nos conclusions). Aussi, on a décidé de faire plus de tests avec les développeurs avant de livrer. A la fin parler du fait que nous avons mis en place une équipe de deux personnes qui sont a 100% dédiées a améliorer l outillage. 6
Maintenant, après plusieurs iterations, revues et améliorations, voici une description du processus version allégée - Plusieurs projets pour Un seul backlog unique - On priorise le backlog - On determine le contenu des livrables. Tous les items du backlog doivent être insérés dans les livraisons déjà cédulés à des dates fixes. - Le développement de chaque iteration est démarré un la suite de l autre. Nous avons du changer notre façon d utiliser notre gestionnaire de sources afin d optimiser son utilisation dans se context (ex.: GIT, modèle de branche, passage à TFS sur le cloud (VSO)) - L équipe SCRUM est maintenant en mesure de se créé un environnement à jour et 100% fonctionnel en quelques cliques sur le cloud grâce à l automatisation via des scripts. - On passe sur l environnement QA à l aide d outil optimisé pour un déploiement rapide et sans faille. - À la dernière étape, l équipe responsable du déploiement en production passe à l action en déployant sur l environnement de production toujours en utilisant les mêmes outils d aide au déploiement. 7
- Une des clés du succès de ce processus fut sans nul doute d avoir dédié des ressources pour la création d outils de build, déploiement et test afin d améliorer ce processus en continue. 7
- VSO : Nous devions migrer vers 2012 ou 2013 tout en sachant qu une nouvelle version (2015) allait sortir bientôt. À chaque migration, nous devons passer environs 2 à 3 semaines à mettre en place la nouvelle version. Avec VSO, nous avons accès aux dernières fonctionnalités sans avoir à gérer nous-même les mises à jour et l infrastructure qui s y rattache. - Malgré le fait que ça soit en mode SaaS, VSO offre une très bonne performance aussi bien pour consulter les backlog que pour faire des mises à jour de code (checkin et checkouts). - Ayant tous des licences MSDN, nous n avions pas à payer un supplément pour utiliser VSO - Nous avons même la possibilité de connecter des serveurs build locaux sur VSO - Après 10 mois d utilisation, les développeurs et gestionnaires en sont très satisfaits - Azure: Cela a été un élément crucial; - l équipe de développement a le contrôle complet sur les environnements de développement. - Nous pouvons créer de nouveaux serveurs de développement préconfigurés en moins d une heure (40 minutes) chiffre a vérifier puisque cela a changé 8
- On peut scaler up les machines quand on en a besoin (augmenter les processeur, la mémoire.) - Notre souscription Azure nous coûte moins de 2000$ par mois (souscription MSDN). - Octopus Deploy : Nous avons remisé nos scripts de déploiement pour utiliser un outils complet de gestion des déploiements: Octopus. Cet outils nous permet de déclencher les déploiements à partir d une interface commune (plus besoin de se logger sur les serveurs de productions) et présente un bon dashboard pour afficher l état de tous les serveurs dans tous les environnements. Il permet aussi de définir des paths pour les déploiements de manière à toujours suivre le même processus. - Beaucoup de PowerShell. La gestion des machines sur Azure, les déploiements dans Octopus sont tous basés sur du PS. Les connaissances dans PS et les librairies Azure sont essentielles dans un tel projet. - Outils maison: - Nous n avons pas hésité à mettre de coté des outils qui avaient demandé beaucoup d heures de développement mais qui n étaient plus adaptés à nos besoins - Nous avons créé des outils intermédiaires qui nous ont été utiles une courte période de transition. Le but était que les personnes concernées par les déploiements n aient pas à payer le prix d une phase de transition - Nous avons créé un portail qui contient plusieurs outils dont la création a été incrémentale : On créé un outil et on observe si vraiment il est utilisé et comment; quand on constate sont efficacité, on l améliore et on rajoute des fonctionnalités, sinon, soit on comprend pourquoi on ne l utilise pas et c est arrivé qu on laisse tomber une fonctionnalité car en bout de ligne, elle ne fait pas gagner autant de temps que cela. Un travail itératif. - Faire attention aux détails: temps de build de la solution par exemple temps de création des machines enfin, on est dans un processus d amélioration continue. 8
D autres ingrédients ont aussi pesé très lourd dans la balance afin d allégé le processus En cours de route nous avons parfois misé sur des éléments importants, mais pas toujours aussi payants que nous l aurions pensé. Par exemple, nous aurions cru que d automatiser les tests UI a eux seul, nous assurerais de livrer de la qualité. Notre expérience nous a montrer que ce n est pas aussi vrai que nous le pensions. Comprennez bien que les tests UI sont utiles, mais en même temps nécessitent beaucoup d efforts pour les mettre en place et les maintenir et qui donnent un résultat pas si élevé comparé aux efforts déployés! Les autres ingrédients, tel que: 1- Definition du DONE 2- Définir explécitement une tâche de validation afin de valider un user storie dans sa globalité. 3- Faire une mini-revue ad-hoc une fois qu un user storie est terminé Avant d ajouter ces ingredients, l équipe avait tendance à compter sur le passage au QA 9
pour la validation de la qualité de ce qu elle développait. Ce qui arrivait effectivement, cependant, les anomalies étaient trouvés très tard dans le processus. Ce qui ammenait beaucoup d inéfficacité! Bref, il ne faut pas négliger les détails; un petit changement peut donner des gros gains De plus, il faut constamment Mesurer, Mesurer et Mesurer afin de comprendre son processus - il est difficile de s améliorer si on ne le connaît pas ou pas suffisamment. 9
Après quelques mois et les changements apportés, nous pouvons remarquer que la courbe des bogues trouvés en DEV (courbe bleue) est monté en dessus de celle représentant les bogues trouvés en UAT (courbe orange). Nous avons atteint un de nos objectifs qui était de trouver un maximum de bogues le plus tôt possible. Évidemment, on continue nos efforts afin de réduire au maximum les bogues trouvés en QA et Acceptance. En chiffres relatifs (pourcentages), nous sommes passés de 33% des bogues trouvés en DEV (pendant le sprint de développement) à 58%. Du même coup, nous sommes passés de 48% des bogues trouvés en QA à 22%. Le pourcentage de bogues trouvés en Acceptance est resté stable (20%). Nous allons devoir trouver de nouvelles ameliorations afin de le voir diminuer. 10
- Les livraisons a date fixe nous ont apporté plus de prévisibilité. - Avec l utilisation d Azure, l équipe est plus autonome et perd moins de temps à attendre après une autre ressource. - Exemple, le temps de déploiement a été réduit sur toute la chaîne. Avant, un développeur pouvait prendre 1 journée à 1 journée et demi pour déployer en développement. Maintenant on déploie en moins d une heure! - Moins de déploiements == moins de paperasse pour les équipes de mise en production - La qualité des fonctionnalités arrive plus vite! 11
1- Acceptation du changement Livraison à dates fixes imposes que les projets doivent s insérer dans le calendrier! Utilisation du Cloud il est important de rencontrer les groupes impliqués tel que les network admin, le groupe de sécurité pour leur expliquer notre but. Bien communiquer notre objectif aide beaucoup! Introduction de nouveaux outils ou nouvelles façon de faire encore une fois, il est important de simplement rencontrer les gens impliqués afin de leur expliquer notre objectif. 2- Suivre au quotidien notre progression Il est primordial de mettre en place des tableaux de bord afin de suivre notre évolution (positive ou non) à travers le temps. Il faut Mesurer, mesurer et encore mesurer Dans notre cas, nous avons suivi, par exemple, les éléments suivants: -le temps de déploiement; -la quantité de bug trouvés et quand; -la catégorie de bugs trouvés; -les dates de livraisons 3- Contrôle de la qualité 12
Afin d optimiser notre cycle de livraison, nous nous sommes vite rendu compte que nous devions mieux contrôler la qualité de ce qui était livré. Au début, à partir de nos métriques mises en place, nous avons remarqué que beaucoup de bugs était détectés tard dans le processus (fin du cycle de QA voir même en UAT). Cet enjeu reste notre préoccupation première et nous la suivons constamment depuis le début de l initiative. 4. Dédier des ressources à temps plein à l outillage Il a fallu convaincre nos patrons qu il était préférable de dédier des ressources pour développer de outils d aide à l équipe de développement. Même si il y avait un cout important associé à ceci. Ce fût l une des meilleurs décisions que nous ayons prise. Ça permet de s assurer que ces outils soient développés tout en gardant l équipe focusé sur ses objectifs. 12
Lean peut s appliquer à l outillage mais aussi au développement en utilisant des PaaS au lieu de développer tout en inhouse. Implanter un processus de test automatisé (TestUI ou UnitTest) prend beaucoup de temps et on doit changer les façons de faire de l équipe de développement. Les testui sont très complexe à mettre en place surtout sur un site dont l interface est constamment en train de changer. Le coût élevé de la mise en place de ce type de tests nous fait hésiter à continuer sur cette voie. Nous allons observer si les tests actuels vont avoir un bon ROI. Toute optimisation peut engendrer des gains très importants à long terme; Par exemple, lors de la migration vers Git, nous avons constaté que les builds prenaient plus de 30 minutes pour toute la solution (en utilisant les templates off the shelf). Nous l avons réduit à moins de 10 minutes (tests compris) en modifiant le template de base - c est un enjeux important surtout pour les build continues qui valident les mises à jour du code. Ne pas hésiter à mettre à la retraite des outils passés date si cela signifie qu on 13
va optimiser le processus de développement (même les outils in house qui ont une valeur sentimentale). 13
14
15