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:

Tester du Legacy Code, mission impossible ?

Dans nos accompagnements techniques, nous observons régulièrement des problèmes de Legacy Code, aussi appelé Code Patrimonial. Ces problèmes surviennent notamment lorsque des équipes font un virage Agile et qu’on leur demande soudainement de faire des tests unitaires automatisés. Pas si facile que ça, car le système en question n’a pas été prévu pour des tests unitaires.
C’est ce qui nous a donné l’idée de monter une présentation en abordant le sujet avec les points suivants :
  • Description de quelques techniques pour nous aider à tester le Legacy Code.
  • Comment avoir le droit de travailler sur du code pour le rendre plus facile à travailler?
  • Quelques pratiques et outils afin de s’en prémunir autant que possible, au jour le jour.
Voici les disapositives utilisées:
Cette présentation a été donnée aux dates suivantes:
  • 10 Novembre 2016 – Beer And Learn (Québec)
  • 16 Novembre 2016 – Agile Tour Montréal
Si vous avez des questions ou besoin de plus amples explications, n’hésitez pas à m’écrire.
Karl Métivier
kmetivier@facilite.com

Le Manifeste du BDD

BDD Manifesto

On voit des manifestes un peu partout ces jours-ci. Étant un passionné de BDD (Behavior-Driven Development), je me disais que cela serait pertinent d’en faire un à ce sujet.

L’objectif, pour moi, est de pouvoir résumer rapidement la technique avec des exemples, et surtout de faire prendre conscience que le BDD n’est pas une histoire d’outils avant tout. En fait, l’outil peut même s’avérer facultatif et arriver dans un deuxième temps.

Bref, afin de comprendre rapidement ce qu’est le BDD, voici mon manifeste :

Combler le fossé de communication entre le domaine d’affaires et le développement
plus que
Développer sans connaitre les objectifs et la vision affaires

L’équipe de développement est responsable de la qualité
plus que
C’est la responsabilité du testeur

Se valider fréquemment à l’aide d’exemples et d’explorations
plus que
Découvrir les bogues plus tard dans le processus de développement

Obtenir une documentation vivante des spécifications de notre système
plus que
Avoir une documentation lourde et coûteuse  à mettre à jour

Avoir des communications efficaces, rapides et avec des perspectives différentes
plus que
Travailler de manière hiérarchique et en silos

Établir des scénarios et des exemples concrets, accessibles et abstraits
plus que
Établir des scripts de tests détaillés et complexes

Automatiser l’exécution des tests fonctionnels
plus que
Réaliser manuellement tous les tests fonctionnels

Qu’en pensez-vous ?

Vos commentaires et critiques sont très appréciés afin d’améliorer ce manifeste.

Vous voulez en savoir davantage ? Il y aura une formation pour le côté fonctionnel et technique « Introduction au BDD » bientôt chez notre partenaire AFI.

Autres manifestes:

Références BDD:

Notes de lecture : Lean Change Management

Nous avons beau avoir de bonnes intentions, être passionnés d’Agilité et dévoués à nos clients, mais l’humain étant ce qu’il est, il est fort difficile de prévoir comment il peut changer !

Comme dans tout bon projet informatique, on ne peut donc pas tout prévoir en détails la planification de la gestion du changement. Pour surpasser les résistances et obtenir des implémentations de changement avec succès, on doit donc adapter les techniques traditionnelles de gestion du changement en y mettant un peu d’Agilité et du « lean ». On ne peut pas tout savoir ou prévoir au départ et il nous faut l’accepter. On doit donc se baser sur les principes et valeurs Agiles pour guider nos actions dans le changement.

C’est le sujet principal du livre « Lean Change Management – Innovative Practices for Managing Organizational Change » dont je vais vous parler aujourd’hui.

Son auteur, Jason Little, est un canadien, ancien développeur et maintenant conseiller en gestion du changement, il a mis à l’épreuve les différentes techniques décrites dans son livre pour une organisation publique canadienne.

Bien que ce soit un petit livre, il fait un peu moins de 200 pages, ce dernier est quand même rempli de processus, frameworks, conseils et autres outils pertinents pour une gestion du changement « lean » et Agile. Tout cela s’articule autour du cycle intitulé « Lean Change Management » que voici :

lean-change-cycle

En gros, voici ce que veut dire chaque étape traduite librement en français:

  • Aperçus (Insights): Comprendre l’état actuel des choses dans l’organisation. Pour collecter cette information, il y a plusieurs méthodes et outils tels que : sondages, entretiens, rétrospectives, etc. Une fois toutes ces informations recueillies, il faut les analyser dans sa vue globale et voir les options à essayer.
  • Options: Les options à mettre en action ont toutes un coût, une valeur et un impact. Prendre celles qui font le plus de sens dans le contexte actuel afin de valider les hypothèses émises.
  • Expérimentations: Introduire un changement via une option et voir comment il en résulte. Cette étape a aussi le sous-cycle suivant :
    • Préparation: Préparer à valider nos hypothèses et notre approche avec les personnes affectées par le changement.
    • Introduction : Le changement est introduit dans le processus.
    • Révision : On regarde les résultats après un certain temps. Selon ce qui s’est passé, on peut prévoir un autre cycle d’expérimentation.

Dans les premiers chapitres du livre, on introduit rapidement le cycle et ses origines. Pour le reste du livre, on décrit en détails chacune des étapes du cycle avec, bien entendu, les commentaires et l’expérience vécue de l’auteur. Ce qui en fait un livre captivant et intéressant à lire. Lors de sa lecture, il nous arrive de prendre note de plusieurs éléments et conseils qui pourront nous servir en tant que coach Agile. Tout ceci est valable autant pour des changements de processus que pour l’adoption de nouvelles techniques telles que le TDD. Un « must » donc à lire pour tout coach Agile impliqué dans une transformation Agile.

En résumé, voici mes trois leçons apprises suite à cette lecture:

  • Utiliser un cycle basé sur le feedback pour mesurer le changement.
  • Impliquer les gens affectés par le changement dans la conception du changement.
  • Bien mesurer nos options. Chacune d’entre elles a un coût, une valeur et des impacts.

Références :

Ce que l’on a retenu de l’Agile Tour Québec 2015

Comme chaque année, l’Agile Tour Québec est une journée spéciale. En plus de formations et conférences, c’est une belle occasion d’avoir des échanges intéressants et de renouer avec d’anciens et de nouveaux collègues. Voici donc les faits saillants que nous avons retenus de cette journée:
Conférence Principale
L’expert de l’Agilité disciplinée, Scott Ambler, était de passage en tant que conférencier principal. Il a bien sûr discuté sur son approche, DAD, surtout au niveau entreprise.
  • On ne peut se limiter qu’à Scrum. On doit s’élever davantage, notamment  au niveau de l’entreprise.
  • Afin de s’élever, il faut avoir une pensée tactique et stratégique.
  • Comment réagiriez-vous si Google essayait de prendre votre business ?
  • Chaque {personne, équipe, organisme} est unique. On ne peut donc appliquer la même recette à tous.
  • Même chose pour les « lifecycle » de nos systèmes informatiques, un format ne convient pas à tous.
  • Bon conseil: toujours faire les choses les plus risquées en premier.
  • Important: l’équipe doit être au courant de la vision d’entreprise.

[slideshare id=54900825&doc=disciplinedagileenterprise-151109100627-lva1-app6892&w=650&h=500]

Lean/Kanban/Kaizen
Le lean est toujours présent à l’Agile Tour sous une forme ou l’autre. Comme par exemple:
Kaizen ou amélioration continue:
  • Petits changements simples que l’on peut contrôler 
  • Pas une responsabilité du gestionnaire, mais plutôt celle des équipes; le gestionnaire encourage cette responsabilité et la catalyse.
  • Ludifier une initiative d’amélioration continue permet de mobiliser les gens.
  • Il faut impliquer les équipes dans la ludification en leur faisant définir les règles et le système de récompense.

 

User Expérience (UX)
Le UX avait une bonne présence cette année avec 2 conférences. Voici en gros ce que l’on a retenu:
  • Le UX, c’est une forme de mentalité dans le processus de développement
  • La recherche se veut :
    • Efficace
    • Efficiente
    • Satisfaisante
    • Compréhensible
  • Le UX est composé de plusieurs techniques qui se regroupent dans les thèmes suivants:
    • Prototypage
    • Analyse d’affaire
    • Design visuel
  • Aller voir les utilisateurs pour réaliser le bon produit afin d’obtenir une meilleure adoption
  • Important de récompenser les échecs, cela nous permet d’apprendre
  • 3 saveurs au UX: Traditionnel, Agile et Lean
  • Bref: L’expérience humaine prime avant tout !
Pratiques Techniques:
Plusieurs sujets divers parlant du coté technique tels que:
L’excellence technique:
    • Nous sommes dans l’ère de la créativité désormais. Sommes-nous prêts ?
      Pour soutenir cette créativité et rester compétitif, il faut être capable de s’adapter rapidement. Pour cela, il faut mettre la qualité du code en priorité.
    • La connaissance est maintenant partout et les choses se complexifient
    • Besoin d’avoir une main d’oeuvre passionnée et curieuse car nous tendons vers une société axée sur le logiciel
    • Les pratiques d’extrême programming sont un préalable à l’Agilité, le code doit être Agile pour être Agile. Scrum et XP sont complémentaires.
    • L’excellence ce n’est pas d’être parfait mais d’être passionné, curieux (il questionne et n’est jamais satisfait du statu quo..) et créatif.
    • Vaut mieux embaucher une personne excellente que 10 mauvaises, l’embauche est la chose la plus importante.
Processus de développement:

Innovmetric a implanté de nouvelles pratiques afin de pallier à ses problèmes qui ralentissaient le développement :

    • Implantation de l’Agilité afin de faciliter la communication dans le cadre du développement et le bon travail d’équipe
    • Des outils ont été implantés afin de :
      • Tester quotidiennement la performance en mesurant le temps d’exécution des fonctionnalités.
      • Détecter la mauvaise utilisation de pointeurs et références en C++.
      • Valider les dépendances entre les modules/projets qui ont été implantés.
      • Enregistrer la pile d’appels dans un fichier dès qu’une exception anormale a lieu.
    • Les tests unitaires automatisés et de simulation de clics, sont exécutés sur une grande variété de systèmes d’exploitation et sur des comptes utilisateurs Windows ayant des droits d’accès variés.
    • Se sont dotés d’une politique pour que 10% des tâches des sprints soient consacrées à l’amélioration continue du système, et 90% pour le développement standard de nouvelles fonctionnalités.
    • L’intégration continue permet de connaître facilement la cause d’un impact négatif sur les tests automatisés ou sur un écran utilisateur. Il suffit de voir quels fichiers ont été modifiés depuis la dernière compilation/exécution des tests et d’analyser le tout afin de connaître la cause du problème et le correctif requis.

Au final, ça rapporte d’implanter ces processus:

    • Les coûts de développement sont maintenant moins grands qu’au départ.
    • Les employés sont plus heureux compte tenu qu’ils travaillent en collaboration et dans un cadre d’amélioration continue.
    • L’embauche et la formation de ressources est plus facile, compte tenu que le système est entouré de processus clairs et fiables.

Bref, dans l’ensemble les conseillers de Facilité Informatique ont bien apprécié cette journée. On a déjà hâte d’être à l’an prochain pour découvrir de nouveaux sujets afin d’améliorer notre Agilité.