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.

Atelier lors du démarrage d'un projet Agile

Publié par Louis-Philippe Carignan le samedi 28 janvier 2012 à 20:00

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

Matrice Des Compe ́tences

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?

Publié par Philippe Tremblay le vendredi 27 janvier 2012 à 13:00

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.

Cout Logiciel Duree Vie

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é

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.

Agile Triangle

Figure B – Paradigme des contraintes de projets Agile

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

Itération : Courte ou longue?

Publié par Louis-Philippe Carignan le jeudi 22 décembre 2011 à 06:08

De par mon expérience, les itérations en mode Agile sont habituellement de deux semaines. Bien que ce soit la norme dans l'industrie, est-ce le bon choix pour votre équipe?

Qu'est-ce qui vous ferait choisir une plus longue itération ou, dans le cas contraire, une itération plus courte? À mon avis, le choix de la durée d'une itération en début de projet est influencé par le risque à exposer par votre équipe.

Par exemple, si l'équipe de réalisation est en démarrage et que vous sentez qu'il faudra une bonne période d'adaptation entre les membres de l'équipe ainsi qu'avec le propriétaire de produit, je réduirais la durée de l'itération pour faire ressortir les problèmes rapidement lors de la rétrospective. Par exemple, je pourrais tenir des itérations d'une semaine au tout début pour exposer les problèmes initiaux (mauvaise communication, incompréhension de l'Agilité, flou fonctionnel, peurs, craintes, résistance aux changements, etc). Si les problèmes initiaux sont atténués après une ou deux itérations, j'allongerais alors l'itération à deux semaines.

Je suis très rarement en faveur d'itérations d'un mois au début d'un projet avec une équipe qui débute avec Scrum. Si elle n'a pas reçu de formation adéquate, je préfère qu'elle vive une courte itération d'une semaine pour comprendre le fonctionnement de Scrum. Il se peut aussi que l'équipe ait à travailler sur des stories risquées dès le premier sprint où celles-ci auront un impact sur le reste du projet. Au lieu d'attendre 1 mois pour vérifier et présenter les résultats de cette story risquée, je vais préférer diminuer la durée de l'itération pour exposer les résultats de cette story le plus rapidement possible aux parties prenantes.

Dan Rawsthorne, dans son livre Exploring Scrum : The Fundamentals, suggère un autre facteur pour déterminer la durée d'une itération. Selon Rawsthorne, l'itération doit être assez longue pour compléter au moins une story. Il suggère de choisir une story de poids moyen et d'estimer le temps qu'une équipe doit prendre pour la réaliser. Il multiple ensuite par 3 cette estimation et cela lui donne une bonne estimation de la durée d'une itération. Par exemple, si une story de poids moyen est de 3 jours, une itération durera (3x3) 9 jours.

Pour conclure, je suggère de démarrer avec des itérations courtes si vous avez des risques à exposer rapidement. Le guide Scrum suggère une itération d'un mois ou moins. L'industrie semble présentement travailler avec des itérations de deux semaines. Si vous êtes toujours indécis quant à la durée de vos itérations, vous pouvez toujours utiliser le truc de Dan Rawsthorne.

Mots-Clés :
  • Plus récents
  • 1
  • Plus anciens

Archive