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.

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 !!!

%d blogueurs aiment cette page :