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

 

La puissance des bloqueurs

Publié par David Beaumier le mardi 19 juin 2012 à 13:51

Les bloqueurs (ou impediment en anglais) servent à mettre en évidence les obstacles rencontrés par une équipe Scrum. Ils jouent un rôle essentiel à l’intérieur d’un sprint en rendant visible les situations où l’équipe ne peut progresser à sa cadence optimale. À ce sujet, le Guide Scrum indique que le Scrum Master sert l’équipe « [...] en supprimant les obstacles nuisant au progrès de l'équipe […] ». Le fait d’ajouter un bloqueur au tableau de tâches énonce le besoin d’une intervention visant à aider l’équipe à respecter son engagement à la livraison du Sprint. Mais au-delà des bénéfices sur le sprint, que peut-on apprendre d’autre des bloqueurs?

En fait, je crois que les bloqueurs peuvent nous aider à identifier des situations qui pourraient facilement passer sous le radar des rétrospectives. En prenant le temps d’analyser les bloquants qui ont été soulevés au cours des sprints passés, l’équipe peut prendre conscience des facteurs qui influencent ses résultats. Évidemment, il convient de distinguer les évènements ponctuels (votre DBA s’est cassé un bras et a été absent deux semaines) de ceux qui sont systémiques.

Pour faciliter l’analyse à plus long terme on peut même penser à conserver des statistiques sur les bloqueurs :

  • Nombre de bloqueurs dans le sprint;
  • Temps écoulé entre l’ouverture et la résolution;
  • Nature du problème (technique, organisation du travail, savoir-faire, etc.);
  • Niveau d’impact sur l’équipe;
  • Etc.

Avec cette information en main il devient beaucoup plus facile d’avoir une vue d’ensemble et d’établir des tendances. En se donnant comme discipline d’analyser ces données sur une base régulière (disons après chaque Sprint) une équipe Scrum dispose ainsi d’un outil de plus pour optimiser ses façons de faire.

Ma présentation à l'IIBA de la région de Québec

Publié par Louis-Philippe Carignan le mercredi 18 avril 2012 à 18:00

J'aimerais remercier le comité organisateur de la section de Québec de l'IIBA pour l'accueil à leur communauté ainsi que leur disponibilité pour répondre à mes questions lors de ma préparation. J'ai beaucoup apprécié nos interactions lors de cette rencontre et j'espère que cette expérience a été profitable pour tous les participants.

Pour ceux qui n'ont pas eu la chance de participer à la rencontre, j'ai couvert les techniques suivantes du chapitre 4 de l’extension Agile du BABOK:

  • Les jeux collaboratifs;
  • Le développement piloté par les comportements (Behavior Driven Development);
  • Les rétrospectives;
  • La cartographie de la valeur de votre processus (Value Stream Mapping).

Vous pouvez voir ou revoir ma présentation ci-dessous ou aller directement sur SlideShare.net pour la télécharger en format pdf.

Évaluer votre rencontre rapidement

Publié par Louis-Philippe Carignan le dimanche 8 avril 2012 à 14:00

Comment faire pour obtenir du feedback de vos participants lorsque vous tenez une rencontre, conférence ou autre réunion? Oui, vous pourriez créer un formulaire d'évaluation en ligne et l'envoyer à tous les participants. Oui, vous pourriez même créer ce formulaire pour qu'il soit accessible par le téléphone intelligent de vos participants. Mais dans un monde de l'instantanné comme le nôtre, n'y aurait-il pas un moyen plus rapide de connaître leur appréciation de la rencontre?

Voici un truc que j'ai trouvé lorsque les moyens technologiques sont limités ou un peu trop long à préparer et envoyer.

Au début de la rencontre, je distribue un Post-It à chaque participant. Retardadaire sont exclus. Tant pis pour eux. J'informe alors les participants de la feuille qui est à côté de la sortie du local. Au haut de la feuille, il y a un visage souriant tandis qu'au bas, il y a un visage mécontent. J'informe les participants qu'à la sortie de le rencontre, ils pourront coller leur Post-It à l'endroit qu'ils le désirent sur la feuille. J'obtiens donc un feedback instantanné de la rencontre. On obtient ce genre de résultat.

Retro Action

Lors de présentations publiques, je laisse aussi ma carte d'affaires pour les gens qui désirent m'envoyer un commentaire personnel par la suite. Si vous animez une rétrospective, vous pouvez même utiliser ce radiateur d'information pour chercher à améliorer vos prochaines rétrospectives.

  • Plus récents
  • 1
  • Plus anciens

Archive