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.

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

Pourquoi vos résolutions ne tiennent pas

Publié par Marc Allard le mercredi 14 janvier 2015 à 16:00

Source: www.clevelandpersonaltraining.comS’il y a un moment dans l’année où Google doit nous trouver prévisibles, c’est bien en janvier. Chaque début d’année, le moteur de recherche enregistre une hausse marquée des recherches pour les appareils de mise en forme comme les tapis roulants et les exerciseurs elliptiques, selon Google Trends. L’engouement pour les marathons, le gym et… les régimes connaît le même genre d’envolée.

Le coupable? Les résolutions du Nouvel An. Gonflés d’espoirs à l’amorce d’une nouvelle douzaine de mois, nous nous promettons de bouger plus, de manger mieux, d’arrêter de fumer, de faire le ménage dans nos finances, d’être plus performants au travail, plus organisés à la maison, plus disponibles pour nos enfants, nos familles, nos amis. La liste est longue. Mais amenez-en! Notre futur soi, version 2015, peut en prendre!

Le problème, c’est qu’il ne tient pas le coup, notre futur soi. Selon une étude de l’Université Scranton, aux États-Unis, parue en 2014, environ 92 % des gens renoncent à leurs résolutions en cours de route, un taux de succès de 8%... Pourquoi sommes-nous aussi poches? Certains auteurs de psycho-pop ne se lassent pas de répéter que c’est parce qu’on manque de volonté, parce qu’on ne veut pas assez. Or, c’est le contraire : on en veut trop — ou du moins, trop en même temps.

Depuis la fin des années 90, c’est ce que le psychologue américain Roy F. Baumeister s’est acharné à démontrer. La volonté, explique-t-il dans son livre Willpower: Rediscovering the Greatest Human Strength, est une réserve d’énergie mentale limitée. Plus on l’exerce sur une chose, moins il en reste pour autre chose. Aussi simple que ça.

Si, par exemple, je prends les marches au lieu de l’ascenseur pour monter au bureau alors que n’en ai pas l’habitude, j’aurais ensuite moins de volonté pour résister à la Kit Kat de la machine distributrice à la pause. Appliqué aux résolutions du Nouvel An, ce concept d’épuisement de la volonté, aussi appelé la «fatigue décisionnelle», signifie qu’il n’y a rien de pire qu’une liste de résolutions adoptées simultanément.

«Parce que vous n’avez qu’une réserve de volonté, écrit Baumeister, les différentes résolutions du Nouvel An compétitionnent toutes entre elles. Chaque fois que vous vous consacrez à une, vous réduisez votre capacité à tenir les autres.»

Bref, si vous êtes déjà gênés en pensant aux promesses que vous vous êtes faites le 1er janvier, vaut mieux y aller une à la fois. 

Et pour vous aider, voici une humble suggestion.

Pourquoi ne pas commencer l’année en échafaudant un kanban personnel dédié à vos résolutions? Sans doute êtes-vous familier avec ce simple outil de visualisation du flux de travail. Armés de post-it, prenez une grande feuille de papier et divisez-la en trois grandes sections verticales. Dans la première, collez les résolutions qui vous semblent les plus importantes ; dans la deuxième, déplacez celle (il devrait y en avoir une à la fois!) qui est en cours ; dans la troisième, ne laissez que celles que vous avez réussi à tenir.

Comme exercice annuel, ça peut paraître un peu intimidant. Mais qui sait, votre futur soi pourrait vous en remercier.

D'autres billets qui pourraient vous intéresser

Une offre d'emploi inspirante

Publié par David Beaumier le mardi 15 avril 2014 à 18:22

Il y a quelques temps, mon collègue Félix-Antoine me faisait part d'une offre d'emploi se démarquant du lot. J'ai tardé un peu à la partager avec vous, mais, même si les postes sont maintenant comblés, je trouve tout de même qu'il vaut la peine d'en parler. L'offre de l'équipe de la plateforme de radio-canada.ca se distingue nettement des offres qu'on rencontre habituellement.

Offre-Emploi-Radio-CanadaBien que je trouve que l'offre parle d'elle-même, je me permet tout de même de souligner, ci-dessous, quelques points que je trouve forts intéressants.

  • Le mot ressource n'est jamais utilisé pour désigner un candidat. On utilise plutôt des mots comme "allumé" ou "personne", des termes beaucoup plus inspirants.
  • On n'utilise pas les énumérations habituelles du type "votre tâche consistera à faire ceci, cela et toute autre tâche connexe". On présente plutôt le profil recherché et les qualités attendues des candidats.
  • On met l'emphase sur les capacités du candidat à comprendre les concepts qu'à avoir un nombre minimal d'années d'expérience.
  • On utilise un langage technique juste et précis. On sait clairement quelles sont les compétences recherchées.
  • On parle de l'équipe et de contribuer à son succès en relevant des défis.
  • La terminologie Agile/Scrum utilisée indique bien dans quel cadre l'équipe oeuvre.

Embaucher un employé dans le secteur des technologies de l'information représente aujourd'hui un bon défi. Cependant, je n'ai aucun doute qu'une telle offre d'emploi aura permis à Radio-Canada de dénicher des candidats au profil recherché. Plusieurs organisations auraient avantage à sortir des sentiers battus et à s'inspirer de cette offre d'emploi lorsqu'ils présentent des opportunités de carrière en développement logiciel.

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 :

À 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 !

Archive