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