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.

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

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

Conférence avec Bob Martin: Exiger du professionnalisme

Publié par David Beaumier le mardi 16 octobre 2012 à 16:09

L'équipe d'Elapse Technologies et la Communauté Agile de Québec sont fiers de rendre disponible la captation vidéo de la conférence prononcée par Robert C. Martin le 24 septembre dernier. Afin de rendre sa présentation des plus dynamique, Bob Martin a choisi de personnifier un CTO nouvellement arrivé dans une organisation. Il nous fait vivre ce que pourrait être la première rencontre du gestionnaire avec son équipe de développement.

Dans un style bien à lui, "Uncle Bob" explique par des exemples très concrets pourquoi exiger du professionnalisme d'une équipe de développement logiciel est devenu un impératif. Peu importe le rôle que vous exercez dans une équipe de développement il ne fait aucun doute que le contenu de ce vidéo saura vous apporter des pistes de réflexion.

N'hésitez pas à utiliser la fonctionnalité de sous-titrage offerte par YouTube si vous souhaitez suivre le texte en même temps que l'allocution. Il suffit de cliquer sur le bouton "CC" qui se trouve dans la barre d'outils situé au bas du vidéo.

D'autres extraits vidéos de Robert C. Martin sont offerts en exclusivité sur le blogue developpementagile.com

Quelles exigences vous imposez-vous?

Publié par David Beaumier le mardi 5 juin 2012 à 14:18

En regardant une entrevue avec le réputé musicien Michel Legrand j'ai été très intéressé de l'entendre parler de la pratique de son art. On a souvent le réflexe de décrire le travail d'un professionnel de son calibre comme frôlant la perfection. C'est toutefois intéressant de voir de quelle façon Michel Legrand perçoit cet élément de perfection.

"[la perfection] ce n'est pas le bon mot. C'est l'exigence qu'on a. Personne n'atteint la perfection, nous non plus. Une exigence telle que tout devient difficile. [...] Parce qu'il faut les jouer de façon sublime." - Michel Legrand

Je vois là un parallèle intéressant avec le travail d'un professionnel du développement logiciel. On le sait, la conception logicielle est un domaine qui demande beaucoup de créativité et de doigté (sans mauvais jeu de mots). Tel un musicien, on doit nous aussi pratiquer notre art et développer notre talent. Que dirait-on d'un musicien qui ne jouerait qu'en concert et qui ne s'accorderait aucune période de pratique avec son orchestre? Pourtant, est-ce que notre industrie encourage les gens à se perfectionner sur une base régulière? Les activités comme les Kata, Dojo et Code Retreat sont-elles fréquentes dans votre organisation?

Qu'il s'agisse du Personal Software Process (PSP) ou des pratiques d'eXtreme Programming, il existe pourtant déjà des cadres de travail qui favorisent cet aspect de qualité, d'apprentissage et de savoir-faire. Qu'est-ce qui fait en sorte qu'après toutes ces années ceux-ci demeurent l'exception?

D'un autre côté, quelles sont les attentes de nos clients? Ne sont-elles pas similaires à celles des spectateurs assistant à un concert et qui s'attendent à être émerveillés par la prestation du musicien? Ces spectateurs ne s'attendent probablement pas à la perfection; quelques fausses notes ou l'oubli de quelques mots dans une chanson rend probablement l'artiste plus humain et plus sympathique à la limite. Par contre, il faut bien quelques uns de ces moments où la prestation nous ébahit.

Et si l'on voyait la revue de Sprint comme un concert et nos client comme les spectateurs. Quelles exigences devrions-nous alors nous imposer durant le Sprint? Qu'est-ce que je peux faire comme individu et comme membre de l'équipe pour en arriver à émerveiller le client et lui permettre de dire "Wow, mais quelle prestation de l'équipe"?

Comme Michel Legrand, êtes-vous prêts à sortir de la facilité de votre zone de confort? Est-ce que c'est un parallèle qui tient réellement la route dans notre secteur? N'hésitez pas à commenter ce billet et à partager votre point de vue à ce sujet.

3 leviers pour aider l'auto-organisation de votre équipe Agile

Publié par Louis-Philippe Carignan le samedi 3 mars 2012 à 12:00

L’un des 12 principes de l’Agilité nous dit :

« The best architectures, requirements, and designs emerge from self-organizing teams. »

« Les meilleurs architectures, requis et design émergent d’équipes auto-organisées »

Mais comment faire pour que votre équipe devienne auto-organisée? Quels sont les outils mis à la disposition du Scrum Master pour que votre équipe soit auto-organisée? Dans le livre « Succeeding with Agile » de Mike Cohn, l’auteur consacre un chapitre à propos de ce thème. Cohn suggère trois leviers que les Scrum Masters peuvent utiliser pour jouer sur l’auto-organisation de leur équipe :

  1. Les contenants : La frontière où l’auto-organisation a lieu
  2. Les différences : La variété dans l’équipe
  3. Les échanges : Les interactions entre les membres de l’équipe

Levier 1 : Les contenants

Les contenants ne sont pas seulement des espaces géographiques comme la même pièce ou le même édifice. Un contenant peut aussi être le même langage de programmation ou la même nationalité. Vous pouvez jouer sur le contenant de votre équipe en changeant le nombre de personnes sur l’équipe. Vous pouvez aussi introduire un nouveau contenant tel qu’une communauté de pratique ou modifier les responsabilités d’une équipe.

Levier 2 : Les différences

Les différences visent la personnalité, l’expérience de travail et la position hiérarchique des membres de l’équipe. Par exemple, vous pouvez influencez l’auto-organisation en ajoutant une personne avec plus de connaissances techniques pour aider l’équipe à résoudre ses problèmes. Ou si l’équipe a de la difficulté à prendre des décisions, on peut jouer sur les différences en ajoutant une personne qui a un certain pouvoir décision. Notez que je n’ai pas dit d’ajouter une personne qui va prendre les décisions pour l’équipe mais bien une personne qui peut aider l’équipe à légitimer ses décisions.

Levier 3 : Les échanges

Les échanges sont la façon que les membres de l’équipe communiquent entre eux ainsi qu’avec leurs parties prenantes. Si on veut influencer un échange, on peut le formaliser (document, réunion, comité) ou le déformaliser. On peut aussi changer la fréquence des échanges. Peut-être qu’une réunion entre l’équipe et une personne externe devrait se faire plus régulièrement?

Mise en pratique

Si vous voulez mettre en pratique ces leviers, je vous suggère de commencer par dresser l’inventaire de ces leviers dans votre équipe. Pour les contenants, commencer par identifier ceux qui sont liées à votre équipe. Pour chaque contenant, est-ce que vous trouvez que celui-ci a un impact positif, négatif ou neutre sur l’auto-organisation de votre équipe? Identifier aussi les différences que vous avez dans l’équipe? Est-ce que tous les membres de l’équipe ont le même niveau d’expérience? Sont-ils tous expérimentés avec les technologies employées dans votre équipe? Selon vous, quelle différence peut améliorer l’auto-organisation de l’équipe? Finalement, en ce qui à trait aux échanges, identifier l’intensité des échanges? Est-ce que les échanges deviennent trop personnels? Est-ce que vous devriez encourager les échanges avec une personne externe pour modifier les échanges?

Conclusion

Je trouve que l'auto-organisation est un concept plus ou moins bien abordé dans l'Agilité. Bien qu'on en fasse la promotion dans la littérature, il est difficile de bien s'outiller pour qu'elle se réalise. Pour un gestionnaire arrivant d'un milieu plus traditionnel, il peut lui être difficile de mettre en pratique un tel concept et revenir à une gestion traditionnelle. Pour une personne avec un passé plus technique, il peut être difficile de travailler sur cet aspect beaucoup moins tangible que les technologies. Après tout, les humains, ça ne se compile pas!

Archive