… 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

APIs REST ouvertes : Considérations de sécurité et implémentation

Le site Programmable Web recense plus de 10000 APIs qui se trouvent au centre du web moderne. Ces APIs permettent d’intégrer différents services allant des réseaux sociaux à la cartographie en passant par des flux d’information, de l’analyse de données, de flux le multimédia …

Fort heureusement, le simple respect des bonnes pratiques de l’architecture du Web permettent d’en lever certains. Mais créer des API ouvertes (utilisables depuis n’import quel site web) comporte tout de même certains risques de sécurité qu’il faut prendre en compte.

Considérations de sécurité

L’attaque la plus typique que peuvent subir les API REST ouvertes et applé le « Cross Site Request Forgery ». Il s’agit du fait qu’un site utilise les données d’authentification stockées dans le navigateur pour appeler des APIs sécurisées à l’insu de l’utilisateur lui même. Voir exemple sur la page wikipedia dédie au Cross Site Request Forgery

De fait, les navigateurs web limitent fortement les possibilités qu’a une page HTML a faire appel à une URL ou une API qui n’est pas sur le même serveur source que la page HTML elle même. De fait, par défaut, si je suis sur la page www.toto.com/unepage.html, je ne pourrait lire www.mesinfosprivees.com/mes_secrets/list.html ni executer www.mesinfosprivees.com/mes_secrets/api/publier. Ce qui est une bonne chose.

CORS un vrai enabler pour les API ouvertes

L’approche se sécurité citée plus haut permet de protéger les informations et services privés de la CSRF, cependant, cela limite la possibilité de mettre en place des services ouverts qui peuvent être appelés par des domaines tiers. Ainsi, je ne pourrais pas dans www.toto.com/unepage.html afficher www.mesinfospubliques.com/mesannonces.html or c’est exactement ce que je souhaite pour les API ouverte.

Le CORS (Cross Origin Resource Sharing) est une norme, implémentée par la quasi totalité des navigateurs modernes et qui permet aux site qui héberge l’API d’autoriser l’accès aux APIs depuis d’autres domaines tout en gardant un certain niveau de contrôle.

Avant d’activer CORS : regarder la sécurité

Mettre en oeuvre CORS coté serveur est en soit relativement simple, le plus complexe est de s’assurer de la maîtrise de la sécurité contre le CSRF. Pour cela :

  1. Ignorer coté serveur d’API toute authentification implicite basée sur les Cookies.
  2. De forcer chaque appel d’API à comporter les informations d’authentification s’il n’est pas public.

Pour ce second point, le pattern le plus pratique est le Synchronizer Token Pattern, il s’agit de :

  1. Générer à l’issue de l’authentification une chaine aléatoire dite (token)
  2. Transmettre à chaque appel d’API se token. (Dans un header http, dans l’URL, dans le corps)

Par contre il est extrêmement important de protéger ce token correctement :

  1. Il ne faut pas qu’il apparaisse dans le DOM (c’est à dire dans le HTML de la page statique ou dynamique)
  2. Qu’il ne soit pas accessible depuis une variable globale.

L’idéal est de le stocker dans un module javascript.

Quelques liens utiles

Prise de décision dans les projets agiles

Dans tout projet il est question de faire des choix et des arbitrages. Par rapport à cela, les projets agiles ont certaines spécificités.

Les variables QCD revisitées

Classiquement, les choix dans un projet sont perçus au bout du compte comme un arbitrage entre les trois composante du tryptique QCD :

  • Qualité : La qualité ou le contenu du livrable (exemple nombre ou complexité des fonctions livrées).
  • Cout : Qui revient souvent à la quantité de ressource qu’il va falloir mobiliser sur un projet (nombre de développeurs, moyens financiers …).
  • Délais : Qui est la date de de livraison prévue.

Ainsi, améliorer la Qualité (Q) nécessite soit de mettre plus de ressource (donc un Cout supplémentaire) ou livrer plus tard (donc un Délais supplémentaire). Inversement, réduire le Cout (donc les ressources mobilisées) nécessiterait soit de réduire les fonctionnalités livrées (donc la Qualité) soit augmenter le Délais de livraison vu le manque de ressources. Ainsi de suite …

En projet classique toutes les variables sont considérées pour l’arbitrage, et souvent, on impactera d’abord le Délais, ensuite éventuellement le Cout et vraiment en dernier recours la qualité.

Les priorités QCD en projet Agile : la Qualité, variable de choix

En agile, les durées d’itérations sont fixées, la composante Délais n’est donc pas une variable d’ajustement sauf très rare exception. Cela a pour avantage de maintenir un synchronisme naturel à la fin de l’itération entre les équipes de développement et le reste de l’entreprise (équipes de test, déploiement, métier, communication …).

La composante Cout de son côté est souvent difficilement ajustable. En effet, en projet agile :

  1. La priorité est donnée au livrable par rapport à la documentation.
  2. L’interaction directe des membres prévaut par rapport aux processus et outils.

De fait la culture de l’équipe est relativement orale et met donc du temps à se transmettre aux nouveaux arrivants.

De plus, les équipes étant souvent auto-organisée, cela nécessite du temps pour se réorganiser en fonction des capacités de nouveaux arrivants.

La variable d’ajustement principale est donc souvent la Qualité autrement dit, la question revient souvent à une variante de : Que vas-t-on livrer ?

Les critères de décision en agile : la valeur et la capacité à livrer

Une fois la question posée, les réponses possibles sont analysées selon deux critères principaux :

  1. Quelle valeur ajoutée apporte tel ou tel choix à l’utilisateur (Valeur métier)
  2. A quel point les informations nécessaires pour livrer cette valeur sont disponibles.

Parmi les options suffisamment précise et réalisables on choisira donc celle qui apporte le plus de Valeur au métier.

Le droit à l’erreur

En projet agile, le changement est la règle et non pas une exception, de fait on se donne le droit de se tromper et de changer de cap, de fait la décision peut se prendre avec un certain niveau d’incertitude. Cependant, il convient dans ce cas là de se donner les moyens de détecter son erreur le plus tôt et la convertir en apprentissage dans le cadre de l’amélioration continue.

En conclusion

Les choix de projet agile reviennent souvent à redefinir le périmètre ou les détails du livrable (variable Qualité), ce choix doit se faire essentiellement en regardant la valeur métier et la capacité à réellement livrer cette valeur. Enfin, il n’est pas une exception de devoir éventuellement changer d’avis plus tard, l’important est de transformer les erreurs en apprentissage.

Quel est le bon outil de gestion de projets informatiques ?

Quel est le meilleur outil pour gèrer les projets de développement informatique? Faut-il fédérer l ‘équipe autour de diagramme de Gantt? Ou est-ce mieux d ‘utiliser un plan d ‘action excel? Ou peut être un tracker?

Je me suis entretenu à ce sujet avec plusieurs developpeurs, chefs de projet et architectes de divers horizons et la question semble loin d ‘avoir une réponse évidente unanimement accptée.

Plusieurs types d ‘outils

Pour être très synthetique, j ‘ai retrouvé essentiellement 3 types d ‘outils :

  • les listes de taches que ce soit une simple feuille excel ou un outils plus avancé de type tracker (redmine…)
  • les gantt de type msproject gantt project ou libreproj.
  • les tableaux de sticker (post it board) il s ‘agit de tableaux blancs ou tableaux de paperboard découpés en sections sur lesquels des post-its représentant les taches sont collés et déplacés.

Plusieurs facteurs de réussite

Lors des différents échangés les outils peuvent être appréciés ou rejetés pour des raisons que je synthétise par :

  • L ‘adoption : les développeurs et les chefs de projet vont-ils réellement savoir utiliser l ‘outil?
  • L ‘utilité : l ‘outil vas-t-il réellement rendre service à son utilisateur ou est-ce un fardeau à porter par obligation?
  • La souplesse : l ‘outil vas-il s ‘adapter au fonctionnement de l ‘équipe ou vas-t-il introduire des contraintes a ce fonctionnement?

Au delà de l ‘outil, les revues régulières, l ‘écoute et la pédagogie du team leader sont un must pour favoriser la bonne utilisation des outils et le bon déroulement du projet.

Symptôme du mauvais outil : le multi-suivi

Quand l ‘outil adopté par le projet ne satisfait pas l ‘équipe, un phénomène se produit quasi systématiquement : Le développement de suivis parallèles à l ‘outil principal : des plans d ‘action sur Excel, des échanges de mail, des pages Wiki des Trackers … Reprennent et s’ajoutent aux taches principales du projet.

Cela vas sans dire : Cela est très nuisible à la synergie de l’équipe et à l’efficacité de la collaboration.

Les développeurs amateurs de plus en plus nombreux selon l’IDC, ils représenteraient actuellement presque 40 % des développeurs

C ‘est plutôt une bonne nouvelle, le concept d’école comme l’Ecole Simplon fait donc sens, Reste quel pourcentage de passionnés et quel pourcentage d ‘opportunistes ….

http://www.developpez.com/actu/66593/Les-developpeurs-amateurs-de-plus-en-plus-nombreux-selon-l-IDC-ils-representeraient-actuellement-presque-40-des-developpeurs/

INVEST – Les 6 piliers d’une bonne User Story scrum

La façon dont les besoins du Metier sont exprimés en terme de story agile est déterminante pour maximiser le gain d’efficacité promise par les projets agiles.

Qu’est ce qu ‘une story

C ‘est une paragraphe court qui decrit sommairement une fonction du produit et sa valeur métier, par exemple :

En tant que client je peut chercher les produits de la e-boutiques en tapant des mots clés cela me permet de trouver rapidement l'ensemble des produits qui repondent à mes besoins.

Une user story est censée être un sujet de discussions et non pas une description détaillée d’une fonction. Il n ‘y a pas de mal à ce que une story soit au départ trops générique voir mal cernée par le product owner lui même tant qu ‘elle reste dans le backlog. Cependant, elle ne peut être admise dans une itération que quand le product owner a la maturité nécessaire pour pouvoir donner des informations detaillées : sur la fonction principale, les chemins alternatifs, les cas d ‘erreur… (Voir cet article sur les critères de réalisation d’une story)

Les 6 critères de qualité INVEST

Afin de s ‘assurer qu ‘une user story a les qualités nécessaires pour être effectivement incluse dans une itération, 6 critères ont été definis sous l’acronyme INVEST.

  • Independant : chaque story doit constituer un avantage métier par elle même : On ne peux pas avoir deux story qui dépendent l ‘une de l ‘autre pour produire de la valeurs. Exemple:
    Story 1: en tant que client mes transactions doivent être stockée en base lors d 'un achat. 
    Story 2: en tant que client je doit recevoir une fois par mois une liste détaillée de transactions pour pouvoir mettre à jour ma comptabilité.
    

    La story 1 ne produit pas de valeur en soit, imaginons qu ‘elle soit réalisée lors d ‘une iteration, il n’y aura de vrai ROI (retour sur investissement) qu’appartir du moment ou la Story 2 est mise en place. Entre temps, du temps de développement a été investi sans réelle rentabilité. Par ailleurs, dans un environnement changeant, la story 2 pourra devenir à un certain moment inutile ou pas prioritaire, on aura alors investit du temps inutilement.

  • Negociable : Toute story peut être remise en question, discutée négociée à tout moment. Par ailleurs, elle doit être exprimée dans un language compris à la fois par l’équipe de développement et le métier pour permettre une réelle négociation et connaissance des enjeux partagée.

  • Valuable : Chaque story doit apporter de la valeur, c’est la base du bon sens. Si on est incapable de décrire le bénéfice utilisateur d’une story, c’est qu’elle est probablement supérflue ou plus proche d’une tache technique que d’une story. Les besoins non fonctionnels sont des fois assez astucieux à exprimer en terme de valeur métier. Ainsi, mettre en place des logs techniques peut s’expriemer :

    En tant qu'opérateur de maintenance je doit avoir accès à des traces d'erreur afin de rapidement résoudre les incidents qui bloquent les utilisateurs.
    
  • Estimable : Litérallement, cela veut dire que l’équipe de développement peut donner une estimation de l’effort pour réaliser la story. Plus concrètement, il s’agit de s’assurer que l’équipe a une discussion autour de la story et voit globalement la solution technique pour la réaliser.

  • Sized appropriately : Doit avoir une taille la plus petite possible. Afin de réduire la taille d’une story une des techniques est de découper en variante ainsi :

    En tant qu'utilisateur, je peux payer mes achats en ligne afin de recevoir ma commande plus rapidement.
    

    On pourrait découper cette story en 3 :

    En tant qu'utilisateur, je peux payer mes achats en ligne par carte banquaire afin de recevoir ma commande plus rapidement.
    En tant qu'utilisateur, je peux payer mes achats en ligne avec mon compte paypal afin de recevoir ma commande plus rapidement.
    En tant qu'utilisateur, je peux payer mes achats en ligne avec mon compte mobile afin de recevoir ma commande plus rapidement.
    
  • Testable : Chaque story développée doit pouvoir être validée par le métier en effectuant des tests. Il faut donc qu’elle soit définie de façon concrète avec des critères d’acceptation précis.

En conclusion

Le découpage en story n’est pas juste une façon différente de produire un cahier des charges mais a un impact réel sur la conception du produit lui même et le déroulé du projet. C’est ce bon découpage qui donne tout son intérêt à un projet agile:
– La motivation des équipe augmente en voyant l’aboutissement concret de ce qu’elles réalisent sans être bloquées par le métier.
– La satisfaction des managers augmente en voyant à chaque itération des fonctions utiles livrées et améliorées et donc un ROI progressif.

Et enfin, le métier garde la marge de manoeure pour ajuster ou re-prioriser les fonctions du produit et gérer les risques et incertitudes de l’évolution du contexte.

PayPal abandonne Java pour JavaScript coté serveur

Node.js a permis un gain important en performance et en temps à l’entreprise, un retex intéressant même si le javascript pour des plates formes d’entreprise ne doit pas être mis entre toutes les mains : la souplesse du langage exige des developpeurs expérimentés pour le manier correctement.

http://www.developpez.com/actu/65013/PayPal-abandonne-Java-pour-JavaScript-Node-js-a-permis-un-gain-important-en-performance-et-en-temps-a-l-entreprise/