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.

Les résumés d'Agile 2015

Publié le dimanche 23 août 2015 à 00:00

Agile2015

Du 3 au 7 août se déroulait à Washington D.C. la conférence annuelle Agile 2015. Nos collègues Félix-Antoine et Pascal y étaient. À chaud, pendant l'événement, ils ont résumé plusieurs des conférences auxquelles ils ont assisté.

Si vous étiez en vacances et que vous avez raté cela, voici une liste de tous leurs résumés. C'est notre façon de partager avec vous notre passion pour le génie logiciel et l'Agilité.

Notez que nos deux ambassadeurs vont publier dans les prochaines semaines leurs impressions personnelles et ce qu'ils retiennent comme tendance après leur passage au coeur de la communauté. Restez à l'écoute!

Bonne lecture!

 

Professionnalisme et gestion de la dette technique

 

 

Besoin d'affaires, fonctionnalités et User Stories 

 

 

Entreprise et équipes

  

  

Coaching et transition

 

 

Technique 

 

 

Feuilles de temps: Bon ou mauvais en Agilité?

Publié par Louis-Philippe Carignan le mardi 28 mai 2013 à 17:00

Cette question m’est souvent posée depuis que j’œuvre dans le domaine des technologies de l’information. Depuis que j’agis en tant que coach Agile, j’ai un certain devoir d’éduquer mes clients à propos de la nécessité de poursuivre avec le suivi des feuilles de temps lorsque je mentionne que c’est le travail qui reste à faire qui est important et non le travail effectué jusqu’à maintenant.

Ayant moi-même été sur des projets où remplir ma feuille de temps était une perte de temps (sans jeu de mots), je peux comprendre les frustrations de certains développeurs qui désirent garder le focus sur le travail pour satisfaire le client. D’un autre côté, je comprends aussi le fournisseur de services qui doit facturer son client pour les heures passées sur son projet. Et pour pouvoir facturer correctement, le département de la facturation doit demander aux développeurs le temps passé sur le projet du dit client.

J’ai donc creusé le sujet pour connaître les opinions de certains experts reconnus dans le domaine des technologies de l’information. Voyons voir ce que ces experts ont à dire à ce sujet.

La version de Scrum Inc

D’un côté du terrain, nous avons Scrum Inc, piloté par Jeff Sutherland, qui semble contre l’idée de comptabiliser les heures dans une feuille de temps lorsqu’on fait partie d’une équipe Scrum.

Sur leur bogue, les gens de Scrum Inc. ont trois billets où un préjugé très défavorable envers les feuilles de temps est exprimé.

Ces billets, étant publié sur plusieurs années, nous permettent de conclure que c’est une opinion que Sutherland et son équipe tiennent depuis longtemps. À la lecture de ces billets, voyons voir comment Scrum Inc. apporte plusieurs de l'eau au moulin en défaveur pour la tenue des feuilles de temps en mode Agile.

Le gros bon sens selon Scrum Inc.

Tout d’abord, les arguments « gros bon sens » de Scrum Inc. contre les feuilles de temps sont tous à fait réalistes bien qu’aucune donnée vient supporter ces énoncés :

  • they demotivate developers
  • 10-15% loss of productivity is the minimum
  • developers have to fake the time to fill them out properly
  • erroneous data is used for reporting and management makes bad decisions
  • customers are deceived
  • they have nothing to do with quality code production
  • they focus the whole organization on phony data instead of production

Si vous avez déjà été membre d'une équipe Agile où il était requis de remplir votre feuille de temps, vous partagez probablement l’un (ou plusieurs) de ces énoncés. Et pourtant, comme le dit si bien Scrum Inc. certaines entreprises semblent être déterminer à remplir les feuilles de temps même si cela n’apporte aucune valeur à l’organisation.

there is a psychological dependency so strong, it is as if they are on drugs.

Une façon « Lean » de rapporter le temps restant

Lors de son passage chez PatientKeeper en tant que CIO, Jeff Sutherland a mené un sondage auprès de ses équipes Scrum pour identifier la meilleure façon de remplir les feuilles de temps. Les réponses ont été contre-intuitive où l’équipe ne voulait même pas afficher explicitement le temps restant sur chaque tâche, ce qui est habituellement encouragé en Scrum. Cela les dérangeait de leur véritable travail à faire et leur estimé restait assez variable à cause du problème à résoudre. Ils sont donc arrivés à cette façon de faire très « Lean ». 

Time remaining to Sprint completion is all that is reported publicly and the team remains focused on what it takes to get "Done" at the end of the Sprint and does not even feel the questions asked relate to time reporting in any way.

L’équipe voulait donc la confiance des gestionnaires en échange de cette façon simpliste de rapporter les heures restantes. On utilisait le temps restant de l’itération pour informer les parties prenantes et l’équipe n’était pas perturbée par aucune donnée liée à propos du temps. Elle pouvait donc se concentrer à livrer de la valeur.

Livrer de la valeur

L’un des points majeurs de l’Agilité est de livrer de la valeur à son client. Contrairement à un gestion de projet traditionnelle où l’on essaie de respecter les trois pointes du triangle de fer (temps, budget, fonctionnalités), on cherche à maximiser la valeur d’affaires livrée au client lorsqu’on fonctionne en mode Agile. On encourage les équipes Agile à penser en terme de valeur d’affaires ainsi que le retour sur l’investissement que bénéficiera la clientèle en utilisant le logiciel. Regardons de plus prêt comment ce principe est employé dans les billets de Scrum Inc. lors de leur réflexion à propos de l’utilité des feuilles de temps:

One difficulty when estimating in hours is that time measures input, and Scrum is concerned about output.

Un peu plus loin dans ce même billet, on mentionne un exemple où une firme d’avocats a surfacturé un client pour une simple question de rentabilité.

If the lawyers had instead focused on the quality of their work (the output in this case) and not billable hours, the client, rather than suing them, would have gladly paid the bill.

On sent vraiment l’influence de livrer de la valeur lorsque l’auteur affirme à la fin de ce billet que : 

Business probably won’t improve until they start to focus on quality of outcome rather than quantity of input.

Pour Scrum Inc., j’en conclu que la nécessité de comptabiliser les heures travaillées est un dérangement dans la livraison de valeur pour le client. J'en déduis qu'il faut garder les équipes concentrées sur l’objectif d’affaires et les feuilles de temps n’ont pas leur place dans cet objectif.

La version de Joel Spolsky

De l’autre côté du terrain, Joel Spolsky a une toute autre vision face à la feuille de temps. Dans son billet Evidence Based Scheduling, Spolsky présente une technique mathématique pour prédire une date de livraison en se basant sur l’historique des tâches faites par l’équipe lors d’autres projets.

Spolsky propose de garder un historique des temps estimés et actuels passé sur chaque tâche. Avec le temps, le développeur pourra s’améliorer en regardant où sont les plus grands écarts entre ces deux valeurs. Il suggère l’emploi d’une machine de Monte Carlo pour générer des probabilités quant à la livraison d’une version. Il suggère aussi l’utilisation d'un logiciel que sa compagnie vend.

Sans aller dans les détails de la technique qui est quand même compliquée, on peut voir à la lecture de ce billet que Spolsky favorise les feuilles de temps pour permettre aux développeurs de s'améliorer.

Dans ce billet, je suis d’ailleurs surpris par le concept de vélocité proposé par l'auteur. Pour Spolsky, la vélocité est la division du temps estimé sur le temps actuellement passé sur cette tâche. Premièrement, une vélocité est basée sur une unité de temps (m/s, km/h, points/itération). En divisant du temps (estimé) par du temps (actuel), on se retrouve avec un ratio sans aucune unité. Je doute fortement de l’effort de réflexion que Spolsky a effectué pour arriver à ce concept.

Et bizarrement, Joel Spolsky partage la même prémisse que Scrum Inc. quant à livrer de la valeur.

You want to be spending your time on things that get the most bang for the buck.

Cependant, son approche est différente puisque pour lui, 

Realistic schedules are the key to creating good software.

On peut donc voir une approche ortogonale à celle de Scrum Inc. et pourtant, elle semble répondre au besoin de livrer de la valeur d'affaires au client.

La version de Jurgen Appelo

L’auteur du livre Management 3.0 et auteur du blogue noop.nl a déjà écrit un billet où il se prononce sur le sujet. En quelques lignes, Appelo se situe entre Scrum Inc. et Spolsky.

Il mitige la position de Scrum Inc. puisque selon lui, il est important de mesurer la profitabilité d’un projet et les feuilles de temps permettent de déterminer cette mesure. De l’autre côté, il est contre l’idée de Spolsky de suivre chaque tâche dans un projet puisque le client n’y gagne aucune valeur et qu’habituellement, ces projets sont à coût fixe.

Il en arrive donc à la conclusion qu’il se situe entre Scrum Inc. et Spolsky : 

  • So yes, you must track time in order to track project profitability.
  • And no, you should not track time in order to improve task estimability.

La version Louis-Philippe

Mon opinion est relativement semblable à celle de Jurgen Appelo. Dans mon jeune temps, je penchais du côté de Scrum Inc. mais avec l’expérience où certaines particularités m’ont fait grandir, j’emprunte certains arguments de Jurgen (mais aucun de Spolsky).

Pour ma part, je commencerais par identifier les personnes qui vont consommer les feuilles de temps.  Par exemple, si le responsable de la paie est la seule personne qui consomme les feuilles de temps produites par les équipes Scrum, je demanderais aux équipes de rentrer deux lignes dans leur feuille de temps : 

  • Heures passés au bureau
  • Heures où vous étiez absent du bureau

Par exemple, pour que la comptabilité effectue les bonnes paies à la fin du mois, je demanderais aux équipes de rentrer leurs absences dans la feuille de temps. Cela aiderait la comptabilité à générer les paies exactes et éviter des corrections à chaque mois. Si le reste du temps est passé sur un projet de recherche et développement, je simplifierais à sa plus simple expression les heures passés au bureau pour ne pas déranger l’équipe.

Je rejoins aussi Jurgen Appelo à propos de comptabiliser les heures pour la facturation. Je comprends le point de vue de Scrum Inc. à propos de livrer de la valeur affaires pour son client et « l’interférence » causée par l’inscription des heures sur la feuille de temps. En tant que développeur dans une équipe, j’ai un « autre » client, c’est-à-dire l’organisation qui paie mon salaire pour exécuter les services à mon vrai client. Pour me payer, l’organisation pour laquelle je travaille doit facturer un client avec qui elle est liée contractuellement. Je comprends qu’il peut y avoir de l’abus dans certains cas comme le remarque Scrum Inc. où l’important devient simplement de facturer des heures imaginaires. Je préfère donc faire abstraction de cette idée peu probable et emprunter l’argument de Jurgen.

Cependant, et bien que Joel Spolsky a eu du succès avec sa technique ainsi que les projets qu’il a lancé (StackExchange, Trello), je ne vois pas l’intérêt de compiler l’historique des tâches pour chaque développeur dans l’objectif d’apporter une meilleure prévisibilité. Étant un adepte des systèmes complexes adaptatifs où un projet logiciel est complexe et impossible à prévoir d’un bout à l’autre, je préconiserais une approche où l’on fait des temps d’arrêts fréquents pour regarder où nous sommes rendus et ajuster le tir. L’approche de Spolsky semble viser un certain déterminisme que je réfute lorsqu’on parle de développement logiciel.

Cartes de planning poker Elapse

Publié par Louis-Philippe Carignan le lundi 17 septembre 2012 à 20:00

Elles sont arrivées

Tons Of Planning Pokers Cards

Un dérivé du "wall session"

Publié par Louis-Philippe Carignan le mardi 21 février 2012 à 23:00

Traditionnellement, les équipes Agile estiment leurs stories à l'aide du planning poker. Puisqu'il y a beaucoup de stories à estimer en démarrage de projet Agile, j'utilise plutôt un "wall session" pour accélérer l'estimation des stories.

Dans la vidéo suivante, Boris Gloger nous présente le "magic estimation" qui est, à mon avis, un dérivé du wall session. Au lieu de placer les stories une à une sur le mur, on remet quelques stories à chaque membre de l'équipe. Chaque personne place alors ses stories au bon endroit sur le mur. On demande alors à tout le monde de réviser chaque story pour s'assurer qu'elle est au bon endroit.

Bon visonnement!

Établir sa vélocité initiale

Publié par Louis-Philippe Carignan le samedi 11 février 2012 à 21:05

Suite à une discussion où mon collègue Mathieu Boisvert chez notre client m'a fait réfléchir, j’ai voulu écrire un billet sur la façon de dresser la vélocité initiale d'une équipe pour ainsi prédire le plan de livraison de cette dernière.

Mise en situation

Imaginons une équipe qui a évalué qu’elle devra livrer un projet de 200 points répartis de la façon suivante :

  • Obligatoire: 100 points
  • Important: 60 points
  • Facultatif: 40 points

Nous avons 43 itérations d’une semaine pour livrer ces points, donc environ 1 an pour livrer ce projet si on enlève les vacances de l'équipe. Le SunSet graph suivant nous permet d'illustrer ces points sur une ligne du temps.

Sun Set De Depart

La prochaine étape consiste donc à établir la vitesse à laquelle seront livrés les points du projet. J'avais surtout l'approche client mais en parlant avec Mathieu, il m'a fait comprendre que l'approche de l'équipe était très important, surtout parce qu'elle m'expose un risque dès le départ.

Comparons donc les deux approches pour voir ce qu'elle nous apporte comme information

L'approche client

Si on se place dans les souliers du client, il veut son projet complété dans 1 an. Si on enlève les vacances de son équipe, on peut dire qu'il faut 43 itérations pour livrer. S’il a 200 points à livrer, il peut se donner trois scénarios possibles :

  • Meilleur scénario : 200 points / 36 itérations = 5,55 points par itération
  • Scénario normal : 200 points / 43 itérations = 4,65 points par itération
  • Pire scénario : 200 points / 50 itérations = 4 points par itération

Cependant, cette approche a un problème. Le client dresse ses attentes dès le départ. Si on présente ces chiffres à l’équipe, elle aura naturellement tendance (à mon avis) à atteindre ces chiffres, même si elle se met à couper dans la qualité des fonctionnalités.

Voyons voir si l'approche de l'équipe peut nous apporter une perspective différente.

L'approche équipe

Si on se place dans les souliers de l’équipe, on constate qu’il faut 200 points à livrer dans 43 itérations. Cependant, on ne leur demandera pas de dresser les trois scénarios comme avec le client.

Lors de la planification de l’itération initiale, on demande à l’équipe de découper les stories retenues pour l'itération en tâches. Selon le nombre d’heures qu’elle peut donner, on voit le nombre de points qu’ils peuvent faire en une itération dès la fin de la planification de l'itération. On va donc chercher la vélocité initiale que l’équipe peut donner dès le départ du projet.

À ce moment, on peut tout de suite constater si l’équipe pense être en mesure d’atteindre les 200 points pour la fin de l’année. Si l’équipe ne peut prendre que 2 points pour la première itération, on voit donc déjà un risque apparaître. Si l’équipe se rend compte qu’elle peut faire 15 points dès la première itération suite au découpage, peut-être que la durée du projet sera plus courte.

Conclusion

Si on utilise l'approche du client, il faut attendre la fin de la première itération pour faire le constat si l’équipe peut (ou non) livrer les points dans l’année. Cependant, avec l'approche de l'équipe, on peut faire ce constat dès le départ, avant même l’itération 1, qu’il y a un risque que l’équipe n’atteigne pas ses 200 points à la fin de l’année du projet.

Ma conclusion est qu’il faut faire les deux approches. Je ferais l'approche client avec le client, seul, pour qu’il constate ce qu’il attend de son équipe dans la prochaine année. Par la suite, à la fin de la planification de l’itération 1, je ferais l'approche de l'équipe. Une fois les deux approches élaborées, je les comparerais et les mettrais en évidence au client pour qu’il puisse comparer de par lui-même que ce qu’il espère (l'approche client) puisse ou non se réaliser par l’équipe.

Archive