IceScrum : Configurer l’application sur Tomcat avec PostgreSQL

Voici une description de l’installation d’IceScrum avec Tomcat et PostgreSQL sur Windows.

Binaires d’installation

Installation

PostgreSQL

  • Il s’agit d’une installation simplifiée. Plusieurs clics sur suivant devraient permettre d’obtenir une installation standard. Cependant préféré une installation sur C:\Applications plutôt que sur C:\Program Files qui pourrait poser des problèmes de droits d’installation avec Windows.
  • Créer la BDD icescrum

Tomcat

  • Décompresser Tomcat dans un dossier, classiquement sur C:\Applications. L’exécution de bin\startup.bat devrait permettre d’obtenir l’accès à l’interface Web Tomcat sur http://localhost:8080.
  • Pour avoir un accès sur le déploiement des applications, il faudra créer un utilisateur avec le rôle manager-gui. Modifier le fichier conf/tomcat-users.xml avec les lignes suivantes :
<role rolename="manager-gui"/>
<user username="tomcat" password="tomcat" roles="manager-gui"/>
  • Eteindre Tomcat

Driver JDBC

  • Copier le fichier jar dans le dossier lib de Tomcat et supprimer le fichier lib/tomcat-jdbc.jar

IceScrum

  • Décompresser le fichier war (qui est en fait un zip) et copier le dossier IceScrum dans le dossier webapps de Tomcat.
  • Modifier le fichier bin/catalina.bat avec la ligne suivante (adapter les valeurs des dossiers à celles de votre installation)
set "CATALINA_OPTS=-Dicescrum.log.dir=C:\Applications\Tomcat\apache-tomcat-7.0.34\logs 
-Duser.timezone=UTC -Dicescrum_config_location=C:\Applications\Tomcat\apache-tomcat-7.0.34\conf\config.groovy 
-Xmx1024m -XX:MaxPermSize=512m"
  • Créer un fichier conf/config.groovy dans Tomcat avec des valeurs comme celles-ci :
//Server URL
grails.serverURL = "http://localhost:8080/icescrum"
//Logging (for debug purposes)
icescrum.debug.enable = true
//Working directory
icescrum.baseDir = "C://Applications//Tomcat//apache-tomcat-7.0.34//webapps//icescrum"
//PostgreSQL
dataSource.driverClassName = "org.postgresql.Driver"
//dataSource.dialect="net.sf.hibernate.dialect.PostgreSQLDialect"
dataSource.dialect="org.hibernate.dialect.PostgreSQLDialect"
dataSource.url = "jdbc:postgresql://localhost:5432/icescrum"
dataSource.username = "postgres"
dataSource.password = "postgres"
//Mail server (These exemple values aren't set by default)
grails.mail.host = "smtp.gmail.com"
grails.mail.port = 465
grails.mail.username = "username@gmail.com"
grails.mail.password = "mypassword"
//Project
icescrum.project.import.enable = true
icescrum.project.export.enable = true
icescrum.project.creation.enable = true
icescrum.project.private.enable = true
//Users
icescrum.gravatar.secure = false
icescrum.gravatar.enable = false
icescrum.registration.enable = true
icescrum.login.retrieve.enable = true
//Alerts
icescrum.auto_follow_productowner = true
icescrum.auto_follow_stakeholder = true
icescrum.auto_follow_scrummaster = true
icescrum.alerts.errors.to = "dev@icescrum.org"
icescrum.alerts.subject_prefix = "[icescrum]"
icescrum.alerts.enable = true
icescrum.alerts.default.from = "webmaster@icescrum.org"
//Attachments
icescrum.attachments.enable = true
  •  L’installation est maintenant terminée.

Lancement

  • Démarrer le serveur Tomcat avec la commande bin/startup.bat
  • Allez sur l’interface IceScrum : http://localhost:8080/icescrum
  • Vérifier qu’après être arrivé sur l’interface, les tables de la BDD ont bien été créées.
  • Il est ensuite possible de créer des utilisateurs et des projets.

Atelier Management : Comprendre la complexité de l’expression du besoin (Lego Game)

Lego - 6177

Préambule

Dans la réalisation d’un projet, notamment informatique, plusieurs acteurs se rejoignent pour travailler ensemble. La communication n’est pas toujours évidente et simple, surtout s’ils arrivent tous avec une expérience et des méthodes différentes. La présentation par le jeu peut permettre de mettre en lumière ces différences et de montrer que des schémas d’organisation ou de méthodologies, apportés par chaque acteur, peut améliorer considérablement la communication dans l’équipe.

Objectifs

L’objectif de cet atelier est de présenter comment l’expression du besoin, notamment dans le développement logiciel, est complexe lorsqu’utilisateurs, chefs de projets et production ont une vision différente des concepts. Même lorsque le produit final est simple à construire. Mais l’objectif est surtout de montrer que des schémas d’amélioration sont possibles à tous les niveaux.

Pourquoi l’essayer avec vos équipes

Platon disait : « On peut en savoir plus sur quelqu’un en une heure de jeu qu’en une année de conversation. ». Cet atelier est un bon moyen pour vos équipes d’apprendre à se connaitre et surtout d’apprendre à fonctionner ensemble. Elles constateront, que même avec des méthodes différentes, il est possible d’arriver à des résultats probants.

Durée

Cet atelier nécessite entre 1h et 1h30.

Matériel

  • Une table par groupe de 3 personnes. Prévoir des nombres de tables de préférence.
  • Une boite de Lego de 600 à 700 pièces environ. Idéalement les boites 6177 ou 5508 que l’on peut trouver pour moins de 50 euros.

Lego - 5508

Démarrage

L’atelier est construit sur 3 exercices.

Exercice 1 : Construction d’une tour Lego

L’objectif de cet exercice est surtout de désinhiber les joueurs des Lego en leur laissant le temps les manipuler et appréhender les différents types de pièces, couleurs, et nombres.

Objectif

  • Construire une tour stable (elle ne doit pas s’écrouler si l’on secoue légèrement la table), la plus haute possible, avec 25 pièces.
  • Durée : 10 minutes maximum.

Déroulement

  • Dans un premier temps, vous allez voir les joueurs construire un socle, puis leur tour.
  • Ils vont ensuite s’apercevoir que celle-ci est très rapidement réalisée et que le socle n’est pas nécessaire.
  • La majorité va comprendre également que la tour ne peut qu’avoir une hauteur maximum du nombre de pièces qu’ils empilent.
  • Et certains vont d’ailleurs le comprendre plus vite que d’autres et souhaiteront expérimenter d’autres alternatives avec plus ou moins de succès.

Débriefing

  • Demandez aux joueurs leurs impressions sur ce premier exercice.
  • Attardez-vous sur les joueurs ayant souhaité explorer des alternatives différents.
  • Les joueurs devraient maintenant être décomplés des Lego. Vous pouvez attaquer l’exercice suivant.

Exercice 2 : Création d’un robot dos à dos

L’objectif est de montrer que le passage d’ordre par la parole pour la construction d’éléments n’est pas chose aisée et qu’elle nécessite vite une organisation.

Objectif

  • Construire un robot simple (choisir entre les robots S1, S2 ou S3 du powerpoint fourni).
  • Les couleurs, les pièces et l’empilement doivent être fidèles à la photo fournie.
  • Durée : 10 minutes

Robot Lego Simple

Démarrage

  • Placer 2 joueurs assis dos à dos. L’un sera en charge de l’explication de la description, l’autre de la construction du robot.
  • Ils ont instruction de ne pas se regarder.
  • Fournir une photo d’un robot simple, face cachée à celui qui va le décrire et qui ne touchera pas les Lego.
  • Au top, lancez le chrono, chaque joueur retourne sa photo, la partie commence.

Déroulement

  • En fonction des personnalités, certains commenceront par le haut ou le bas du robot. Par sélectionner les pièces ou non.
  • Ils feront ensuite un check étape par étape et/ou également à la fin pour s’assurer que le robot construit est conforme à la description.
  • Si une équipe indique avoir terminé, faites la vérification sans que ni l’un ni l’autre ne voit le résultat ou la photo. Si le résultat n’est pas conforme, dites leur de poursuivre.

Débriefing

  • Demandez aux joueurs leurs impressions sur cet exercice.
  • Déroulez les différents process mis en place, au démarrage, lors de la construction lors de la vérification finale du robot. → Méthodes d’organisation.
  • Mettez en évidence les méthodes différentes mises en place qui permettent d’aboutir malgré tout à un résultat → Organisations différentes, résultats identiques.
  • Mettez également en évidence les manques qui ont pu aboutir à un résultat différent de celui décrit → Manque dans les process, dans la rigueur de la réalisation.
  • Montrez les types d’erreurs qui ont pu être commis lors de la validation (couleurs, formes, emboîtements…) → A mettre en corrélation avec les erreurs qui peuvent être commises par vos équipes et l’impact que cela peut avoir sur le résultat.
  • Enfin faites la corrélation complète avec votre organisation, vos méthodes de travail et les étapes à renforcer sur l’existant.

Exercice 3 : Création d’un robot avec un intermédiaire

L’objectif est de montrer qu’avec des méthodes, même avec un intermédiaire, il est possible de réaliser des éléments complexes.

Objectif

  • Construire un robot complexe (choisir entre les robots C1 à C5 du powerpoint fourni).
  • Les couleurs, les pièces et l’empilement doivent être fidèles à la photo fournie.
  • Durée : 10 minutes

Robot Lego Complexe

Démarrage

  • Faire des équipes de 3 à 4 joueurs. Un joueur sera le client, un deuxième l’intermédiaire, le troisième sera le producteur. Pour les équipes de 4 personnes, laisser décider l’équipe sur le rôle du quatrième.
  • Le client va construire seul une première fois le robot et s’assurer que les pièces nécessaires à sa construction sont disponibles dans le tas de pièces utilisé par le producteur.
  • Ensuite le client va s’éloigner de quelques mètres, pour ne pas être en mesure de voir le robot construit. Il va devoir décrire le robot sans jamais le montrer à l’intermédiaire.
  • L’intermédiaire va réaliser le passage d’information entre le client et le producteur. Il ne peut ni voir le robot, ni toucher les Lego.
  • Le producteur va lui construire le robot, uniquement sur les ordres de l’intermédiaire.

Déroulement

Chaque acteur devrait appliquer les méthodes vues lors du second exercice.

Certains, notamment les producteurs, devraient même aller plus loin en préparant les Lego triés par type ou couleur.

Si une équipe indique avoir terminé, faites la vérification sans que ni l’un ni l’autre ne voit le résultat ou la photo. Si le résultat n’est pas conforme, dites leur de poursuivre.

Débriefing

  • Demandez aux joueurs leurs impressions sur cet exercice.
  • Déroulez les différents process mis en place, au démarrage, lors de la construction lors de la vérification finale du robot. → Méthodes d’organisation.
  • Montrez que les méthodes acquises et les erreurs commises lors de l’exercice 2 ont été appliquées ou corrigées permettant d’améliorer l’organisation, la communication et la production → Amélioration continue dans l’organisation, la communication et la production.
  • Mettez encore en évidence les manques qui ont pu aboutir à un résultat différent de celui décrit → Manque dans les process, dans la rigueur de la réalisation.
  • Enfin faites la corrélation complète avec votre organisation, vos méthodes de travail et les étapes à renforcer sur l’existant.

Notes

  • Les exercices seront plus pertinents avec les membres d’une même équipe, et notamment avec des personnes ayant des rôles différents sur les projets (conception fonctionnelle, technique, réalisation, recette, gestion de projets).
  • Fichier powerpoint contenant les robots : Scrum – Lego – Cynefin v0.5
  • Si vous souhaitez de l’aide dans la réalisation de cet atelier ou si vous souhaitez que je réalise cet atelier avec vos équipes, n’hésitez pas à me contacter.

Scrum, XP : A qui profite l’agilité ?

Il y a un très bon article dans le magazine Programmez du mois de Juin 2009 qui décrit Scrum, XP et la journée d’un développeur agile.

Formé à l’ancienne sur des méthodes de cycle en V, et ayant appliqué XP de manière intensive, j’étais dubitatif mais enthousiaste et intéressé par les nouvelles méthodes agiles, Scrum plus particulièrement. Je ne pensais cependant pas que la nature des concepts était si révolutionnaire que cela.

Pratiquant Scrum depuis maintenant 6 mois dans ma nouvelle entreprise, je dois dire que l’ensemble de mes concepts a été remis à zéro, sur de nouvelles bases, et de nouvelles méthodes. Et après ces 6 mois, je peux dire que mon opinion est faite. Scrum est une des meilleures méthodes de développement logiciel actuelles. Il était temps que l’informatique innove pour s’améliorer. Maintenant les entreprises vont devoir intégrer les méthodes, c’est un point plus difficile.

Mais revenons au titre de mon sujet. A qui profite l’agilité ?

Vraisemblablement, pour Programmez, la personne bénéficiaire est le développeur, et puisqu’il est plus productif, par conséquent, son employeur l’est également. Mais commençons avec le développeur.

Le développeur

Par un développement progressif, auxquels se succèdent tests unitaires, tests d’intégration et couverture de code, puis compilation sur un serveur de référence, le développeur gagne en retour, positif ou négatif, sur son travail. Il est alors mieux à même de connaître les impacts de ses nouveaux développements sur le code existant. Il est plus sûr de lui, plus confiant et donc plus à même de modifier, d’améliorer et progresser dans son travail. Le gain de productivité est très important. Avec la démonstration de son travail à la fin de chaque itération, les progrès sont concrets et perceptibles immédiatement par le métier, une relation de confiance s’instaure, la compréhension des partenaires métier et technique s’intensifie. La qualité des développement s’améliore.

L’architecte

L’architecte n’ayant « qu’à » dessiner les bases de l’application sur des besoins réels immédiats, en préservant tout de même des choix en cas de modifications ou d’améliorations importantes, il évite un travail d’approfondissement contraignant, souvent inutile et trop abstrait, et couteux en temps. Cette agilité lui permet donc de s’économiser pour travailler sur des tâches réellement importantes et à retour sur investissement court. Il gagne beaucoup en productivité. Le logiciel perd en complexité inutile et préméditée.

Le chef de projet

Il est difficile de définir un chef de projet en utilisant des méthodes agiles comme Scrum. On peut le confondre avec un ScrumMaster et/ou un chef d’équipe. Il peut également être assimilé à l’architecte. Cependant en faisant interagir les membres de son équipe comme un tout, directement avec le métier, la transmission de la connaissance et la fluidité de la communication lui permettent de diminuer les risques d’erreur ou d’incompréhension métier et/ou technique. Toutes questions étant posées lors des réunions quotidiennes et/ou lors des réunions de planning. Les temps morts, retours en arrière, frustation sont diminués, l’équipe gagne en productivité et connaissance métier, le chef de projet gagne en sérénité.

Le chef de produit

Celui-ci s’exprime directement avec les développeurs lors des plannings et démonstrations. Il est a même d’expliquer ce qu’il attend, ce qui va et ce qui ne va pas dans ce qui a été produit. Il fournit ainsi un dialogue direct qui permet aux développeurs de comprendre plus facilement ce qui doit être fait et comment. Avec des déploiement fréquent, il reçoit également son logiciel dans des délais plus courts et en fonction de besoins réels immédiat. Son équipe gagne en productivité, par l’utilisation de fonctions développées en priorité, selon ses propres recommandations. Il gère mieux son travail, celui de son équipe et le futur de son organisation. La productivité métier est accrue.

Les décideurs

Le premier objectif des décideurs dans l’application des méthodes agiles est d’augmenter la productivité des développeurs pour que ceux-ci augmentent la productivité du métier, et afin que ces derniers augmentent le chiffre d’affaire et surtout le bénéfice de l’entreprise. Si la productivité des développeurs est assurée, celle du métier sera alors encore plus importante, le pari est donc gagné.

Mais revenons sur le terme de l’agilité. Le fait que le retour sur investissement (ROI) avec les méthodes agiles soit court, 2 à 3 semaines, va permettre aux décideurs de pouvoir décider (c’est leur métier après tout) et faire appliquer leur décision sur des cycles plus courts, vraisemblablement une à deux itérations. Ils pourront ainsi s’adapter plus rapidement aux marchés et emprunter des chemins aujourd’hui impossibles sur des méthodes traditionnelles, type cycle en V.

Reprenons le schéma que j’avais fourni lors d’un précédent post : Scrum : De l’intérêt des méthodes agiles

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

Ce schéma montre les coûts de production logiciel et la productivité du métier.

Dans le cas de développement avec la méthode de cycle en V (ligne verte), le décideur n’a d’autres choix que d’attendre le déploiement du logiciel en production avant de placer ses équipes sur un autre développement, plus stratégique (sauf à retirer quelques ressources, mais en impactant le planning de déploiement de son logiciel en cours).

Avec les méthodes agiles, le métier est plus productif dès la seconde itération (ligne rouge). Si le décideur choisit d’interrompre les développements logiciels, il peut le faire, premier point, mais il peut également calculer le gap entre la productivité actuelle et maximum du métier avec les développements restants et choisir de réorienter une partie ou l’ensemble de son équipe sur des points plus stratégiques.

En définitive, s’il est un acteur de l’entreprise qui gagne en agilité avec les méthodes agiles, c’est le décideur. Des décisions en connaissance de cause, moins pénalisante, plus stratégique, plus rapide et plus efficace.

L’agilité est aux décideurs. A eux de faire les bons choix.

Méthodologie Scrum en vidéo

Voici une vidéo de la méthodologie Scrum en pratique. Très sympa.

Les utilisateurs de Scrum reconnaitront les différentes phases, les autres se demanderont bien ce que peuvent faire ces gugus avec leurs post-its et leurs jeux de cartes. 🙂

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 :