Scrum : De l’intérêt des méthodes agiles

Depuis l’année dernière je m’intéressais beaucoup aux méthodes dites agiles dans la gestion de projet, comme Scrum, par exemple.

J’ai l’occasion grâce à mon emploi actuel de m’initier à ces principes qui sont aux antipodes des méthodes dites traditionnelles de gestion de project que nous pouvons pratiquer en France et qui sont enseignées dans nos universités.

Il n’est pas simple pour un manager de passer de l’un à l’autre. Beaucoup de principes et concepts sont à revoir, réapprendre et le faire seul est une étape difficile. Heureusement pour moi, j’ai la chance d’être initié (sur la pratique tout au moins) par une collègue canadienne, devenue Scrum Master récemment.

Avec ces principes, vous ne devez plus penser long terme, mais court terme, et surtout retour sur investissement (ROI). Les premiers mois ont été plutôt difficiles. En effet, l’envie de faire des projets et des plannings restent forts. Surtout lorsque vous disposez de MS Project 2007 et que vous avez envie de faire « joujou » avec.

Et puis le temps passe, vous faites des réunions et des itérations (planning, développements, tests, bugs, démo et déploiments) et vous vous sentez tout à coup envahi par ces principes qui remettent en question tout ce que vous avez pu faire avant.

En effet, dans une démarche standard, vous avez l’étape de spécifications, pendant laquelle vous réfléchissez avec votre client ou votre MOA. Les idées sont souvent vagues, il est difficile de se faire une idée concrète du produit final, vous êtes seul ou dans une équipe réduite à son minimum. Pas de développeur. Ensuite vous attaquez les devs et tests et suivez avec fidélité les spécifications qui sont très souvent vagues et pour lesquelles vous devez retourner voir le client car vous avez besoin d’éclaircissements. Puis vient le jour du déploiement et des formations utilisateurs. Et comme bien souvent, à cette étape, l’équipe est à nouveau réduite et vous êtes le seul à recevoir les remerciements (ou les blâmes, cela dépend). Et puisqu’à cette date, vous quittez vous-même le projet, vous ne savez pas ce qui va réellement être utilisé et ce qui convient et ne convient pas. Grosso modo, quel est le travail réellement intéressant et qui apporte une réelle plus value au métier. Les manques sont considérables.

Dans l’autre cas, méthode Scrum, par exemple, vous êtes au contact direct du métier. L’équipe complète se forme très rapidement et les premiers développements apparaissent après la première ou deuxième itération (après un mois environ). Vous avez donc des retours client quasi immédiatement. Les choix de développement se font itération après itération, l’ensemble de l’équipe est impliqué et le client vous félicite (ou vous blâme) tous ensemble. Vous avez donc un retour instantané sur ce qui est « bien » et ce qui ne l’est pas, vous comprenez mieux le métier, plus rapidement. Le client a également une plus grande réactivité dans ses choix de développement, en choisissant d’annuler ou refaire un développement, si la première version qu’il a reçu n’apparait finalement pas convenir à ses besoins.

Si les principes de Scrum sont bien respectés, et si donc, l’équipe projet a suffisamment d’expérience dans ce domaine, les projets utilisant cette méthodologie sont plus à même de répondre aux besoins réels du métier.

Cependant il ne faut pas se leurrer. Cette méthodologie comporte des pièges que seules des personnes expérimentées sont à même d’éviter ou prévenir. Car la complexité projet ne disparait pas pour autant.

  • Premièrement le métier doit savoir de quoi il parle et doit se tenir à la disposition de l’équipe de développement tout au long du projet et pas uniquement sur le début comme dans un développement standard.
  • Deuxièmement, le chef de projet ou ScrumMaster, doit être conscient des limites de son équipe de développement et s’assure les conseils d’un senior en architecture/développement, histoire de ne pas revoir toute l’implémentation au moindre changement de conception.
  • Troisièmement, l’agilité ne concerne pas que la partie Scrum, mais toutes les phases de développement. eXtreme Programing pour un transfert de connaissance fluide, des tests et un serveur d’intégration continue, afin de pouvoir faire des modifications rapidement, facilement et sans crainte, un processus de déploiement simplifié, pour le répéter à chaque itération sans difficulté.

En suivant ces quelques principes, les projets suivant la méthodologie Scrum ont plus de chance d’aboutir et d’être à même de satisfaire le métier en fournissant des logiciels qui correspondent réellement à leurs attentes du moment (et pas à celles d’il y a 10 mois, déjà mises à l’oubli pour cause de crise, réorg ou perte de marché)

Le tableau suivant présente une comparaison des coûts de production des équipes de développement et la productivité du métier entre la méthodologie Scrum et les méthodes standards.

Comparaison des coûts de production et productivité entre Scrum et méthode standard

Comparaison des coûts de production et productivité entre Scrum et méthode standard

Dans le cas standard, on retrouve ce qui fait le principe d’un projet dit classique. Des coûts de production bas sur le début, lors des phases de spécifications, une intensification lors des développements et une baisse progressive sur la fin de projet lorsqu’il ne reste que la livraison, la correction des bugs et les formations utilisateurs. La productivité quant à elle ne débute qu’après la livraison et fournit son plein potentiel quelques mois après la livraison.

Pour Scrum, les coûts de production sont rapidement à leur maximum, puisque l’équipe intervient très rapidement sur le développement du produit. Ces coûts s’arrêtent d’ailleurs quasi immédiatement après la fin du projet, puisque l’application est livrée, les bugs sont déjà corrigés et les utilisateurs déjà formés. La productivité cependant débute juste quelques mois après les premiers développements. Cette productivité, timide sur le début, s’accélère rapidement puisque les fonctionnalités les plus importantes sont développées en priorité. Et la productivité est plus importante sur la fin, car elle correspond exactement à ce que demande le client au moment où il le demande (et non à ce que avait été défini dans les spécifications 10 mois avant, comme c’est le cas avec le méthode standard). Les gains de productivité sont d’ailleurs beaucoup moins important sur la fin de projet. C’est à ce moment que le client devra se demander s’il est légitime de poursuivre les développements, puisque ceux-ci n’apportent plus réellement de valeur ajoutée. On pourra alors stopper net le projet ou réorienter les développements vers d’autres objectifs.

Ce graphique montre tout le potentiel de Scrum.

Le coût d’un copier-coller

Afin de donner un exemple concret de ce qu’il ne faut pas faire et pour vous montrer qu’il vous coûte plus cher de ne pas suivre vos développeurs que de les accompagner jour après jour, voici une histoire plus ou moins récente d’un de mes clients.

L’histoire est au présent pour plus de simplicité.

Mon client a un fournisseur de contenu que nous avons en charge de traiter. Ce contenu est envoyé de manière assez irrégulière mais demande à être traité avec soin. Il s’agit d’un fichier plat type csv classique. Les données sont séparées par un ; et informent sur un produit, des sections et sous-sections et autres codes.

Le processsus, même s’il est manuel, est plutôt bien rodé. Un développeur reçoit le fichier plat, le fait passer dans son programme « fait-maison », intègre les données dans une base de dev et vérifie que ca passe bien. Ensuite 2 ou 3 personnes sont chargées de vérifier l’ensemble des données pendant une petite semaine. Les données validées sont alors transférées dans une base de pré-prod.

Il se trouve qu’un jour,  le fichier change de format, un caractère : a été inséré pour ajouter une information. Le fournisseur prévient le développeur, celui modifie son programme et le relance pour intégrer les données. Une semaine se passe et les testeurs s’aperçoivent qu’une partie des données est corrompue car le caractère : n’a pas été pris en compte.

Nous entamons alors une réunion à 5 personnes, le chef de projet, le développeur, le responsable des données, le développeur SQL et le responsable des bases de données. Après examen des données corrompues, on s’aperçoit qu’un pan entier n’a pas été pris en compte, parce que la modification du programme a été faite sur les 4 premières parties du code, qui sont en fait 4 copier-coller identiques de gestion du format, mais que la 5ème partie n’a pas été modifiée. Dommage.

Coût du copier-coller

  • Une semaine de 2 testeurs, qui vont devoir tout retester,
  • 1 heure de réunion * 5 personnes pour identifier le problème,
  • 1 heure de développeur pour remettre à jour son programme et vérifier que ca tourne cette fois,
  • 4 heures de développeur SQL pour écrire une procédure stockée afin de corriger les données,
  • 1 heure de réunion * 5 personnes pour expliquer ce qui a été fait et vérifier que cela fonctionne correctement.
  • Combien de temps cela aurait-il pris au développeur de réfléchir à son programme afin de factoriser un maximum de code pour ne pas produire ce genre de problème ? 2 ou 3 heures.
  • Pourquoi ne l’a-t’il pas fait? Parce que factoriser demande à réfléchir. Et qu’un développeur suit souvent la devise « Quand ca marche, tu touches pas!« 

Maintenant lors de ces discussions, personne n’a parlé de modifier le programme afin de factoriser le code, ce qui veut dire qu’au prochain changement de format, vous pouvez être sur à 50% que la même erreur va se reproduire.

Imaginez maintenant que le développeur quitte la société, est malade ou en vacances. Quelqu’un va obligatoirement devoir le remplacer dans cette tâche. Le taux d’échec de la transformation va alors monter à 95%.

Si en plus vous ajoutez le fait qu’il est fort probable que le développeur a créé une nouvelle branche de source pour ce format, plutôt que de rajouter un test sur le type de format, le prochain développeur va même tout réécrire pour reproduire les mêmes erreurs.

Elle est pas belle la vie ?!!!

PS : Attention, je n’exagère absolument pas la réalité.

PS2 : Mais où sont les bons développeurs.

PS3 : Un ancien collègue m’a dit un jour que les développeurs sont une espèce à part. Je vais commencer à croire que c’est vrai…

Accompagnez vos développeurs

Depuis quelques temps, je lis beaucoup de documentations sur la gestion de projet avec Scrum, le Lean Development, l’eXtreme Programming et l’agilité. Je suis toujours ravi de voir qu’une des bases de ces concepts est de fournir un produit avec une structure technique de qualité. Qualité de l’architecture, qualité de la documentation, qualité du code.

Mais chaque fois que j’arrive dans une nouvelle entreprise, je suis toujours étonné de la qualité de ce qui a été conçu.

  • On parle d’architecture, mais il n’y a pas d’architecte.
  • On parle de documentation, mais il n’y a pas de document.
  • On parle de logiciels, mais lorsqu’on étudie le code, on voit clairement le concept principal, « je code vite, je code pour que çà marche, le reste (bon code, commentaires, syntaxe généralisée) on verra plus tard (c’est à dire : jamais)« .

Je crois avoir presque tout vu :

  • Des classes avec le nom du développeur, très pratique quand il ne fait que passer sur le projet,
  • Du code très très technique qui marche à moitié, mais dont on ne sait pas grand chose car il n’y a aucun commentaire, aucune doc et puisque le développeur est parti depuis de nombreuses années,
  • Du code de base, mais sans aucun commentaire, aucune règle, aucune organisation,
  • Des méthodes très longues (+ de 2000 lignes),
  • Du code avec plus de codes commentés que de codes exécutés,
  • Des classes avec des méthodes sans paramètres, les membres de classe sont utilisés comme paramètres, imaginez l’enchevêtrement lorsque le code n’est pas exécuté dans le bon sens,
  • Des membres de classes définis par le constructeur mais jamais utilisés, pratique lorsqu’on se dit que la classe pourrait répondre à nos attentes avec un paramètre mais qu’il n’en est rien,
  • Des projets où tous les fichiers (pages web, classes, javascript, images, fichier de properties…) sont à la racine du projet, aucun dossier, super pour rechercher ses fichiers,
  • Des classes avec l’ensemble de toutes les valeurs utilisées éparpillées dans le code, en dur, répétées des dizaines de fois. Vous changez le nom d’une valeur, il faut le changer dans 10 classes différentes, imaginez lorsque vous travaillez sur un fichier xml et que l’ensemble des balises est répété à plusieurs endroits, comprendre le code, le modifier ou le réutiliser sont un vrai bonheur,
  • Des logs en dur avec System.out partout, avec marquez « toto3, « test1 » ou « passe par ici », « passe par là »,
  • Des centaines de lignes de code copier-coller, avec une ou deux lignes qui changent, comme ça, pour corriger les bugs, ce sera le bonheur,
  • Des développeurs qui, pour adapter leur projet à un process particulier, préfèrent créer une nouvelle branche et faire les quelques modifications qui s’imposent, plutôt que de faire fonctionner leur esprit afin d’ajouter un paramètre dans une méthode,

Ce ne sont que quelques extraits, et ils ne sont pas réservés à des développeurs junior, bien au contraire.

La seule société où j’ai pu travailler sur un code de qualité remonte à ma première expérience en Suisse. Certes les Suisses sont connus pour la qualité de leur travail, mais on peut dire qu’ici le code (et le développeur) était traité avec le respect qui lui est du. Règles de développement, commentaires, documentations, process strict, packages, rôles… Débuter dans cette société m’a permis d’intégrer un point essentiel que tout développeur devrait maitriser. Le développement de qualité.

Et lorsque vous croisez un ‘mauvais’ développeur (mauvais dans le sens où il ne respecte pas de standard en développement, commentaires, organisation), vous ne pouvez pas le blâmer. S’il n’a pas été éduqué pour faire du bon code, il faudrait qu’il prenne sur lui afin d’apprendre seul, ce qui n’est jamais facile.

Qui blâmer alors si on ne peut pas blâmer le développeur ?

Facile, son supérieur direct. Le chef d’équipe ou le chef du projet. On entend souvent qu’un chef d’équipe ou un chef de projet informatique n’a pas besoin de connaitre l’informatique pour être un bon chef. Faites moi rire, vous en connaissez beaucoup des chefs IT qui n’ont jamais fait de développements ? Je n’en ai jamais croisé.

Son rôle est certes de gérer l’équipe ou le projet mais il est également de s’assurer de la qualité de ce qui est produit et pas seulement que le produit répond aux attentes ou non. Ce serait un peu trop facile.

Alors oui, c’est long, oui, c’est fastidieux, oui, il faut répéter, insister, vérifier, re-vérifier. Mais si vous voulez des développeurs de qualité, il vous faut fournir un travail de qualité. Si vous ne faites pas ce travail avec vos développeurs en controlant, expliquant pourquoi vous voulez ceci comme ca, et pas autrement, vos développeurs ne seront jamais de bons développeurs et vous aurez des difficultés par la suite à faire avancer votre projet. Prenez le temps maintenant, vous en gagnerez beaucoup plus tard.

Accompagnez vos développeurs !!!

MS Visual Studio 2008 : Une mauvaise copie d’Eclipse

Depuis quelques jours, j’ai l’occasion d’utiliser Visual Studio 2008 à mon travail. Ceci me permet de faire quelques comparaisons avec mes outils fétiches, Eclipse et Netbeans.

Et la conclusion est désespérante pour Microsoft.

Leur produit est plus ancien mais beaucoup moins fourni, un comble.

Voici mes arguments :

  • Pas de touche magique (Le Ctrl + Shift + 1 d’Eclipse). Et oui, ces 3 touches parfaitement positinionnées qui permettent de faire pratiquement tout ce dont vous avez besoin au moment ou vous en avez besoin. Correction d’erreurs, import de classes, renommage, complétion. Avec VS 2008, rien de tout ca, vous avez la souris et son clic droit qui permettent de faire certaines choses, mais très peu en comparaison d’Eclipse.
  • Pas d’accès facile entre les classes, vous êtes obligé d utiliser le bouton droit de la souris et de faire « go to definition ». C’est lent, demande plusieurs manoeuvre et ca m’a rebuté plus d’une fois.
  • Génération de code laborieuse. Il est difficile de trouver les générateurs de code (genre get/set), et les complétions de code se génèrent souvent sans les parenthèses nécessaires aux appels de méthodes (vides) ou sans les accolades de fin des méthodes ou blocs conditionnels. Vous êtes donc toujours obligés de fermer les accolades, VS 2008 ne le fait pas pour vous.
  • Mise à jour des erreurs très tardives parfois. VS 2008 vous indique des erreurs, assez bien, même si on aurait aimé un affichage plus lisible, mais lorsque vous corrigez ces erreurs, celles-ci restent affichées jusqu’au prochain lancement du serveur. Ce n’est pas très agréable de chercher une erreur alors que vous venez de la corriger.
  • Documentation avec peu d informations. Je crois que c’est le pire. Microsoft vous fournit une grosse documentation sur MSDN, mais pour trouver un type en entrée ou en sortie d’appels de méthodes, il faut écrire la méthode dans l’éditeur pour le savoir. C’est plutôt moyen. Quand on compare avec la javadoc, on s’aperçoit vite que MS fait beaucoup moins bien dans ce domaine. J’avais trouvé une doc assez complète dans la MSDN, j’allais féliciter MS pour ces progrès et finalement il s’agissait de documentation java. Y’a pas à dire (faudra m’expliquer ce que fait la documentation java dans MSDN).
  • Utilisation brouillon des génériques. MS a fait pareil que Java en rajoutant des génériques sur ses types. Mais pourquoi faire simple quand on peut faire compliquer. Ce sont de nouveaux types, extensions des anciens mais dans d’autres packages et avec des fonctionnalités parfois différentes. Ce qui implique des imports différents, des utilisations différentes de type en fonction du contexte de programmation. Au final, on est vite perdu dans leur utilisation. Mais pourquoi n’ont-ils pas fait comme java ? Les mêmes types mais on autorise la généricité…
  • Fonctionnement de l’éditeur différent en fonction du langage. Et oui, l’éditeur ne se comporte pas de la même façon si vous développez en VB ou en C#. La complétion par exemple, avec la touche entrée, dans un cas, elle vous renvoie à la ligne, dans l’autre elle vous laisse après le bloc compléter. Ceci s’explique surement par des raisons historiques, mais c’est quand même bien dommage.
  • Pas de surbrillance des éléments. C’est une fonction bien agréable d’Eclipse. Vous placez le curseur sur une variable, une méthode, une exception et Eclipse vous montre son utilisation dans le code. C’est particulièrement pratique pour voir les références dans le code. Sous VS 2008, cette fonctionnalité n’explique tout simplement pas. Une horreur lorsqu’on a pris l’habitude de l’utiliser.
  • Presque pas de couleur. L’éditeur de MS ne fournit quasiment pas de couleur pour la syntaxe. Beaucoup de noir, un peu de bleu clair, un peu de bleu foncé et du vert pour les commentaires, c’est tout. Pas de mise en gras ou de souligné, pas d’autres couleurs. Ca rend le code peu lisible et peu engageant.
  • Une documentation en pseudo HTML avec des balises limitées. La javadoc .Net se crée avec des balises style HTML <summary> qui sont à moitié généré. A moitié car les fins de balise sont à écrire à la main. Déjà que les développeurs n’aiment pas écrire la documentation dans le code, avec VS 2008, on dirait que MS a fait exprès de les rebuter au maximum. En plus, il n’existe qu’un nombre très limité de balise et pas de author, since ou version. Comment voulez-vous faire dans ces conditions ?

Avec tous ses défauts, on se demande ce qu’on peut trouver à VS 2008. L’éditeur a 2 ans de retard sur ses concurrents directs (Eclipse et Netbeans). Il apprend et copie des autres, mais vraisemblablement pas assez vite.

Et avec tout ca, on vous raconte que l’environnement .Net vous permet d’être plus productif. Il va falloir me donner des arguments pour me le prouver !!

Heureusement j’ai lu qu’Eclipse allait permettre d’écrire du code .Net. Voila une très grosse concurrence pour VS2008. Vite c’est où qu’on récupère le plugin ?!!!

Le Web 2.0 avec Python et Django

Bon, alors après avoir testé un peu Python et Django, voir mon post précédent avec rss4mininova, je me suis dit que j’allais me faire une petite application Web 2.0, avec de l’AJAX, un petit truc simple mais qui en jette plein les yeux…

Alors qu’est-ce-qu’on choisit ? Et bien du javascript bien sur. Alors lequel, Dojo, Extjs ou je ne sais quel autre… Essayons Dojo avec Google, « Python Django Dojo », résultat intéressant, 1 seul. Super. On essaie, pas facile, faut connaitre le javascript, Dojo, le CSS et le HTML, tout ca pour faire un simple bouton qui affiche un « Hello World », laisse tomber.

Passons à extjs, le framework parait super, la démo est super soignée, recherche sur Google, pareil, un résultat intéressant, mais avec une ancienne version, ca compile pas, faut tout corriger et faut connaitre le javascript, extjs, le CSS et le HTML, encore des tonnes de connaissance pour afficher un « Hello World ». On oublie.

Mais que vois-je ?, Pyjamas, un super framework de la mort qui tue pour Python (et qui copie GWT de Google en moins bien), afin de faire des applis Web 2.0. Super !!! Recherche Google, presque pareil, un site intéressant, un gars a réussi à mélanger du Django et du Pyjamas, un exploit, il ne lui a fallu que 15 fichiers, 400 lignes de code pour afficher « Hello World ». Merci la simplicité.

Bon quand je vois Python, c’est cool, on fait des choses très bien, très rapidement. Quand je vois Django, ca commence à devenir moins cool, mais ca reste jouable, pour des petits sites. Quand je vois ce qu’on peut faire en Web 2.0, je dis « arrêtez !!! », vous n’êtes pas sur la bonne voie, ca ne va pas le faire.

Donc conclusion, vous voulez faire du Web 2.0, oubliez Python. Vous voulez faire des scripts de la mort qui tue et qui traitent vos fichiers, fournissent un serveur de données, penchez pour Python.

Pour tout le reste, utilisez Java… !!! 😉

Prise en main de Python, Django et Google App Engine

Etant dans une petite période de chomage (que j’espère courte), je me suis aventuré sur le chemin de Python, Django (un framework pour Python) et Google App Engine (les serveurs Google faisant tourner du Python).

J’avais bien envie de me mettre à une technologie de script, afin de faire plus tard (dans mon futur job?) des petits scripts rapides afin de traiter des fichiers, des données ou tout autre besoin.

Pourquoi Python ?, parce qu’il s’agit d’un des outils à la mode en ce moment, surtout dans la région de Saskatoon au canada, puisque ca devait être un de mes langages de travail (avant qu’on annule le poste). Et puis Google est en soutien avec son GAE, donc y’a pas de raison que ca ne dure pas.

Donc je prends les tutoriaux Python (très bien fait), les tutoriaux Django (un peu moins) et je me lance dans la création de flux RSS à partir des données fournies par Mininova (Faut bien que ce soit utile quand même !!!)

Alors initiation, essais, tests, traitement de technos diverses (http, listes, parsing, xml, rss) et finalement au bout de 2 jours pleins (compter 16 heures), me voila avec ma petite application sur GAE.

Petite conclusion rapide après 2 jours : La langage se prend bien en main, même si j’aurais aimé une documentation plus complète (ca ne vaut pas la javadoc de Sun), mais il y a pas mal d’exemple sur le net. Et puis je n’ai pas encore essayé un éditeur digne de ce nom, juste Notepad++. D’ailleurs après réflexion, je crois que je vais opter pour Netbeans Python, ca me semble un des plus simples à installer et des plus aboutis. Je vous tiens au courant avec une petite mise à jour.

Pour info, la petite application GAE prend un ou plusieurs mots-clés dans son url (style « heroes » ou « heroes+720P » pour la version HD), récupére le résultat dans Mininova, ordonnancé par seeds et crée un flux rss avec ces données. Quand on l’intègre dans Netvibes, on en voit tout de suite l’énorme intérêt.

Résultat du programme Python (tri sur Seeds) et celui fournit par Mininova (sans tri sur les seeds)

Résultat du programme Python (tri sur Seeds) et celui fournit par Mininova (sans tri sur les seeds)

Sur ce, je vous laisse les liens utiles et les sources (pour ceux qui voudraient s’en inspirer).

Les 7 règles d’or du développement

En naviguant sur le Web, viadeo en l’occurrence, je suis tombé sur un post de la société OCTO, qui propose un livre blanc concernant 12 règles pour booster votre productivité en java. Curieux par nature, je me suis dit que j’allais devenir encore plus productif que je ne le suis déjà, super.

Ah ah, dommage, en lisant rapidement le document, on s’aperçoit qu’il ne s’agit que des règles élémentaires du développement, même pas java d’ailleurs :

  • Utiliser un IDE, style Eclipse ;
  • Utiliser un gestionnaire de version, style CVS ;
  • Utiliser un bugtracker, style Bugzilla ;

C’est dommage, je pense qu’il y avait matière à donner des conseils plus avisés. Allez, comme je suis un gars investi et impliqué par son travail, ;-), je vous fais part de mes 7 règles d’or, vous me direz ce que vous en pensez.

les_7_regles_d_or_du_developpement_v0.6.7

Le site d’OCTO où trouver leur document : http://www.octo.com/com/com_Java-Productivity-Primer-white-paper-octo.html

%d blogueurs aiment cette page :