Blog

2017-07-04

DevOps, l’apogée de l’Agilité?

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:

Devops_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:

Devops_pas_outils

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:

devops_dev_op

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:

devops_pas_dev_op

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:

devops

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:

  • Développement: livraison d’incrément du produit;
  • Opérations: stabilité, fiabilité et sécurité;
  • Affaires: exigences en constante évolution pour obtenir de meilleurs produits et des clients contents.

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:

  • Passer de 2 à 4 livraisons par année est un objectif très louable;
  • Automatiser graduellement les trucs effectués manuellement pour gagner continuellement en productivité;
  • Se bâtir une suite de tests automatisés sur nos composants de logique d’affaires;
  • Etc.

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.

devops2

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:

2017-05-31

Estimer, oui mais comment?

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’estimateur est un outil de mesure

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).

Lire la suite

2017-05-18

Revenu Québec et l’Agilité se distinguent lors du gala ANALYZ de l’IIBA

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.

 

2017-05-10

Avez-vous l’impression que l’agilité a atteint un plateau dans votre organisation?

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 :

  • Une utilisation des approches Agiles localisée aux équipes de développement.
  • Un déploiement de l’Agilité appuyé seulement par Scrum.
  • Une inattention à l’impact culturel du changement provoqué par l’Agilité.

Lire la suite

2017-04-27

Architecture / Préparation express à Agile Québec

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é!

2017-04-18

Le livre blanc de notre démarche Kanban

Une démarche simple pour vos équipes en quête de performance !!

DemarcheKanban

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 !!

livre
2017-04-11

Attention au glissement du risque

(english follows)

En gestion de projet, atteindre la prédictibilité est un élément clé du succès et son bloquant majeur est le risque. Pour contenir ce dernier lors de la préparation d’un projet, nous prenons grand soin de gérer la quantité de risque inclue dans la portée. En ne voulant rien laisser au hasard, nous augmentons ainsi nos chances de succès en travaillant sur ce risque en début de projet. Lorsque que le risque est résolu ou sous contrôle, nous pouvons enfin tourner notre attention vers la prédictibilité.

N’est-ce pas bizarre alors de voir des ajouts volontaires de risques supplémentaires pendant le projet?

Ceci peut s’expliquer via un comportement de compensation du risque poussant les gens à faire moins attention lorsqu’ils se sentent en sécurité. Cet effet, combiné avec la pression de livrer un maximum de fonctionnalités de qualités, peut nous pousser à prendre des risques supplémentaires en remplacement de ceux qui sont résolus. J’appelle ceci “remplir sa dette de risque”, étant donné que les membres de l’équipe agissant de cette façon sont similaires aux gens qui utilisent leur crédit de façon impulsive. Au même moment, pour certains membres du projet, une baisse de pression sur le risque peut être interprétée comme un signe de perte d’opportunité. Pour résoudre ceci, on doit se concentrer à maintenir un effort constant et soutenable, alors qu’au même moment, on doit accepter une oscillation dans le niveau de risque alors que le focus fait des allers-retours entre le développement et le déploiement.

Le risque est sournois, car il fait toujours partie du développement logiciel, nous désensibilisant ainsi de sa présence et de son importance et aussi parce qu’il prend deux formes : le risque connu, qui peut faire partie de la planification, et les risques inconnus, qui nous surprendront sur le chemin. Plusieurs de ces risques inconnus seront bloquants, nous forçant ainsi à investir un temps précieux pour les résoudre alors que, et nous devrions prendre avantage de ce fait, nous avons le choix d’accepter, gérer ou, plus particulièrement, rejeter les risques connus.

Livrer la vision en résolvant les risques engagés devrait donc toujours surpasser l’ajout de risque additionnel.

Phillipe Cantin

—

Beware of Risk Creep

When managing a project, achieving predictability is a key element of success and one of its major impediments is risk. To curb this problem while preparing for a project, we take great care, managing the amount of risk accepted in the scope. Not willing to leave anything to chance, we further improve our odds by tackling this risk early in the project which, once removed or under control, clears the way for predictability.

How funny then, to see new risks being purposefully added during a project production.

One reason explaining this is the Risk Compensation behavior, when people tend to be “less careful if they feel more protected”. This effect, combined with the pressure to deliver a maximum of quality features, can drive us to take on new risks as the existing risk is removed. I call this “Maxing out the risk” since team members acting this way are similar to people feeling compelled to max out their credit. At the same moment, for some people, a drop of pressure on risk can be interpreted as a sign of lost opportunity. To resolve all this, we must concentrate on maintaining a constant and sustainable effort level while, at the same time, accepting an oscillation in the risk level as the focus goes back and forth between development and release.

Risk is a sneaky thing as it is always a part of software development, desensitising us to its presence and importance. It is also sneaky as it comes in two shapes: the known risks, which can be part of the planning, and the unknown risks, which will surprise us along the way. We don’t have a choice but to deal with the unknowns [risks] as they pop up here and there during the project, and we should take advantage of this fact. We have a choice to either accept, manage or, especially, reject known risks.

Shipping the vision while resolving the engaged risks should always trump the addition of new risk.

Phillipe Cantin

2017-04-04

Propulser le système au-delà de ses limites connues !

image2017-3-6_15-32-11.png

Propulser le système

Nous proposons actuellement notre démarche Kanban afin d’appuyer une organisation dans l’implantation de Kanban.

La démarche que l’on a créée se décline en 3 Jalons, est alignée sur les 6 Pratiques Kanban de la méthode et est supportée par une Roadmap de Gestion du Changement.

Vous pouvez relire le premier billet de la série intitulé : Des passionnés de Kanban. ainsi que celui consacré au premier jalon :INTRODUIRE, puis le second : STABILISER.

Cette semaine, nous vous amenons au dernier jalon : PROPULSER.

PROPULSER – « Propulser le système »

L’objectif de ce jalon est d’outiller l’équipe pour qu’elle soit en mesure d’optimiser son travail, ses processus et ses règles pour ainsi être en mesure d’augmenter la valeur d’affaires livrée à sa clientèle.

Dans ce jalon, les conditions sont réunies afin de maximiser l’utilisation des métriques et des techniques de prédictibilité avancées qui permettent de contrôler l’impact des contraintes internes et externes.

Optimisation fine

image2017-3-28_21-41-49.png

L’assistant chimiste au célèbre professeur :

Professeur, est-ce le moment d’ajouter 3 ml de potassium dans la solution, comme hier ?

L’éminent savant de s’écrier :

Surtout pas, malheureux ! Hier, la température de la pièce était un degré plus basse…

Aujourd’hui, si nous ajoutons plus de 1,5 ml de chlorure de potassium, le laboratoire risque d’exploser !!

Une fois que l’on connait bien son système, on doit agir dessus en optimisation fine.

Lorsque l’on comprend son environnement, on peut en absorber les éléments de variabilité petit à petit dans le système pour en diminuer l’impact.

Description du jalon

À l’intérieur de la démarche, un jalon est un ensemble d’outils et de techniques à mettre en place afin d’atteindre une cible. Un jalon se décline en 6 sections, soit une pour chacune des pratiques de la méthode Kanban.

Une liste d’éléments de gestion du changement est attachée à chaque section. Ces éléments doivent être pris en compte pour appuyer l’implantation de Kanban et s’adressent à 4 clientèles:

image2017-2-17_9-52-52.png image2017-2-17_9-53-0.png image2017-2-17_9-52-31.png image2017-2-17_9-52-42.png
Équipe  Gestionnaire  Client  Partie prenante

Pour atteindre la cible du jalon, l’ensemble de ces outils et techniques ainsi que l’exécution des éléments de gestion du changement doivent avoir été complétés avec succès. L’objectif de la démarche n’est pas de décrire de façon détaillée l’implantation, mais de structurer les éléments principaux afin de laisser place à l’adaptation au contexte d’une équipe. Chez Facilité, la philosophie est ancrée dans le pragmatisme. Ce que nous conseillons est toujours en fonction du contexte dans lequel on intervient. Le rythme, la portée et la vélocité du changement sera variable d’un contexte à l’autre.

Cible du jalon

La cible visée est la suivante :

  • Priorisation par la valeur
  • Processus en optimisation
  • Prévisibilité basée sur des métriques avancées

Visualiser le processus

  • Optimiser le processus
  • Élargir la portée du système (en amont et/ou en aval)
GESTION DU CHANGEMENT

Équipe

Gestionnaire

Client

Partie Prenante
S’approprier le processus

X

 

 
Gérer le système et le travail, plutôt que les équipiers

 

X 

 
Élargir la portée du système

 

X 

 

  X

Limiter le travail en cours (WIP)

  • Maximisation des limites de travail en cours (WIP)
GESTION DU CHANGEMENT

Équipe

Gestionnaire

Client

Partie Prenante
Faire évoluer les valeurs de WIP afin de maintenir le niveau de service

X

 

 

 

Optimiser le flux de travail

  • Analyser l’efficacité du flux (Flow Efficiency Diagram)
  • Planification à l’aide des simulations de Monte Carlo
  • Analyse des sources de blocage (Blocker Clustering)
GESTION DU CHANGEMENT

Équipe

Gestionnaire

Client

Partie Prenante
Faire la guerre aux bloquants

X

 X

 

 
Identifier les temps d’attente et optimiser le système (Flow Efficiency)

 X

X 

 

 X
Prévoir le futur avec la méthode de Monte Carlo

 X

 

 

 
Comprendre les nouvelles ententes de service basées sur les données probabilistes (Simulations Monte Carlo)

 

 

 X

 

Rendre les règles explicites

  • Priorisation par la valeur
GESTION DU CHANGEMENT

Équipe

Gestionnaire

Client

Partie Prenante
Comprendre, définir et respecter la valeur définie par le client

X

 
Exprimer la valeur des éléments de travail et prioriser en fonction de celle-ci

 

 

  X  

Identifier les cadences

  • Cadencer les livraisons
GESTION DU CHANGEMENT

Équipe

Gestionnaire

Client

Partie Prenante
Comprendre les besoins afin de livrer au moment optimal pour le client

X

 X

 

X 
S’impliquer pour assouplir les contraintes qui freinent les cadences de livraison

 

X 

 

 
Comprendre les cadences de livraison implémentées par l’équipe

 

X 

 X

 X

Améliorer en continu

  • Prioriser l’amélioration à travers un carnet d’amélioration
  • Découpler la cadence d’amélioration et faire de l’amélioration en continue
  • Utiliser des katas d’amélioration
  • Identifier les sources de gaspillage
  • Instaurer une culture de Kaizen
GESTION DU CHANGEMENT

Équipe

Gestionnaire

Client

Partie Prenante
Mettre de l’avant les initiatives d’amélioration continue et mesurer l’impact des changements

X

 

 

 
Encourager les actes de leadership et d’auto-organisation de l’équipe

 

 X

 

 
Impliquer dans l’amélioration continue

 

 X

 X

X 

À suivre prochainement

Lorsque votre équipe aura atteint les objectifs de ce jalon, elle maitrisera un grand ensemble de pratiques et d’outils qui lui permettront de maintenir un système stable, prévisible et en optimisation continue.

Pour vous remercier de nous avoir suivi tout au long de cette série de blogs sur notre démarche Kanban, nous vous offrirons prochainement LE LIVRE BLANC DE LA DÉMARCHE KANBAN de FACILITÉ.

Nicolas Mercier
Valéry Germain