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.

Agile comme un enfant

Publié par Marc Allard le mardi 14 avril 2015 à 08:12

Quand il était responsable de l’«expérience des usagers» chez Palm, l’entreprise pionnière de l’ordinateur de poche, Peter Skillman a inventé un exercice de design surnommé le «challenge de la guimauve». Le défi consiste à bâtir la plus haute tour possible avec 20 spaghettis, un mètre de ruban adhésif et un bout de ficelle. Les participants disposent de 18 minutes pour construire la tour, sur laquelle ils doivent être capables de faire tenir une guimauve. 

Durant cinq ans, au début des années 2000, Skillman a observé des tas de groupes, divisés en équipes de quatre, se livrer à l’exercice. Il a notamment réuni des ingénieurs en télécoms taïwanais, des étudiants en administration et des enfants de la maternelle. Sans trop de surprise, les ingénieurs se sont distingués et les étudiants en administration se sont plantés. 

Mais devinez qui a fait mieux que tout le monde? Les enfants, qui ont réussi à bâtir une tour de 1 pouce plus élevé que les ingénieurs.

Skillman a raconté cette anecdote lors d’une présentation filmée qu’il a donnée dans une conférence sur la création technologique en 2007. Dans la salle se trouvait Megan McCardle. Cette journaliste, auteure et ex-étudiante en administration a écrit un livre publié en 2014 intitulé «The Up Side of Down», dans lequel elle entame son premier chapitre en revenant sur le challenge de la guimauve.

Comment les enfants ont-ils réussi à battre les ingénieurs ? nous demande McCardle. «Par le simple processus de l’expérimentation et de l’itération, écrit-elle. Ils ne se sont pas laissé freiner par des assomptions sur les règles du jeu — ils ont été le seul groupe à demander plus de spaghetti. Et parce qu’ils avaient plus de spaghettis, ils n’ont pas eu à perdre du temps à réfléchir au look de la tour ou à qui devrait écrire l’énoncé de vision. Ils se sont juste lancés et ont commencé à créer, laissant de côté tout ce qui ne marchait pas.» 

D’une certain façon, les enfants se sont montrés très agiles. Ils ont épousé la philosophie du kaïzen, cette pratique japonaise de l'amélioration en continu qui mise sur de petits changements fréquents plutôt qu’une longue planification élaborée à partir d’une idée unique. Quand on y pense, les jeunes enfants sont des adeptes naturels du kaïzen. Avant de comprendre le langage, les bébés sont l’incarnation même de l’amélioration en continu, se développant essentiellement à coups d’essais et d’erreurs. Les tout-petits bénéficient des enseignements de leurs parents, mais leur inclinaison pour l’expérimentation reste intacte, comme en témoignent tant de traces de crayon-feutre sur des murs blancs. 

En fait, cette inclinaison ne s’effrite qu’à mesure où les enfants commencent à craindre ce qui n’effrayait pas encore trop nos champions de la tour en spaghetti : la peur de l’échec.

The Up Side Of DownComme l’explique Megan McCardle, dans la vie ou au travail, c’est souvent cette peur qui est le plus gros obstacle à l’amélioration. Or, le challenge de la guimauve le montre bien : «si tu n’as pas beaucoup de temps de devant toi, le plus important c’est que tu échoues», dit Skillman à son audience. «Tu échoues plus tôt pour pouvoir réussir plus rapidement». L’essai/erreur est le style naturel d’apprentissage du cerveau, qui forge des connexions efficaces une fois qu’il a éliminé toutes celles qui ne le sont pas, explique McCardle.

J’ai lu quelque part qu’un génie, c’est quelqu’un qui déjà a commis toutes les erreurs. Bien sûr, précise McCardle, il ne s’agit pas d’échouer pour le plaisir d’échouer ou de prendre des risques inconsidérés. L’idée est de prendre beaucoup de petits risques calculés, parce que ça reste la seule façon de voir ce qui fonctionne vraiment. 

C’est ce qui j’ai essayé récemment avec ma fille de 4 ans, qui n’arrivait pas à zipper son manteau. Durant une semaine, je lui ai laissé le temps chaque matin d’essayer de le faire toute seule. Ensemble, on a pris le risque qu’elle s’impatiente et se fâche et qu’on arrive beaucoup plus tard à la garderie — ce qui est effectivement arrivé. Mais au bout d’une semaine, à force d’essais et d’erreurs, elle a compris le fonctionnement du zipper et, depuis, c’est un dossier clos! 

La semaine prochaine, je pense qu’elle sera mûre pour la tour de spaghettis.

D'autres billets qui pourraient vous intéresser

 

Souligner les succès…

Publié par Vincent Crépin le lundi 3 février 2014 à 20:11

J’ai récemment été appelé à effectuer une intervention à La Capitale et c’était la première fois que l’occasion se présentait à moi. J’avais eu de bons mots de plusieurs personnes ayant effectué des interventions auparavant mais rien de précis. Bien évidemment j’ai été impressionné par leur nouvel édifice vert qui vaut le détour à lui seul. Mais ce n’est pas le sujet de mon article…

Lors de rencontres avec les architectes d’affaires et organiques, j’ai pu prendre connaissance du niveau d’implantation des techniques agiles dans le département du développement et je dois dire que j’ai été impressionné. Je n’avais jamais vraiment entendu parler de cet aspect de La Capitale mais parmi les endroits que j’ai visités, ils sont au sommet de la liste selon ce que j’ai vu.

Salle de développement à La CapitaleJe parle surtout ici des pratiques de développement (TDD, refactoring, intégration continue). Ils utilisent TDD pour tous leurs développement qui utilisent la plateforme Ruby on Rails. Ils possèdent actuellement une base de tests qui se comptent en plusieurs milliers et dont la couverture frôle le 100%. Ils ont une salle de développement dans laquelle la première chose que l’on remarque, c’est la présence intimidante d’un écran géant qui donne en temps réel l’état des builds (il y avait une tuile rouge quand je suis passé ;-)). Voici d’ailleurs une photo de cela.

On sent dans cette salle la très grande complicité entre les développeurs et tous ces facteurs se matérialisent par des mises en production exemptes de défauts.

Il va sans dire que cet accomplissement est un travail acharné d’équipe, comme on le devine tous. Je félicite ces personnes qui se sont battues pour leurs idées et qui ont accompli quelque chose de bien et qui peut servir de modèle pour notre communauté.

À deux, c'est mieux !

Publié par Jean-Francois Gilbert le mercredi 19 juin 2013 à 00:00

Tout le monde connait la programmation en binôme, plus souvent appelée « pair programming ». Ses bienfaits ont été empiriquement démontrés, mais sa popularité demeure relativement marginale dans les faits. Il est évident que l'apport de nos collègues ne devrait pas être négligé. Il y a plus d'une façon de collaborer avec les membres de notre équipe et de bénéficier de leur expertise. Dans l'équipe où j'œuvre présentement, cette collaboration porte le nom de "test par un pair". Il s'agit d'une validation de la part d'un collègue, du travail qui a été exécuté et fait partie intégrante de la définition de "terminé" des éléments du carnet de Sprint. Cette pratique s'est avérée très efficace et ses bénéfices sont multiples. Elle a été empruntée à une autre équipe qui avait eu cette brillante idée et nous l'avons bonifiée par la suite.

Fonctionnement

Lors du découpage des tâches des éléments du carnet par l'équipe Scrum, nous créons presqu'obligatoirement une tâche nommée "Test par un pair". C'est la dernière tâche effectuée et elle détermine si l'élément du carnet est terminé ou non. Le collègue qui fait la vérification procède à peu près de la façon suivante :

  • Prend connaissance de l'élément du carnet et des critères d'acceptation.
  • Exécute les tests fonctionnels, aidés par les critères d'acceptation.
  • Consulte le gestionnaire de sources (Team Foundation Server dans notre cas) afin de connaître les changements qui ont été effectués au niveau du code (ajout/suppression de fichiers, modification du code existant, etc.)
  • Valide la qualité du code, c'est-à-dire si celui-ci est conforme à l'architecture et aux normes prescrites par l'équipe, s'il suit les bonnes pratiques de développement, etc.
  • Au besoin, il peut effectuer des corrections ou améliorer le code. Si ces modifications sont non-triviales, il avertira l'auteur du code original pour s'assurer que le changement est sans risque (de plus, les tests unitaires font office de filet de sûreté).
  • Valide la documentation au besoin.

Bénéfices

Outre le fait que l'élément du carnet est testé, cette façon de faire comporte d'autres avantages :

  • Le code que vous écrivez sera presqu'assurément lu par vos collègues. Cela ajoute une saine pression qui incite à produire du code qui respecte les règles de l'art. C'est juste normal de vouloir bien paraître devant nos collègues.
  • Cela force l'équipe à définir des critères d'acceptation et souvent des scénarios de tests avant de commencer à coder.
  • Cela favorise l'échange d'informations. Si vous n'avez pas eu la chance de travailler sur un élément du carnet, le fait de le réviser vous permet de vous mettre au parfum autant au niveau fonctionnel que technique.
  • C'est un excellent moyen d'apprendre et d'enseigner. Si vous trouvez que le code n'est pas optimal, vous avez une excellente opportunité d'enseigner un nouveau design pattern, un nouvel outil, une nouvelle façon de faire à votre collègue.

Les qualités requises

Le test par un pair demande aux membres de l'équipe 2 qualités importantes. D'abord, il faut être en mesure d'accepter de voir son travail scruté et potentiellement critiqué par nos collègues. Parfois, ça fait un peu mal à l'égo, mais c'est une occasion de s'améliorer comme développeur. D'un autre côté, cela demande nécessairement de la diplomatie et du tact lorsque l'on critique le code d'un compère. Les deux parties doivent en tout temps garder en tête que c'est un exercise qui se veut constructif.

Un risque potentiel

Que se passe-t-il si le code révisé ne respecte clairement pas les exigences de qualité ? Si fonctionnellement ça répond au besoin mais que le code est mal écrit ? Après tout, si l'élément du carnet est à toute fin pratique terminé et que vous renvoyez votre collègue à la table à dessin. cela ne mettra-t-il pas le sprint en danger ?

Dans notre équipe, nous avons trouvé une façon d'éviter ce problème. Nous le traitons en amont. Lorsqu'un élément du carnet comporte un tant soit peu de difficulté technique ou d'inconnu, nous ajoutons une tâche qui s'appelle "Atelier de conception". Elle doit être faite avant d'entreprendre les autres tâches de cet élément du carnet. Avant de commencer le développement, 2 ou 3 membres de l'équipe sont sollicités afin de discuter de ce qui doit être fait et de s'entendre sur l'architecture ou l'orientation à prendre pour répondre aux critères d'acceptation. Ainsi, lors de la revue par un pair, la personne faisant le révision ne devrait pas avoir de surprise quant  à la solution technique choisie. En effet, il a soit pris part aux discussions initiales ou bien il sait que plusieurs personnes ont réfléchi à l'approche utilisée. Si jamais la solution venait à changer en cours de route, il suffit d'expliquer ce qui nous a fait prendre une autre approche. Cela n'élimine pas complètement la possibilité de s'égarer en chemin mais le risque est grandement diminué.

Voilà donc notre façon de renforcer la qualité du code que nous écrivons tout en transmettant les connaissances d'un coéquipier à l'autre. C'est tout simple, mais très efficace !

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

Penser autrement ... avec un p'tit peu de d'aide

Publié par Louis-Philippe Carignan le mardi 11 décembre 2012 à 12:18

Albert Einstein a déjà dit « On ne peut résoudre une problématique au même niveau qu’elle s’est créée. Nous devons changer de niveau. ». Avec cette citation en tête, on peut penser qu’il faut faire évoluer notre pensée lorsque nous sommes confrontés à un problème difficile à résoudre. Mais que faire si nous n’avons pas la chance de « changer de niveau » comme le dit Einstein?

On peut aussi consulter un collègue qui n’a pas la même vision que nous face à un problème. Par exemple, notre cerveau a la prédominance vers l’une ou l’autre de ses hémisphères. Cette prédominance influencera notre façon de penser, d’agir et de prendre des décisions. Par exemple, l’hémisphère gauche du cerveau aura l’habitude de faire appel à notre côté logique. Face à un problème, le côté gauche de notre cerveau voudra établir des priorités, établir des limites et des procédures ou simplement dresser une liste des points d’action à prendre pour résoudre le problème.

Mais si vous sentez être dans une impasse avec ces façons de faire, trouvez-vous une personne dont l’hémisphère droit prédomine. Si les stratégies énumérées au paragraphe précédent ne suffisent pas, votre collègue au côté droit prédominant voudra visualiser la solution ainsi que la comparer en images. Il vous suggèrera de travailler en équipe tout en faisant preuve de tolérance face aux options qui pourront ressortir de cette rencontre d’équipe. Bref, il utilisera des stratégies différentes des vôtres mais tout aussi louables.

Bref, le changement de niveau souligné par Einstein ne repose pas que sur vos épaules. Vous êtes épaulés par des collègues qui sont différents de vous. Identifiez ceux qui peuvent vous offrir une perspective différente et faites leur confiance sur les idées qu’ils peuvent vous apporter. Vous serez étonnés du résultat.

 

Archive