Atelier lors du démarrage d'un projet Agile

Lors du démarrage d'un projet Agile, il est important d'identifier ce que chaque membre de l'équipe peut apporter au cours du projet. Bien qu'on pourrait facilement écrire un document où l'on rassemble les compétences de chacun, je crois qu'il est bon d'utiliser des techniques pour mettre en valeur la collaboration dès le départ d'un projet Agile. Un atelier collaboratif permet aussi à l'équipe de réalisation de briser la glace avec leur propriétaire de produit et ainsi bâtir une belle relation entre eux pour la durée du projet.

Dans leur livre "Choisir l'Agilité : Du développement à la gouvernance", Mathieu Boisvert et Sylvie Trudel suggèrent un atelier à la page 28 qui permet d'identifier les gens qui seront les "cochons" de l'équipe.

L'atelier consiste à tracer deux demi-cercle l'un en face de l'autre avec le Scrum Master entre les deux demi-cercles. Un demi-cercle va contenir l'équipe de réalisation tandis que l'autre représente les parties prenantes. L'image montre comment le Scrum Master protège son équipe en étant entre les deux demi-cercles. Le facilitateur demande alors aux personnes présentent dans la salle de mettre leur nom dans un seul demi-cercle. Si vous avez des gens dans la salle qui désirent s'impliquer à moitié dans le projet, vous les forcerez ainsi à choisir un camp.  

J'aime bien cet exercice puisqu'il permet d'identifier dès le départ les gens qui seront impliqués dans le projet. Si jamais vous avez quelqu'un qui veut "traîner" dans l'équipe Agile sans s'impliquer, vous le cernez dès le départ.

Matrice des compétences

J'utilise cet atelier lorsque j'ai une nouvelle équipe où je veux que les gens sachent ce qu'ils peuvent offrir au projet. Cette matrice permet d'identifier ce que les membres de l'équipe sont en mesure de faire, peuvent faire et aimeraient faire. Une fois cette matrice créé, je l'utilise lors des planifications d'itération pour aider les gens à travailler en équipe pour réaliser les stories de l'itération.

Dans l'image suivante, on peut voir une matrice des compétences dessinée par les membres de l'équipe. Chaque personne écrit son nom sur une ligne. Elle crée ensuite des colonnes où elle y inscrit les compétences qu'elle peut, veut et aimerait faire dans ce projet. Pour différencier ces trois catégories, on utilise un symbole différent:

• Peut faire: Un X
• Veut faire: Un cercle 
• Amerait faire: Un cercle avec une étoile à l'intérieur

Une fois terminée, je prends une photo de la matrice. Je m'assure qu'elle soit visible dans la salle des rencontres de l'équipe Scrum (mêlées quotidiennes, planification, revue) pour que l'équipe la garde en tête. Des fois, j'ajoute une dernière colonne à cette matrice où l'on y présente une passion que chaque personne a. Cela permet de tracer un lien plus personnel avec les gens et ainsi savoir ce qui les occupent à l'extérieur du travail.  

Conclusion

Comme vous pouve le constater, ces deux ateliers permettent de mieux cerner les gens qui seront impliqués dans le projet Agile. Dans le cadre de la matrice des compétences, on peut aussi voir ce que les membres de l'équipe peuvent, veulent et aimeraient faire. Bien qu'il est possible de simplement rédiger un document qui identifie ces compétences, je crois qu'un atelier collaboratif viendra renforcir le lien de travail entre les membres de l'équipe.

Bon démarrage de projet Agile!

Pourrez-vous soutenir le rythme?

Lors d’un précédent billet intitulé « OÙ EN ÊTES-VOUS DANS VOTRE PROGRESSION AGILE », nous avons énuméré quelques techniques permettant d’évaluer la progression d’une adoption Agile dans une organisation.

Bien que ces mesures permettent l’évaluation de l’état actuel de la situation, bien peu d’entre elles permettent d’estimer si le produit développé permettra à une organisation de soutenir le rythme et contribuer à la prédictibilité espérée en développement itératif.

Soutenir le rythme

Au cours de sa durée de vie, est-ce que votre logiciel pourra évoluer tout en maintenant un niveau de coût linéaire plutôt qu’exponentiel?  La figure suivante illustre la différence entre les coûts de développement au cours du temps d’un produit répondant aux (nombreux) critères de qualité et un autre qui minimise ou voir même néglige l’importance des principes de qualité logicielle.

Figure A - Coûts du développement d’un produit dans le temps

Un logiciel de qualité pourrait avoir un coût initial plus élevé qu’un autre de moindre qualité.  Il est cependant indéniable que les raccourcis pris (consciemment ou non) lors de la conception de ce dernier rattraperont et dépasseront rapidement les coûts de celui développé selon les caractéristiques d’un logiciel de qualité.

Un « nouveau » produit deviendra assez tôt un « ancien » sans ces caractéristiques de qualité.  Il sera bientôt difficile de défendre le produit contre les attaques des coûts de maintenance astronomique et l’incessante croissance de la complexité.  Ironiquement, ce sera probablement l’équipe de développement qui militera face aux gestionnaires afin de remplacer l’ancien produit par un (autre) nouveau.  Et malgré les bonnes intentions, il est fort possible que les caractéristiques de qualité soient encore absentes et que le gaspillage se répète tout en dilapidant les précieux revenus de l’organisation.

Un logiciel de qualité, c’est quoi exactement?

Pour bien répondre, nous devrions faire plusieurs billets sur le sujet, mais de façon (très) concise, voici quelques-unes des caractéristiques d’un logiciel de qualité

• Principes SOLID
• Lisibilité, facilité de compréhension
• Faible Couplage
• Facile à tester (automatisé)
• Architecture émergente extensible
• Principes Clean Code (“cheat sheet”)

Feuilles de thé ou lignes de la main?

Vous pouvez toujours essayer les méthodes « alternatives » afin de faire des prévisions sur la capacité du logiciel à soutenir le rythme, mais ce ne serait pas notre premier conseil.  Quelles mesures pourraient bien nous aider?

La vélocité?  Pas vraiment.  Bien que la vélocité permette d’estimer la capacité de l’équipe, elle dépend de beaucoup de facteurs subjectifs et variables.  Dont celui de notre définition de « Terminé ».  Ce qui signifie que nous pourrions avoir une vélocité moindre en ajoutant des critères de qualité à notre définition de « Terminé ».

Le nombre de défectuosités?  Après tout, avoir la plus petite quantité de défectuosités possible, n’est-ce pas ce qu’on entend par « un logiciel de qualité »?  Non, non et non!  On peut atteindre un nombre limité de défectuosités en investissant une quantité de temps indécente dans le « contrôle de qualité » d’un produit plus que déficient.

Le taux de couverture de nos tests automatisés, ça c’est bon…N’est-ce pas?  Désolé, un logiciel de piètre qualité peut avoir 100% de couverture en tests automatisés tout en demeurant illisible et sans respecter les principes SOLID ou Clean code etc.

La beauté, c’est à l’intérieur

Hé oui, vous devrez « regardez sous le capot » pour savoir si vous avez un logiciel de qualité entre les mains.  Vous me direz peut-être que vous faites de la revue de code régulièrement.  Que signifie régulièrement pour vous?  Plusieurs fois par année, par mois?  Peut-être avez-vous la discipline de le faire plusieurs fois par semaine.  Même cette fréquence ne peut probablement pas permettre d’obtenir une idée objective de la qualité du logiciel au cours des itérations.

Afin de soutenir le rythme d’un développement itératif et de vous assurer que vous n’êtes pas en train d’alimenter le spectre d’une dette technique grandissante, plusieurs outils et techniques sont à votre disposition.  En voici quelques-uns

• Outils automatisés pour les mesures statiques
  • Sonar (Java, C#, C, PHP)
  • TFS avec CodeMetric
  • NDepend (mesures statiques et analyse des dépendances)
  • Revue de code entre les pairs intégré dans votre définition de « Terminé »
  • Programmation en pair

Conclusion

N’oublions jamais le paradigme sous lequel nous devons concevoir les projets sous les principes Agile.  La qualité ne doit plus être une variable, mais bien une constante (Figure B).  La meilleure façon d’obtenir cette régularité est d’inspecter et adapter assidûment ce que l’on crée afin que l’organisation génère un actif plutôt qu’un passif.

C’est ainsi que l’organisation sera en meilleure posture afin de répondre aux besoins de ses clients…aujourd’hui et demain.



Figure B – Paradigme des contraintes de projets Agile

©Cette image est une gracieuseté de M. Patrik Malmquist (http://www.applitude.se)

Atelier pour Scrum Master à Agile Québec

Merci beaucoup à tous ceux et celles qui ont participé à mon atelier Scrum Master du 25 janvier à la Communauté Agile de Québec. J'espère que vous avez l'impression d'avoir profité d'une activité riche en apprentissage et que vous retournerez au travail avec un outil supplémentaire pour vous épauler dans votre rôle de Scrum Master.

Pour ceux qui aimeraient visionner ma présentation, vous pouvez la télécharger sur notre canal Slideshare ou tout simplement la visionner ci-dessous.

Où en êtes-vous dans votre progression agile

Un des grands principes Lean et du manifeste agile stipule qu'une organisation, une équipe doit régulièrement observer ses façons de faire et s'adapter, s'améliorer progressivement selon ce qui est constaté, découvert.

Bien des organisations n'ont pas encore cette discipline, mais pour celles qui s'y mettent, il peut parfois être difficile d'évaluer la progression agile qu'elles font. Bien souvent, les gains faits en début d'adoption d'une mentalité agile font valoir leur présence en criant haut et fort les impacts. Cependant, dès que l'organisation s'est bien adaptée aux changements initiaux, les étapes subséquentes sont beaucoup moins extroverties.

Afin de continuer sa progression et mettre à profit les investissements faits, une organisation aura avantage à établir des objectifs mesurables plutôt qu'utiliser des critères subjectifs quelconques. Il existe de nombreuses mesures permettant d'évaluer la progression d'une organisation. En voici quelques-unes :

• Vélocité
• Satisfaction de la clientèle
• Retour sur l'investissement (ROI)
• Réduction des risques d'affaires (itérations pour découvrir et réduire ces risques)
• Index de bonheur des équipes
• Durée du délai entre la demande initiale du besoin et la réponse finale
• Pourcentage d'utilisation des nouvelles fonctionnalités (répondons-nous bien aux besoins réels de nos clients?)
• Nombre de défectuosités
• Taux de couverture des tests automatisés
• Qualité du design, du code

Ces mesures ne sont pas nécessairement valables dans tous les contextes et ont certainement chacune leurs forces et faiblesses. Une conjugaison de plusieurs d'entre elles permet à une organisation d'obtenir une estimation fiable de leur progression vers la haute performance et le succès durable attendu lors d'une adoption agile.

En terminant, n'attendez pas d'avoir concocté une recette idéale avant de mettre en place vos mesures. Profitez de vos gains dès maintenant et n'oubliez pas que l'évaluation de votre progression agile est elle-même soumise aux principes de l'agilité et qu'elle doit être constamment améliorée.

Capsule Clean Code avec Bob Martin

Après plusieurs semaines d'attente nous sommes maintenant en mesure de vous proposer la première capsule d'une série d'entrevues que nous avons réalisées avec Robert C. Martin
lors de son passage à Québec l'automne dernier.

Dans cette première capsule Robert C. Martin nous parle de son célèbre ouvrage, Clean Code. Ce livre est devenu un classique parmi les développeurs qui y ont trouvé une référence unique en matière de règles de développement. Il nous explique dans quel état d'esprit le livre a été écrit et comment des détails qui pourraient paraîtres insignifiants sont pourtant essentiels pour produire du code de grande qualité.

Il nous fait aussi part de son enthousiasme renouvelé à offrir sa formation Clean Code à des groupes de développeurs qui ont à cœur d'exceller dans leur métier.

D'autres capsules avec Bob Martin seront mises en ligne dans les prochaines semaines. Nous vous invitons à suivre notre blogue!