Bienvenue sur Développement Agile

Référence sur le développement logiciel Agile. Nous traitons de conception, de programmation, de pratiques de génie logiciel, d'essais et d'autres sujets connexes.

Les principes Agiles appliqués à la famille

Publié par David Beaumier le vendredi 31 janvier 2014 à 15:07

J’ai récemment eu l’occasion d’échanger avec Marc Allard, journaliste de la région de Québec, sur l’application des principes du développement Agile dans une famille. Marc avait entendu parler de Bruce Feiler, auteur du livre The Secrets Of Happy Families, qui propose de mettre en application plusieurs des principes Agiles au niveau de la famille. J'ai pensé qu'il serait intéressant de partager ce sujet sur le blogue puisque plusieurs lecteurs sont aussi des parents.

Il faut savoir que Feiler cherchait, à la base, des approches qui aideraient à réduire le stress, rapprocher les membres de la famille et favoriser l’autonomie des enfants dans le contexte des familles d’aujourd’hui. Comme nous l’avons fait nous-même il y a maintenant plus d’une décennie en développement logiciel,  Feiler a trouvé dans les principes Agiles des façons de faire permettant d’envisager autrement la dynamique familiale.

Le manifeste des familles agiles

En s’inspirant du manifeste Agile rédigé en 2001, Feiler propose un équivalent pour les familles qui se base sur les 3 grands principes présentés ci-dessous.

1. « Adapt all the times »: Les parents ne peuvent tout prévoir et les enfants vieillissent. Ajustons les règles aux situations que l’on rencontre en cours de route. Ce qui fonctionne bien, on le garde et ce qui fonctionne moins bien, on le révise. L’inspection et l’adaptation est importante pour la famille car les enfants ont tendance à grandir rapidement et à nous sortir hors de notre zone de confort.

Ce principe vise à rendre les parents à l’aise d’essayer de nouvelles approches car celles-ci seront évaluées au mérite et ajustées au besoin, voir même remplacées si nécessaire. Enfants et parents, soyez ouverts aux nouveautés! N’hésitez pas à proposer des idées différentes et laissez émerger les meilleures!

2. « Empower your children » : Établir des objectifs avec les enfants et leur donner la possibilité d’identifier eux-mêmes les moyens pour les atteindre. Par exemple, pour les comportements indésirables on peut demander aux enfants d’identifier quelle conséquence devrait s’appliquer.

3.  « Tell your story » : Trouver une façon d’unir la famille autour de valeurs et d’orientations communes. Qu’est-ce qui est important pour votre famille? Quelles sont les valeurs fondamentales pour votre famille? Ce sont elles qui vous permettront d’établir les principes encadrant la dynamique de votre famille.

Pour Feiler, le bonheur n’est pas quelque chose qu’on récolte, mais plutôt qu’on bâtit. Pour y arriver, il propose de s’inspirer des approches itératives et incrémentales afin d’identifier graduellement la recette gagnante pour votre famille. Je vous invite à écouter la conférence qu’il a prononcée à TED. J’espère que cela sera aussi inspirant pour vous que ça l’a été pour moi.

Références

Parmi les références mentionnées par Bruce Feiler, il y a le cas vécu de la famille de David Starr. Chose intéressante, David Starr a écrit un article détaillé sur la mise en oeuvre des principes agiles dans sa famille Agile Practices for Families: Iterating with Children and Parents.

Voici d’autres références reliées au même sujet :

Et vous, appliquez-vous des principes Agiles dans votre famille? En avez-vous tiré des bénéfices intéressants? N'hésitez pas à partager votre expérience avec les autres lecteurs en laissant un commentaire ci-dessous.

Mots-Clés :

La complexité involontaire

Publié par David Beaumier le vendredi 26 juillet 2013 à 17:07

Comme développeur nous avons tous à lire et surtout, à comprendre le code écrit par d'autres personnes. Que ce soit pour modifier une fonctionnalité existante ou pour effectuer une forme de rétro-ingénierie, il est primordial de ne pas avoir à s'arracher les cheveux de la tête pour comprendre l'intention du code. Or, hélas, trop souvent ce n'est pas le cas.

Il peut y avoir plusieurs causes à cette situation : méthode trop longue, mauvais nommage, non-respect des règles de nomenclature, etc. Ceci dit, je crois que bien souvent le code ne s’est pas retrouvé dans cet état dès le départ. J’aurais plutôt tendance à blâmer la vilaine complexité involontaire. Non, il ne s’agit pas d’une maladie contagieuse ou d’un mal contre lequel votre anti-virus pourra vous protéger. C’est plutôt comme la moisissure sur le fromage : ça apparaît après un certain temps et plus rapidement si on le manipule fréquemment sans prendre les précautions nécessaires!

Prenons un exemple dans le domaine d’affaires de l’assurance pour illustrer le processus. Une personne a créé au départ une structure de contrôle pour ne traiter que les polices à renouveler au cours des 30 jours à venir. Assez simple, n’est-ce pas?

if (p.DateRenouvellement < Now.AddDays(30)) {
  TraiterRenouvellement(p);
}

Quelques temps plus tard, un collègue a implémenté une nouvelle règle d’affaires dans le traitement pour répondre à un besoin de l’entreprise.

if (p.DateRenouvellement < Now.AddDays(30)) {
  if (Date.Now.Year - p.Client.EstClientDepuis.Year > 10) {
    var rabais = 0.1;
    TraiterRenouvellement(p, rabais);
  }
Else {
  TraiterRenouvellement(p, 0);
}

Par la suite, une autre demande est venue s’ajouter et une autre personne est venue modifier la fonction.

if (p.DateRenouvellement < Now.AddDays(30)) {
  if (Date.Now.Year - p.Client.EstClientDepuis.Year > 10) {
    var rabais = (Date.Now.Year - p.Client.EstClientDepuis.Year)/100;
    TraiterRenouvellement(p, rabais);
} }

Et ainsi de suite, jusqu’à ce qu’on ait une méthode de 125 lignes, ou même plus! Bien qu’avec le recul on puisse identifier différents éléments qui auraient pu être faits pour réduire la complexité, le plus souvent on ne peut accuser les gens de mauvaise foi. C’est plutôt une spirale sournoise dans laquelle l’équipe s’est engagée s’en trop s’en rendre compte… Jusqu’au jour où on ne s’y retrouve plus!

Favoriser la lisibilité du code source

Barbara Liskov (bien connue pour avoir donné son nom au Liskov Substitution Principle) mentionnait dans une récente entrevue que l’on devrait accorder plus d'importance à la lisibilité du code qu'à son écriture (read-ability VS write-ability). Les compilateurs, éditeurs de code et autres outils de développement offrent une panoplie de fonctions qui tendent à réduire le nombre de lignes de code source. Cependant, est-ce qu'on y gagne réellement au change?

Je pense, par exemple, à la fonctionnalité de Resharper qui permet de convertir une boucle en une expression LINQ. Oui, il y a des cas où cela peut-être bénéfique, mais il y a aussi bien des cas où, en fin de compte, on aura perdu une part de lisibilité du code dans l'opération.

Quelques façons d’éviter la complexité involontaire

Il existe différentes façons de s’entraîner à développer sa capacité à détecter les pièges de la complexité involontaire. De façon générale il faut débuter par accepter de sortir de sa zone de confort et graduellement apprendre à prendre un peu de recul et évaluer le code que l’on produit ou modifie.

Plusieurs excellents ouvrages de référence ont été publiés sur le sujet. C’est un bon point de départ pour quiconque veut approfondir ces techniques. Voici quelques suggestions :

Revues de conception

Pourquoi ne pas ajouter la notion de revue de conception ou de test par un pair à la définition d’avoir terminé de votre équipe? Chacun s’assure qu’au moins une autre paire d’yeux a jugé son travail et en a validé la conformité aux standards de l’équipe. C’est une étape qui permet de détecter rapidement des éléments qui manquent de clarté et qui apparaissent ambigus pour une autre personne. Ça ne veut pas dire que vos collègues ont forcément raison et vous tort, mais ça vaut probablement la peine de tenir une brève discussion sur les aspects qui ont été soulevés durant la revue.

Bien que je trouve que la revue par un pair apporte la meilleure valeur pour l’équipe, je crois que l’on peut aussi faire preuve d’autocritique. Par exemple, pourquoi ne pas prendre un peu de temps chaque matin pour repasser le code qu’on a écrit la veille? Par comparaison, un ébéniste prend habituellement le temps de faire un montage à sec avant de coller les assemblages d’un meuble. Cela lui permet de vérifier toute anomalie et la corriger avant de faire le collage final. Oui, ça prend un peu de temps, mais c’est une étape qui lui permet de s’éviter d’éventuels ennuis.

Métriques du code

En plus des évaluations qualitatives dont on vient de discuter, la complexité du code peut se mesurer de façon quantitative. Il existe plusieurs mesures, telles que la complexité cyclomatique, l’index de maintenabilité, le niveau de profondeur des structures de contrôle et la cohésion.

Il existe aussi des outils d’analyse statique du code qui permettent d’assurer le respect des règles de développement de l’équipe (nomenclature, etc.). Plusieurs de ces outils sont gratuits (tel que Source Monitor) ou même intégrés directement aux IDEs (comme le propose Visual Studio).

Conclusion

Développer et maintenir un système c’est comme une partie d’échecs. On doit penser quelques coups d’avance, tout en étant capable de réagir aux mouvements de l’adversaire. Il revient à chacun de trouver le juste équilibre entre perfection et livraison, mais il convient, à mon avis, d’identifier le seuil minimal que vous vous engagez à respecter. Lorsque le contexte ne vous permet pas de rencontrer ce seuil, n’hésitez pas à rendre cette situation visible à l’équipe et à discuter de la possibilité d’ajouter un élément au carnet de produit pour revoir cette partie du code source à un moment qui sera plus opportun (tel qu’au début du prochain cycle de livraison).

J’ai un jour entendu une personne dire ceci : "Écrivez votre code comme si celui ou celle qui en fera la maintenance était un psychopathe dangereux qui connaît votre adresse". C'est peut-être un peu extrême, mais ça m'a toujours forcé à me mettre dans la peau de la personne qui allait devoir comprendre mon code en m'efforçant de réduire le plus possible la complexité de celui-ci. Bon développement!

Une firme de service-conseils TI pas comme les autres

Publié par Louis-Philippe Carignan le mercredi 22 mai 2013 à 10:00

En avril 2012, Infoq.com a publié la liste des 20 personnes les plus influentes en Agilité. En 20ième position, on retrouve Henrick Kniberg, un suédois dont la biographie mérite d’être lue avant de continuer à lire ce billet. Il est aussi co-propriétaire de Crisp, une petite firme de consultants en technologie de l’information en Suède.

En mai 2010, Henrik a publié un billet à propos de Crisp où il raconte comment ils ont découvert leur identité. Pendant des années, il trouvait que leurs rencontres de compagnie biannuelles ne donnaient pas les résultats escomptés. 

"Every conference we would spend lots of effort around a big conference room table attempting to define these things, but the only results would be a bunch of wiki pages (our intranet) with lots of different options and ideas. No clear decisions."

Une année, Henrik a donc emprunté une approche différente pour identifier leur vision. Il a fait les étapes suivantes:

  • Découvrir leur vision et la mettre en mots.
  • Rendre la vision physique.
  • Dessiner avec des crayons de plomb puisque la vision n’est jamais finale.
  • Limiter l’espace pour se forcer à choisir les bons mots.
  • L’afficher partout.
  • Obtenir l’approbation de tous.

Comparativement à d’autres organisations qui font un exercice similaire, le résultat de cette expérience a fait son bout de chemin au travers le temps. Une fois leur identité découverte avec cette vision en dessins, des éléments intéressants en ont découlé. Voici ce qu’Henrik raconte sur son blogue

Indice du bonheur – version Crisp

Maintenant outillé avec leur vision sous forme de dessins, Crisp a mis sur pied l’indice du bonheur, une simple feuille de calcul sur Google Spreadsheet qui mesure, de 1 à 5, le niveau de bonheur de chaque personne à chaque mois.

On y trace un graphique mensuel où on fait la moyenne de cet indice. Si le graphique montre une courbe négative, les gens deviennent alors concernés et travaillent ensemble pour résoudre ce qui irritent leurs collègues.

HappinessGraph.jpg 

Voici le constat d’Henrik par rapport à cette mesure :

"Crisp Happiness Index is more important than any financial metric, not only because it visualizes the aspect that matters most to us, but also because it is a leading indicator, which makes us agile. Most financial metrics are trailing indicators, making it hard to react to change in time."

Leur indice du bonheur est un bon indicateur puisqu’il donne un aperçu de ce qui va se produire dans la compagnie. En étant heureux chez Crisp, les employés rendront heureux leurs clients. Henrik fait le constat que les indicateurs financiers sont en arrière (lagging) puisqu’ils donnent une lecture après qu’une prestation de service ait été faite chez un client.

La valeur des actions chez Crisp

Leur indice du bonheur a permis une autre prise de conscience aux employés de Crisp:

"As a result of understanding our own values better, we’ve dramatically changed our partnership contract between Crisp stock owners. We’ve literally made our own stock worthless (at least from a pure monetary perspective)"

Vous avez bien lu. Leurs actions ne valent plus rien sur le plan monétaire. Ils ne veulent pas être une firme pour enrichir les actionnaires. Ils veulent être une maison pour les consultants en technologie de l’information.

Il est d’ailleurs dommage qu’il n’explique pas en détails ce volet. Je serais curieux de connaître comment Crisp gère sa comptabilité, paie ses impôts ou si un partage de revenus annuel est fait.

Et leur plan pour gérer la croissance

En continuant la lecture de l’article, on apprend que pour eux, la croissance de l’entreprise n’est tout simplement pas un paramètre qu’ils désirent contrôler. Puisqu’ils s’identifient comme étant une maison pour consultants en TI, c’est plutôt leur indice du bonheur qui indiquer si leur croissance actuelle est plaisante (ou non). J'ai entendu plusieurs fois des gestionnaires expliqués comment la croissance était importante pour aller chercher de nouvelles opportunités d'affaires. Crisp a une vision tout à fait différente de la croissance. Elle n'est pas liée aux opportunités d'affaires mais à l'indice du bonheur de ses employés.   

En conclusion

Je vous invite à consulter les deux dessins qu’Henrik présente au début de son article. Il a traduit les mots en anglais pour faciliter notre compréhension. Le premier montre la maison des consultants avec les valeurs importantes à leurs yeux. Mais c’est le dessin à la deuxième page qui est plus révélateur à mon avis. L’image « What do we do with money? » est particulièrement intéressante ainsi que la mesure du bonheur à la gauche de la feuille. Si les employés sont heureux, leurs clients le seront tout autant.

Comme le dit si bien les Poppendieck dans leur troisième excellent livre « Leading Lean Software Development » à la page 198 à propos des entreprises dans l'économie du savoir :

"In knowledge work, success comes entirely from people and the system within which they work. Results are not the point. Developing the people and the system so that together they are capable of achieving successful results is the point."

Un sondage Agile toujours bien reçu

Publié par Louis-Philippe Carignan le lundi 4 mars 2013 à 08:00

Depuis maintenant 7 ans, la compagnie américaine VersionOne produit un sondage hautement respecté à propos de l’état de l’Agilité dans l’industrie des technologies de l’information. La compilation 2012 du sondage a été publiée dans les derniers jours. Vous le retrouverez ici.

La première information que j’ai apprécié dans ce sondage est la personne qui connaît le mieux l’Agilité dans l’organisation. À la page 3, la personne qui en connaît le plus est le Scrum Master suivi des rôles de gestionnaire (directeur, vice-président, etc). Je considère ce point important puisque le gestionnaire en charge d'un département T.I doit bien connaître les nouvelles façons de faire que ses équipes mettront en place.  

La deuxième information que j’ai notée est les pratiques Agile mises en place par les organisations. À la page 5, on y présente les 26 pratiques les plus couramment utilisées dans l’organisation. Bien que ce soit les mêmes pratiques que l’année passée, leur mise en application est en augmentation mis à part le déploiement continue. J’aime aussi corréler ces pratiques avec les 52 pratiques Agile que l’on retrouve sur le site de l’Agile Alliance. Présenté sous forme d’une carte de métro, on y voit les pratiques Agile catégorisées par ligne de métro. De plus, on peut cliquer sur chaque pratique pour connaître son historique ainsi que son utilité.

Les deux dernières informations que je trouve utile sont à la page 6 et 7. À la page 6, on présente les causes qui ont mené à l’échec de la mise en place de l’Agilité dans son organisation. La première cause est « La philosophie ou la culture de notre entreprise ne se conjugue pas avec les valeurs Agile ». Et si on va à la page 7, la question du bas évoque les barrières pour empêcher une adoption plus large de l’Agilité. Étrangement, 52% des répondants ont noté que leur incapacité à changer la culture organisationnelle pour rejoindre les valeurs Agile est le facteur primare pour empêcher l'adoption de l'Agilité.

Je me permets de faire un lien entre ces deux statistiques. À mon avis, la culture organisationnelle est l’un des facteurs les plus importants à considérer lorsqu’on débute une adoption Agile. Au-delà de son désir personnel d’améliorer son travail ainsi que celui de son équipe dans le but de mieux répondre aux besoins du client, est-ce que les pratiques mises en place suite à notre départ, une promotion dans un autre département ou l’arrivée d’un nouveau projet, survivront? Je pense que la culture organisationnelle, d’une manière ou d’une autre, fera en sorte que votre effort Agile subsistera sur le long terme.

Je vous invite donc à consulter ce sondage. Il peut être utile comme base de discussion avec vos gestionnaires lors d’un dîner pour discuter d’Agilité ou à l’intérieur de votre équipe si vous cherchez des pistes pour vous améliorer. 

 

Culture. Culture. Culture.

Publié par Louis-Philippe Carignan le samedi 2 mars 2013 à 00:00

Lorsque je donne le cours Professional Scrum Master (PSM), je m’efforce de toucher le point de la culture organisationnelle à quelque part. Partant de la fameuse citation de Peter Drucker « Culture eats strategy for breakfast », je désire informer les participants qui s’intéressent au rôle de Scrum Master de l’importance de la culture organisationnelle dans leur objectif personnel à mettre en place certaines parties de l’Agilité.

Une vidéo que j’aime bien pour vous donner une idée de la culture organisationnelle, ainsi qu’identifier celle de votre entreprise, est celle que Michael Sahota a fait en mai 2011. Dans cette vidéo de 10 minutes, Michael décortique les valeurs et principes Agiles pour les agencer au modèle de Schneider, modèle qui identifie 4 cultures organisationnelles.

La leçon que je retire de cette vidéo est l’importance de bien identifier la culture organisationnelle en place avant de démarrer avec l’Agilité. À mon avis, cela peut vous aider à déterminer l’ampleur des efforts dans votre promotion des valeurs Agile. D’ailleurs, peut-être même que vous réaliserez pourquoi certaines pratiques ont été faciles à mettre en place tandis que d’autres sont plus difficiles.

Par exemple, dans une culture de compétence où l’excellence technique est fortement valorisée, les pratiques d’ingénierie logicielles promues par l’Agilité seront probablement facilement acceptées par votre équipe.

Mots-Clés :

Archive