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

Article publié précédemment sur ExcellenceAgile.com

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:

Publicités

Notes de lecture : Lean Change Management

Article publié précédemment sur ExcellenceAgile.com

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

Bloggeur sur ExcellenceAgile.com

stamp_logo

Avec mes collègues de Facilité Informatique, je suis bloggeur sur le site ExcellenceAgile.com.

Je vous recommande fortement de suivre ce site qui contient déjà plusieurs billets fort pertinents sur l’agilité en général. Ces lectures bénéfiques vous donneront des perspectives différentes basées sur notre travail chez nos clients.

Je vais aussi continuer d’écrire des billets ici sur KarlMetivier.Net et y reproduire certains que j’aurais composés sur ExcellenceAgile.com.

Au plaisir de vous y voir comme lecteur et n’hésitez-pas à commenter nos billets afin de participer à la discussion !

Être réviseur de livres techniques

Savez-vous qu’il possible de faire partie des réviseurs d’un livre technique en cours d’écriture ?

Cela vous demande un peu de temps et de donner un feedback constructif à l’auteur. Est-ce que vous avez besoin d’être un expert pour faire une revue de code ? Non, pas vraiment. Il faut surtout être intéressé par le sujet et bien gérer son temps. Il faut parfois respecter des dates cibles pour envoyer nos commentaires.

Les avantages ?

La maison d’édition vous donne en général une copie gratuite du livre et vous avez votre nom inscrit dans la liste des réviseurs quelque part dans le livre. Vous aurez aussi la satisfaction d’avoir aidé l’auteur à rédiger son livre. C’est quand même très bien.

Et peut-être aussi qu’ils choisiront une de vos citations et l’afficheront à l’arrière du livre. C’est que Manning Press a fait dernièrement pour le livre « BDD in action ». C’est assez flatteur, pour mon cas, de retrouver son nom et celui de son employeur à côté de Dan North, inventeur du BDD.

BDDInActionSi être un réviseur technique d’un livre vous intéresse, regardez les liens suivants:

Agile Tour Québec 2013

ATKiosk

Le 6 novembre dernier, a eu lieu la 5e édition du Agile Tour Québec. Étant bénévole, j’ai eu la chance d’assister à de belles conférences et aussi y faire de bons échanges avec les participants et présentateurs. Cette année, nous avons franchi le cap des 500 participants, ce qui est très bien pour la ville de Québec. Et encore une fois, de bons présentateurs sont venus donner leur temps pour nous parler de développement Agile.

Et voici le récapitulatif de ce que j’ai vu et entendu:

Rapid and Lasting Agile Adoption (conférenc principale)

J’ai été plus ou moins attentif à cette présentation étant donné l’effervescence du début de la journée et de l’inscription. Mais j’ai retenu quand même plusieurs points intéressants:

  • Passer d’une méthode de travail à une autre est comme un genre de deuil.
  • Un rite de passage est utile pour favoriser l’adoption « Agile » dans la culture d’entreprise.
  • Les gens doivent s’engager, idéalement, au lieu de se faire imposer une nouvelle manière de travailler.

Le conférencier a formalisé le tout autour du principe de « Open Agile Adoption ». Je trouve très intéressant tout cela et cela a plein de bon sens de faire des rencontres ouvertes ponctuelles pour discuter de l’adoption agile. On retrouve ici dans le schéma suivant l’essentiel de ce principe:

OAnA-fig1large1

Pour plus de détails, consulter les sites suivants:

À vos marques, prêts, codez!

Format un peu inusité pour cette présentation:

  • 2 développeurs programment avec sur un écran distinct.
  • Ils utilisent deux langages de programmation différents: le C# et le Python.
  • Un 3e présentateur est à l’arrière de la salle et fait l’animation.

Bien qu’inventif comme format, j’ai plus ou moins aimé. Malgré certains commentaires pertinents de l’animateur, il avait plutôt l’air de quelqu’un qui commente une game de hockey par moment.

Quand on présente un « Code Kata » dans une présentation, j’aime bien quand le développeur pense à haute voix et on peut ainsi comprendre son raisonnement et ses choix. Ce ne fut pas le cas ici. Seulement des interventions occasionnelles de l’animateur en questionnant les développeurs.

Aussi, l’introduction était un peu absente. Mettre le schéma du TDD au début aurait été utile pour certains.

Quelques points intéressants que j’ai notés:

  • Il y a de multiples chemins pour résoudre un Kata
  • Il est parfois utile de se mettre un minuteur pour nous rappeler à l’ordre afin de faire passer un test au « vert ».
  • Lors d’un refactoring ou perfectionnement du code, bien-être certain de l’intention.
  • Lors de l’étape « Rouge » ou faire un test qui échoue, au début il s’agit surtout d’améliorer le message d’erreur.
  • On est rarement assez agressif avec le refactoring.

Bref, un peu déçu, mais quand même bravo aux présentateurs, car ce n’est pas toujours facile de programmer « live » devant plusieurs personnes et d’essayer un nouveau genre de présentation.

Esclave de votre dette technique?

Présentation très dynamique de Pascal Roy et de Félix-Antoine Bourbonnais. Les deux gars sont des passionnés !

Les faits saillants:

  • Quadrant de la dette technique de Martin Fowler pour savoir quelle genre de dette technique on a affaire.
  • Des outils existent pour aider à identifier notre dette technique, comme la duplication par exemple.
  • Ne pas négocier votre dette
  • Faire du refactoring dans des endroits gagnants.
  • Prendre la responsabilité de cette dette.
  • Faire son bilan.
  • Chérissez votre code !

Voici la présentation intégrale sur Slideshare:

Javascript : Tester le code oublié

Bien que loin d’être un expert Javascript, j’ai fait à l’occasion, mais vraiment pas souvent, j’ai quand même aimé cette présentation.

L’interaction entre les deux présentateurs, Vincent Crépin (l’architecte) et Jean-Nicolas (le développeur) était intéressante. On voyait ainsi la réflexion de quelqu’un qui commence s’intéresser au Javascript avec l’aide d’un autre qui en mange tous les jours.

Les faits saillants:

  • Tester les fonctions qui sont au coeur du langage
  • Jasmine est le framework recommandé pour faire des tests style TDD/BDD. Il est assez simple de l’installer et de commencer à s’en servir.
  • Le concept de « closure » peut paraître complexe au premier abord, mais est très important à maîtriser.
  • Knockout.js est un framework Javascript intéressant pour faire une interface web avec le patron Model-View-ViewModel (MVVM).

Plus qu’une équipe : bâtir une entreprise Lean

George Saad a toujours des choses intéressantes à raconter. Cette fois-ci, c’est un peu plus personnel, car il nous explique le fonctionnement de sa boîte de développement web: Spektrum Media.

Avec une équipe réduite d’une dizaine de personnes où pratiquement tout le monde fait du code, il est possible d’être efficace outre les budgets.

En appliquant les principes Lean de bout en bout de son entreprise, il se permet de brasser la cage et de compléter des projets bien en deçà des budgets préliminaires. Comment fait-il exactement ?

  • Évite le gaspillage au maximum.
  • Se permettre de choisir les projets, car la demande est plus grande que l’offre de service de son entreprise.
  • Trouve le juste milieu entre le prix et la qualité
  • 1 seul développeur est nécessaire pour l’évaluation de la proposition. Par la suite, un analyste/chargé de projet y met son grain de sel.
  • Procède toujours en commençant petit, morceau par morceau, afin d’obtenir le feedback ou rétroaction le plus rapide du client. De cette manière, on valide régulièrement si on est sur la bonne voix et si cela vaut la peine de continuer.
  • Côté recrutement, cherche les meilleurs développeurs, le genre qui se foutent un peu du langage et de la technologie.

J’aime particulièrement le concept du « vendredi innovation ». À cette journée, les employés travaillent sur des projets personnels à moins qu’il y ait du retard dans un des projets pour des clients. Quand cela arrive, c’est une forme d’indicateur de gestion indiquant qu’il y’a peut-être des problèmes à l’horizon.

Référence:

Top 5 – Lectures 2012

J’ai fait plusieurs lectures en 2012 et sur des sujets diverses. Je vous propose ici une compilation Top 5 des meilleurs ouvrages liés au domaine de l’informatique que j’ai lu dans le courant de l’année 2012:

1. Software Architecture for Developers par Simon Brown

Excellent résumé de ce que fait (et devrait faire) un architecte logiciel et comment partager sa structure et sa vision à l’équipe. L’auteur, Simon Brown, nous montre son côté pragmatique dans cette vue d’ensemble. J’ai apprécié particulièrement les parties sur le rôle d’architecte et la façon de concevoir et de communiquer le logiciel.

On y parle aussi de l’agilité et de son impact sur l’architecture ainsi que la notion qu’un diagramme UML n’est pas toujours nécessaire. Noter que ce livre est publié de manière indépendante sur « Leanpub » et est toujours en évolution. Un « Must » à lire pour tout développeur ou un architecte logiciel!

Lien du livre sur LeanPub

 

2. Specification By Example par Gojko Adzic

Gojko Adzic nous a écrit un 2e livre sur les spécifications.  Son premier, Bridging the communication gap, était surtout de nature théorique. Cette fois-ci, on nous présente les expériences de personnes et organismes différents avec l’utilisation de la spécification par l’exemple. En plus de cela, nous voyons comment Gojko a fait évoluer sa pensée sur la spécification et après quelques chapitres, nous allons au-delà des notions de base.

Soit dit en passant, ce livre ne parle pas de code ou d’outils. Seulement des principes et des pratiques utilisées pour communiquer les spécifications dès le début d’un projet logiciel jusqu’à sa fin.
Un des beaux résultats de cette approche est que tout le monde dans une équipe de développement logiciel travaille à avoir une « Documentation vivante » au lieu d’un tas de papiers classés quelque part dans un classeur.

Je recommande cette lecture à toute personne impliquée dans la création de logiciels. En particulier si utilisez les approches suivantes:  Behaviour Drive Development (BDD), Acceptance Test-Driven Development (ATDD), Test-Driven Development (TDD) et le Domain Driven Design (DDD).

Liens commandités du livre sur Amazon : France | Canada | USA

 

3. Techical Blogging par Antonio Cangiano

Si vous êtes sérieux à propos des blogues, ce livre est pour vous. L’auteur, Antonio Cangiano, couvre de nombreux aspects liés à l’écriture de blogue tels que la planification, la création de contenu, la promotion, le référencement, les avantages et les médias sociaux. Certains aspects sont directement liés à l’outil de blogage WordPress, mais la plus grande partie du contenu de ce livre peut être appliqué à n’importe quel type de blogue.

Liens commandités du livre sur Amazon : France | Canada | USA

 

4. Steal like an Artist par Austin Kleon

L’auteur, Austin Kleon, nous donne 10 règles pour développer notre créativité. Ces règles peuvent être utiles à toute personne, artiste ou non. En fait, pourquoi voler comme un artiste ? Parce que rien n’est original finalement… Le livre est aussi magnifiquement illustré et le papier utilisé pour imprimer le livre est de grande qualité. Le résultat: un excellent livre sur la créativité et la productivité qui se lit très bien. Inspirant !

Liens commandités du livre sur Amazon : France | Canada | USA

 

5. Impact Mapping par Gojko Adzic

Un 2e livre de Gojko Adzic dans mon Top 5 (eh oui !). Celui-ci est un peu différent toutefois. En fait, il s’agit plutôt d’un guide qu’un d’un livre en soit. L’auteur nous présente une technique pour mieux comprendre, mesurer et aligner les objectifs de l’entreprise avec la planification de la livraison d’un produit logiciel. Voici le « Impact Mapping » qui est une sorte de schéma heuristique (ou « Mind Map ») pour représenter les aspects suivants: But (pourquoi), Acteur (qui), Impacts (comment) et  le Livrable (quoi). Aussi, le livre est magnifiquement illustré. Je recommande vivement d’obtenir la version papier.

Liens commandités du livre sur Amazon : France | Canada | USA

Agile Tour 2012: Les sessions Partie 2

Voici mon compte rendu des sessions de l’après-midi lors de l’Agile Tour Québec 2012. La partie 1 est ici.

Le Programmeur Lean Startup par Olivier Gourment

Olivier Gourment nous a offert une bonne présentation avec quelques touches d’humour. Parfait pour ne pas s’endormir après le repas du midi. Trois thèmes principaux étaient présentés. Les voici donc avec mes commentaires:

  • Lean Startup : Une introduction au Lean Startup est faite ici en expliquant le cycle « Construire – Mesurer – Apprendre ».  Le but dans un Lean Startup est d’apprendre le plus rapidement possible afin de construire le produit minimal viable. Très intéressante approche, que ce soit pour une entreprise en démarrage ou un projet interne dans une compagnie bien établie.
  • Code: Le code est souvent trop « gras » et nous ralentit. Il faut alors l’amincir avec du « Refactoring ». On fait la revue de quelques autres bonnes pratiques de programmation. Classique, mais toujours bon d’en faire le rappel.
  • Programmeur: On parle ici qu’il faut un peu du rôle de programmeur dans la vie de tous les jours. Olivier recommande d’adopter les pratiques d’ingénierie agile, prévoir la formation continue. Il a mentionné aussi un fait avec lequel je ne suis pas totalement d’accord: avoir des juniors dans notre équipe pour permettre l’innovation. Je crois davantage que l’on peut innover à tout âge. Pour favoriser l’innovation, j’irais en ayant simplement une équipe diversifiée et variée avec des gens différents, peu importe l’âge.

En conclusion, plusieurs sujets très intéressants ont été survolés. Mais je trouve que les sujets manquaient un peu de profondeur par moment. Aussi, les liens entre les trois thèmes principaux sont plus ou moins directs, mais bon ce n’est pas trop grave. Bonne prestation d’Olivier Gourment somme toute.

Références :

Le rôle de l’Architecte Agile par Jean-René Rousseau et Mathieu Boisvert

Sujet fort intéressant pour moi. Je ne pouvais me résoudre à aller voir toute autre présentation.

Question intéressante posée d’amblée: peut-on faire de l’architecture en amont en Agile ? Bien sûr que oui, on peut en faire un peu. L’architecture est quand même nécessaire afin d’avoir un aperçu des risques et complexités des problèmes à résoudre. Les approches Agiles occasionnent plusieurs impacts sur le rôle de l’architecte. Deux ont été ciblés et discutés lors de cette présentation:

  • Émergence et Incrémentalité: Il s’agit ici de bien balancer Anticipation et Adaptation afin de, sans trop tout détailler, avoir une architecture souple et ouverte aux changements.  On parle aussi d’établir des patrons de démarrage de projet. Aspect intéressant qui a été mentionné aussi: prévoir une stratégie pour gérer et planifier les considérations d’architecture.
  • Collaborer avec les équipes: L’architecte a son lot de responsabilité au sein d’une équipe. Il se doit de prévoir une stratégie de communication et accompagner son équipe. Il arrive souvent qu’il doive s’occuper de plusieurs projets en même temps. Mais, si la disponibilité le permet, la meilleure place pour lui est d’être équipier. Et je suis très en accord avec ce point. Ainsi, en étant équipier, il pourra davantage transmettre son savoir, guider l’équipe et aussi programmer à l’occasion. Ou mieux, faire de la programmation en paire histoire de se mettre à jour et faire un transfert de connaissance. Car un architecte qui ne code jamais risque de devenir un architecte dans sa tour d’ivoire.

Un problème que je remarque parfois dans les organisations, c’est que l’architecte logiciel est davantage un titre qu’un rôle.  Au lieu d’être un titre attribué, l’architecte logiciel ne devrait-il pas être un rôle, comme le ScrumMaster, qui est attribué selon le projet et peut changer à l’occasion ? J’imagine bien une équipe de programmeurs qui fait la rotation de ce rôle ou encore mieux, que ce rôle soit partagé par tous les membres de l’équipe. Cela ferait de très bons échanges de connaissances tout en permettant à tous de faire du code régulièrement. Bon, c’est peut-être une idée utopique, mais bon, cela fait du bien d’en parler.

Bref, malgré le fait qu’on dirait par moment que nous avons davantage le point de vue d’un architecte fonctionnel que d’un architecte logiciel, plusieurs points intéressants ont été amenés dans cette présentation. J’espère que d’autres présentations de ce genre suivront, car je crois que le sujet mérite d’être encore débattu, discuté et approfondi.

Références :