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 :)
Inscription à :
Articles (Atom)