mathieu boisvert

Mathieu est un conseiller en adoption des méthodes Agiles depuis plus de 5 ans à Montréal, à Québec et à Paris. Il anime le démarrage de nouveaux projets de développement logiciel à titre de conseiller et facilite la réussite d'équipes de développement à titre de ScrumMaster.
voir mon profil complet »

Articles de mathieu :


    dans Agile, Agile Manager, Education, Témoignages

    Méthodologies Agiles à la chaire de gestion de projet de l’UQAM

    Quelques contacts ont remarqué que mon profil LinkedIn indique que je suis chargé de cours. Effectivement, je suis chargé de cours à la Chaire de gestion de projet de l’UQAM. Je donne avec Shayne Mitchell, sur invitation de Claude Besner, le cours « Méthodologie Agile en gestion de projet ». Nous avons donné 8 cours sur 15 à ce jour.

    Lire la suite »

    dans Agile, Innovation, Scrum

    La mesure du succès — Comment vérifiez-vous le succès de vos projets?

    Moi qui suis toujours à la recherche de nouveaux moyens pour atteindre les objectifs fixés par les projets, j’ai été interpellé par cet article: Après avoir dépensé 75 millions de dollars, le gouvernement du Québec suspend le projet d’informatisation du système judiciaire, voué à l’échec. Pas tellement parce que c’est un projet public, mais plutôt parce que je crois que le marché du développement logiciel manque toujours d’expertise pour assurer le succès de ses projets. La citation de Michelle Courchesne résume très bien le symptôme: « … On ne peut pas attendre d’avoir dépensé les 105 millions de dollars autorisés et se dire que ça ne marche pas. Sinon, après, il faudra donner encore plus d’argent. C’est fini ça, on ne peut plus faire ça. »
    Lire la suite »

    Tags:
    dans Agile, Architecture

    Garder les options ouvertes

    Face à un choix, on peut prendre une décision éclairée ou courir le risque de prendre une mauvaise décision. On peut également retarder la décision afin de réunir l’information permettant d’augmenter les chances de prendre la meilleure décision possible.

    La prise de décision au dernier moment responsable est un concept fort des méthodes Agiles, en particulier de l’approche Lean. La lecture du document Agile Extension to the BABOK Guide m’a fait redécouvrir l’analyse par les options réelles (en anglais : ROA–Real Options Analysis), qui est une application du concept du dernier moment responsable.

    Lire la suite »

    Tags:
    dans Agile, Transition Agile

    Adaptation du rôle d’analyste d’affaires dans une équipe Agile

    Le Agile Extention to the BABOK® Guide apporte une piste de réflexion intéressante à propos des analystes d’affaires en dressant une liste des rôles naturellement tenus par un analyste au sein des équipes Agiles. Le document se concentre sur les analystes d’affaires, mais selon moi cela s’applique également aux analystes fonctionnels et, en partie, aux analystes organiques.

    Voici ce que la liste indique :

    Lire la suite »

    dans Agile, Scrum

    Kanban vs Scrum de Henrik Kniberg

    Je suis en mandat avec une équipe de développement qui ne peut d’emblée adopter toutes les pratiques de Scrum. Le domaine d’affaire de l’application est si complexe qu’il est difficile pour le PO de présenter à l’équipe l’équivalent de quelques semaines de travail. Pour le moment, nous avons décidé de contourner le problème sans se priver des valeurs d’amélioration et de collaboration de l’Agilité en adoptant la méthode Kanban. Isabelle Therrien m’a référé un très bon article de Henrik Kniberg à propos du Kanban versus Scrum. C’est la meilleure vulgarisation de la méthode que j’ai lu à ce jour. Contrairement à d’autres articles, il explique bien le Kanban comme une méthode Agile à part entière, et pas seulement une adaptation de Scrum.

    L’article explique notamment que: – Scrum est dirigé par l’engagement et les boîtes de temps alors que le Kanban est dirigé par un flux tendu et le périmètre. – Kanban permet la ré-introduction de spécialités impossibles à diffuser au sein d’une équipe pluri-disciplinaire – Kanban permet au PO de planifier les items à développer à l’unité alors que Scrum permet la planification d’items en lot

    Attention! Kanban est moins restrictif que le Scrum. Il faut prendre garde de respecter l’esprit Agile.

    Avez-vous des mises en garde ou des opinions à propos de Kanban?

    dans Développement logiciel

    Les compétences techniques qu’un développeur devrait améliorer selon Justin James

    J’aime bien cet article qui liste les compétences passe-partout que les développeurs devraient chercher à améliorer. Voici la liste des thèmes, lire l’article pour le détail.

    1. : Connaître un langage majeur (ex: .NET, Java, PHP)
    2. : Connaître une technologie de client riche (RIAs)
    3. : Connaître le développement web
    4. : Connaître les services web
    5. : Avoir des compétences humaines (Soft skills)
    6. : Connaître les langages dynamiques
    7. : Connaître les méthodes Agile
    8. : Avoir de l’intérêt pour les domaines d’affaire
    9. : Avoir une bonne hygiène de développement
    10. : Connaître le développement embarqué (Mobile)

    Les temps changent; il me semble qu’à mes débuts, la liste aurait aussi inclus des connaissances du SQL avec un SGBD, et au moins un langage script (utile entre autres pour faire des scripts de build et des batchs).

    Dans tout les cas, je vois d’un bon œil d’avoir une liste d’axes de compétences avec laquelle je peux me mesurer dans mon processus d’amélioration continue.

    dans Scrum

    Quand la mêlée quotidienne sonne faux.

    - Hier j’ai travaillé sur l’import/export et je vais continuer aujourd’hui. Je n’ai pas de difficultés…”

    Entendez-vous les violons stridents qui annoncent un meurtre? Ils annoncent la mort de la mêlée quotidienne. Même si on a déjà posté sur ce sujet sur le blog de Pyxis, j’en rajoute une couche.

    Le problème avec l’intervention citée plus haut, c’est qu’elle n’a aucune valeur ajoutée; j’aurais pu obtenir la même information en regardant le tableau des tâches. Si vous tenez votre mêlée en face de votre tableau des tâches et de votre graphique d’avancement, et que les participants continuent de tenir de mêlées aussi insipides, vous gaspillez tous les jours 15 minutes de temps de travail. Au moins, vous aurez réduit à 15 minutes le massacre quotidien.

    Quel est le contexte d’une mêlée? Ça ressemble un peu à un article de journal; je veux savoir ce qui a progressé depuis hier à propos des élections américaines. Si rien n’a changé, je ne tiens pas à le savoir. Dans le cadre d’une itération, en tant que membre impliqué, je veux savoir où nous en sommes et je veux partager avec mes coéquipiers mes contributions, mes observations et les risques que j’ai identifiés. Ce n’est pas moi le sujet de cette rencontre, mais notre engagement. En quoi ma journée a contribué au projet? En quoi j’ai affecté NOTRE itération? En quoi j’ai amélioré la qualité de NOTRE produit? Qu’est-ce qu’ON peut faire pour adresser un obstacle?

    - Mais Mathieu, je n’ai rien fais sinon de modifier les scripts d’import pour tenir en compte les accents qui n’étaient pas supportés. C’est un travail qui n’était pas prévu et a été vite réglé. Maintenant je dois finir l’import.

    Voilà!

    Si vous avez de la difficulté à secouer vos troupes, changez la formulation de vos questions ou jetez-les par la fenêtre! Préférez une question qui s’adresse à tous le groupe sur la progression de votre itération.
    dans Développement logiciel

    Les Dojos de Développement (Coding Dojo)

    L’amélioration continue est un concept clé des pratiques agiles. Les livres, les blogues et les formations sont de bonnes façons de se perfectionner. La tenue de dojos est une autre façon ludique et motivante de partager et se perfectionner sur le développement logiciel.

    Les Dojos

    Si je veux apprendre le Judo, je vais m’inscrire au dojo du coin et y passer une heure par semaine pendant deux ans, au bout de quoi j’aurai peut-être envie de pratiquer plus assidûment.

    Si je veux apprendre la programmation objet, mon employeur va me trouver une formation de trois jours à Java dans le catalogue 2004.

    Cherchez l’erreur.

    Laurent Bossavit

    Se donner des périodes pour pratiquer la programmation nous éveille à de nouvelles techniques et nous fait découvrir de nouveaux langages sans amputer sur nos mandats professionnelles. De le faire en groupe nous encourage et nous aide à nous défaire de nos pratiques routinières.

    Références

    Statégies

    • Recommencer à zéro: on ne cherche pas vraiment à résoudre un problème, mais plutôt à pratiquer. Les problèmes rencontrés dans un cas simple réalisable en une heure seront similaires à ceux que l’on rencontre dans la réalisation de plus gros projets.
    • Prévoir une courte pause au milieu de l’atelier pour inspecter et ajuster l’exercice en cas de besoin. On pourra y définir de nouvelles règles ou s’entendre sur la ligne directrice de conception.

    Foire aux questions

    • Où peut-on trouver des exemples de défis?

    Un défi populaire dans la communauté, c’est le fameux pointage du jeu de quilles . Le catalogue du site Coding Dojo  est une bonne source d’inspiration. Pragmatic Dave propose également d’autres katas .

    Le défi se doit de rester simple et réalisable dans un court laps de temps. Écrire un convertisseur de chiffres romains est un bon exemple de défi raisonnable.

    • Quel est le but du dojo si ce n’est pas la résolution du défi?

    Le but est de se perfectionner dans une discipline du développement logiciel. On peut perfectionner une pratique comme le TDD ou l’orienté-objet, un langage comme Ruby, ou encore l’utilisation d’un framework comme Rails.

    • A quel moment on doit changer le binôme au commandes d’un randori?

    Une boîte de temps est sûrement la technique la plus simple (ex. entre 5 et 7 minutes). On aussi peut utiliser le cycle normal du TDD; chaque binôme est responsable de faire passer un nouveau test.

    Le Coding Dojo de Pittsburg a une autre approche; tous les participants binôment simultanément sur le défi et l’atelier se termine par une rétrospective de groupe.