Dernière journée de formation sur Scrum chez Valtech...
Et bien, je dois reconnaître avoir particulièrement apprécié cette troisième journée qui fut assez dense ! Tout ou presque a été abordé y compris le Stand-up Meeting, la démo ainsi que la rétrospective en passant par les indicateurs (Sprint Burn-Down Chart et Product Backlog Burn-Up Chart).
J'avoue avoir eu initialement un "a priori" sur la capacité de voir tous les sujets traités d'ici la fin de la formation. Toutefois, même si tous les aspects de la méthode ont été couverts et les ateliers (planning poker, jeux de rôle, mises en situation) bien pensés et instructifs, je pense quand-même que le rythme de la formation est au final assez inégal...
En définitive, je la recommande quand même et cela malgré les problèmes de rythme, car l'animateur a très bien maîtrisé son sujet et a su faire preuve de pédagogie.
Il ne reste plus qu'à appliquer tout cela dès demain :)
mercredi 24 septembre 2014
mardi 23 septembre 2014
Formation Scrum chez Valtech - Retour d'expérience Journée 2
Petit retour d'expérience suite à cette deuxième journée de formation Scrum dispensée par Valtech...
Si la première journée m'avait un peu laissé sur la faim, cette deuxième journée fut un peu plus intéressante. Nous avons eu l'occasion d'aborder :
Le programme demain devrait normalement être chargé et je me demande comment nous pourrons tout voir :
Pour note, nous sommes à la page 80 il me semble du support du cours (et il y en a au moins 250).
Le mot de la fin sera donc demain mais pour le moment, je pense que ces deux premières journées auraient pu largement tenir sur une seule.
Si la première journée m'avait un peu laissé sur la faim, cette deuxième journée fut un peu plus intéressante. Nous avons eu l'occasion d'aborder :
- Les rôles dans Scrum :
- Le Product Owner est un décisionnaire qui a en charge la gestion et l'alimentation du Product Backlog (ce qu'il y a à faire, i.e. le QUOI) en plus de bien veiller à ce que la Vision du produit soit bien partagée par l’ensemble des intervenants. Son rôle est vraiment déterminant pour la réussite du projet d'autant qu'il se doit d'être le plus disponible possible pour la Scrum Team durant toute la réalisation du Sprint ;
- Le Scrum Master a quant à lui la responsabilité de s'assurer que la méthode Scrum est bien respectée par tous. C'est avant tout un facilitateur qui présente des qualités humaines indéniables (empathie, bienveillance) en plus d'être un leader. Toutefois, il ne doit pas être directif ni imposer son point de vue. Il doit avant tout gérer les conflits et aider l'équipe à franchir les obstacles qu'elle rencontre. Son rôle est un rôle à plein temps, du moins au début... Car à plus long terme, lorsque la méthode est parfaitement assimilée, son rôle n'est plus nécessaire. Il peut soit redevenir un membre de la Scrum Team (cf. ci-après) ou devenir coach Scrum qui par conséquent intervient sur un autre projet dans le but d'enseigner la méthode auprès de nouvelles équipes ;
- La Scrum Team est l'équipe en charge de réaliser le produit. Elle commence par planifier et estimer ce qu'il y a à faire en sélectionnant en priorité les User Stories qui présente la plus grande valeur ajoutée pour le Product Owner et qui constituent la Backlog du Sprint. Les User Stories sélectionnées doivent avoir au préalable avoir été validées par le Product Owner et suffisamment spécifiées pour qu'il ne subsiste aucune ambiguïté au début du Sprint. Ces User Stories sont ensuite décomposées en tâches suffisamment fines pour pouvoir tenir dans un Sprint (une itération). Cette décomposition en tâches est réalisée par la Scrum Team (qui apporte donc la réponse au COMMENT) en accord avec le Product Owner. Lorsqu'une User Story comporte trop de points de réalisation, celle-ci devient une Epic (Épopée) qui est elle-même subdivisée en plusieurs sous User Stories ;
- Le principe général de la méthode, i.e. itérative et incrémentale, de deux à quatre semaines avec des mêlées quotidiennes, les points communs et les différences avec Kanban ;
- Les types de réunion suivantes :
- La réunion de planification au début de l'itération ;
- La réunion de clôture en fin d'itération (la démo au client) ;
- La rétrospective ;
- Les ateliers pratiques après les Lego et les avions en papier de la veille :
- Exercice de la NASA qui pose la question des objets à emmener avec soi pour survivre sur la Lune et répondant dans un temps contraint, d'abord tout seul, puis en équipe pour montrer que l'intelligence collective est supérieure à l'intelligence individuelle ;
- Exercice sur la définition de la Vision d'un Produit ;
- Exercice de planification (commencé et qu'on doit terminer demain) ;
Le programme demain devrait normalement être chargé et je me demande comment nous pourrons tout voir :
- Terminer l'expérience de la planification en début de Sprint ;
- Le stand-up meeting ;
- La démo au client en fin d'itération;
- La rétrospective ;
- Ce qu'est qu'une entreprise agile ;
Pour note, nous sommes à la page 80 il me semble du support du cours (et il y en a au moins 250).
Le mot de la fin sera donc demain mais pour le moment, je pense que ces deux premières journées auraient pu largement tenir sur une seule.
lundi 22 septembre 2014
Formation Scrum chez Valtech - Retour d'expérience Journée 1
Après quatre ans d'attente, la voici, la fameuse "formation Scrum" !
Dispensée par Valtech, c'est en ce beau lundi 22 septembre 2014 que j'ai pu assister à la première journée d'une formation de trois jours sur la méthode éponyme "Scrum".
Parmi les points positifs, je retiens de cette première journée :
Par exemple, à la fin de cette première journée, ni les concepts de "Backlog", "User Story", "Epic" et encore moins les "Stand-Up Meeting" n'ont été abordés, ni même présentés ! Du coup, je m'interroge quant au contenu des deux autres journées qui j'espère seront plus "fournies" que la première.
Pour finir, je dois vous partager un élément m'a gêné dans la présentation de la méthode à savoir que "Scrum" permettrait un "rythme soutenu" contrairement à la méthode en V. Certes, mais je préfère parler de "rythme durable" (ok, on est là pour bosser et atteindre une certaine vélocité à condition que cette vélocité reste "raisonnable") car j'ai l'impression que là-aussi le marketing est passé par-là et que son effet a été de faire croire "qu'avec Scrum, on développe plus vite et mieux !". Je ne pense pas en savoir plus que le formateur, et peut-être ai-je mal compris la méthode mais c'est à mon avis une erreur que de penser cela ! Quand on parle de rythme soutenu, cela laisse sous-entendre que la charge de travail demandée peut être plus importante avec le risque par conséquent d'avoir besoin, pour les membres de l'équipe, de disposer de longues périodes de transitions pour recharger les batteries "entre deux itérations difficiles". Pour l'avoir vécu en 2012, cela a conduit à un effet dévastateur allant jusqu'à une certaine démotivation de l'ensemble de l'équipe à l'époque... qui du coup ne voulait plus revivre ça...
Voilà pour aujourd'hui... La suite au prochain épisode :)
Dispensée par Valtech, c'est en ce beau lundi 22 septembre 2014 que j'ai pu assister à la première journée d'une formation de trois jours sur la méthode éponyme "Scrum".
Parmi les points positifs, je retiens de cette première journée :
- un support de cours assez complet et intéressant ;
- le "serious game" apprendre la méthode Scrum en jouant aux Lego :)
- des locaux agréables et un accueil chaleureux (machine à café gratuite et viennoiseries à volonté) ;
Par exemple, à la fin de cette première journée, ni les concepts de "Backlog", "User Story", "Epic" et encore moins les "Stand-Up Meeting" n'ont été abordés, ni même présentés ! Du coup, je m'interroge quant au contenu des deux autres journées qui j'espère seront plus "fournies" que la première.
Pour finir, je dois vous partager un élément m'a gêné dans la présentation de la méthode à savoir que "Scrum" permettrait un "rythme soutenu" contrairement à la méthode en V. Certes, mais je préfère parler de "rythme durable" (ok, on est là pour bosser et atteindre une certaine vélocité à condition que cette vélocité reste "raisonnable") car j'ai l'impression que là-aussi le marketing est passé par-là et que son effet a été de faire croire "qu'avec Scrum, on développe plus vite et mieux !". Je ne pense pas en savoir plus que le formateur, et peut-être ai-je mal compris la méthode mais c'est à mon avis une erreur que de penser cela ! Quand on parle de rythme soutenu, cela laisse sous-entendre que la charge de travail demandée peut être plus importante avec le risque par conséquent d'avoir besoin, pour les membres de l'équipe, de disposer de longues périodes de transitions pour recharger les batteries "entre deux itérations difficiles". Pour l'avoir vécu en 2012, cela a conduit à un effet dévastateur allant jusqu'à une certaine démotivation de l'ensemble de l'équipe à l'époque... qui du coup ne voulait plus revivre ça...
Voilà pour aujourd'hui... La suite au prochain épisode :)
mercredi 13 août 2014
CDI 1.2 et le scope @javax.inject.Singleton, le mal aimé...
Si vous utilisez CDI a.k.a. Contexts and Dependency Injection for the Java EE Platform, peut-être utilisez-vous aussi CDI dans un contexte Java SE, i.e. en dehors de tout serveur d’application Java EE.
Le 8 avril 2014 a vu le jour d’une maintenance release pour CDI à savoir la version 1.2.
Cette version n’est actuellement pas fournie par un serveur d’application quelconque, la spécification Java EE 7 s’appuyant sur CDI 1.1 et Java EE 8 devrait quant-à elle s’appuyer sur CDI 2.0.
La documentation de cette nouvelle mouture est disponible à l’URL suivante sur le site de JBoss.
L’objectif premier de cette version est de clarifier certains éléments de la spécification comme le fonctionnement des événements liés au cycle de vie du conteneur. Toutefois, bien que cette version ne semble être qu’intermédiaire, les travaux menés peuvent parfois être déroutant pour ceux qui utilisent le scope @javax.inject.Singleton à ne pas confondre avec l’annotation @javax.ejb.Singleton propre à la spécification EJB 3.1 et +
Et c’est là justement que les choses peuvent déranger car dorénavant, la spécification CDI 1.2, lorsqu’elle adresse des questions liés à des beans @Singleton, il n’est question exclusivement que des beans Singletons EJB !
Ok ! Peut-être que la stratégie à long terme est de ne disposer que d’une seule annotation @Singleton plutôt que d’avoir deux annotations, la première dans le package javax.inject et la deuxième dans javax.ejb.
La question est volontairement un peu provocatrice mais le problème constaté est que dorénavant, tous les beans annotés avec l’annotation @javax.inject.Singleton ne sont plus systèmatiquement chargés par CDI dès lors que le fichier "beans.xml" est présent et que le mode "bean-discovery-mode" est positionné à "annotated".
Dans ce cas, vous avez le droit à une belle IllegalStateException :
Bref, si vous vous retrouvez dans cette situation, il faut alors recréer sa propre annotation, par exemple @Unique (ou appelez-là comme vous voulez) en la faisant hériter de @Stereotype et @javax.inject.Singleton :
Vous trouverez plus d'explications, une implémentation et quelques tests unitaires sur mon GitHub ou en accédant à la documentation générée à partir du plugin Maven Site 3.3.
J'espère qu'il y aura une forme d'alignement quelconque entre CDI et l'annotation @javax.inject.Singleton d'ici la version 2.0 de la spéc :)
Le 8 avril 2014 a vu le jour d’une maintenance release pour CDI à savoir la version 1.2.
Cette version n’est actuellement pas fournie par un serveur d’application quelconque, la spécification Java EE 7 s’appuyant sur CDI 1.1 et Java EE 8 devrait quant-à elle s’appuyer sur CDI 2.0.
CDI 1.2
La documentation de cette nouvelle mouture est disponible à l’URL suivante sur le site de JBoss.
L’objectif premier de cette version est de clarifier certains éléments de la spécification comme le fonctionnement des événements liés au cycle de vie du conteneur. Toutefois, bien que cette version ne semble être qu’intermédiaire, les travaux menés peuvent parfois être déroutant pour ceux qui utilisent le scope @javax.inject.Singleton à ne pas confondre avec l’annotation @javax.ejb.Singleton propre à la spécification EJB 3.1 et +
Et c’est là justement que les choses peuvent déranger car dorénavant, la spécification CDI 1.2, lorsqu’elle adresse des questions liés à des beans @Singleton, il n’est question exclusivement que des beans Singletons EJB !
Ok ! Peut-être que la stratégie à long terme est de ne disposer que d’une seule annotation @Singleton plutôt que d’avoir deux annotations, la première dans le package javax.inject et la deuxième dans javax.ejb.
Le Singleton : mal aimé du monde Java SE ?
La question est volontairement un peu provocatrice mais le problème constaté est que dorénavant, tous les beans annotés avec l’annotation @javax.inject.Singleton ne sont plus systèmatiquement chargés par CDI dès lors que le fichier "beans.xml" est présent et que le mode "bean-discovery-mode" est positionné à "annotated".
Dans ce cas, vous avez le droit à une belle IllegalStateException :
Bref, si vous vous retrouvez dans cette situation, il faut alors recréer sa propre annotation, par exemple @Unique (ou appelez-là comme vous voulez) en la faisant hériter de @Stereotype et @javax.inject.Singleton :
Vous trouverez plus d'explications, une implémentation et quelques tests unitaires sur mon GitHub ou en accédant à la documentation générée à partir du plugin Maven Site 3.3.
J'espère qu'il y aura une forme d'alignement quelconque entre CDI et l'annotation @javax.inject.Singleton d'ici la version 2.0 de la spéc :)
dimanche 30 mars 2014
Pourquoi ai-je voulu faire partie de la liste http://jesuisundeveloppeur.io/
Pourquoi ai-je voulu faire partie de la liste je suis un développeur ?
Pour deux raisons essentiellement.
La première pour réagir au rapport de Tariq Krim remis à Fleur Pellerin, il y a quelques jours. Faire la promotion des développeurs et les présenter comme un atout pour la France, c'est bien. Il s'agit même d'une très belle initiative, car pour une fois, le développement logiciel est présenté comme un levier et non comme une contrainte. En dresser la liste du top 100 est en revanche une vision trop réductrice à mon humble avis. M. Krim ne pensait pas à mal, d'autant qu'il reconnaît lui-même la subjectivité de la dite-liste, mais dans ce cas, quel est l'objectif recherché ? Si elle permet en effet de valoriser les travaux de nombreux développeurs Français, elle n'est pas représentative de toute la population existante de développeurs, codeurs, architectes, programmeurs. J'ai pour ma part, eu la chance de rencontrer certaines personnes dans ma vie professionnelle, qui ont fait de moi ce que je suis aujourd'hui : un amoureux du code.
Ces développeurs sont pourtant anonymes, n'ont pas de blog ou bien n'ont pas le temps de les maintenir car trop occupés déjà à faire leur travail avec passion et professionnalisme. Je pense à Stéphane dans le Pas-de-Calais, mon mentor, autodidacte et pourtant meilleur programmeur que j'ai connu : il avait ce don pour écrire des algorithmes sortis des sentiers battus, plus performants, plus courts et plus élégants aussi (oui, le code peut être beau !). Il y a aussi Laurent, mon professeur en DESS (il y a donc plus de dix de cela) qui m'a ouvert les yeux et surtout l'esprit sur une autre vision du métier de développeur. Il m'a donné l'envie de créer, d'innover, de réfléchir à ce que je fais : pourquoi programmer comme ça, pourquoi tel pattern, est-ce que telle fonction peut être implémentée autrement, etc. Ils sont inconnus, et il y en a plein d'autres que nous connaissons tous.
A la place d'une liste, j'aurais souhaité que le rapport aille plus loin dans les recommandations car 6 mesures proposées seulement, même si certaines sont des plus pertinentes, c'est un peu décevant.
Pour rappel, les 6 mesures en question sont :
Et je suis un peu déçu car à la place de ces 6 mesures et d'une liste de 100 développeurs (- pourquoi pas mais je ne comprends pas à quoi cette dernière peut bien servir... -), j'aurais préféré plus de recommandations encore, un rapport peut-être un peu plus percutant telle qu'une proposition de réforme des SSII/ESN qui reposent toutes sur un modèle économique aux conséquences dévastatrices car elles ne participent pas à la promotion du rôle du développement logiciel en tant que levier. Le mode de fonctionnement de nos SSII limite la possibilité de doter notre pays d'une réserve de compétences pointues car expérimentées donc plus chères et par conséquent plus difficiles à placer chez les clients. Car ces SSII cherchent avant tout à placer des jeunes sans expérience sur des missions là où il faudrait un développeur sénior ; faire un maximum de profit pour un minimum de coûts. En effet, les SSII sont selon moi une des causes majeures de la mauvaise image du métier de développeur en France.
Enfin, je n'ai pas vu dans le rapport un phénomène inquiétant pour les séniors : celui des développeurs de plus de 35 ans qui veulent continuer à coder et qui, s'ils veulent le faire, ne le peuvent qu'en devenant indépendant. Car à cet âge, il est très difficile de trouver un employeur pour faire du développement logiciel ! C'est un fait !
C'est aussi pour cette deuxième raison que j'ai donc souhaité faire partie de la liste : parce que j'ai 35 ans et que je suis développeur !
Par conséquent cela signifie aux yeux du monde professionnel de l'IT en France, que j'ai raté ma vie de chef de projet !! Et si cela était à refaire, je ferai en sorte d'échouer de la même manière :)
Il n'y a pas longtemps, un chasseur de têtes pour le compte d'une grosse SSII (vous avez ces boîtes d'intérim de luxe !) m'a indiqué "votre profil technique est très intéressant, mais on aurait préféré que vous évoluiez vers un poste de Direction de Projet, avec une compétence commerciale... plus forte". Et bla bla bla...
Serait-ce une gageure que d'aimer vouloir continuer à coder après 35 ans, continuer à apprendre, créer, améliorer ?
Là, où je travaille, mes supérieurs me considèrent comme un geek... Mais pourquoi tant de haine ? Pourquoi faut-il sans cesse essayer de faire entrer les gens dans des cases ? Sommes-nous des marginaux ?
Je voudrais pouvoir espérer qu'il en soit tout autre... Tous les matins, je me lève avec la question suivante : que vais-je apprendre aujourd'hui, et que vais-je partager avec les autres ? Est-ce un crime ? Pourquoi suis-je considéré comme un simple exécutant par ma hiérarchie alors que j'ai un bon retour de la part des utilisateurs (qui sont finalement mes vrais clients) ? Ces derniers sont satisfaits de mon travail, ne me considèrent pas comme un extra-terrestre pour autant. Je comprends leur langage, je m'adapte, et finalement, j'en sais plus sur le fonctionnement de la boîte que mes chefs. Peut-être vous reconnaissez-vous aussi ?
Il existe, je pense, un problème plus général encore dans notre pays qui touchent tous les métiers d'ingénierie : une forme de dédain ou un désintéressement pour tous les métiers à composante technique ou scientifique
Aujourd'hui, nos administrations et autres sociétés du secteur privé sont de plus en plus "managées" (il y a quelques années, on auraient "gérées" mais "managées" est un terme plus hype) par des personnes issues de telle école de commerce ou de marketing qui pourtant, ne connaissent rien au cœur de métier, voire ne veulent pas s'y intéresser. Ces mêmes personnes ne sont malheureusement là avant tout que pour quelques années (3 à 4 ans maximum en général) en pensant que leur carrière a plus de valeur que leurs devoirs. C'est aussi vrai pour des mandats dans certaines administrations publiques ; les présidents ne sont nommés que pour cinq ans en général, ce qui laisse peu de place pour appliquer une stratégie sur le long terme. Difficile dans ces conditions de faire évoluer les mentalités.
Il y a aussi ces "managers" dans certaines directions qui ne veulent pas faire progresser leurs collaborateurs en ne les associant que très peu aux projets cœur de métier de leur Entreprise. En effet, c'est bien connu, on préfère faire appel à des boîtes externes qui ne connaissent pas le métier et qui doivent pourtant rédiger tel cahier des charges à la place de la MOA qui n'a pas le temps pour cela... Et après, on s'étonne de voir que les projets dérapent. Et puis, on fait appel à d'autres consultants pour assurer la réalisation du projet car les informaticiens, eux, qu'ils soient développeurs, DBA ou administrateurs systèmes, ne savent pas travailler correctement...
Combien de chaînes intermédiaires inutiles et coûteuses dans la réalisation d'un projet informatique ? Pourquoi ne pas proposer d'investir dans la gestion de la connaissance et son partage au sein de l'Entreprise, à chercher à limiter la dette technique ? Combien de talents (développeurs ou autres) sont mal ou non utilisés ? Dans le management par le Lean, il s'agit même d'une des 8 formes de gaspillage.
Alors, j'ai une proposition à faire à ces mêmes "managers", si vous voulez vous montrer dignes de ceux que vous gouvernez : accordez-leur plus de confiance, ces gens sont issus du terrain, ils se lèvent le matin pour un idéal, pour faire avancer la boîte, pensent "collaboratif" et non pas "individuel", bref, ils représentent un potentiel non négligeable de "création de valeur"... laissez-les s'exprimer ! Vous n'avez rien à perdre... A moins que...
Et si, au lieu d'externaliser ces personnes, ces informaticiens, ces scientifiques (qui continuent de déserter nos contrées parce qu'il n'y a pas de place pour la recherche), au motif qu'il faille réduire les dépenses dans un contexte de crise économique, on externalisait, à la la place, ces managers, ces strates intermédiaires, qui coûtent cher ? Après tout, quel est leur apport concrètement ? Je le cherche encore...
Pour deux raisons essentiellement.
Un bon rapport certes, qui aurait mérité à être plus percutant
La première pour réagir au rapport de Tariq Krim remis à Fleur Pellerin, il y a quelques jours. Faire la promotion des développeurs et les présenter comme un atout pour la France, c'est bien. Il s'agit même d'une très belle initiative, car pour une fois, le développement logiciel est présenté comme un levier et non comme une contrainte. En dresser la liste du top 100 est en revanche une vision trop réductrice à mon humble avis. M. Krim ne pensait pas à mal, d'autant qu'il reconnaît lui-même la subjectivité de la dite-liste, mais dans ce cas, quel est l'objectif recherché ? Si elle permet en effet de valoriser les travaux de nombreux développeurs Français, elle n'est pas représentative de toute la population existante de développeurs, codeurs, architectes, programmeurs. J'ai pour ma part, eu la chance de rencontrer certaines personnes dans ma vie professionnelle, qui ont fait de moi ce que je suis aujourd'hui : un amoureux du code.
Ces développeurs sont pourtant anonymes, n'ont pas de blog ou bien n'ont pas le temps de les maintenir car trop occupés déjà à faire leur travail avec passion et professionnalisme. Je pense à Stéphane dans le Pas-de-Calais, mon mentor, autodidacte et pourtant meilleur programmeur que j'ai connu : il avait ce don pour écrire des algorithmes sortis des sentiers battus, plus performants, plus courts et plus élégants aussi (oui, le code peut être beau !). Il y a aussi Laurent, mon professeur en DESS (il y a donc plus de dix de cela) qui m'a ouvert les yeux et surtout l'esprit sur une autre vision du métier de développeur. Il m'a donné l'envie de créer, d'innover, de réfléchir à ce que je fais : pourquoi programmer comme ça, pourquoi tel pattern, est-ce que telle fonction peut être implémentée autrement, etc. Ils sont inconnus, et il y en a plein d'autres que nous connaissons tous.
A la place d'une liste, j'aurais souhaité que le rapport aille plus loin dans les recommandations car 6 mesures proposées seulement, même si certaines sont des plus pertinentes, c'est un peu décevant.
Pour rappel, les 6 mesures en question sont :
- Prendre en compte le rôle essentiel des développeurs : Il s'agit du point le plus important à mon avis. Ce qui m'a plu : "L’univers des développeurs bénéficie en France d’une faible reconnaissance. Ils sont souvent considérés comme des exécutants." et "Les développeurs sont dans un angle mort : on ignore leur nombre. On ne sait pas grand chose sur leurs trajectoires, leurs qualifications.". Et c'est malheureusement tout. La mesure ne précise pas comment changer cet état de fait.
- Une feuille de route technologique pour l’État, les ministères et les opérateurs publics : M. Krim présente le phénomène de rupture(s) technologique(s) que nous connaissons - la mobilité, les objets connectés, le cloud et le Big Data - et propose de renforcer les secteurs impactés par ce phénomène comme la santé, l'éducation et l'énergie à l'aide d'une feuille de route à destination des DSI précisant quelques axes technologiques et aussi la mise à disposition de briques logicielles ouvertes, standardisées et réutilisables sur ce qui serait un "Github Français". Sur ce point, et travaillant qui plus est dans le secteur de la santé, je trouve cette mesure des plus pertinentes.
- Promouvoir les développeurs dans l'administration en cessant de considérer les projets de développement logiciel comme "autonomes et non évolutifs" en faisant notamment la promotion des méthodes agiles et en diminuant la "sous-traitance aveugle" aux grosses SSII/ESN et autres prestations coûteuses d'assistance à MOA, qui lorsqu'elles sont invoquées sur des domaines stratégiques, conduisent régulièrement à l'échec des projets IT. Si je suis d'accord sur ce point, je suis plus timoré sur sa conclusion lorsque M. Krim propose "de promouvoir les développeurs aux postes de responsabilité pour la conduite des projets numériques" car tous les bons développeurs ne font pas nécessairement de bons managers. En revanche, il faut que les développeurs, notamment ceux qui travaillent sur le cœur de métier de leur Entreprise soient plus écoutés, et qu'ils soient plus sollicités concernant les choix techniques ; je n'ai que trop connu le nombre de solutions choisies pour des considérations purement marketing sans tenir compte du vrai besoin utilisateur, et cela même au détriment de la valeur ajoutée fonctionnelle.
- Adapter les conditions d’investissement pour soutenir les projets technologiques en octroyant une quote-part de "20% des projets financés en les ouvrant aux startups disruptives". Là, rien à redire, il s'agit d'une proposition qui pourrait faire bouger les lignes.
- Formation des développeurs : L'auteur présente un stock de compétences important mais aussi "des recruteurs qui ont souvent du mal à trouver des candidats adaptés aux postes à pourvoir" et de l'autre côté "des ingénieurs qualifiés à des tâches de techniciens informatiques faute de candidats employables à ce niveau de formation". Le manque de développeurs adaptés aux postes à pourvoir pourrait passer également selon l'auteur par la mise en place d'un "visa de travail pour les développeurs venant en France" . (c'est la 6ème mesure).
Et je suis un peu déçu car à la place de ces 6 mesures et d'une liste de 100 développeurs (- pourquoi pas mais je ne comprends pas à quoi cette dernière peut bien servir... -), j'aurais préféré plus de recommandations encore, un rapport peut-être un peu plus percutant telle qu'une proposition de réforme des SSII/ESN qui reposent toutes sur un modèle économique aux conséquences dévastatrices car elles ne participent pas à la promotion du rôle du développement logiciel en tant que levier. Le mode de fonctionnement de nos SSII limite la possibilité de doter notre pays d'une réserve de compétences pointues car expérimentées donc plus chères et par conséquent plus difficiles à placer chez les clients. Car ces SSII cherchent avant tout à placer des jeunes sans expérience sur des missions là où il faudrait un développeur sénior ; faire un maximum de profit pour un minimum de coûts. En effet, les SSII sont selon moi une des causes majeures de la mauvaise image du métier de développeur en France.
Enfin, je n'ai pas vu dans le rapport un phénomène inquiétant pour les séniors : celui des développeurs de plus de 35 ans qui veulent continuer à coder et qui, s'ils veulent le faire, ne le peuvent qu'en devenant indépendant. Car à cet âge, il est très difficile de trouver un employeur pour faire du développement logiciel ! C'est un fait !
Dénoncer le fait qu'à 35 ans, en France, on n'a plus le droit de coder
C'est aussi pour cette deuxième raison que j'ai donc souhaité faire partie de la liste : parce que j'ai 35 ans et que je suis développeur !
Par conséquent cela signifie aux yeux du monde professionnel de l'IT en France, que j'ai raté ma vie de chef de projet !! Et si cela était à refaire, je ferai en sorte d'échouer de la même manière :)
Il n'y a pas longtemps, un chasseur de têtes pour le compte d'une grosse SSII (vous avez ces boîtes d'intérim de luxe !) m'a indiqué "votre profil technique est très intéressant, mais on aurait préféré que vous évoluiez vers un poste de Direction de Projet, avec une compétence commerciale... plus forte". Et bla bla bla...
Serait-ce une gageure que d'aimer vouloir continuer à coder après 35 ans, continuer à apprendre, créer, améliorer ?
Là, où je travaille, mes supérieurs me considèrent comme un geek... Mais pourquoi tant de haine ? Pourquoi faut-il sans cesse essayer de faire entrer les gens dans des cases ? Sommes-nous des marginaux ?
Je voudrais pouvoir espérer qu'il en soit tout autre... Tous les matins, je me lève avec la question suivante : que vais-je apprendre aujourd'hui, et que vais-je partager avec les autres ? Est-ce un crime ? Pourquoi suis-je considéré comme un simple exécutant par ma hiérarchie alors que j'ai un bon retour de la part des utilisateurs (qui sont finalement mes vrais clients) ? Ces derniers sont satisfaits de mon travail, ne me considèrent pas comme un extra-terrestre pour autant. Je comprends leur langage, je m'adapte, et finalement, j'en sais plus sur le fonctionnement de la boîte que mes chefs. Peut-être vous reconnaissez-vous aussi ?
Il existe, je pense, un problème plus général encore dans notre pays qui touchent tous les métiers d'ingénierie : une forme de dédain ou un désintéressement pour tous les métiers à composante technique ou scientifique
Aujourd'hui, nos administrations et autres sociétés du secteur privé sont de plus en plus "managées" (il y a quelques années, on auraient "gérées" mais "managées" est un terme plus hype) par des personnes issues de telle école de commerce ou de marketing qui pourtant, ne connaissent rien au cœur de métier, voire ne veulent pas s'y intéresser. Ces mêmes personnes ne sont malheureusement là avant tout que pour quelques années (3 à 4 ans maximum en général) en pensant que leur carrière a plus de valeur que leurs devoirs. C'est aussi vrai pour des mandats dans certaines administrations publiques ; les présidents ne sont nommés que pour cinq ans en général, ce qui laisse peu de place pour appliquer une stratégie sur le long terme. Difficile dans ces conditions de faire évoluer les mentalités.
Le non rôle du management intermédiaire
Il y a aussi ces "managers" dans certaines directions qui ne veulent pas faire progresser leurs collaborateurs en ne les associant que très peu aux projets cœur de métier de leur Entreprise. En effet, c'est bien connu, on préfère faire appel à des boîtes externes qui ne connaissent pas le métier et qui doivent pourtant rédiger tel cahier des charges à la place de la MOA qui n'a pas le temps pour cela... Et après, on s'étonne de voir que les projets dérapent. Et puis, on fait appel à d'autres consultants pour assurer la réalisation du projet car les informaticiens, eux, qu'ils soient développeurs, DBA ou administrateurs systèmes, ne savent pas travailler correctement...
Combien de chaînes intermédiaires inutiles et coûteuses dans la réalisation d'un projet informatique ? Pourquoi ne pas proposer d'investir dans la gestion de la connaissance et son partage au sein de l'Entreprise, à chercher à limiter la dette technique ? Combien de talents (développeurs ou autres) sont mal ou non utilisés ? Dans le management par le Lean, il s'agit même d'une des 8 formes de gaspillage.
Alors, j'ai une proposition à faire à ces mêmes "managers", si vous voulez vous montrer dignes de ceux que vous gouvernez : accordez-leur plus de confiance, ces gens sont issus du terrain, ils se lèvent le matin pour un idéal, pour faire avancer la boîte, pensent "collaboratif" et non pas "individuel", bref, ils représentent un potentiel non négligeable de "création de valeur"... laissez-les s'exprimer ! Vous n'avez rien à perdre... A moins que...
Et si, au lieu d'externaliser ces personnes, ces informaticiens, ces scientifiques (qui continuent de déserter nos contrées parce qu'il n'y a pas de place pour la recherche), au motif qu'il faille réduire les dépenses dans un contexte de crise économique, on externalisait, à la la place, ces managers, ces strates intermédiaires, qui coûtent cher ? Après tout, quel est leur apport concrètement ? Je le cherche encore...
dimanche 19 janvier 2014
Camel and (JBoss) WildFly 8.x Integration Testing with Arquillian
It's been a while since I've written anything... Furthermore, it's the first time I write a post in English. So, I'm really sorry for my speech. It's a well-known fact that French people have a catastrophic level foreign language :) So, let's go...
In recent years, a lot of tech have evolved, practices too... In particular, I had the chance to implement a number of agile practices, including TDD a.k.a. Test-Driven Development. TDD is not an easy stuff when you have to create an application implementing databases, mail server and others IT resources, such as legacy systems... because in that event, mocking objects does not really make sense... Furthermore, legacy systems can be integrated by using an EAI, ESB or lightweight integration frameworks. Some of them are very popular like Spring Integration and Apache Camel. But when you have to embed a such framework in an Application Server (JBoss or Glassfish for instance), you may believe things do not go as planned.
Contrary to what you might think, I found this was not as difficult. I wrote a sample that you should checkout on my Github. You can view the code at https://github.com/sydisnet/blog-samples/tree/master/camel-integration.
I hope this can help... This sample embeds a Camel container whose lifecycle is managed by a Singleton EJB. When the singleton starts, a CamelContext is created with a Camel Route connected to an external application. For the purpose of this Use Case, I used Camel Exec Component and Arquillian with WildFly 8.0.0.CR1.
The test is very easy (thanks to Arquillian - my favorite framework this last years). It shows how to create a @Deployment static archive, downloads Camel libs from pom.xml.
Last but not least, don't forget to check your Wildfly Home location in arquillian.xml file.
Have fun :)
In recent years, a lot of tech have evolved, practices too... In particular, I had the chance to implement a number of agile practices, including TDD a.k.a. Test-Driven Development. TDD is not an easy stuff when you have to create an application implementing databases, mail server and others IT resources, such as legacy systems... because in that event, mocking objects does not really make sense... Furthermore, legacy systems can be integrated by using an EAI, ESB or lightweight integration frameworks. Some of them are very popular like Spring Integration and Apache Camel. But when you have to embed a such framework in an Application Server (JBoss or Glassfish for instance), you may believe things do not go as planned.
Contrary to what you might think, I found this was not as difficult. I wrote a sample that you should checkout on my Github. You can view the code at https://github.com/sydisnet/blog-samples/tree/master/camel-integration.
I hope this can help... This sample embeds a Camel container whose lifecycle is managed by a Singleton EJB. When the singleton starts, a CamelContext is created with a Camel Route connected to an external application. For the purpose of this Use Case, I used Camel Exec Component and Arquillian with WildFly 8.0.0.CR1.
The test is very easy (thanks to Arquillian - my favorite framework this last years). It shows how to create a @Deployment static archive, downloads Camel libs from pom.xml.
Last but not least, don't forget to check your Wildfly Home location in arquillian.xml file.
Have fun :)
jeudi 11 novembre 2010
Utiliser Glassfish Embedded pour tester ses EJB 3.1
Depuis la sixième version de Java EE, il est possible de tester ses EJB avec l'API "EJB Embedded Container". Glassfish propose son implémentation intitulée "glassfish-embedded".
Cet article a un double objectif :
1/ Configuration du projet
Dans cet article, j'ai utilisé un projet Maven 2 afin de ne pas être dépendant de quelqu'IDE que ce soit. Les dépendances utilisées sont l'API Java EE 6, JUnit et Glassfsih Embedded (cliquez sur l'image pour agrandir) :
Pour que tout fonctionne, il faut bien entendu configurer les dépôts et les plugins (cliquez sur l'image pour agrandir) :
L'API Java EE 6 propose également certaines mises à jour des API de base fournies avec Java. Aussi, si l'on souhaite disposer de ces mises à jour, il faut configurer un Profile (cliquez sur l'image pour agrandir) :
2/ Création d'un EJB Hello World
Maintenant que notre projet est configuré, passons à l'implémentation de nos EJB. Commençons par un EJB simplissime : un "Hello World !" :
Vous noterez que notre EJB est un simple POJO annoté. En effet, la version 3.1 a considérablement simplifié l'écriture de ces composants. L'annotation @Stateless signifie que notre EJB est sans état. Un tel composant ne maintient pas d'état conversationnel avec l'appelant du bean. Cela signifie qu'une même instance du bean peut servir plusieurs clients (ou appelants).
3/ Ecriture de notre premier test unitaire
Il ne nous reste plus qu'à créer le test unitaire qui va bien :
Quelques explications maintenant. La première chose à faire est de créer un EJBContainer. Pour cela, il est nécessaire de créer une Map contenant toutes les propriétés correspondant à la configuration de notre conteneur :
Remarque sur JNDI :
Parmi les trois paramètres précédents, seul EJBContainer.MODULES est obligatoire.Vous noterez que deux lignes ont été mises en commentaires :
Une fois que notre EJBContainer est créé, il suffit de demander à ce dernier de récupérer le contexte de l'application (variable appContext).
Ensuite, tous les tests (méthodes annotées par @Test) sont exécutés. Le programme se termine lorsque la méthode annotée par @AfterClass est appelée. Dans cette méthode, nous fermons le contexte de l'application, (appContext.close()) et nous arrêtons le conteneur (container.close()).
Enfin, il ne nous reste plus qu'à exécuter notre test unitaire. Mais les choses ne se passent pas comme prévues. En effet, une erreur apparaît :
Après correction, le test ne pose plus de problème. Toutefois, un message d'erreur apparaît : "ejb.embedded.location_not_exists". Ce dernier signifie que la propriété org.glassfish.ejb.embedded.glassfish.installation.root n'a pas été passée au conteneur. Puisque nous partons du principe que nous ne disposons d'aucune installation existante de Glassfish, nous n'avons pas à configurer ce paramètre.
Une fois le fichier domain.xml en place, il ne faut pas oublier de configurer la dépendance au driver MySQL :
Et voilà ! Notre source de données MySQL est configurée.
5/ Test de la source de données avec Glassfish Embedded
Pour tester notre conteneur embarqué et la source de données configurée, ajoutons le test unitaire comme suit :
Normalement, vous devriez voir quelque part dans les logs la châine MySQL suivi du numéro de la version de votre SGBD favori :)
La suite !
Comme nous l'avons vu, il est facile d'utiliser "Glassfish Embedded" pour tester unitairement ses EJB. De plus, intégrer une source de données vers une base de données quelconque ne demande pas beaucoup plus de travail.
Puisqu'une DataSource MySQL est maintenant configurée, on peut facilement développer des entités JPA (bean annotés avec @Entity) manipulées par un EntityManager. Comment ? En configurant une unité de persistance utilisant notre source de données "jdbc/test" dans un fichier "persistence.xml".
Cela fera l'objet d'un prochain article. [Note : Je pense faire un autre tutorial mettant en œuvre Arquillian].
Enfin, pour information, sachez que Glassfish Embedded ne s'arrête pas à de simples tests. En effet, ce dernier intègre un ORB client (gestionnaire d'objets distribués basé sur CORBA) ce qui signifie qu'il peut tout-à-fait se connecter à des EJB distants. En revanche, il ne permet pas d'héberger lui-même de tels composants.
Cet article a un double objectif :
- Présenter "Glassfish Embedded" et en quoi son utilisation facilite grandement le test de ses EJB ;
- Lever certaines interrogations et fausses rumeurs selon lesquelles il serait impossible de tester ses EJB avec une base de données autre que JavaDB. En effet, "Glassfish Embedded" est fourni avec une source de données JavaDB embarquée accessible via l'entrée JNDI suivante : jdbc/__default. Or, comment faire si je veux tester un EJB qui manipule des entités JPA devant être synchronisées avec un support de persistance tel que MySQL par exemple ?
1/ Configuration du projet
Dans cet article, j'ai utilisé un projet Maven 2 afin de ne pas être dépendant de quelqu'IDE que ce soit. Les dépendances utilisées sont l'API Java EE 6, JUnit et Glassfsih Embedded (cliquez sur l'image pour agrandir) :
Pour que tout fonctionne, il faut bien entendu configurer les dépôts et les plugins (cliquez sur l'image pour agrandir) :
L'API Java EE 6 propose également certaines mises à jour des API de base fournies avec Java. Aussi, si l'on souhaite disposer de ces mises à jour, il faut configurer un Profile (cliquez sur l'image pour agrandir) :
2/ Création d'un EJB Hello World
Maintenant que notre projet est configuré, passons à l'implémentation de nos EJB. Commençons par un EJB simplissime : un "Hello World !" :
Vous noterez que notre EJB est un simple POJO annoté. En effet, la version 3.1 a considérablement simplifié l'écriture de ces composants. L'annotation @Stateless signifie que notre EJB est sans état. Un tel composant ne maintient pas d'état conversationnel avec l'appelant du bean. Cela signifie qu'une même instance du bean peut servir plusieurs clients (ou appelants).
3/ Ecriture de notre premier test unitaire
Il ne nous reste plus qu'à créer le test unitaire qui va bien :
Quelques explications maintenant. La première chose à faire est de créer un EJBContainer. Pour cela, il est nécessaire de créer une Map contenant toutes les propriétés correspondant à la configuration de notre conteneur :
- EJBContainer.APP_NAME : Le nom de notre application, ici unittesting. Ce paramètre est optionnel ;
- EJBContainer.MODULES : Les modules EJB à charger. Il peut s'agir de répertoires ou d'archives JAR référencées par des objets File. Dans notre cas ici, nous définissons un objet File pointant sur le répertoire "target/classes" (répertoire Maven de nos fichiers .class compilés). Ce paramètre semble obligatoire sinon il sera impossible pour le conteneur de localiser vos EJBs au démarrage. Dans ce cas, un message "ejb.embedded.no_modules_found" sera affiché ;
- EJBContainer.PROVIDER : Le nom complet de la classe d'implémentation mise à disposition par le fournisseur du conteneur embarqué. C'est cette classe qu'il faut adapter suivant les fournisseurs. Ce paramètre est lui aussi optionnel car si glassfish-embedded-all-3.0.1.jar est dans le classpath, la classe d'implémentation sera automatiquement chargée.
Remarque sur JNDI :
EJBContainer.APP_NAME est un paramètre optionnel. S'il n'est pas paramétré alors les EJBs déployés seront accessibles via leur nom JNDI global (standardisé depuis Java EE 6). Ce dernier est construit de la manière suivante :
- java:global/classes/NOM_DE_LA_CLASSE_EJB
Si, en revanche, ce paramètre est bien précisé, le nom global JNDI sera alors comme suit :
- java:global/NOM_APPLICATION/NOM_DE_LA_CLASSE_EJB
Dans notre cas, puisque nous avons précisé le nom de l'application (unittesting), notre bean HelloService est accessible via l'URL JNDI suivante :
- java:global/unittesting/HelloService
Il existe une autre manière de retrouver un EJB dans l'annuaire JNDI en suffixant l'URL par le nom de la classe d'implémentation :
- java:global/unittesting/HelloService!fr.sydisnet.blog.embedded.hellocomponent.HelloService
Si maintenant, notre EJB implémente une interface IHelloService (cette dernière spécifiant la méthode String sayHello()), alors ce dernier sera accessible de deux manières :
- java:global/unittesting/HelloService
- java:global/unittesting/HelloService!fr.sydisnet.blog.embedded.hellocomponent.IHelloService : Dans ce dernier cas, le nom JNDI est suffixé par le nom complet de l'interface.
Parmi les trois paramètres précédents, seul EJBContainer.MODULES est obligatoire.Vous noterez que deux lignes ont été mises en commentaires :
- La première configure l'emplacement d'un serveur Glassfish 3.0.1 déjà installé à l'aide de la propriété org.glassfish.ejb.embedded.glassfish.installation.root. Cette propriété permet d'utiliser une installation existante afin de récupérer la configuration de l'instance du serveur. Cela est très utile pour pouvoir utiliser des ressources telles que des sources de données JDBC déjà paramétrées.
- La deuxième est plus intéressante : Si aucune installation existante de Glassfish 3.0.1 n'est disponible, il est possible de spécifier au conteneur embarqué un fichier domain.xml à l'aide de la propriété org.glassfish.ejb.embedded.glassfish.configuration.file. C'est dans ce fichier que de nouvelles sources de données peuvent être configurées. Je reviendrai ultérieurement sur ce fichier domain.xml lorque nous configurerons une source de données MySQL.
Une fois que notre EJBContainer est créé, il suffit de demander à ce dernier de récupérer le contexte de l'application (variable appContext).
Ensuite, tous les tests (méthodes annotées par @Test) sont exécutés. Le programme se termine lorsque la méthode annotée par @AfterClass est appelée. Dans cette méthode, nous fermons le contexte de l'application, (appContext.close()) et nous arrêtons le conteneur (container.close()).
Enfin, il ne nous reste plus qu'à exécuter notre test unitaire. Mais les choses ne se passent pas comme prévues. En effet, une erreur apparaît :
- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.095 sec <<< FAILURE!
initializationError(fr.sydisnet.blog.embedded.hellocomponent.HelloServiceTest) Time elapsed: 0.008 sec <<< ERROR!
java.lang.ClassFormatError: Absent Code attribute in method that is not native or abstract in class file javax/ejb/embeddable/EJBContainer
Après correction, le test ne pose plus de problème. Toutefois, un message d'erreur apparaît : "ejb.embedded.location_not_exists". Ce dernier signifie que la propriété org.glassfish.ejb.embedded.glassfish.installation.root n'a pas été passée au conteneur. Puisque nous partons du principe que nous ne disposons d'aucune installation existante de Glassfish, nous n'avons pas à configurer ce paramètre.
Félicitations ! Vous venez d'exécuter votre premier test unitaire mettant en œuvre Glassfish Embedded :)
4/ Configuration d'une source de données MySQL
Comme cela a été évoqué précédemment, il suffit de paramétrer l'emplacement d'un fichier de configuration à l'aide de la propriété org.glassfish.ejb.embedded.glassfish.configuration.file. Ce fichier s'intitule domain.xml. Mais comment créer ce fichier ?
Déplacez-vous à l'emplacement local Maven de votre ordinateur où est stocké le fichier glassfish-embedded-all-ejb-3.0.1.jar. Après avoir copié et décompressé le fichier quelque part, vous trouverez le fichier domain.xml dans le sous répertoire org/glassfish/embed.
Il ne reste plus qu'à copier le fichier à l'emplacement de votre choix et à configurer la propriété org.glassfish.ejb.embedded.glassfish.configuration.file attendue par le conteneur.
Pour ma part, je n'ai pas configuré la propriété en question car j'ai opté pour une deuxième solution. En effet, par défaut, le fichier domain.xml se trouve dans le package org.glassfish.embed.
Cela signifie qu'en plaçant le répertoire domain.xml dans src/main/resources/org/glassfish/embed, nous n'avons plus besoin de configurer la propriété org.glassfish.ejb.embedded.glassfish.configuration.file en question.
Il ne reste plus qu'à configurer un pool de connexions, d'enregistrer ce dernier dans l'annuaire JNDI et de référencer la ressource en question au niveau du conteneur embarqué (cliquez sur l'image pour agrandir) :
Une fois le fichier domain.xml en place, il ne faut pas oublier de configurer la dépendance au driver MySQL :
Et voilà ! Notre source de données MySQL est configurée.
5/ Test de la source de données avec Glassfish Embedded
Pour tester notre conteneur embarqué et la source de données configurée, ajoutons le test unitaire comme suit :
Normalement, vous devriez voir quelque part dans les logs la châine MySQL suivi du numéro de la version de votre SGBD favori :)
La suite !
Comme nous l'avons vu, il est facile d'utiliser "Glassfish Embedded" pour tester unitairement ses EJB. De plus, intégrer une source de données vers une base de données quelconque ne demande pas beaucoup plus de travail.
Puisqu'une DataSource MySQL est maintenant configurée, on peut facilement développer des entités JPA (bean annotés avec @Entity) manipulées par un EntityManager. Comment ? En configurant une unité de persistance utilisant notre source de données "jdbc/test" dans un fichier "persistence.xml".
Enfin, pour information, sachez que Glassfish Embedded ne s'arrête pas à de simples tests. En effet, ce dernier intègre un ORB client (gestionnaire d'objets distribués basé sur CORBA) ce qui signifie qu'il peut tout-à-fait se connecter à des EJB distants. En revanche, il ne permet pas d'héberger lui-même de tels composants.
Inscription à :
Articles (Atom)