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.

La complexité involontaire

Publié par David Beaumier le vendredi 26 juillet 2013 à 17:07

Comme développeur nous avons tous à lire et surtout, à comprendre le code écrit par d'autres personnes. Que ce soit pour modifier une fonctionnalité existante ou pour effectuer une forme de rétro-ingénierie, il est primordial de ne pas avoir à s'arracher les cheveux de la tête pour comprendre l'intention du code. Or, hélas, trop souvent ce n'est pas le cas.

Il peut y avoir plusieurs causes à cette situation : méthode trop longue, mauvais nommage, non-respect des règles de nomenclature, etc. Ceci dit, je crois que bien souvent le code ne s’est pas retrouvé dans cet état dès le départ. J’aurais plutôt tendance à blâmer la vilaine complexité involontaire. Non, il ne s’agit pas d’une maladie contagieuse ou d’un mal contre lequel votre anti-virus pourra vous protéger. C’est plutôt comme la moisissure sur le fromage : ça apparaît après un certain temps et plus rapidement si on le manipule fréquemment sans prendre les précautions nécessaires!

Prenons un exemple dans le domaine d’affaires de l’assurance pour illustrer le processus. Une personne a créé au départ une structure de contrôle pour ne traiter que les polices à renouveler au cours des 30 jours à venir. Assez simple, n’est-ce pas?

if (p.DateRenouvellement < Now.AddDays(30)) {
  TraiterRenouvellement(p);
}

Quelques temps plus tard, un collègue a implémenté une nouvelle règle d’affaires dans le traitement pour répondre à un besoin de l’entreprise.

if (p.DateRenouvellement < Now.AddDays(30)) {
  if (Date.Now.Year - p.Client.EstClientDepuis.Year > 10) {
    var rabais = 0.1;
    TraiterRenouvellement(p, rabais);
  }
Else {
  TraiterRenouvellement(p, 0);
}

Par la suite, une autre demande est venue s’ajouter et une autre personne est venue modifier la fonction.

if (p.DateRenouvellement < Now.AddDays(30)) {
  if (Date.Now.Year - p.Client.EstClientDepuis.Year > 10) {
    var rabais = (Date.Now.Year - p.Client.EstClientDepuis.Year)/100;
    TraiterRenouvellement(p, rabais);
} }

Et ainsi de suite, jusqu’à ce qu’on ait une méthode de 125 lignes, ou même plus! Bien qu’avec le recul on puisse identifier différents éléments qui auraient pu être faits pour réduire la complexité, le plus souvent on ne peut accuser les gens de mauvaise foi. C’est plutôt une spirale sournoise dans laquelle l’équipe s’est engagée s’en trop s’en rendre compte… Jusqu’au jour où on ne s’y retrouve plus!

Favoriser la lisibilité du code source

Barbara Liskov (bien connue pour avoir donné son nom au Liskov Substitution Principle) mentionnait dans une récente entrevue que l’on devrait accorder plus d'importance à la lisibilité du code qu'à son écriture (read-ability VS write-ability). Les compilateurs, éditeurs de code et autres outils de développement offrent une panoplie de fonctions qui tendent à réduire le nombre de lignes de code source. Cependant, est-ce qu'on y gagne réellement au change?

Je pense, par exemple, à la fonctionnalité de Resharper qui permet de convertir une boucle en une expression LINQ. Oui, il y a des cas où cela peut-être bénéfique, mais il y a aussi bien des cas où, en fin de compte, on aura perdu une part de lisibilité du code dans l'opération.

Quelques façons d’éviter la complexité involontaire

Il existe différentes façons de s’entraîner à développer sa capacité à détecter les pièges de la complexité involontaire. De façon générale il faut débuter par accepter de sortir de sa zone de confort et graduellement apprendre à prendre un peu de recul et évaluer le code que l’on produit ou modifie.

Plusieurs excellents ouvrages de référence ont été publiés sur le sujet. C’est un bon point de départ pour quiconque veut approfondir ces techniques. Voici quelques suggestions :

Revues de conception

Pourquoi ne pas ajouter la notion de revue de conception ou de test par un pair à la définition d’avoir terminé de votre équipe? Chacun s’assure qu’au moins une autre paire d’yeux a jugé son travail et en a validé la conformité aux standards de l’équipe. C’est une étape qui permet de détecter rapidement des éléments qui manquent de clarté et qui apparaissent ambigus pour une autre personne. Ça ne veut pas dire que vos collègues ont forcément raison et vous tort, mais ça vaut probablement la peine de tenir une brève discussion sur les aspects qui ont été soulevés durant la revue.

Bien que je trouve que la revue par un pair apporte la meilleure valeur pour l’équipe, je crois que l’on peut aussi faire preuve d’autocritique. Par exemple, pourquoi ne pas prendre un peu de temps chaque matin pour repasser le code qu’on a écrit la veille? Par comparaison, un ébéniste prend habituellement le temps de faire un montage à sec avant de coller les assemblages d’un meuble. Cela lui permet de vérifier toute anomalie et la corriger avant de faire le collage final. Oui, ça prend un peu de temps, mais c’est une étape qui lui permet de s’éviter d’éventuels ennuis.

Métriques du code

En plus des évaluations qualitatives dont on vient de discuter, la complexité du code peut se mesurer de façon quantitative. Il existe plusieurs mesures, telles que la complexité cyclomatique, l’index de maintenabilité, le niveau de profondeur des structures de contrôle et la cohésion.

Il existe aussi des outils d’analyse statique du code qui permettent d’assurer le respect des règles de développement de l’équipe (nomenclature, etc.). Plusieurs de ces outils sont gratuits (tel que Source Monitor) ou même intégrés directement aux IDEs (comme le propose Visual Studio).

Conclusion

Développer et maintenir un système c’est comme une partie d’échecs. On doit penser quelques coups d’avance, tout en étant capable de réagir aux mouvements de l’adversaire. Il revient à chacun de trouver le juste équilibre entre perfection et livraison, mais il convient, à mon avis, d’identifier le seuil minimal que vous vous engagez à respecter. Lorsque le contexte ne vous permet pas de rencontrer ce seuil, n’hésitez pas à rendre cette situation visible à l’équipe et à discuter de la possibilité d’ajouter un élément au carnet de produit pour revoir cette partie du code source à un moment qui sera plus opportun (tel qu’au début du prochain cycle de livraison).

J’ai un jour entendu une personne dire ceci : "Écrivez votre code comme si celui ou celle qui en fera la maintenance était un psychopathe dangereux qui connaît votre adresse". C'est peut-être un peu extrême, mais ça m'a toujours forcé à me mettre dans la peau de la personne qui allait devoir comprendre mon code en m'efforçant de réduire le plus possible la complexité de celui-ci. Bon développement!

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.

Simple, compliqué, complexe ou chaotique

Publié par Louis-Philippe Carignan le mardi 26 février 2013 à 15:03

L’Agilité est de plus en plus présente en entreprise. Selon une étude de Forrester publiée en 2010, les méthodes Agile sont maintenant plus utilisées que l’approche traditionnelle en développement logiciel. D’ailleurs, le CHAOS Reort, publié en 2011, montre que plus de projets Agile sont réalisés avec succès que l’approche traditionnelle (42% pour l’approche Agile tandis que 14% pour l’approche traditionnelle).

Le sondage 2011 de VersionOne nommé « State of Agile Survey » confirme que la gestion de projets avec Scrum est l’approche la plus utilisée lors de projets Agile. Vous avez peut-être vous-même eu un certain succès avec Scrum dans un projet pilote ou bien vous êtes peut-être maintenant rendu au stade où vous utilisez toujours l’Agilité lors de la phase de réalisation de vos projets de développement. Fier de ce nouveau succès professionnel, je trouve que l’être humain a tendance à répéter ce qui a bien fonctionné sans prendre le temps de prendre connaissance de la nouvelle situation qui se présente devant lui. L’objectif de ce billet n’est pas d’énumérer les situations où Scrum s’applique. Plutôt, il veut rappeler au lecteur quel type de problème on peut résoudre avec cet outil.

La matrice de Stacey

Ralph Stacey de l’Université de Hertfordshire a mis au point une matrice qu’il nomme « The Stacey Matrix ». Cette matrice permet de prendre connaissance du degré de complexité d’une situation selon le niveau d’incertitude et le niveau d’accord face à la situation. 

La matrice de Stacey

L’axe des X montre le niveau d’incertitude où, à la gauche, il y a peu d’incertitude (close to certainty) tandis qu’il y aura de plus en plus d’incertitude lorsqu’on s’éloigne vers la droite. Sur l’axe des Y, on évaluera le niveau d’accord. Plus on se rapproche de l’origine, plus le niveau d’accord est fort tandis que plus on s’éloigne de l’origine, plus on devient en désaccord sur un sujet. On peut accoler plusieurs thèmes sur ces axes.

Par exemple, on peut se servir de cette matrice dans le choix des technologies à employer pour un projet. Les technologies viendront donc meubler l’axe des X où le degré d’incertitude permettra de nous situer au bon endroit. Quant à l’axe des Y, lors d’un projet, il pourra représenter les requis. Selon le niveau d’accord par le monde Affaires (i.e. votre clientèle à qui est destiné le produit final) face à leurs besoins, on peut alors se situer sur l’axe des Y.

Simple Stacey Chart

À une plus simple expression de la matrice de Stacey, on retrouve 4 états que l’on énumère de la façon suivante :

  • Connu (simple): Tout est connu
  • Compliqué (complicated): Il y a plus de connus que d'inconnus
  • Complexe (complex): Il y a plus d'inconnus que de connus
  • Chaotique (anarchy): Très peu d'éléments connus

Selon mon expérience, des besoins plus ou moins bien connus et une solution inconnue me situe dans la zone complexe de la matrice de Stacey. Selon moi, cela représente souvent l’état de plusieurs projets de développement logiciel en démarrage. Le client a une idée générale de son besoin mais ne sait pas encore à quoi va ressembler la solution finale.

Dans cette zone de complexité de la matrice, Scrum est un excellent outil pour gérer l’imprévisible. Par son approche empirique, Scrum permet de faire de petits pas en livrant des incréments de la solution finale pour permettre de gérer l’inconnu. Le style de management dans cette zone est aussi prescrit par Scrum. À l’aide d’un leadership au service de l’équipe, on fera émerger des idées tout en augementant le niveau de communication dans l’équipe.

Cependant, tous vos projets ne sont pas aussi complexes et ne requiert pas l’Agilité. Et c’est cette nuance que je vois largement ignorée. Par exemple, si vous êtes dans un projet d’entretien, demandez-vous si vous êtes encore dans la même zone de complexité. Si vos clientèles en maintenance ont des besoins très précis et indépendants l’un de l’autre, vous serez moins haut sur l’axe des Y puisque le niveau d’accord sera plus fort. L’impact de ces demandes sur le produit actuellement en production sera peut-être plus faible. En d’autres termes, le changement technologique demandé sera faible et bien compris, ce qui nous pousse vers la gauche sur l’axe des X.

Toutefois, il se peut que vous restiez dans une zone complexe si vos clients ne s’entendent pas sur leurs besoins mutuels. Il se peut aussi que le logiciel à entretenir soit mal conçu, provoquant ainsi de longues séries de tests avant une mise en production.

Pour conclure

L’objectif de ce billet est de rappeler au lecteur que l’Agilité ne s’applique pas à toutes les situations. Selon le niveau de complexité de votre projet, vous devez utiliser la bonne approche. La matrice de Stacey est un outil qui vous permet de vous positionner quant au niveau de complexité de votre projet. Une fois cela déterminée, il suffit de prendre l’approche pour gérer cette complexité.

Il existe plusieurs outils sur le marché pour vous aider à choisir entre l’Agilité et l’approche traditionnelle. Par exemple, Dean Leffingwell, auteur du Scaled Agile Framework, offre un questionnaire de 10 questions pour vous aider à déterminer quelle approche prendre. À mon avis, un retour à la base, c’est-à-dire bien comprendre l’envergure du projet ainsi que voir sa position dans la matrice de Stacey, vous permettra de voir clair quant à l’approche à prendre.

 

Références des graphiques:

http://www.gp-training.net/training/communication_skills/consultation/equipoise/complexity/stacey.htm

  • Plus récents
  • 1
  • Plus anciens

Archive