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.

Une roche dans le soulier

Publié par Jean-Francois Gilbert le jeudi 23 avril 2015 à 00:00

Course

Vous courez depuis un bon moment déjà et vous avez atteint votre vitesse de croisière. L'endorphine et le vent chaud du printemps provoquent en vous une douce euphorie. Tout va bien, vous filez le parfait bonheur! Soudain, vous la sentez vous piquer. Une petite roche s'est glissée dans votre soulier, puis à l'intérieur de votre bas. Au début, vous la remarquez à peine. Mais après un moment, l'inconfort fait place à la douleur. Vous pourriez décider de l'endurer et de continuer à courir. Après tout, vous avez la moitié du chemin de parcouru. Mais vous savez que la roche risque de vous couper. En modifiant un peu votre foulée, vous vous rendez compte que la roche se fait plus discrète. Cependant, après quelques kilomètres de plus, votre démarche inhabituelle créé une douleur musculaire pire que celle causée par la roche ! Parfois, la seule idée de prendre une pause de 2 minutes pour détacher notre soulier, retirer le bas et enlever le caillou nous horripile. Le rythme est bon, il ne faut surtout pas s'arrêter de courir ! Pourtant, on risque une blessure qui va nous ralentir encore plus.

Je vois souvent le même comportement dans des équipes de développement logiciel. On accumule de la dette technique. Le build fonctionne une fois sur deux. Des tests intégrés sont instables et on commence à les ignorer sans essayer de comprendre la cause du problème. Comme le coureur, l'équipe risque d'en souffrir beaucoup plus à long terme. Les tests n'étant plus fiables, on ignorera des symptômes évidents et la stabilité du logiciel s'en ressentira. Parfois ce sont des problèmes humains : l'ambiance dans l'équipe n'est plus bonne ou encore on accepte sans rien dire des comportements néfastes.

Ce n'est pas toujours plaisant de faire une pause dans le développement. Parfois on subit beaucoup de pression de nos supérieurs pour soutenir la cadence. Mais il faut vraiment le faire lorsque ça devient nécessaire. Les problèmes se règlent rarement d'eux-mêmes et il ne faut pas attendre que ça fasse mal pour s'y attarder. La rétrospective du sprint est le moment tout indiqué pour mettre en lumière les problèmes à corriger. On a souvent tendance à faire cet exercice un peu vite et à la légère. Il n'y a pourtant pas de meilleur moment pour discuter des embûches, que lorsque toute l'équipe est présente. C'est l'occasion de se questionner en tant qu'équipe et de relever les points agaçants qui vous empêchent de bien travailler. 

Une fois les irritants énumérés, c'est le moment de passer à l'action afin de les éliminer. À mon avis, ces actions devraient se retrouver dans le carnet du sprint autant que possible. Il faut les rendre visibles, les prioriser et les attaquer rapidement. L'équipe devrait s'engager à régler les problèmes de la même façon qu'elle s'engage à livrer de la valeur au client. Autrement, après quelques sprints une vilaine roche risque de réduire la capacité de l'équipe à satisfaire le client.

D'autres billets qui pourraient vous intéresser

 

Nettoyer votre code pour le rendre 5 S

Publié par David Beaumier et Jean-François Gilbert le lundi 20 avril 2015 à 08:13

Nous voilà rendus au 3ième concept de la méthode 5S : nettoyer (ou seiso en japonais). Comment ce principe, pensé à la base pour éviter la détérioration de la machinerie et des équipements, peut-il s’appliquer en développement logiciel?

Revenons pour une seconde aux fondements de la méthode 5S : une fois l’espace de travail ordonné (le premier S) et rangé (le second S), il devient beaucoup plus simple de le nettoyer puisque ce qui a besoin de nettoyage devient dès lors visible.  En développement, on pourrait penser à ces bouts de codes qui ont mal vieilli et qui handicapent d’une façon ou d’une autre le système. La fameuse dette technique, quoi!

Évidemment, pas besoin d’avoir fait les étapes 1 et 2 dans l’ensemble du code pour pouvoir passer au nettoyage. En procédant ainsi vous risqueriez même de salir de nouveau certains coins si l’application est d’une certaine envergure. Pourquoi ne pas directement cibler les morceaux qui sont connus pour dégager une odeur (virtuelle, on s’entend) nauséabonde? Probablement qu’il faudrait très peu de temps à l’équipe pour les identifier!

Nous vous proposons dans ce billet quelques suggestions pour procéder au nettoyage de votre base de code.

La règle des scouts

La bonne vieille règle des scouts, soit celle de laisser le campement plus propre au départ qu’à l’arrivée, peut être une bonne façon de procéder à un nettoyer graduel de votre code. En effectuant ici et là une extraction de méthode, un renommage ou en révisant une condition en introduisant un guard clause (quelqu’un a une bonne traduction à proposer?) votre équipe en viendra à rehausser la maintenabilité de la base de code. Et cela, sans impacter de façon significative son rythme de livraison habituel.

L’important dans toute opération de nettoyage de cette envergure est de se donner des objectifs atteignables, de mesurer la progression régulièrement (tous les sprints, par exemple) et d’ajuster le tir en fonction de ce que vous découvrirez. C’est surprenant de voir ce qu’on peut accomplir lorsqu’on rend visible la crasse qui se cache dans certains recoins du code!

Réingénierie (refactoring)

La réingénierie logicielle est la technique qui revient le plus souvent lorsqu’on parle de nettoyer du code existant.

La réingénierie logicielle est un processus ayant pour objectif de transformer et améliorer un logiciel à partir du modèle existant sans toutefois modifier son comportement externe.

Livre RefactoringtopatternMême si elle est simple à comprendre, c’est une technique qui demande beaucoup de pratique pour développer les bons réflexes et savoir bien doser son utilisation. Si vous débutez avec cette pratique, la lecture du livre Refactoring: Improving the Design of Existing Code de Martin Fowler s’avère toujours un bon point de départ (même après plus de 15 ans). Un catalogue des différents types de réingénierie est aussi disponible en ligne.

Le livre de Kerievsky s’adressera quant à lui aux personnes qui ont déjà un peu d’expériences avec la réingénierie et qui souhaitent voir comment cette technique peut être combinée avec les patrons de conception.

Scott Ambler et Pramod Sadalage ont même appliqué les principes de la réingénierie logicielle aux bases de données relationnelles dans leur livre Refactoring Databases: Evolutionary Database Design.  Vous n’aurez dorénavant plus aucune excuse pour ne pas nettoyer votre schéma de base de données!

Outils disponibles

Il existe aujourd’hui des fonctionnalités de réingénierie dans pratiquement tous les IDEs. Sinon, des extensions plus avancées peuvent vous aider, tel que Resharper sous Visual Studio. Ces outils vous sauveront du temps, tout en évitant les erreurs typiques associées aux opérations manuelles de rechercher/remplacer.

Des outils spécialisés pour les SGBDR, tels que Liquibase ou SQL Server Data Tools vous aideront à produire les scripts de mise à jour requis pour offrir une cure de jeunesse à vos bases de données. La vidéo ci-dessous vous permettra d'avoir un aperçu de l'utilisation de Liquibase.

Identifier les candidats potentiels au nettoyage

Encore une fois, les techniques du management visuel peuvent venir à notre rescousse pour vous aider à identifier les bouts de code qui sont de bons candidats à la réingénierie. Par exemple, l'extension Microsoft CodeLens Code Health Indicator (pour Visual Studio Ultimate) permet d’obtenir plusieurs mesures sur la maintenabilité du code et l’indicateur visuel vous indiquera si vous êtes face à un bout de code qui rencontre les exigences (en tout cas, celles de Microsoft). On peut même voir si la modification courante améliore ou non le code et ajuster le tir au besoin. Ça réduit de beaucoup la boucle de rétroaction.

Codehealth

SourceMonitor est un autre outil qui peut aider à identifier les classes qui ont besoin d’un peu d’amour. Bien qu’il ne soit pas directement intégré à un IDE, SourceMonitor a l’avantage de supporter plusieurs langages de programmation, tels que C++, C, C#, VB.NET, Java et Delphi. Il permet de cibler un sous-ensemble plus ou moins grand de votre base de code et produit les métriques de différentes façons, tel que démontré ci-dessous. Il est aussi possible d'en automatiser l'utilisation de façon à prendre des mesures sur une base régulière.

Sourcemonitor

Et vous, quels sont les techniques et outils qui vous permettent de nettoyer votre code? Quels approches ont été les plus bénéfiques pour votre équipe?

D'autres billets qui pourraient vous intéresser

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

 

Appliquer les principes du « 5 S » dans votre code – Ranger

Publié par David Beaumier et Jean-François Gilbert le jeudi 9 avril 2015 à 07:45

Dans ce second article de la série sur l’application de la méthode 5S en développement logiciel nous abordons le second concept : ranger (ou Seiton, en japonais). On peut résumer le concept de cette façon : « Une place pour chaque chose, et chaque chose à sa place » (source : Wikipedia).

Le but derrière cette notion de rangement est de s’assurer que les équipiers ne perdent pas de temps de travail à chercher les éléments dont ils ont besoin dans le cadre de leur travail. Dans le cas du développement logiciel il peut s’agir autant des classes communes, d’utilitaires pour effectuer certaines opérations que de documentation sur les patrons de conception. Quoi de plus frustrant que de chercher pendant plusieurs minutes où a été déposé l’utilitaire qui permet de convertir une base de données!

Vous trouverez ci-dessous quelques suggestions pour optimiser le rangement dans votre équipe de développement logiciel.

Bien structurer votre projet

Le découpage (dossiers) de votre projet devrait s’appuyer sur le vocabulaire du domaine d’affaires. Il est important d’avoir une uniformité dans le langage utilisé et cela doit se refléter dans le code aussi. Si on parle de « gestion des accès » dans votre application on ne devrait pas retrouver un dossier « autorisations » dans le projet.

Dans un projet Web, il peut être aussi intéressant de penser à une structure qui permette de rapidement distinguer les artéfacts selon qu’ils s’appliquent à la structure du document (html), aux styles (CSS) ou au code (JS).

Assurer une cohérence physique des dossiers et des paquetage

Des outils comme Resharper vous indiqueront s’il existe des écarts entre les dossiers physiques et le nom des paquetages (namespaces dans ce cas-ci). Avec le temps, on peut avoir renommé quelques dossiers, mais avoir oublié de faire les ajustements dans le code.

5S Ranger Resharpernamespacelocation

Valider la dépendance entre les paquetages

 La dépendance entre les paquetages devrait,  elle aussi, respecter le découpage fonctionnel. Ces dépendances sont souvent exprimées en UML sous forme de diagramme de paquetages.

Les fonctionnalités de Dependency Graph et de CodeMap de Visual Studio permettent de dresser une cartographie des dépendances qui vous permettra de valider que celles-ci sont conformes à la cible.

5S Ranger Dependencygraph

5S Ranger Vscodemap

Des outils comme JArchitect peuvent produire diverses métriques sur le niveau de dépendance entre les différentes parties du code. Celles-ci vous permettront de vérifier si les principes architecturaux ont été respectés et vous éviteront d’avoir un couplage trop fort entre les entités de votre système, ce qui a tendance à rendre l'entretien et la réingénierie plus difficile à long terme.

5S Ranger Dependencymatrix

N’oubliez pas la documentation

On ne parle pas ici de la documentation du code source en lui-même (bien qu’elle soit importante), mais plutôt de celle qui forme la base de connaissances de votre équipe. Comment un nouvel équipier saura quel outil utiliser pour produire un script de mise à jour de la base de données relationnelle? Où trouvera-t-il les règles de nomenclatures à respecter?

Que vous utilisiez un wiki ou un autre outil de gestion documentaire, assurez-vous d’y consigner les informations importantes. Souvent, un bref résumé et quelques liens pertinents permettent de conserver une documentation suffisante sur un sujet. Comme le disait Albert Einstein, « Ne mémorisez pas une information que l’on peut facilement retrouver ».

D'autres billets qui pourraient vous intéresser

L'art de recevoir du feedback

Publié par Marc Allard le mercredi 18 mars 2015 à 09:32

C’est un dimanche ensoleillé de printemps et papa amène ses deux jumelles, Annie et Elsie, au terrain se baseball pour qu’elles se pratiquent au bâton. Il leur montre à bien se positionner au marbre, à ne pas casser leur élan et à garder les yeux sur la balle. Annie adore l’expérience. Elle passe du temps avec son père sur le gazon fraîchement coupé et sent qu’elle s’améliore chaque fois qu’elle claque la balle.

Pendant ce temps, Elsie boude. Elle est accotée sur la clôture et quand son père essaie de la persuader de revenir au marbre pour lui donner des conseils sur son timing, elle maugrée :

«Tu penses que j’ai pas de coordination! Tu me critiques tout le temps!»

«Je ne te critique pas!», corrige son père. «Ma puce, j’essaie juste de t’aider à t’améliorer».

«Tu vois!, dit Elsie. Tu penses que je ne suis pas assez bonne!» Puis, elle jette son bâton par terre et sort du terrain.

Cet exemple est tiré du livre Thanks for the Feedback, dont je vous ai parlé dans un précédent billet. Les auteurs Douglas Stone et Sheila Heen, deux experts du Harvard Negociation Project, expliquent pourquoi le feedback est si irritant dans la vie, mais surtout pourquoi il est si important pour ceux qui aspirent à devenir une meilleure version d’eux-mêmes. 

Le papa des jumelles, lui, ne comprend rien. De son point de vue, il a donné exactement le même genre de feedback à ses deux filles. Et pourtant, Annie et Elsie n’ont pas du tout réagi de la même manière. La première était contente, elle lui montrait sa gratitude et aurait voulu que ça continue. La deuxième était frustrée, sur la défensive et voulait partir.

À la maison ou au boulot, nos réactions au feedback s’apparentent tantôt à celle d’Annie, tantôt à celle d’Elsie. Nous alternons entre les deux, car nos réactions n’ont pas tant à voir avec les habiletés de l’émetteur ou ce qu’il a dit qu’avec le type de feedback qu’on perçoit et celui qu’on aurait souhaité recevoir.     

Les 3 types de rétroactions

Dans le concept un peu fourre-tout qu’est le feedback, il y a en réalité trois types de rétroaction : l’appréciation, l’évaluation et le coaching. Et c’est souvent quand on les entremêle que la tension monte, un peu comme des fils qui se touchent.

L’appréciation, vous l’aurez deviné, consiste à montrer son appréciation à quelqu’un en le remerciant, en le félicitant ou simplement en reconnaissant ce qu’il a fait. C’est ce que la plupart des parents font naturellement avec leurs enfants, mais que votre boss oublie trop souvent de faire. Plus délicate, l’évaluation exige une comparaison : on veut indiquer à l’autre où il se situe par rapport à certains standards. C’est le même boss qui vous dit que vous avez surpassé vos objectifs et que si vous continuez comme ça, il y a une promotion à l’horizon. Le coaching a plus à voir avec l’apprentissage, avec l’aiguisage des habiletés. C’est le prof de guitare qui vous explique comment mieux placer vos doigts pour faire un accord barré, pour que vous puissiez enfin jouer Stairway to Heaven.

De retour au terrain de baseball, c’est clair pour le papa : il coache. Annie est sur même longueur d’onde et affiche un grand sourire. Elsie, par contre, perçoit les commentaires paternels comme une évaluation : «Tu penses que je ne suis pas assez bonne!» Autrement dit, elle mêle le coaching et l’évaluation. Pourquoi? Stone et Heen évoquent quelques raisons potentielles. Peut-être qu’Elsie sent une comparaison implicite avec sa soeur, qu’elle est insécure par rapport à ses habiletés athlétiques ou qu’elle trouve que les observations de son père ne sont pas toujours justes.

Bref, tout est aligné pour qu’Elsie se sente évaluée alors que son père ne voulait que l’aider à faire grimper sa moyenne au bâton. À la défense d’Elsie, tout coaching implique une certaine part d’évaluation, qui dit quelque chose comme : «tu n’es pas encore au niveau que tu pourrais atteindre». Mais les sentiments qui influencent notre réaction ont tendance à amenuiser ou à grossir cette part d’évaluation.   

Que faire pour ne pas tomber dans le piège? On s’aligne, tranchent Stone et Heen. Qu’on soit celui qui donne le feedback ou celui qui reçoit, dès que la tension monte, on discute explicitement de l’objectif de la rétroaction. Est-ce que l’objectif principal en est un d’évaluation, de coaching ou d’appréciation? Si le papa avait passé son temps à dire à Annie «bravo ma championne!», alors qu’elle voulait des trucs pour bonifier son élan, parions qu’elle n’aurait pas été aussi souriante.

Douglas et Heen croient que la plupart du temps, c’est au récepteur de prendre le taureau par les cornes : «tu m’aides à améliorer mon élan, mais j’aimerais que tu me dises si je me débrouille bien dans l’ensemble, comme ça je vais pouvoir relaxer et me concentrer sur tes conseils». Ou : «Tu me dis que tu me coaches, mais j’ai aussi l’impression que tu m’évalues. Est-ce que je me trompe ou je traîne de la patte?»

C’est ce qui a aidé Elsie et son père. Il lui a demandé : Elsie, qu’est-ce qu’il y a ? Elle a fondu en larmes. Papa a appris qu’elle avait passé la semaine à s’entraîner et qu’elle espérait l’impressionner au bâton le dimanche. Mais le moment venu, le bâton ne suivait pas ses ambitions. Elsie aurait eu besoin d’appréciation, que son père la réconforte et qu’il reconnaisse ses progrès. Au lieu de ça, elle a eu reçu d’autres conseils techniques.

Mais après avoir discuté, ils se sont réalignés. Le livre ne dit pas la fin de l’histoire, mais j'ai entendu dire qu’Elsie est revenue frapper quelques balles...

D'autres billets qui pourraient vous intéresser

 

Archive