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.

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

 

Leçon de vie

Publié par Jean-François Gilbert le lundi 9 mars 2015 à 00:00

Il y a quelques temps, j'ai commencé à travailler sur une preuve de concept relativement complexe. Au départ, je n'avais qu’une vague idée des outils et de l’architecture que j’allais utiliser. Il y avait tellement d'inconnus que je ne savais pas trop par où commencer. 

J'ai donc avancé le projet un peu à tâtons. Je m’efforçais de répondre aux exigences fonctionnelles complexes tout en explorant une plateforme que je connaissais peu. Bref, j'en avais un peu par-dessus la tête. Pour sauver du temps et parce que je croyais tout jeter à la poubelle de toute façon, j'ai commencé à coder sans écrire de tests unitaires. Je vois d’ici vos hochements de tête désapprobateurs. Mais je croyais que les chances que mon code puisse être réutilisé plus tard étaient tellement minces que ça me ralentirait d’écrire des tests tout de suite. Oh, mais quelle erreur !

Au début, je dois avouer que ça allait plutôt bien. J'essayais des choses, je changeais d'idée, j’effaçais le code, j’essayais autre chose. Pas de temps à perdre, je produisais du code à la vitesse grand V ! Étant habitué à programmer presqu'exclusivement en mode TDD, je ressentais quand même un certain malaise. Je n'avais pas mon filet de sûreté habituel et je n’étais pas particulièrement fier du design de mes classes. Mais bon, mon prototype fonctionnait, non ?

A un certain moment j’ai réalisé que globalement, la piste que je suivais depuis plusieurs jours était la bonne. Il y avait bien quelques inconnus ici et là, mais je commençais à avoir entre les mains quelque chose d’intéressant. Or, puisque j'avais codé un peu en cow-boy, le design n'était pas génial et ma solution commençait à être sens dessus dessous. J'ai donc commencé à faire du réusinage pour être capable de mieux me retrouver. C'est à ce moment que des bugs ont commencé à faire surface. Je me suis mis à perdre un temps fou. Les modifications étaient suivies par des séances de débogage dans Visual Studio et je maudissais les dieux de la programmation, mais surtout moi-même. Au lieu d'avancer, je faisais des pas en arrière à chaque fois que je modifiais du code.

Je n'ai eu d'autre choix que de recommencer du début. Mais cette fois, j'ai bâti mon code comme je suis habitué de le faire : en TDD. J’ai quelque fois eu le goût de prendre le code du prototype et le copier dans mes nouvelles classes, mais j'ai presque toujours résisté à la tentation. Bien sûr, j'ai gardé certains concepts mais le fait de recommencer du début a fait émerger un design différent et surtout meilleur.

En bref, soyez plus brillants que moi. Prenez le temps de bien faire les choses dès le début et en bout de ligne vous gagnerez du temps. Je crois qu'on peut se permettre d'expérimenter de nouveaux outils sans faire de tests unitaires exhaustifs. Mais il faut savoir identifier le moment où on a une assez bonne idée de la solution et reprendre les bonnes pratiques de développement.

En terminant, voici quelques billets qui pourraient vous intéresser concernant le TDD et les tests unitaires.

Jusqu'à quel point dois-je tester mon code ?

TDD : comment partir du bon pied ?

Comment rendre vos tests plus propres grâce aux builders ?

 

Appliquer les principes du « 5 S » dans votre code: Ordonner

Publié par David Beaumier et Jean-François Gilbert le jeudi 19 février 2015 à 13:32

Un de mes derniers billet présentait comment la méthode 5 S  peut s’appliquer au développement logiciel autant que dans un environnement de travail "physique".  Aujourd’hui, mon collègue Jean-François Gilbert et moi avons pensé donner suite à ce billet en vous proposant quelques outils et références fort utiles pour celui ou celle qui souhaite rendre sa base de code 5 S.

Notre objectif n’est pas ici de dresser une liste exhaustive des outils disponibles, mais bien de démonter comment chacun des concepts 5 S peuvent être mis en œuvre en tirant profit des facilités à notre disposition. Aujourd'hui, nous débutons la série avec le premier concept : ordonner (ou Seiri, en japonais). Cette première opération nous demande de supprimer l’inutile.

Retirer le code mort

Heureusement, plusieurs outils permettent maintenant d’identifier en temps réel si un bout de code est utilisé ou non. Il devient ainsi facile de prendre l’habitude de valider si une partie du code qu’on touche pourrait être éliminée.

Voici un exemple où Resharper est configuré de façon à fournir un indicateur visuel qui permet de voir en un clin d’œil les parties inutiles du code source. On peut d'ailleurs établir un parallèle entre ce type d'indicateurs et le management visuel, fortement utilisé en Lean management.

Resharper Indicateurvisuel Codemort

Identifier le code dupliqué

À bien des égards, le code dupliqué est pire que le code mort. Surtout si l'ensemble de ces rejetons n'évolue pas au même rythme. On risque de se retrouver avec des variantes du code de base qui peuvent être difficiles à réconcilier à terme. Et que dire du risque de bogues si on oublie de modifier une de ces copies!

Plusieurs IDE, tel que RubyMine, offrent des fonctionnalités pour identifier les parties de code qui se retrouvent dupliquées.

Rubymine Analyserduplication

Les utilisateurs de Visual Studio ne sont pas en reste avec la fonctionnalité Code Clone Detection.

VS Code Clone Detection

Voilà quelques exemple d'outils qui devraient vous permettre de mette en application la règle des scouts : « laisser le campement plus propre en partant qu’à l’arrivée ».

Et vous, avez-vous des outils préférés pour garder votre code ordonné? N'hésitez pas à partager vos coups de coeur en nous laissant un commentaire ci-dessous.

D'autres billets qui pourraient vous intéresser

Merci pour le feedback

Publié par Marc Allard le mardi 17 février 2015 à 19:19

Thanks For The Feedback

C’est la fin d’une dure journée. Au bureau, des clients vous ont tenu au téléphone pendant une heure à râler pour des pacotilles et votre boss vous a reproché de ne pas être assez patient avec eux. De retour à la maison, vos enfants ont boudé le repas équilibré que vous avez trouvé l’énergie de leur préparer. Et après la routine du dodo, quand vous avez eu enfin la liberté de vous affaler sur le divan pour regarder votre série préférée, votre douce moitié a voulu faire le bilan des factures et de tâches ménagères qui s’accumulent depuis trop longtemps. 

Dans ce temps-là, je ne sais pas pour vous, mais moi j’ai envie de faire comme certains commerces qui ferment un certain temps pour rénover. L’affiche dirait quelque chose comme : « Fermé pour travaux majeurs. Cause : surdose de feedback. »

« On nage dans un océan de feedback », écrivent Douglas Stone et Sheila Heen, dans leur livre Thanks for the Feedback, paru au printemps dernier. Stone et Heen ne parlent pas à travers leur chapeau. Ils font partie du Harvard Negociation Project, un programme fondé en 1979  dans l’université du même nom qui a révolutionné la science de la négociation et dont les membres ont été appelés à l’aide de graves conflits comme la crise des otages iranienne, les négociations de paix israélo-palestinienne et l’apartheid sud-africain.

Stone et Heen, eux, ont travaillé avec tout un assortiment de travailleurs : des PDG, des entrepreneurs, des opérateurs de puits de pétrole, des leaders religieux, des policiers, des cinéastes, des journalistes, des travailleurs de la santé, des astronautes, etc. Lorsqu’ils demandaient à leurs clients de décrire le genre de conversation qu’ils trouvaient le plus difficile, le feedback revenait tout le temps. Après tout, difficile d’en donner, même quand c’est impératif: la personne qui le reçoit se met sur la défensive ou en colère et elle se retrouve moins motivée, pas plus. Alors, pourquoi se casser la tête à en donner?

De toute façon, tout le monde l’a expérimenté avec un patron déconnecté : le feedback est injuste ou infondé, et d’ailleurs le moment était mal choisi et le ton manquait cruellement d’empathie. Le donneur de leçons ne comprenait pas notre job et n’avait aucune idée de nos contraintes. Il aurait dû s’attarder à ce qui va vraiment mal dans la boîte — s’il veut une liste, ça nous ferait plaisir de lui fournir!

Durant longtemps, la solution a semblé du côté des émetteurs de feedback. Il fallait montrer aux cadres comment trouver les bons mots, le bon ton et s’assurer que leurs remarques soient pertinentes. On a toutefois oublié les récepteurs dans l’équation — et la clé se trouve de leur côté, soutiennent Stone et Heen. 

« Entraîner les cadres à donner du feedback (…) peut être utile, écrivent-ils. Mais si le récepteur ne veut pas ou s’il n’est pas apte à absorber le feedback, même la persévérance et une livraison habile du message ne pourront pas se rendre très loin. L’autorité ou le pouvoir des émetteurs importent peu; les récepteurs ont le contrôle sur ce qu’ils font, sur ce qu’ils laissent les atteindre, sur le sens qu’ils donnent à ce qu’ils entendent, et s’ils décident de changer. »

C’est vrai au bureau comme à la maison. Dans son livre sur l’agilité familiale, The Secrets of Happy Families, le chroniquer du New York Times Bruce Feiler rencontre Bill Ury, un des cofondateurs du Harvard Negociation project. Feiler s’interroge à savoir si les techniques de négociation qui ont fait leurs preuves en entreprises peuvent fonctionner dans un couple et avec les enfants. Ury lui répond que son questionnement est tout à fait normal, puisque le modèle hiérarchique qui prévalait depuis des lustres dans la société ne tient plus.

« Maintenant, nous sommes dans une période de transition, explique Ury. La démocratie se répand à travers le monde, les organisations deviennent de plus en plus horizontales. La même chose se produit avec les familles, au sein desquelles les membres veulent prendre part aux décisions qui les affectent. Ce qui veut dire que tout est négociable. Qui fait la vaisselle? Ce n’était pas une question il y a une génération. La nôtre est la première où la négociation est la norme. »

Or, toute négociation repose sur le feedback. Le problème, c'est que la rétroaction est difficile à recevoir, parce qu’elle entre en conflit avec quelque chose de fondamental : notre besoin d’être aimé, accepté et respecté tel qu’on est, expliquent les auteurs de Thanks for the Feedback. Ça ne nous vient pas naturellement de voir le bon côté du feedback; notre réflexe est plutôt de froncer les sourcils.

En se braquant, on perd cependant une source incroyable d’apprentissage. Je me souviens d’avoir lu par exemple que, très jeune, Eugenie Bouchard se distinguait des autres joueuses sur le court de tennis car elle était très attentive aux commentaires de ses entraîneurs et se faisait un devoir de corriger ses erreurs au plus vite pour élever son niveau de jeu. On sait où elle est rendue aujourd’hui! 

Pour le reste d’entre nous qui ne possédons pas cette attitude par défaut, Douglas Stone et Sheila Heen nous rassurent : c’est une habileté qui s’apprend. Même après une dure journée. 

D'autres billets qui pourraient vous intéresser

Entretien avec David Starr

Publié par Marc Allard le jeudi 5 février 2015 à 13:14

DavidstarrDavid Starr est un pionnier de l’agilité familiale. Il y a une dizaine d’années, cet ingénieur en logiciel de l’état de Washington, aux États-Unis, et père de quatre enfants (dont un atteint d’un TDAH et un du syndrome d’asperger), a eu l’idée de transposer à la maison les méthodes agiles. M. Starr et sa famille font partie des figures marquantes du best-seller de Bruce Feiler, The Secrets of Happy Families. Je l’ai interviewé il y a un peu plus d’un an, mais l’entrevue reste toujours aussi pertinente. La voici.  

Q. J’ai lu que vous teniez des réunions familiales à la manière agile, comment se déroulent-elles ? 

R. Chaque jour, on se réunit autour de notre plan hebdomadaire et on regarde notre progression par rapport à ce plan. À la fin de la semaine, on fait une rétrospective : on inspecte et on adapte pour voir comment se comporte notre famille. Et après, on recommence! 

Q. Et vous faites ça vraiment chaque matin ?

R. On appelle ça notre mêlée quotidienne (daily huddle). On se réunit chaque matin cinq minutes alors qu’ils (les enfants) se préparent pour aller à l’école et on se dit : «OK, à quoi va ressembler la journée ?» Ça incite vraiment les enfants à se demander à quoi va ressembler leur journée. Bien sûr, ça va probablement changer, mais au moins ça les start avec un sentiment de contrôle sur eux et sur leur journée. Logistiquement, il faut souvent faire ça un enfant à la fois, mais c’est OK aussi. 

Q. Et à quoi ressemble la rencontre familiale hebdomadaire ? 

R. C’est plus élaboré. On réfléchit à ce qui s’est passé dans la dernière semaine — c’est là que se trouve la vraie valeur de l’exercice. On a des conversations super constructives, utiles et bénéfiques durant cette rétrospective. On évalue ce qu’on a fait pour atteindre les objectifs de la semaine et  à quel point on a réussi, mais aussi comment on s’est amélioré. Parfois, on va discuter d’enjeux personnels, mais on focalise vraiment sur la famille en tant que groupe. De là, on essaie de déterminer de nouveaux objectifs pour la semaine suivante. 

Q. Cette semaine, par exemple, sur quel objectif travaillez-vous ? 

R. Il y en a deux. Le premier est anodin — c’est d’être en mesure de répondre à son téléphone. Nous sommes six dans cette maison et ça arrive qu’on ne soit pas capable de joindre personne. On a découvert que c’est parce qu’ils (les enfants) ne rechargent pas leurs téléphones ! (…) C’est ce qui m’a amené à bricoler une petite station de recharge et à inciter les enfants à déposer leur téléphone à un même endroit. Ça, c’est de la logistique, mais ça adoucit les choses dans la maison. 

Le deuxième, c’est de diminuer les frictions et d’augmenter l’harmonie avant le souper. (…) Pour y arriver, on demande à chaque membre de la famille ce qu’il est prêt à faire pour atteindre l’objectif. Par exemple, ma fille a accepté cette semaine d’aider mon plus jeune garçon [qui a un TDAH] à se calmer quand il se fâche — ce qui lui arrive souvent. Et ça, c’est l’exemple parfait de ce qu’on tente de faire, c’est-à-dire de voir comment on peut s’entraider. 

Q. Transposer des méthodes du travail à la maison reste tabou. Pour beaucoup de gens, on ne doit pas mêler les deux….

R. J’ai réalisé à un certain moment que les choses qui fonctionnent au travail fonctionnent parce qu’elles fonctionnement, et non simplement parce que c’est dans un contexte de travail. (…) Nous sommes tous des humains. Qu’on soit ensemble pour atteindre un objectif dans une business ou qu’on soit ensemble pour atteindre un objectif en famille, les dynamiques sont très similaires. 

Q. Et d’après vous, d’où vient cette réticence à s’inspirer du travail pour s’épanouir en famille ?

R. Pour plusieurs, ça peut être apeurant d’appliquer des stratégies venues du monde du travail à la famille. Certains ont connu des entreprises avec une hiérarchie qui s’apparente à un système totalitaire. Or, le développement agile a mis ce système à l’envers en forçant les leaders de l’organisation à être au service des gens qui travaillent pour eux. C’est beaucoup plus humain et beaucoup plus approprié pour ma famille, parce que je suis au service de mes enfants pour qu’ils deviennent des adultes qui fonctionnement bien.

D'autres billets qui pourraient vous intéresser

Archive