Recrutement et rétention d’éducateurs en milieu rural

La qualité de l'enseignant est considérée comme un élément clé de la réussite scolaire des élèves, or recruter et retenir des éducateurs de qualité dans les milieux ruraux victimes d'éloignement et de pauvreté est un challenge. L'objet de ce billet est de synthétiser des éléments de la littérature académique abordant les difficultés de recrutement et de rétention d'éducateurs en milieu rural. Afin de se faire une idée plus claire de l'ampleur du défi et partager des expériences pour inspirer une action et des choix efficaces. 

Différentes études relatent des difficultés auxquelles font face les éducateurs en milieu rural (Sargent & Hannum, 2005) (Collins,1999) (Howley & Howley, B., 2005). Elles peuvent aussi bien être d'ordre professionnel mais aussi personnel et social, elles sont liées à :

  1. L'éloignement de leur lieu d'origine 
  2. La situation de l'enseignant: le fait d'être plus jeune, d'être male, d'être célibataire, d'être plus qualifié réduisent la satisfaction des éducteurs en milieu rural.
  3. L'isolation, et le manque d'interaction avec les collègues, accentuée par le décalage culturel avec la communauté locale (Sargent & Hannum, 2005) et le manque de moyens de transport et de communications (Sargent & Hannum, 2005)(Howley & Howley, B., 2005)
  4. La charge de travail, typiquement dans le cas de classes multi-niveau, surtout dans les cas ou des préparations ou taches spécifiques doivent être réalisées hors temps scolaires.
  5. La question du salaire est un grand élément d'insatisfaction qui est accentué en milieu rural par le coût élevé de la vie et par le manque d'opportunité de travail complémentaire comme les cours de soutien.
  6. Manque de moyens et de ressources de l'école.
  7. Difficulté de trouver un compagnon pour les célibataires.

Il ressort de la revue de littérature que ces difficultés sont rencontrées aussi bien dans les pays en développement que dans les pays développés, bien que l'acuité des problèmes diffère d'un milieu à l'autre. Ainsi, dans les pays en développement, le problème peut être accentué par une vie rurale plus dure, mais dans les payes développés un défi supplémentaire provient de l'abondance d'opportunités plus intéressantes en ville.

En contre partie, certains éléments positifs du travail en milieux rural que les éducateurs apprécient sont selon (Collins,1999):

  1. Meilleur dicipline des enfants 
  2. Plus de liberté de décision et d'action de l'éducateur, notamment la prise en compte de ses remarques, retours dans le choix de l'école sont importants. 
  3. Taille de classe plus petite (le cas échéant) 
  4. Charge réduite de travail (le cas échéant) 

En plus de ces points, des points plus généraux comme les opportunités de développement professionnel, de formation, La proximité du village d'origine  … sont importants.

(Collins,1999) indique que l'une des approches intéressantes pour recruter et retenir les enseignants dans ces milieux ruraux est le "grow-your-own", c'est à dire encourager les étudiants de communautés rurales à devenir enseignant dans leur propre village. Le travail commence alors au niveau du lycée par identifier les candidats ayant les bonnes compétences pour les motiver à envisager une carrière d'enseignant rural. Ainsi le club "Future Teachers America" encourrage les jeunes étudiants à envisager un carrière d'enseignant dans leur village natal après leur diplôme.

Afin d'encourrager les enseignants à s'installer dans le milieu rurale, des incentives importantes sont mises en place, comme :

  1. Primes et avantages salariaux  (Argentine : 80% du salaire de base, Nepal : 100% du salaire de base, Philippine : 25%, en Costa Rica, Egypte, Guyane, Honduras, Jamaique, Lybie,  Mexique, Venezuella)
  2. Formation spécifique (Bangladesh, Colombie, Mexique, Nicaragua, Venezuella)
  3. Avantage sur les retraites (Costa Rica)
  4. Avantages sur la carrière : Accélération de l'avancement, choix d'affectation … (Egypte, Guyane, Honduras)
  5. Logement offert, accès à la propriété (Iraq, Mexique, Pakistan: foyer pour femmes, Sierra Leone, Senegal, Syrie, Zimbabwe )
  6. Création de réseaux d'enseignants et opportunités de rencontre et échange (Mali et autres).

Selon (Howley & Howley, B., 2005), bien que certaines de ces mesures soient bien conçues en réponse à des besoins identifiés des éducateurs et en fonction des contextes des pays, l'efficacité de ces mesures reste fondée sur des hypothèses théoriques sur le comportement et les priorités de l'éducateur qui ne sont pas prouvées empiriquement. 

D'autres pays, en prise avec ces difficultés ont aussi recours à des stratégies différentes comme :

  1. Le recrutement d'enseignants locaux même moins qualifiés (Sargent & Hannum, 2005)
  2. Une prime par élève pour les initiatives d'écoles privées rurales (Collins,1999), il peut s'agir de jeunes femmes du village qui enseignent,  des fois chez elles, quelques enfants pour une somme modique.

Au delà de ces mesures, il semble selon (Collins,1999) qu'une forte implication dans la vie scolaire et culturelle de la communauté cible contribue à augmenter les chances de rester. Certains enseignants de milieu rural peuvent aussi maintenir une double activité d'enseignement et de travail de la terre. Même si l'expérience peut être éprouvante, leur niveau d'éducation leur permet de s'améliorer dans leur pratique.

En synthèses, les difficultés rencontrées par les enseignants en milieu rural sont réelles et multiples, ce qui rend leur recrutement et rétention plus délicats. En réponse à ses difficultés des approches d'encouragement tout aussi diverses ont été mises en place, aussi bien que des approches d'accompagnement à plus long terme pour développer au sein de la communauté même la ressource à même de prendre en charge la mission d'enseignement. Pour la suite, cette revue demande certainement à être complétée par une revue des études empiriques sur l'efficacité des différentes approches.

Lecture dans « Hooked » : La démarche pour rendre accros des Appli Smartphone

La psychologie de la dépendance, appliquée aux Applis

Être « accroc » a son téléphone est ce qui nous prend des fois d’ouvrir spontanément son téléphone et passer y plusieurs minutes sans y être invités ou avoir un objectif précis. Ou comme dit l’auteur, c’est ce qui conduit certains à regarder leur Smartphone le matin avant de dire bonjour à leurs bien-aimés.

Réussir à mettre l’utilisateur dans cet état est pour les éditeurs d’application un Graal procurant divers avantages dont la fidélité et la propension plus élevée à payer des services. Ce livre analyse cet état de dépendance vis à vis des applications en faisant référence à des recherches en psychologie, ethnologie … pour aller chercher au plus profond de la psychologie humaine et de ses prédispositions génétiques comment le rendre accroc.

Se voulant comme guide pour les Startup Technologiques, le livre définit et détaille un modèle simple appelé le « Hook Model » (Le modèle du crochet ou de l’hameçon)  qui est un cycle d’activité sensé faire naitre le comportement Accroc chez l’utilisateur. Il montre ainsi plusieurs exemple sur comment 7des applications et des jeux vidéos sont conçus pour rendre accroc et comment nous tombons dans le piège. Reconnaissant que ll’approche est à limite entre le Design et la Manipulation, l’auteur propose une chapitre pour pour réfléchir sur l’éthique de la démarche.

Ce livre peut se lire sous l’angle d’apprendre comment concevoir des applications Smartphone qui rendent accroc, mais il est plus riche à lire sous un autre angle : Celui de mieux nous connaitre et connaître comment, inconsciemment, nous interagissons avec la technologies et nous développons de nouvelles habitudes. A nous d’en faire des habitudes positives ou négatives. 

Le Modèle de l’Hameçon (Hook Model)

Naturellement, certains déclencheurs provoquent des réactions de notre part : Quand le téléphone sonne nous régissons en répondant à l’appel. Ce genre de déclancheurs sont appelés des déclencheurs externes  (external Triggers). 

Les entreprises qui souhaitent rendre une application addictive cherchent à associer l’utilisation de leur application à déclancheurs internes, souvent inconsients. Par exemple:

Crainte d’oublier une tache ou une idée     Noter dans Evernote  
Peur de laisser fuir l’instant présent  Prendre une photo instagram
Besoin de lien social
Ouvrir facebook

Le modèle de l’hameçon est un cycle en 4 etapes qu’une application va faire parcourir à l’utilisateur un certain nombre de fois pour associer le déclencheur interne voulu à l’utilisation de l’application, comme une sorte d’entrainement  C’est étapes sont : 

  1. Tout d’abord le déclencheur qui est en un premier temps externe : sonnerie, reception d’e-mail … Le but étant qu’il devienne interne à un moment. Le livre donne l’exemple de cette application de gestion de tâches qui détecte les réuni nos de l’utilisateur dans son agenda. Elle lui envoie, en fin de réunion un message pour lui proposer de notre ses idées et tâches. Pourquoi ? Parce que, en fin d’une réunion riche on sent le besoin d’organiser des tâches et des idées, avec une crainte de rater des points importants. C’est cette émotion que l’éditeur de l:’application veut connecter à son application. Au bout d’un certain nombre de répétition l’utilisateur sera conditionné à ouvrir l’application à chaque fois qu’il se sent confus.
  2. Ensuite viens le temps de l’action.
  3. Ensuite l’action donne lieu à une récompense (Reward ). Cette partie se base sur les études menées en neurologie et psychologie sur l’addiction, notamment aux jeux d’argent. En résumé. Ce qui provoque l’efusion d’hormones du plaisir dans le cerveau n’est pas l’obtention d’un objet désiré mais l’attente impatiente de cet objet. Provoquer de façon reccurente une telle sensation crée un comportement addictif. Si l’action donnait lieu en permanence à la même récompense, l’utilisateur s’habitue et n’a plus cette attente de la récompense. Par contre il suffit que cette récompense soit rendue aléatoire pour que le comportement addictif commence à se mettre en place. Par exemple :  quand on ouvre sa boîte mail on ne sait pas combien de nouveaux mails on a, qui nous a écrit . ..
  4. Ensuite vientviens la phase d’investissement

Pour boucler la boucle un nouveau déclencheur doit amener l’utilisateur refaire un cycle action/recompense/investissement . 

Affinity Estimating : Une réunion structurée pour estimer les tailles de User Story en projet Agile

affinitye

En projet Agile, toute la planification se base sur l’estimation de la taille des User Story. Par ailleurs, la construction d’itérations équilibrées nécessite d’avoir des Story de taille suffisement petite. Quand le Product Backlog contient plusieurs dizaines voir quelques centaines de Story, estimer ces Story peut prendre un temps conséquent pour l’équipe. L’Affinity Estimating est une réunion structurée qui peut permettre, dans l’espace de 2 ou 3 heures de définir les tailles des Story d’un backlog de taille conséquente.

Qui doit participer ?

L’équipe, le Coach ainsi que le Product Owner et d’éventuels utilisateurs ou parties prenantes doivent être présentes. Les personnes présente du coté du Product Owner doivent connaître les Product Backlog suffisamment pour pouvoir donner à l’équipe les détails nécessaires.

Quelle durée ?

Une durée entre 2 à 3 heures doit être prévue.

Autres préparatifs

Les User Story du Product Backlog doivent être disponibles sous forme de cartes que l’on peut accrocher et déplacer sur un mur ou un tableau. Sur le tableau ou le mur de travail, une extrémité est marquée « Petite Story », et l’autre « Grande Story », de façon à ce que l’équipe identifie l’ordre dans lequel les Story sont sensées être triées. Par example, de gauche à droite de la plus petite à la plus grande.

Les étapes de la réunion

Chapter 1. Etape 1 : Classification silencieuse

Le Product Owner fournit à l’équipe le Product Backlog par Packet à l’équipe. Les membres de l’équipes vont placer et déplacer les Story sur le mur une à une dans l’ordre de taille. Pendant cette exercice l’équipe ne discute pas entre elle, cependant elle peut obtenir de la part du Prodcut Owner ou des utilisateurs les clarifications nécessaires sur les Story. Cette étape se termine quand plus personne n’a envie de bouger des Story. Elle peut aussi être « Time-boxée », c’est à dire avoir une durée maximale pré-determinée, afin de maîtriser le temps de réunion. Une telle timebox peut être par exemple d’une heure.

Chapter 2. Etape 2 : Discussion de l’équipe

A cette étape, chaque membre de l’équipe peux changer l’ordre des Story sur le tableau mais doit pour cela en discuter et le justifier auprès de ses collègues. Cette étape se termine quand plus personne n’a envie de bouger des Story.

Chapter 3. Etape 3 : Mise en boite

Des colonnes sont tracées sur le tableau pour grouper les User Story par taille, chaque groupe ainsi crée contient les Story de la même taille dans l’échelle. L’échelle est celle définie par l’équipe, classiquement :

  • La suite de fibonacci : 1; 2; 3; 5; 8; 13 …
  • Les tailles : XS, S, M, L, XL
  • Deux puissance N : 2, 4, 8, 16 …

Chapter 4. Etape 4 : Intervention du Product Owner et utilisateurs

L’équipe peut prendre une pause pendant que le Product Owner et autres utilisateurs présents marquent les Story dont il souhaitent rediscuter l’estimation avec une marque ou une couleur particulière.

Chapter 5. Etape 5 : Discussion avec le Product Owner

L’équipe et le Product Owner se concentrent sur les Story les plus prioritaires pour affiner ou confirmer la première estimation de taille.

Finalisation

Au bout de cette étapes les Stories du Product Product backlog on été triées et ont une taille associée. Certaines peuvent rester trop floues pour être estimées, elles nécessiteront par exemple un « Spike », c’est à dire une étude exploratoire de 1 ou 2 jours pendant une itération, afin de lever les incertitudes et donner une estimation. D’autres seront d’une taille trop grosses pour être incluse dans une itération et devront être détaillées par le Product Backlog en plusieurs « Story » plus petites.

Introduction à Running Lean : une méthode pour lancer sa Startup

Il existe plusieurs guides du type « comment faire une étude de marché », pour les Startups ces méthodes sont inadaptées et se transforment rapidement en méthode pour produire de la paprasse pour faire plaisir aux partenaires et investisseurs.
Les méthodes du Lean Startup et Running Lean en particulier se positionnent à l’opposé : c’est des démarches spécifiquement adaptées aux Startups conscientes que leur existence se justifie principalement par leur capacité à apporter des réponses pertinentes à des problèmes que vivent leurs clients.

Running Lean

Basée sur les pratiques du Lean Startup, la méthode Running Lean a été inventée et développée par Ash Maurya. Alors que les méthodes d’étude de marché pré-supposent que le produit est déjà défini, Running Lean met les entrepreneurs dans une démarche d’apprentissage qui développe leur produit en parallèle du développement de leur connaissance du marché.

Le challenge d’une startup

Le succès selon Running Lean est de :

« Réussir à trouver un business qui fonctionne avant d’épuiser ses ressource »

Or l’e-commerce existait bien avant Amazon, le webmail bien avant Gmail et les réseaux sociaux bien avant Facebook ce n’est donc ni la technologie ni l’idée qui fait le succès d’une startup mais autre chose.
Appliquer Running Lean commence donc par se rendre compte de cette réalité et de se mettre à la recherche de ce « business qui fonctionne ».

Tout entrepreneur honnête est dès le départ convaincu qu’il a une bonne solution, avantageuse pour ses utilisateurs, mais ceci n’est malheureusement pas la condition d’un « business qui fonctionne ». La condition d’un « business qui fonctionne » est que suffisamment d’utilisateurs soient prêts à payer un prix convenable pour la solution proposée, cela nécessite que la solution résolve un problème qui « compte » pour l’utilisateur. D’ou la première Phase du développement d’une startup : le Problem / Solution fit.

Les phases de développement d’une startup selon Running Lean

La vie d’une Startup est découpée en 3 phases, à chaque phase l’entrepreneur concentre ses efforts sur un aspect différent de son entreprise :

  • Phase 1, « Problem/Solution fit » : La correspondance entre la solution qu’on souhaite apporter et les problèmes que vivent les clients supposés : est-ce que ce qu’on propose permet aux utilisateurs de résoudre un problème qui compte pour eux ?
  • Phase 2, « Product/Market fit » : La correspondance entre le produit et le marché : mes clients sont il prêts à utiliser ma solution dans des conditions financières acceptables pour moi ?. Lors de cette phase on cherche notamment à découvrir à quel point les utilisateurs sont prêts à payer un prix pour la solution.
  • Phase 3, « Scaling »: Le développement, c’est à dire mettre en place le nécessaire pour « vendre la solution en masse ».

Par exemple : Les méthodes d’étude de marché se concentrent sur des études quantitatives. Pour Running Lean, cette activité n’est pertinente qu’en fin de Phase 2 et en préparation de la Phase 3: il est trop risqué d’investir du temps et de l’argent sur des études de ce type avant d’avoir muri la reflexion sur la pertinence de sa solution et la viabilité de son produit.

La démarche d’apprentissage continu

80% des produits nouveaux échouent. Running Lean se base donc sur le principe que l’on va forcement se tromper au départ, de fait « quit a se tromper, autant se tromper les plutôt possible ». Aussi une démarche concrète de test est systématiquement présente à chaque étape :

  1. On écrit ses idées et hypothèses (en moins de 20 minutes en général)
  2. On identifie parmi ces point ce qui est flou ou simple supposition.
  3. On met en place le nécessaire pour le tester.
  4. On reboucle sur l’étape 1.

Pour permettre de rapidement décrire les aspects clé des idées de produit, Ash Maurya a conçu un tableau dérivé du Business Model Canvas qu’il a appelé Lean Canvas. Sur le lean canvas les aspects aussi bien stratégiques, techniques que commerciaux sont notés et en fonction de la Phase de développement de la startup, les tests se concentrerons certaines cases plutôt que d’autres.

Un avis sur la méthode

Il ne faut pas se tromper : le succès ne dépends pas d’une méthode, aussi rigoureux soit-on à l’appliquer, en contre partie, le succès se donne rarement à ceux qui ne se remettent pas en question et qui ne se mettent pas en posture d’apprendre de l’expérience des autres. Donc comme toujours : il faut lire le livre, il y a des choses intéressantes, se retrousser les manches, et tracer son propre chemin.

Les 3 symptômes des méthodes de gestion de projet inadaptées

Un outil de gestion de projet doit rester pour les membres de l’équipe un outil, et ne doit surtout pas devenir un fardeau. Bien souvent, ce n’est pas le cas et les équipes elles-mêmes ont du mal à diagnostiquer la situation. Ci dessous quelques signaux avant-courreurs qui devraient vous pousser à vous poser des questions sur les outils et méthodes que vous adoptez:

Symptome 1 : la multiplication des listes de taches

Quand l’outil de gestion de projet n’est pas suffisemment utile et pratique, les équipes commencent à multiplier les listes de taches à gauche et à droite. Cela peut se matérialiser entre autres par des liste de taches qui s’échangent dans des mails ou encore des fichiers de tableurs partagées en local ou sur le cloud.

Symptome 2 : la nécessité des relances pour la mise à jour.

La tenue à jour d’un outil se fait au fil de l’eau quand celui-ci est réellement utilisé pour s’organiser individuellement ou communiquer avec les autres. Quand ce n’est pas le cas, il y a toujours besoin de pousser pour tenir à jour le suivi, car c’est bien de cela qu’il s’agit.

Symptome 3 : la taches stagnantes

Personne ne porte d’intérêt réel à la pertinence du contenu d’un outil inutile. Des taches peuvent ainsi rester des mois sans avancer, tout simplement parce que personne ne les a comprises ou prises en compte, et ça ne les dérange pas le moins du monde que l’outil soit pollué d’informations périmée.

La solution qu’apporte Teamwall

S’inspirant des méthodes agiles Teamwall apporte une solution nouvelle en appliquant 3 principes simples :

  1. L’utilité : Un outil existe pour être utile à ses utilisateurs, Teamwall s’est donc concentré sur les fonctions qui aident les utilisateurs à s’organiser et à communiquer. Ainsi, pour s’organiser, chaque utilisateur peut facilement et rapidement identifier et gérer les taches qui le concernent. Et pour communiquer l’équipe partage en temps réel une vision sur l’état du projet et peut mener des standups efficaces même à distance.
  2. Le plaisir : L’utilisation de l’outil doit rester un plaisir : cela passe par le soin apporté à l’aspect visuel, par l’élimination des formulaires complexes au profits de textes simples éventuellement taggés et par des fonctions pratiques comme le partage des fichiers par glisser/déposer et l’interaction en temps réel.
  3. La souplesse : C’est l’utilisateur qui adapte son outil à ses besoin et non pas l’outil qui contraint l’utilisateur à son processus. Ainsi, dans Teamwall les utilisateurs peuvent en quelques clics créer des tableaux de notes privés, les personnaliser puis les partager, les adapter ou les retirer en fonction des besoins. Ce la permet de garder l’outil de gestion en cohérence avec les pratiques de l’équipe et de gérer les multiples micro plans d’action qui accompagnent souvent un projet.

Au Startup Weekend HEC du 2 Mai : ça vaut le coups d’être Startuper « technique »

Le concept est génial, l’ambiance aussi, le slogan : « Not Talks Just Action » est bien appliqué, de l’excellent team-building, reste la motivation pour poursuivre ….

En pratique, c’est un weekend ou on sélectionne le vendredi soir des idées. Puis on forme des équipes qui, accompagnées par des coachs, vont travailler le long du weekend et présenter le dimanche soir devant un jury d’entrepreneurs et d’investisseurs.

C’est un excellent moyen de travailler avec une équipe pendant un week-end pour non pas connaitre les ‘CV des gens’ mais bien voir l’équipe et les personnalités fonctionnent bien ensemble. Ceci dit, pour le coups.

Un point d’étonnement tout de même, pour quelq’un issu d’un milieu « technique » : les personnes capables de mettre en oeuvre, techniquement, les innovations imaginées (dits développeurs dans le StartupWeekend) sont rares et recherchées, contrairement à ce qu’on peut s’imaginer !

Une dernière note : en fin de partie, les projets qui ont eu les meilleures places du jury ont finalement été des projets portés par des « développeurs » et qui avaient un certain avancement technique concrêt … à méditer …

Gantt Vs. Tableau de Notes ou les fausses prévisons Vs. le vrai état du présent

Le gantt représente une réalité projetée. Dans les projets à forte composante d’ingénieure comme l’informatique, on sait que cette prévision sera fausse, cela n’empêchera pas ceux qui regardent le planning de l’utiliser pour s’organiser et construire des stratégies.
Le tableau de note se concentre sur la représentation de la réalité présente avec le plus de précision possible : qu’avons nous fait, que sommes nous en train de faire que nous reste-t-il à faire.

On peut reprocher au tableau de notes de ne pas donner par lui même une projection du futur, la question est : vaut-il mieux avoir une fausse prévision ou un vrai état de la situation présente ? Pour les équipes elle même c’est plus le présent qui est important, pour les partenaires c’est plus la projection du futur qui est importante.

… Plutôt que de faire représenter le processus type par des spécialistes et ensuite de le faire exécuter aux personnes sur le terrain, Kanban s’appuie sur ceux qui font le travail pour visualiser la situation actuelle. à lire ici

Chronique d’optimisation : Réduction de 2/3 du temps de déploiement sur JBoss AS 6

En ajoutant un nouveau composant à une application J2EE, j’ai vu le temps de déploiement se multiplier par plus que 3. Bien que cela n’aie pas beaucoups d’importance sur un environnement de production, cela est critique dans un environnement de développement :

  1. Perte de temps : si on déploie 5 fois par heure et avec 2 minutes par déploiement, c’est plus d’une heure de travail perdue par jour.
  2. Perte de perfomance : La Rupture du Flux mental due au déploiement lent réduit d’autant l’efficacité du développeur.
  3. Perte de qualité : La tendance qu’on aura alors à déployer moins va faire qu’on réalisera moins de test, qu’on auras moins tendance à améliorer ou optimiser le code …

Mais que se passe-t-il donc ? Le threaddump nous dira

En regardant les logs, je voyais bien qu’au déploiement l’ancienne version d’application était « dé-déployée » en quelques secondes puis le JBoss marquait une pause de plusieurs secondes avant de commencer le déploiement de la nouvelle version, sans aucune ligne de log. Que faisait-il donc pendant cette période ?

Pour diagnostiquer cela, la JVM nous permet de faire des ThreadDump, il s’agit d’une photo instantanée de ce qu’est en train de faire la VM.

Il existe pour cela plusieurs outils, j’ai utilisé VisualVM mais il existe d’autres moyens (kill -3 <PID> sous unix, jstack, Outil IBM …)

Thread Dump dans VisualVM

Dans les différents ThreadDump réalisés pendant cette pause de JBoss, j’ai remarqué qu’il y avait un point commun : l’AnnotationScanningPlugin. En effet, depuis J2EE 5 la configuration en XML a été allégée voir rendue optionnelle en faveur d’annotation dans le code. Plutôt propre et pratique comme approche. Seulement voila : cela oblige le serveur d’application à parcourir l’ensemble des classes pour rechercher d’éventuelles annotations.

Optimiser le scan d’annotation sur JBoss

Je vous passe le gros défaut de JBoss : la documentation, toujours difficile de trouver de la documentation de référence à jour. Après quelques recherches, j’ai en effet trouvé que depuis le AS5, un fichier jboss-scanning.xml permet d’optimiser cette étape voir Wiki JBoss ici. Dans mon cas c’était un war, j’ai donc crée jboss-scanning.xml dans le WEB-INF.

Avec le contenu suivant par exemple, JBoss limite le scan au package com.acme.foo mais sans parcourir les classes de com.acme.foo.bar:

<scanning xmlns="urn:jboss:scanning:1.0">
  <path name="WEB-INF/classes">
    <include name="com.acme.foo"/>
    <exclude name="com.acme.foo.bar"/>
  </path>
</scanning>

Et pour empêcher totalement le scan on peut utiliser :

<scanning xmlns="urn:jboss:scanning:1.0">
  <path name="WEB-INF" excluded="true"/>
</scanning>

Pour comprendre le format de ce fichier, la seule documentation que j’ai trouvée est le code source annoté en JAX-B

Résultat : 2/3 de gain de temps au déploiement

Le temps de déploiement a été réduit de 2/3 et un gain en ergonomie et en temps considérable pour l’équipe de développement.

… le Toyota Way a deux piliers : le Respect des Hommes (employés, partenaires ou autres), et l’Amélioration continue… Certes, on peut toujours utiliser quelques outils de lean (ex : kanban) pour réduire des coûts (réduction des les stocks dans le cas du kanban) et présenter les résultats des gains ici et là pour impressionner les collègues, visiteurs, les concurrents, les investisseurs ou la bourse mais cela ne s’appelle pas déployer du lean…

Les deux piliers du Toyota Way : l’Amélioration continue et le Respect des Hommes