En 1979, Atari lançait le jeu Asteroids… un vrai jeu Agile!
L’utilisation des métaphores et des analogies est une technique de coaching efficace et bien connue. Elle permet de déplacer une personne de son environnement de travail vers un environnement autre, mais familier, et de discuter de concepts tout en réduisant les « oui, mais ça marche pas comme ça ici ». En voici une qui permet d’expliquer un grand nombre de concepts Agile dans un ensemble cohérent: Lire la suite
On parle beaucoup de DevOps ces temps-ci. Mais est-ce qu’on saisit bien toute sa définition et les impacts de son implantation au sein d’un organisme ou une entreprise? Commençons par bien définir le DevOps pour avoir une meilleure perspective que le simple « buzzword ».
Au premier abord, on peut penser que faire du DevOps, c’est tout simplement une histoire d’outils:
Euh, mais non. Bien que certains outils soient nécessaires pour automatiser les aspects de notre livraison en continu, il y a bien plus que cela en jeu. Le fait de choisir des outils, de les l’installer, de les configurer et de s’en servir ne veut pas nécessairement dire qu’on fait du DevOps. Donc:
Poursuivons notre analyse. Si les outils ne règlent pas tout, j’imagine qu’il faut y mettre un peu de collaboration. La collaboration usuelle à laquelle on pourrait facilement penser est bien sûr la suivante:
Tout à fait d’accord avec ceci! D’ailleurs, il faut faire attention si on travaille actuellement en silos (développement et opération) de ne pas répéter la même chose avec DevOps en la mettant elle aussi dans un silo. On n’a pas besoin d’une troisième équipe qui fonctionne ainsi, n’est-ce pas? On a besoin davantage d’unir les forces de l’équipe de développement et de celles des opérations (environnement, sécurité, livraisons, mise en production, etc) afin de plutôt en faire une équipe qui s’entraide mutuellement. Bref, on veut que tout le monde se préoccupe des livraisons en production.
Par contre, je vais être déplaisant et poser ma question de coach:
C’est bon, vous voulez livrer en continu, mais pourquoi? Cela donne de la valeur à qui en bout de compte?
Oups, il nous manque une partie importante dans notre équation! Donc:
La partie affaires (utilisateurs, pilotage, PO, analyste d’affaires) doit aussi être incluse dans notre équation DevOps, ce qui équivaut à représenter le DevOps ainsi:
Il manque ainsi une bonne partie de l’équation si on fait du DevOps sans se préoccuper du côté affaires, avec des éléments tels que:
Les affaires, le développement et les opérations ont tous à la base des objectifs différents:
Le DevOps devrait donc permettre d’aligner ensemble les objectifs de ces trois aspects.
De plus, je vais être à nouveau déplaisant, mais sans l’aspect des tests automatisés, il est très difficile, voire impossible, de faire du DevOps convenablement. Eh oui, il est temps de vous réveiller si vous ne faites actuellement aucuns tests automatisés sur vos systèmes ! Et idéalement, il faut les faire AVANT le code en mode TDD (Test-Driven Development). Cela vous permettra de clarifier les intentions et diriger les efforts avant d’écrire le code de production.
Pour faire des tests automatisés correctement, des approches Agile et un paquet de pratiques d’ingénierie Agile sont aussi très utiles.
Et si on voyait le DevOps comme l’apogée de l’Agilité, soit la poursuite logique de notre transition vers l’Agilité par la maîtrise des approches Agile, qui sont sensés pour nous dans notre contexte, afin de pouvoir livrer en continu? Bref, voir le tout comme un rassemblement de forces (ou pratiques) Agile nous poussant vers le DevOps!
Eh oui, le DevOps est probablement l’objectif ultime à atteindre! Avec lui, on relève toutes sortes de points à améliorer, pas juste au niveau de l’équipe de développement. C’est comme de l’amélioration continue au niveau de l’entreprise ou organisme au complet.
Et la beauté dans tout cela, c’est qu’on a pas besoin de maîtriser toutes les nombreuses pratiques Agile, les valeurs, le Lean Software Development et le Lean Startup pour faire du DevOps. Pas non plus obligé de se développer comme les Amazon et Netflix de ce monde avec leurs méga infrastructures. On peut y aller à petits pas, comme mentionné par Kent Beck dans son XP Programming. Voici quelques exemples:
En fin de compte, il vaut probablement mieux évoluer vers de petites livraisons avec peu de changement que de grosses livraisons avec beaucoup de modifications et de risques. On peut donc y voir ici un très bon ROI potentiel si on investit dans le DevOps.
Quand on implante DevOps, il ne faut pas oublier de voir à pouvoir se remettre d’une mauvaise mise en production rapidement. Il faut ainsi permettre des erreurs dans un environnement sécuritaire pour apprendre et arrêter de faire tout le temps les mêmes choses à chaque mise en production sans se remettre en question.
Il est fort probable qu’un changement de culture soit également nécessaire dans votre entreprise. Mais rien n’est impossible, même chez vous, peu importe le contexte. On peut trouver plusieurs exemples d’entreprises qui ont mis des applications Legacy dans un mode DevOps, notamment afin de les revitaliser.
J’espère que cet article a su démystifier le « buzzword » DevOps qu’on entend régulièrement de nos jours.
Références:
Les ateliers de formation peuvent parfois être un peu trop lisses et manquer des petits charmes de l’imprévu du quotidien… Dans une situation d’apprentissage d’outil ou de méthode impliquant de la répétition, l’ajout d’inattendu dans un atelier peut enrichir celui-ci et renforcer son impact.
Si vous avez depuis quelques temps un tableau Kanban dans votre environnement, il ressemble fort probablement à ceci:
Bon… pas très créatif tout ça!
Voici quelques idées afin de rendre tout ça un peu plus ludique!
Que ce soit lors d’un sprint planning ou dans une réponse d’appel d’offre, l’estimation est essentielle. Peu importe l’unité (t-shirt size, story point, temps en heures, $$$, j/p, etc.), les experts sont appelés à estimer presque quotidiennement. Mais une question demeure: comment mesurer la fiabilité de l’estimation produite par un expert? Est-ce qu’un sénior dans un domaine en fait automatiquement un expert en estimation?
Certains diront qu’il est impossible d’obtenir une évaluation d’une précision acceptable en TI en raison de la trop grande variabilité du domaine (#NoEstimates). Contrairement à la construction, on ne peut mesurer la surface à couvrir et s’appuyer sur des chantiers similaires pour en extrapoler les coûts. Malgré tout, je ne crois pas que la tâche soit impossible.
L’expert estimateur est un outil de mesure au même titre qu’un pèse-personne ou qu’un ruban à mesurer. On s’attend donc à ce qu’il soit précis et exact. Généralement, lorsqu’on demande à l’expert d’estimer, on favorise un seul de ces points puisqu’on lui demande un nombre unique. Il devient alors impossible de déterminer si l’estimé est exact (peu de risque de dépassement) ou précis (proche de l’effort réel).
L’Agile Tour Sherbrooke 2017 est maintenant derrière nous. Facilité est extrêmement fière d’avoir participé à cette première édition.
Merci aux participants et organisateurs qui ont rendu l’événement possible! Ce fût une belle journée bien remplie. Merci également à ceux qui sont venus assister à nos conférences « Architecture/Préparation Express » et « En route vers l’optimisation! Votre succès avec Kanban étape par étape » .
Si vous avez manqué nos conférences ou aimeriez en revoir le contenu, nous nous faisons un plaisir de les rendre disponibles ici.
Si vous avez des questions ou commentaires, vous pouvez communiquer avec les auteurs Éric Lessard et Frédéric Paquet.
Si vous avez des questions ou commentaires, vous pouvez communiquer avec les auteurs Valéry Germain et Nicolas Mercier.
Le 5 mai dernier, dans le cadre du gala ANALYZ de l’IIBA région de Québec, Revenu Québec s’est vu décerner le Prix Graal 2017 pour « La mise en place d’une démarche de réalisation des dossiers d’affaires en mode Agile ». Dans le cadre de nos mandats actuels à Revenu Québec, nous sommes fiers d’avoir eu la chance de contribuer à l’élaboration et la mise en oeuvre de cette démarche innovante.
Félicitations à toute l’équipe de Revenu Québec pour cet autre beau succès lié à vos efforts de transformation Agile.
Une amertume perdure chez certains leaders Agiles : une impression que l’agilité ne va pas au bout de ses promesses et qu’il y a encore beaucoup de place à amélioration. Avez-vous cette impression?
2001 a vraiment marqué un tournant dans l’histoire du développement logiciel avec la parution du manifeste Agile (agilemanifesto.org). À l’époque certains la voyaient simplement comme une mode passagère qui s’estomperait avec le temps. Aujourd’hui, 16 ans plus tard, l’Agile est plus présente que jamais et est maintenant utilisée dans la plupart des organisations qui cherchent à augmenter l’efficience de leurs activités de développement logiciel et s’étend même à d’autres secteurs d’activités.
Malgré ce succès, je constate qu’une amertume perdure chez certains leaders Agile : une impression que l’agilité ne va pas au bout de ses promesses et qu’il y a encore beaucoup de place à amélioration. Avez-vous cette impression ? Croyez-vous que l’utilisation des approches Agiles a atteint un plateau dans votre organisation ? Plusieurs facteurs peuvent expliquer ce phénomène et nous nous attarderons ici sur les trois principaux, soit :
Merci d’être venus en grand nombre assister à notre présentation sur la préparation express qui a eu lieu hier à la mensuelle d’Agile Québec.
Nous sommes heureux d’avoir partagé avec vous cette méthode énergisante et efficace pour démarrer vos projets Agile.
Nous vous invitons chaleureusement à essayer ces outils, nous donner vos commentaires et raconter vos histoires.
Si vous avez manqué la présentation ou aimeriez revoir le matériel, il est disponible ici.
Si vous avez des questions ou avez besoin de plus d’informations, contactez l’équipe de Facilité!
Comme vous avez pu le découvrir depuis notre premier blog de cette série sur Kanban, nous sommes des passionnés recherchant toujours la solution la plus adéquate, la plus efficace pour les équipes que nous accompagnons, supportée par la manière la plus simple et directe pour y arriver. C’est le fruit de notre expertise et de notre expérience que nous partageons aujourd’hui sous la forme d’un livre blanc que vous êtes libres d’utiliser dans vos équipes, de partager autour de vous et d’expérimenter pour vous inspirer !!
Comme des guerriers sans repos, nous avons continué d’enrichir notre démarche après la publication des blogs. Ainsi, vous trouverez dans ce livre blanc des listes de points de validation permettant de mesurer l’atteinte des objectifs de chaque jalon et d’identifier vos angles morts !!
Bonne lecture… et bon succès dans votre implantation Kanban !!
Excellence Agile 