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.

Appeler un Web Service REST/JSON en .NET

Les Web Services REST avec le format JSON sont devenus en peu de temps un nouveau moyen d’implémenter des Web Services de manière simple (sans formatage XML et parsing) et orientés données.

Si la procédure de création de Web Services RPC ou REST et SOAP ou JSON en .Net est simplifiée grâce à WCF, et que l’appel d’un Web Service RPC/SOAP est quasi transparent pour le développeur, il n’en est pas de même pour la création du client en REST/JSON.

Ce petit post va vous permettre de mettre en place rapidement un client Web Service .NET avec REST/JSON. Je fais l’impasse sur l’implémentation serveur, je vous laisse vous référer aux différents liens placés en fin de billet.

  • Ajoutez une référence a votre Web Service dans votre projet VS et pointez sur votre URL de type : www.monsite.com/monservice.svc
    • Cet étape va générer votre client Web Service, mais surtout ce qui nous intéresse, les objets en transit,
  • Ajoutez JSON.NET dans votre projet afin de déserialiser vos données automatiquement,
  • Implémentez le code suivant :
Uri requestUri = new Uri("www.monsite.com/monservice.svc/users/5474");
WebRequest webRequest = WebRequest.Create(requestUri);
WebResponse webResponse = webRequest.GetResponse();
Stream response = webResponse.GetResponseStream();
StreamReader reader = new StreamReader(response);
Newtonsoft.Json.JsonSerializer jsonSer = new Newtonsoft.Json.JsonSerializer();
MyUser user = (MyUser) jsonSer.Deserialize(reader, typeof(MyUser));
  • Vous obtenez ainsi votre objet côté client, il ne vous reste plus qu’à en faire bon usage,
  • Vous pouvez également récuperer une liste ou un tableau d’objets avec le code suivant :
List<MyUser> usersList = (List<MyUser>)jsonSer.Deserialize(reader, typeof(List<MyUser>));

Je vous conseille fortement de créer une méthode générique avec 3 parametres (URL, type de résultat et résultat) afin de pouvoir réutiliser ce code a loisirs.

Update : Vous avez également la possibilité de ne pas utiliser JSON.NET avec le Serializer intégré dans .Net 3.5

DataContractJsonSerializer jsonSer = new DataContractJsonSerializer(typeof(List<MyUser>));
List<MyUser> usersList = (List<MyUser>)jsonSer.ReadObject(response);

Après quelques tests, il semblerait que le parser de MS soit le plus rapide. Cependant cette page semble donner plus d’informations concrètes :

La qualité est un voyage

pas une destination.

C’est par ces mots que se termine la conférence Qualité du code source et l’intégration continue des collaborateurs de Xebia. Il est bon de rappeler que la qualité ne peut pas être quelque chose qui s’enclenche en un geste, ni même qu’elle se termine.

Au cours de ma carrière, j’ai souvent été surpris par le peu de qualité fournie sur les projets, tant au niveau du code source que de la documentation. Et ne parlons pas des tests ou de l’intégration continue, concepts encore trop souvent inconnus chez certains éditeurs.

Mais instaurer la qualité sur un projet existant ou dans une société n’est pas chose aisée. Xebia le détaille d’ailleurs très bien sur les dernières diapositives de son exposé.

Pour ma part, je dirais que la plus grosse difficulté n’est pas sur la technique, puisque qu’après tout, si d’autres sociétés le font, tout le monde peut le faire, mais sur les individus et la motivation.

En effet, si les participants au changement ne connaissent pas ces pratiques, ils peuvent douter de leurs biens fondés, de la facilité de mise en place, des gains de productivité et qualité et de l’impact direct sur leur travail.

Imaginez, vous demandez à des développeurs, souvent en place depuis plusieurs années de :

  • changer leur façon de développer, cela pourrait laisser penser qu’ils ne savent pas développer,
  • écrire des tests unitaires et d’intégration, ce qui va leur demander plus de temps, et donc faire baisser leur productivité,
  • suivre leur projet sur un serveur d’intégration et corriger toute erreur en priorité si le cas se présente, ce qui signifie que corriger un serveur de build est plus important qu’une fonctionnalité métier,

Il est clair que si l’on évoque ces trois points, la qualité du code source et l’intégration continue ne semblent pas apporter de productivité aux développements, bien au contraire.

Mais lorsqu’on connait les 3 points suivants, les premiers commentaires semblent bien négligeables, face aux avantages accumulés :

  • Un développeur passe 80% de son temps à lire du code et 20% à en écrire, il a donc tout intérêt à avoir un code lisible et rapidement compréhensible, pour diminuer son temps de lecture et augmenter son temps d’écriture,
  • Les tests permettent d’être informé de la moindre régression dans le code et de modifier à loisirs et sans doute du code existant afin de l’améliorer,
  • Le serveur de build informe, en temps quasi-réel, de l’état du projet et des tests pour l’ensemble des acteurs du projet, afin de corriger une erreur au plus tôt et de ne pas attendre d’être en production pour corriger une faille passée au travers des tests métiers,

Pour une société qui ne maitrise aucun des points cités précédemment, les gains de productivité peuvent atteindre 300%, voire plus si le code est réellement catastrophique ou si l’intégration de nouveaux développeurs est importante. Vous me direz alors, 300%, c’est énorme. En fait à y réfléchir, ces 300% ne sont pas très important, c’est principalement la productivité de départ qui est très faible. Car bien souvent, si vous n’avez pas de qualité du source code ou d’intégration continue, vous empilez les bugs, vous multipliez les copier-coller de peur de modifier l’existant, vous passez votre temps à lire et vérifier une implémentation…

Mais rappelez-vous, pour mettre en place les bons process de développements, le plus important n’est pas la technique, c’est l’accompagnement au changement. Soyez sur d’avoir les bonnes personnes pour vous aider.

Plugin Firefox : Greasefire et Google Fx

Et oui, encore 2 petits plugin firefox. Enfin pas tout à fait. Le premier est un plugin firefox, le second un script greasemonkey. Dans tous les cas cependant, il vous faudra firefox.

Greasefire : Découvrez les scripts GreaseMonkey

Greasefire est un plugin firefox qui permet au fil des sites sur lesquels vous surfez, de vous informer des scripts disponibles pour ceux-ci. Vous pouvez donc surfer normalement et si le site sur lequel vous vous trouvez permet d’utiliser des scripts GreaseMonkey, greasefire vous l’indiquera et vous fournira directement dans Firefox une petite interface pour découvrir le script et l’installer. Un must lorsqu’on souhaite personnaliser son surf.

Affichage des scripts disponibles sur le site courant

Affichage des scripts disponibles sur le site courant

Google Fx : Personnaliser votre recherche Google

Google Fx quant à lui est un script GreaseMonkey, qui vous permet de personnaliser la page de résultat Google afin d’afficher plus que la simple recherche de site proposée par Google. Vous y retrouverez Wikipedia, Google Images, Google Video, des liens vers d’autres moteurs de recherche, triés par catégorie, filtrable sur le titre, le contenu, la date… Un vrai bonheur pour celui qui souhaite voir organiser ses résultats. Mais attention cependant, ce petit script ralentira légèrement l’affichage des résultats. C’est perceptible mais pas réellement gênant.

Affichage de la page de résultat Google avec le script Google Fx

Affichage de la page de résultat Google avec le script Google Fx

Pour la forme, je vous rappelle mes propres scripts GreaseMonkey :

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.

Dette technique, capacité et volonté de la réduire

J’ai lu dernièrement un article très intéressant parlant de la dette technique d’une application sur le blog de Claude Aubry :

Ces deux liens donnent une définition plutôt claire de la dette technique et des moyens de la reconnaitre.

Je me permets cependant de compléter ces articles, puisque je suis actuellement dans un cas similaire où j’ai pour mission d’améliorer la qualité et la productivité d’un projet qui supporte une dette technique particulièrement importante.

S’il y a dette technique sur un projet, l’équipe projet ne sera pas à même de la reconnaitre, sinon celle-ci n’aurait pas de dette technique (ou alors minime) à moins d’avoir un éclair de génie et de se dire, « Mais nous avons une grosse dette technique !!! ». Sur le projet que j’encadre actuellement, les développeurs n’ont absolument aucune conscience de la mauvaise qualité des développements et considèrent que les difficultés qu’ils rencontrent sont essentiellement dû à l’environnement particulier de développement (du javascript sur un serveur NetSuite). Le code n’est pas formaté, n’a aucune convention de nommage, ne réutilise pas ces composants, et pire les développeurs font du copier-coller de code à outrance, car ils ne veulent pas casser du code existant de peur d’engendrer des bugs en série. Et bien évidemment, ils ne connaissent pas les tests unitaires et d’intégration. Dans ces conditions, comment voulez-vous que cette équipe soit à même de reconnaitre la dette technique de son projet ?

Capacité à voir la dette technique

Pour reconnaitre la dette technique d’un projet, il est nécessaire de faire appel à une personne extérieure au projet. Cette personne peut être de la même entreprise, mais si tous les projets sont fondés sur les mêmes principes (pas de formatage, pas de convention de nommage, pas de réutilisation de code et pas de tests unitaires), alors il est préférable de faire appel à une personne extérieure, nouvellement embauchée ou intervenant extérieur.

Cette personne devra avoir les capacités techniques et fonctionnelles nécessaires à l’acquisition des bases d’un projet mal ficelé (autant dire de très bonnes compétences) et comprendre ce qui a amené les développeurs à se retrouver dans une telle situation. Compétences et/ou connaissances techniques insuffisantes, pression du business pour avancer toujours plus vite sans réfléchir sur ses actes pour réorganiser le projet au fur et à mesure de son accroissement… Cette personne devra également avoir de gros talents de persuasion et de négociation pour que les développeurs eux-mêmes reconnaissent que quelque chose doit être fait. En effet une personne extérieure au projet et plus spécialement extérieure à l’entreprise aura toujours plus de mal à convaincre, surtout si elle doit faire les preuves de ses capacités.

Mais le plus important n’est pas de reconnaitre cette dette technique, de la faire reconnaitre aux développeurs ou de trouver une solution afin de la réduire.

Volonté à réduire la dette technique

En effet, une fois les premiers acteurs du projet acquis, il va vous falloir convaincre les décideurs, c’est à dire le métier, qu’il y a une grosse dette technique (qu’ils n’ont jamais vu d’ailleurs) que celle-ci est pénalisante pour le projet et que réduire cette dette technique va permettre d’accroitre la productivité par 2 voire 3 fois.

Mais surtout il va falloir leur expliquer que pour combler cette dette technique, vous allez devoir pénaliser la production pendant une période plus ou moins courte (3 mois dans mon cas, mais la dette technique est vraiment très importante) afin de mettre en place un process de développement et/ou une architecture digne de ce nom. Et c’est sur ce dernier point que vous allez rencontrer les plus grosses difficultés.

Rien ne garantit en effet que vous aurez les gains de productivité attendus, qui paraissent tout de même extraordinaire. Le business est bien évidemment dans une phase critique et réduire les développements est inimaginable. Alors vous allez expliquer et négocier, mais si le business a réellement besoin de ces développements, vous pouvez être sur que le planning de votre refactoring va s’allonger dans le temps ou être décalé jusqu’à des temps plus sereins (ce qui d’après mon expérience existe rarement).

Bonne chance pour réussir sur ce dernier point.

PS : La décision de mon example sera prise dans les jours prochains, nous verrons ce qu’en aura décidé le business. (Je crains le pire).

%d blogueurs aiment cette page :