Moi : Wow! Je viens de croiser un de vos clients et il est super satisfait du produit que vous venez de lui livrer.

Client : C’est sûr. Pour nous, la satisfaction du client est une chose très importante.

Moi : Je vois que vous semblez avoir un processus de livraison très bien huilé. Pourquoi mettez-vous autant d’efforts dans ce processus?

Client : C’est parce que, pour nous, c’est la chose la plus importante. Nous savons déjà que nous avons un des meilleurs produits sur le marché, mais si nous n’arrivons pas à le livrer à temps pour nos clients, ils seront déçus et iront voir ailleurs.

Moi : Parlez-moi un peu de ce processus.

Client : Notre équipe de livraison…

Moi : Équipe! Vous voulez dire qu’il y a toute une équipe qui travaille uniquement pour la livraison?

Client : En effet, nous avons une équipe dédiée. Elle s’occupe de s’assurer que tout est prêt pour le jour de la livraison. Elle coordonne les efforts des équipes de production et de contrôle de la qualité pour s’assurer que le produit sera livré à temps et dans la meilleure condition possible. Elle fixe d’ailleurs les critères à respecter pour considérer le produit comme « livrable ». Elle s’assure que toutes les demandes spéciales du client sont bien installées et fonctionnelles. Le produit est d’ailleurs livré avec un guide d’entretien et un manuel d’utilisation complet. Nous faisons le tour du produit pour expliquer toutes les fonctionnalités à notre client, et nous prenons le temps de répondre à toutes ces questions.

Moi : Malgré tous ces efforts, est-ce qu’il vous arrive de ne pas réussir à livrer à temps ou avec la qualité souhaitée?

Client : Au début oui. Mais maintenant, le processus est presque tout automatique. Une simple liste à cocher à la fin pour s’assurer qu’il ne manque rien, et le tour est joué!

Moi : Vous devriez donner des cours sur votre façon de faire. Je crois que vous pourriez en faire bénéficier plusieurs.

Je suis alors sorti de chez le concessionnaire automobile avec une inspiration nouvelle et le désir d’améliorer le processus de livraison dans ma propre équipe.

—

Bien entendu, ce dialogue est fictif, mais il aurait très bien pu se dérouler exactement comme ça. Le monde de la vente de voitures porte en effet une attention particulière à la livraison de leur produit.

C’est un exemple à suivre!

Les approches de développement Agiles gagnent en popularité, mais trop peu en comprennent bien les fondements. Au cours de cette séance, les valeurs ainsi que les principes et pratiques d’une approche de développement Agile seront présentés par de multiples exemples concrets. Pour intégrer un maximum d’aspects pratiques, la présentation portera sur notre expérience concernant la mise en place d’une pratique d’analyse d’affaires au CN. Ceci nous permettra de présenter des discussions que nous avons eues, des choix que nous avons dû faire, des outils que nous avons choisis et comment nous les avons adaptés, comment nous avons utilisé des principes Agiles dans la conduite de l’initiative et aussi comment nous entrevoyons le futur.

Plus de renseignements sur l’événement : Journée-conférence en analyse d’affaires – IIBA Montréal

Au plaisir de vous y voir!

Le monde de l’Agilité, plus particulièrement l’approche Scrum, est de plus en plus en demande dans des entreprises cherchant à améliorer leurs pratiques de développement logiciel. Urban Turtle est une suite de modules Agiles pour la plateforme Team Foundation Server de Microsoft. Plus précisément, il s’insère de manière transparente à même le portail Web de la plateforme, soit Team Web Access. La plateforme Urban Turtle comporte une suite d’outils Agiles qui aide les organisations de développement logiciel dans la réalisation de leurs projets. Qu’il s’agisse de la planification, de la réalisation ou du suivi d’un projet, Urban Turtle est là pour simplifier la vie des gens qui l’utilisent. Notre application des méthodes Agiles nous permet de livrer de la valeur chaque mois. Notre objectif pour 2013, 12 versions en 12 mois.

« Depuis notre toute première version en 2008, nous travaillons très fort pour rendre la vie des équipes de développement plus simple et agréable. Après 5 ans et 3 versions, nous sommes très fiers de ce que nous avons accompli. Je veux remercier tous les membres de l’équipe Urban Turtle ainsi que tous les Pyxissiens qui contribuent à faire de ce produit une réussite commerciale, » indique Dominic Danis, directeur du produit.

« Nous déployons des efforts considérables afin d’offrir de la valeur aux utilisateurs et d’améliorer ce produit. Celui-ci s’inscrit très bien dans la mission du /studio, et je suis très fier du travail accompli par l’équipe jusqu’à maintenant, » affirme Martin Landreville, vice-président au développement de solutions et produits à Pyxis /studio.

L’équipe a bien hâte au 25 mai prochain pour connaître le gagnant dans la catégorie « Réussite commerciale ». Nous souhaitons à toute l’équipe d’Urban Turtle la meilleure des chances.

C’est donc avec beaucoup d’enthousiasme que nous vous annonçons l’arrivée de Francesco Lomonaco, coach Agile et formateur trilingue (français, anglais et italien) au sein de notre équipe. Francesco est un ex-guitariste classique qui, un jour, s’est intéressé au développement logiciel. Dès lors, sa carrière a pris un sérieux tournant puisque cela fait maintenant 15 ans qu’il compose avec des lignes de code. Ces dernières années, il a joué plusieurs rôles au sein de diverses équipes de développement, du développeur au gestionnaire en passant par celui de formateur. Les méthodes Agiles le passionnent et on peut dire qu’il a un vrai don pour transmettre ce sentiment. Je vous invite donc à faire connaissance avec Francesco et je m’unis à toute l’équipe de Pyxis pour lui souhaiter la bienvenue parmi nous!

L’arrivée de Francesco nous permet également d’étendre notre offre à partir de la Suisse. Tout d’abord au niveau de l’accompagnement, nous augmentons notre capacité et nous élargissons le champ des possibles. Que ce soit au niveau technique ou organisationnel, dans le cadre d’une transition Agile globale ou pour le démarrage d’un projet pilote, nous sommes à même de vous aider et de répondre à vos demandes, et ce, dans les meilleures conditions. La formation est également à l’honneur avec de nouvelles dates en Belgique, en Angleterre, en Italie, en France et en Suisse. Nous reviendrons très prochainement sur ce sujet. D’ici là, rendez-vous sur notre page Formation pour en apprendre davantage.

Cette nouvelle année nous promet beaucoup d’action et de nouveaux défis. Nous avions envie de partager notre ressenti et espérons pouvoir réussir avec vous à changer le monde, une entreprise après l’autre

Vous devez déjà reconnaître l’importance de l’entraînement dans notre milieu de travail. Je vous souhaite d’avoir déjà fait quelques entraînements.

• Avez-vous réussi à justifier à votre patron votre temps d’entraînement?
• Est-ce que votre entraînement a été rentable?
• Avez-vous vraiment amélioré vos compétences?

À la mesure de vos attentes

Pour justifier l’entraînement, il faut d’abord déterminer les besoins. Je vous ai déjà présenté comment recueillir des sujets d’entraînement, mais pas encore comment choisir le bon. Dans les équipes Agiles autoorganisées, cette responsabilité renvient à l’équipe.

Pour commencer, en équipe, déterminez 4 à 6 sujets avec lesquels vous vous sentez moins à l’aise. Essayez de trouver des sujets qui font partie de votre travail quotidien et pour lesquels vous devez toujours faire un effort. Par exemple, si vous travaillez avec du code legacy et que vous avez toujours de la difficulté à extraire les dépendances pour ajouter des tests automatisés, il s’agit d’un bon sujet.

Une fois que vous aurez votre liste de sujets, évaluez votre niveau de compétence actuel pour chacun. Une bonne référence pour déterminer le niveau de compétence est l’échelle de Dreyfus.

Ensuite, établissez une cible à atteindre et un objectif de sprint. Vous pouvez utiliser un tableau comme celui-ci pour consigner vos résultats.

Vous êtes maintenant prêts à l’entraînement.

On n’arrête pas le progrès

Une fois l’entraînement terminé ou, minimalement, lors de la rétrospective, il est important d’évaluer où vous en êtes. Prenez le temps de revoir les sujets que vous aviez choisis et refaites votre auto-évaluation. Soyez honnêtes et ne vous découragez pas. Il est possible qu’après le premier et peut-être même le deuxième entraînement, il n’y ait pas d’amélioration notable. Après tout, c’est comme dans la vie, ce n’est pas après deux séances d’entraînement au gym qu’on a perdu les kilos en trop résultant des excès faits pendant le temps des Fêtes.

La mesure de progression selon l’échelle de Dreyfus est quand même une mesure subjective. Il faut donc être honnête et critique pour que la mesure soit significative. Il est possible d’utiliser d’autres mesures de performance plus objectives. Par exemple, la vélocité de l’équipe ou le temps réel d’exécution de certaines tâches par rapport à une référence similaire dans le passé.

Si vous sentez avoir atteint vos objectifs dans tous les sujets choisis, alors refaites le processus du début avec une nouvelle liste de sujets. Par contre, n’oubliez pas que si vous ne vous entraînez plus sur un sujet, il est possible de régresser. Refaites régulièrement une auto-évaluation sur les sujets passés.

J’espère que ces renseignements auront un effet d’entraînement…

Ça y est, c’est fait! Nous avons complété notre première séance d’entraînement. (Voir blogue précédent)

Nous avons réussi à convaincre la direction. Celle-ci nous a accordé 3 heures par sprint de 3 semaines pour parfaire nos techniques. Donc, à partir de maintenant, à chaque trois semaines, le vendredi de 9 heures à midi, c’est notre séance d’entraînement.

Étant dans un projet en cours, nous avions identifié un besoin de nous entraîner sur les techniques de remaniement (refactoring) du code existant. Nous voulions surtout nous entraîner sur une technique précise que je pourrais nommer la « transplantation ». Si vous lisez tous les livres sur le remaniement de code, comme “Refactoring: Improving design of existing code” par Martin Fowler, Kent Beck et d’autres, vous trouverez plusieurs techniques pour faire du remaniement. Ces techniques prennent souvent en compte le fait que vous ayez une bonne couverture de tests au départ. Ce qui n’est pas le cas pour notre projet actuel. Cette lacune m’a amené à développer la technique de la « transplantation ».

La transplantation

Ceci consiste à remplacer du code malade par du code sain, sans faire souffrir le système. La technique comporte trois étapes simples :

1. Extraire les fonctionnalités du code à corriger;
2. Améliorer le code en passant le TDD et le refactoring;
3. Réintroduire le code dans son environnement initial.

Ça peut paraître simple et évident au premier coup d’œil, mais dans les faits ça ne l’est pas tant que ça.

L’extraction

Je parle ici d’extraction de la fonctionnalité et non du code. Quand un chirurgien veut remplacer un cœur naturel par un cœur artificiel, il n’a pas besoins de simuler parfaitement le battement du cœur. Il a seulement besoin d’une pompe pour faire circuler le sang.

Dans le code, c’est pareil. Si votre code malade accède directement à une base de données SQL Server pour récupérer l’information, vous n’avez pas à faire la même chose. L’important c’est de remplacer la fonctionnalité, par exemple, par un repository.

Le remaniement

C’est là qu’entre en jeu toutes ces belles techniques de remaniement mentionnées dans les livres suivants : Extract Method, Extract Class, Introduce parameter Object, Replace Conditional With Polymorphism,… Pour éviter de partir de rien, vous allez sûrement avoir tendance à reprendre du code existant, et c’est normal, mais soyez prudents!

Avant de modifier quoi que ce soit, assurez-vous d’avoir une couverture complète de votre code par des tests unitaires. Du refactoing sans couverture de tests, c’est comme conduire sans ceinture de sécurité; ça va tant qu’il n’y a pas de problèmes.

Le plus grand défi auquel vous aurez à faire face c’est l’abstraction des dépendances. Je vous parlerai de ce point dans un prochain billet.

La réintroduction

Si vous avez bien travaillé à l’étape précédente, la réintroduction devrait se faire facilement, sans trop de risques de rejet. Par contre, il peut arriver que le nouveau code ne soit pas parfaitement adapté à son nouvel environnement. Après tout, il a été créé en laboratoire.

Dans ce cas, vous avez deux choix : soit vous retournez à l’étape précédente pour faire des corrections, toujours avec la protection de tests, soit vous modifiez l’environnement du code pour qu’il fonctionne bien. Si vous choisissez cette deuxième option, il faut que vous ayez l’intention de remanier cet environnement plus tard et que le code d’adaptation ne soit que temporaire.

 A suivre…

Quoi?

Premièrement, il faut déterminer les techniques et les pratiques à améliorer. Faites une liste de tout ce que vous devez maîtriser pour votre projet :

• outils (éditeurs de code, cadre de test, outils de refactoring, outils de gestion de sources…);
• technologies (service Web, site Web, application de bureau, mobile…);
• langages de programmation (C#, Java, JavaScript, HTML, Python, PHP…);
• standards de développement (ceux de l’industrie, vos propres standards)…

Vous constaterez que cette liste sera longue. Une bonne façon de ne rien oublier, c’est de monter cette liste sous forme de sondage à toute l’équipe. Nous avons utilisé un wiki dans lequel chacun a ajouté ses idées, qu’elles soient bonnes ou moins bonnes.

Prioriser

Bon, vous avez maintenant 20, 40, 60 items dans votre liste. Il faut maintenant les ordonner en ordre de priorité et d’importance. Tentez de mettre en premier les items qui auront le plus grand gain à court terme. Accordez de l’importance aux compétences qui ne sont maitrisées que par une seule personne. Il n’est pas nécessaire d’ordonner toute la liste. De toute façon, il y a de fortes chances que de nouvelles compétences s’ajoutent ou soient retirées en cours de route.

Planifier (quand?)

Ensuite, il faut établir un horaire réaliste et le respecter. Prévoyez une fréquence et une durée. Par exemple, tous les vendredis après-midi pendant 4 heures. Il est important de prévoir suffisamment de temps pour aborder le sujet choisi. Tout comme dans d’autres domaines, un entraînement trop court n’apportera pas les gains escomptés et un entraînement trop long aura tendance à ne pas être assez ciblé sur l’objectif à atteindre.

Comment?

Un bon entraînement se déroule en trois étapes :

• Théorie ‒ Réservez une période suffisamment longue au début d’un entraînement pour réviser la théorie sur le sujet. Si la compétence est déjà maîtrisée par un membre de l’équipe, celui-ci peut donner une minicours sur le sujet.
• Pratique ‒ La pratique doit permettre de se perfectionner sur le sujet. Plus le sujet est complexe, plus il faudra de répétition. Un des buts ici, c’est que le sujet soit suffisamment maîtrisé pour qu’il devienne presque un réflexe de l’appliquer.
• Évaluation ‒ À la fin de chaque pratique, il est important d’évaluer ce qui a été accompli et de se questionner sur les points à améliorer pour les prochaines pratiques. Pour évaluer vos connaissances sur un sujet, vous pouvez utiliser l’échelle de Dreyfus. Avant la pratique, attribuez-vous une note et un objectif à atteindre et valider le résultat à la fin de la pratique. Rappelez-vous qu’il n’est pas nécessaire d’être un expert dans tout!

Bon entraînement!

Voir la suite dans Le premier entraînement.

En parallèle, j’ai commencé à corriger le premier devoir de la session.

Devoir
Dans le but de mieux se connaître et d’ajuster le matériel en fonction de vos objectifs, décrivez les raisons de votre intérêt pour ce cours. Cette description devrait comprendre :

• votre expérience avec l’Agilité (théorique ou en entreprise);
• vos objectifs envers le cours : ce que vous aimeriez connaître ou savoir faire à la fin de la session.

C’est à la lecture des devoirs que le hamster dans ma tête a commencé à tourner et que mon approche s’est transformée. En résumé, voici les 4 grandes réponses des étudiants :

• découvrir les méthodes Agiles;
• apprendre à utiliser les pratiques Agiles;
• être en mesure de justifier l’utilisation de l’Agilité (avantages et inconvénients);
• être en mesure de mettre en place les méthodes Agiles.

Je pense bien qu’à la 2e semaine, nous avions couvert les 3 premiers objectifs. Par contre, j’avais des doutes sur l’atteinte du 4e objectif : est-ce que les étudiants sont en mesure de mettre en place une méthode Lean? Sont-ils en mesure de faire un diagnostic? De faire une proposition Lean basée sur des objectifs d’amélioration? Même si c’est normal de ne pas être un expert après un seul cours, je voulais maintenant vérifier que les étudiants avaient au moins une idée des premier pas à faire, qu’ils étaient capables de se risquer à une initiative Lean.

Alors, j’ai partagé ma réflexion avec les étudiants au début du cours de la 3e semaine. Effectivement, les étudiants avaient bien compris les concepts, mais ils ne savaient pas encore comment les mettre en œuvre. Convaincu, j’ai décidé de reprendre le cours depuis le début, en gardant en tête les objectifs des étudiants. Je suis vraiment content de l’avoir fait. Les apprentissages des étudiants étaient de plus grande qualité. Qu’est-ce que j’ai fait de différent?

• J’ai questionné les étudiants sur presque tous les sujets, avec des questions pour vérifier que les concepts étaient bien intégrés, indépendamment et collectivement.
• J’ai invité les étudiants à établir un plan d’attaque à l’aide d’une mise en situation inspiré de mon quotidien : un gestionnaire cherchant à améliorer le processus de son équipe d’entretien. J’ai été patient et j’ai laissé place à la réflexion, car mon intention était de vérifier qu’ils sont capables de faire les premiers pas dans une transition.
• Un des étudiants nous a partagé l’expérience difficile de sa conjointe qui a vécu la mise en œuvre de Lean dans son entreprise. Nous en avons profité pour chercher les causes des difficultés, et nous avons identifié ce qui avait été négligé dans l’expérience de la conjointe. Cela nous a permis de détecter comment une transition peut mal virer et ce que nous aurions pu proposer pour rétablir la situation.

Finalement, nous n’avons pas vraiment couvert plus de théorie que la première fois. Par contre, les étudiants sont mieux préparés à vivre ou mettre en place un processus Lean. De mon côté, j’ai changé mon approche de chargé de cours : j’ai maintenant une définition de ‘terminé’ qui me permet de valider avec la classe que le cours répond bien à leurs attentes. Je crois bien que les étudiants et moi avons réussi à augmenter la valeur de ce cours.

La saison de hockey vient (finalement) de commencer, et la première chose que les joueurs ont fait, c’est s’entraîner. Ils n’ont pas vraiment joué une partie complète au début. Ils ont fait des allers-retours sur la patinoire. Ils ont pratiqué le maniement de la rondelle. Ils ont fait des tirs au but, et j’en passe… Ils ont fait tout ça dans le but de gagner leur première partie, même s’ils avaient déjà fait tout cela par le passé.

Dans le cadre de notre travail de développeur, on est souvent affectés à des projets utilisant de nouvelles technologies et on a à travailler avec des collègues avec qui on n’a jamais travaillé. On s’attend alors à ce que l’on réussisse nos projets… sans faille. On fait tout ça sans vraiment s’être entraînés auparavant. En fait, dans ces cas-là, on finit par apprendre « sur le tas ». On apprend de nos erreurs aux dépends du projet.

Cet apprentissage en cours de projet pose très souvent des problèmes qui sont décelés très tard dans le cycle de développement. La plupart des gens savent que ça coûte moins cher de trouver les problèmes le plus tôt possible.

 
Source: Applied Software Measurement, Capers Jones, 1996

Qu’en est-il pour nous, développeurs? Notre métier relève davantage de l’art que de la science. Certes, il y a quelques principes bien établis, mais, la plupart du temps, on se retrouve en mode création. Cette créativité a besoin d’être stimulée comme c’est le cas pour les sportifs et les artistes. Le sportif pratique plusieurs techniques liées à son sport pour être prêt lors de la première partie. Le peintre se pratique à peindre différentes parties d’un visage (yeux, bouche, nez et oreilles) avant de faire un portrait complet. Le musicien dans un orchestre va pratiquer sa partition seul afin d’être prêt pour le prochain concert…

Dans la majorité des cas, comme développeur, nous commençons dès le premier jour à produire du code de production avec une technologie qui n’est pas nécessairement maitrisée et avec des outils qui ne sont pas plus maitrisés…

Alors quelle est la solution?

S’entraîner!

A suivre dans le prochain billet.

Lorsque je suis arrivé à Pyxis en 2008, j’ai découvert une équipe fantastique. J’ai laissé derrière moi mon numéro d’employé pour une entreprise qui a des valeurs beaucoup plus proches des miennes : l’importance de l’individu, la collaboration et l’engagement.

Directeur du produit Urban Turtle, je suis fier de faire partie du groupe d’actionnaires de Pyxis pour y apporter mon expérience en développement de produit. Je me joins à cette belle équipe avec mon énergie, mon sens de l’action et mon leadership épidémique!