Le navigateur Web Chrome a le vent en poupe : rapide, bien pensé et bénéficiant d'une quantité croissante d'extensions. Apparues il y a de longues années déjà dans Firefox, ces dernières sont un bon moyen d'étendre les fonctionnalités natives du navigateur : capture d'écran, partage de favoris, actualités, notifications, etc. Mais au fond, ce sont tout simplement de petites applications se basant sur les standards HTML, CSS et JavaScript... autant dire que tous les développeurs Web manipulant ces trois (...)

Tout d'abord, il faut que je vous présente cette conférence. La conférence "Agile" est l'un des événements les plus importants de l'année dans la communauté agile. J'ai découvert cette conférence en 2008 (Agile 2008), où j'avais présenté un retour d'expérience sur le passage à l'agilité d'une organisation développement des applications d'assurances sur plateformes Java/.NET dans un contexte "mainframe".

Cette conférence vise :

• à proposer aux participants les dernières idées dans le domaine de l’agilité,
• à enrichir les connaissances, à multiplier les axes de réflexion, à encourager les débats et à promouvoir les idées innovantes.

Elle vise aussi à réunir des dirigeants, des manageurs, des praticiens du logiciel et des chercheurs. Cette conférence n’est pas dédiée à une méthode ou une approche, mais plutôt propose un forum d’échanges d’informations sur toutes les technologies agiles. Ainsi en 2009, la répartition des participants par métier était la suivante :

La conférence attirait principalement des développeurs et consultants (43%) et des chefs de projet et dirigeants (30%). En 2010, 1400 personnes, provenant de 38 pays, étaient présentes à la conférence. Il y avait 180 orateurs pour 227 sessions.

Après la récupération de mon sac, direction les deux sessions de la journée (chacune de 180 mn) :

9:00 - 12:30 Leader's Workshop: Making Change Happen and Making it Stick, Mary Poppendieck

Pour les minutes, je vous recommande ce post ! La salle était, comme on pouvait s'y attendre pleine à craquer ;-)

  

C'est l'une des sessions qui m'a le plus marqué ! J'ai noté au passage les points suivants :

• Money don't motivate people but autonomy, mastering, self direction,
• Open source is an inflection point for collaboration -> motivation 3.0,
• Employees must be managed as volunteers and especially knowledge workers,
• Look at what is working to scale it, not a what is failing to fix it. Because, roots of failures may be impossible to change,
• Script the critical moves with checklists to capture key steps based on existing working practices. Don't add how to do steps,
• Shareholders are better served by a long term focus over quarterly results.

Quelques livres ont été cités :

• Switch: How to Change Things When Change Is Hard 
• Drive: The Surprising Truth About What Motivates Us
• Only the Paranoid Survive: How to Exploit the Crisis Points That Challenge Every Company
• Influencer: The Power to Change Anything
• l'inévitable Getting the Right Things Done: A Leader's Guide to Planning and Execution
• A Sense of Urgency avec une stratégie pour adopter l'Agilité avec le moins de résistance possible :
  • Create a tranformation team (VP plus lead engineers)
  • Strategy: sell agile to BUs, develop a brand
  • Transformation team looks for and changes organizational policies which get in the way.
•  

13:30 - 17:00 Agile Estimating & Planning: From Basics to Brain Stumpers, Mike Cohn

Aussi beaucoup de monde pour cette session de l'un des fondateurs de la Scrum Alliance et auteur des livres incontournables que sont  Agile Estimating and Planning, User Stories Applied for Agile Software Development, et Succeeding with Agile Software Development using Scrum.

 Mike insiste sur la notion de précision des estimations et de son ajustement progressif en fonction de son niveau de compréhension des user stories : "It's better to be roughly right than precisely wrong", John Maynard Keynes.

Des user stories peuvent être estimées plus grossièrement et seront mieux estimées en fonction des user stories déjà réalisées aux précédentes itérations. Il s'agit de profiter des itérations passées pour mieux ajuster le nombre de story points pour chaque user story en les comparant aux user stories développées.

La planification agile utilise finalement le changement comme un outil d'ajustement et de convergence des estimations.

A voir aussi, cet interview abordant l'estimation :

Agile Development Teams: Scope and Scale with Mike Cohn - Watch more Videos at Vodpod.

 Peu de sessions ce premier jour, mais des sessions denses et par des orateurs exceptionnels :-)

La vie terrestre des ESB, aura été courte. À peine compris et apprivoisés, les voilà qui s’envolent vers d’autres cieux. En effet, depuis quelque temps, on commence à percevoir les premières initiatives d’ESB dans les nuages comme celle de la firme WSO2 avec sa plateforme Stratos ou encore celle de Savoir technologies, dans le milieu hospitalier, où la mise en place d’un ESB dans les nuages a facilité les échanges des données des patients entre les différents départements.

Dans la suite de ce billet, nous allons essayer d’analyser cette tendance émergente en revenant brièvement sur :

• Ce qu’est un ESB et les besoins des systèmes en terme d’intégration.
• Les plates-formes de cloud computing et leurs différents modèles.

Lire la suite de cet article …

Un outil pour l’amélioration continue du standard

Désolé pour les gamers, mais non je ne vais pas vous parler du dernier Day of Defeat. Par DoD comprenez plutôt « Definition of Done », c’est à dire l’ensemble des critères à respecter pour considérer une tâche terminée. Par exemple, avant de soumettre son code, un développeur doit s’assurer de respecter le critère: « tests unitaires OK ».

En quoi un outil aussi « low-tech » et aussi simpliste qu’une check-list peut nous aider à l’ère de Google et de l’iPhone ? À une révolution dans le niveau de qualité fournie. Pour preuve emblématique, les initiatives récentes dans le milieu hospitalier. Cet extrait parle de la pose d’un cathéter (voie veineuse centrale).

« In 2001, though, a critical care specialist at Johns Hopkins Hospital named Peter Pronovost decided to give a doctor checklist a try. [...] Doctor are supposed to (1) wash their hands with soap, (2) clean the patient’s skin with chlorhexidine antiseptic, (3) put sterile drap over the entire patient, (4) wear a mask, hat, steril gown, and gloves, and (5) put a steril dressing over the insertion site once the line is in. [...]

In the Keystone initiative’s first eighteen months, the hospitals saved an estimated $175 million in costs and more than fifteen hundred lives.« 

Et ce seulement dans le Michigan !

Avant même de parler des DoD, je rappelle que ceux-ci sont au service de l’amélioration continue du standard.

Qu’est ce qu’un ( bon ) standard ?

Je vous propose cette définition :
« Un standard est la meilleure pratique constatée à ce jour, énoncé explicitement, avec une finalité affichée, et dont on sait mesurer les écarts. »

Celui-ci au sens Lean se doit de respecter certaines grandes caractéristiques, il doit être :

• issu du terrain
• évolué sur la base de l’amélioration continue et de la résolution de problème
• simple
• supporté au maximum par du management visuel
• remis en cause sur la forme et sur le fond lorsqu’il n’est pas appliqué

Les DoD sont des éléments de ce standard, ils se doivent donc eux aussi de respecter ces caractéristiques. Appliquons donc celles-ci à nos DoD :

Issu du terrain

C’est sur le terrain que devra être appliqué le standard et c’est bien là que les problèmes sont rencontrés et encore là que le standard sera remis en cause et amélioré.

Voici un autre extrait tiré du même livre qui relate l’échec de la première version de cette check-list. Cette première version ayant été rédigée par des chirurgiens, non pas au bloc, mais lors de réunions en omettant la plupart des acteurs, infirmières, anesthésistes, …

« I gave the checklist to Dee, the circulating nurse, and asked her to run through the first section with us at the right time. Fifteen minutes later, we were about to put the patient under general anesthesia, and I had to say, Wait, what about the checklist?
« I already did it, » Dee said. She showed me the sheet. All the boxes were checked off.
No, no, no, I said. It’s supposed to be a verbal checklist, a team checklist.
« Where does it say that? » she asked. I looked again. She was right. It didn’t say that anywhere.
Just try it verbally anyway, I said.
Dee shrugged and started going through the list. But some of the checks were ambiguous. [...]. And after a few minutes of puzzling our way through the list, everyone was becoming exasperated. Even the patient started shifting around the table.
« Is everything okay? » she asked.
Oh yes, I told her. We ‘re only going through our checklist. Don’t worry.
But I was getting impatient, too.  The checklist was too long. It was unclear. And past a certain point, it was starting to feel like a distraction from person we had on the table.
By the end of the day, we had stopped using the checklist. Forget making this work around the table. It wasn’t even working in one operating room. »

Dans cet extrait il est clair que l’infirmière Dee aurait dû être consultée pour l’élaboration de la check-list. Les propositions d’améliorations doivent être émises par ceux qui rencontrent le problème et qui ont la meilleure vision de toutes les contraintes. Mais c’est loin d’être suffisant.

Un exemple issu de nos métiers : Jean développeur décide qu’à partir de maintenant le passage dans un formateur de code est obligatoire avant tout commit. C’est donc un nouveau DoD pour terminer une tâche de développement.

C’est sans doute une bonne initiative, mais elle est vouée à l’échec. Pourquoi ?

Évoluant sur la base de l’amélioration continue et de la résolution de problème

Le standard ne pourra être respecté que si il est partagé par toute l’équipe. Pour y arriver, le Lean nous met à disposition l’amélioration continue et la résolution de problème via, dans le cas des méthodes agiles, les rétrospectives.

Revenons au formateur de code de Jean. C’est une nouvelle contrainte pour les développeurs qui ne la comprennent pas forcément ( « c’est pour faire joli ? », « moi j’aime pas les accolades à droite ! « , etc…).

En effet, les autres membres n’éprouveront pas le besoin puisqu’ils n’y voient pas de solution à un problème donné.

Pourquoi ne pas se servir de la rétrospective ?

Si des actions d’amélioration ont été trouvées lors d’une rétrospective, il est très probable que des DoD puissent s’en déduire. De plus, c’est un moment privilégié où toute l’équipe est concentrée à l’amélioration du process.

Comment ce cas aurait pu être traité en rétro ?

Jean : « Je n’ai pas pu finir ma user story pour la recette, le merge était trop difficile avec la US de René. »

René : « Mais on ne travaillait pas sur les mêmes méthodes ? »

Jean : « J’ai eu pleins de conflits parce que tu mets toutes tes accolades à la ligne… »

René : « Mais c’est beaucoup plus lisible au niveau de l’indentation, non ? »

Jean : « C’est pas le standard le plus répandu ! »

René : « C’est toi le stand… »

La vache Octo : « Meuuuuuuuuuuuuuuuuuuuuuuh »

Le coach Octo : « Ca vous dit de traiter le point au calme et en rétrospective technique ? »

Dans cette retro spécifique aux développeurs le coach (ou team leader) va aider l’équipe à clore ce débat « passionnant » de l’indentation et convenir d’un formateur unique ainsi que de l’ajout au standard d’un DoD « FORMATEUR DE CODE APPLIQUÉ ».

On a maintenant deux fervents défenseurs de cette partie du standard, Jean qui appréhende un nouveau merge difficile et René qui aime ses accolades !

C’est donc bien le processus d’amélioration continue qui nourrit et fait évoluer le standard.

Simple

Le but final est de construire le meilleur standard applicable. Qui dit applicable dit simple. Cela implique que les DoD qui le composent soient le plus simples possibles.

Ainsi, la formalisation d’un DoD doit respecter quelques règles :

• univoque pour toute l’équipe :
  • « BUILD OK » peut ne pas être suffisant, c’est en local ? en environnement sandbox ?
  • « BUILD OK SUR MACHINE TOTO » lève le doute.
• en nombre limité :
  • Cette liste de DoD devra être appliquée et contrôlée pour chaque tâche Il faut donc limiter leur nombre (entre 1 et 10 critères pour passer une tâche d’un état à un autre)
• concis :
  • Le nombre de DoD pour l’ensemble du process peut devenir conséquent, il ne faut pas noyer l’information. À « Vérifier que le build d’intégration continue sur la machine TOTO n’a pas été mis en échec par notre commit », on préférera « BUILD OK SUR MACHINE LP32″ qui reste malgré tout parlant pour l’équipe.

Management visuel

Toujours dans le but de rendre notre standard applicable le plus simplement possible, nous allons cette fois ci nous appuyer sur le management visuel.

Rendre les DoD visuels les rendra plus accessibles et donc plus facilement utilisables.

Comme ils ne seront qu’une source d’informations parmi d’autres, il convient de les rendre clairs et normés. Par exemple Post-It vert clair /  marqueur noir / en majuscule.

Je vous laisse apprécier la différence :

En agile, les étapes du processus sont reflétées par les colonnes du scrumboard / kanban board. Les DoD doivent être contrôlés au changement d’état. Celui-ci se matérialise par le déplacement du Post-It de la colonne A vers la colonne B. Le meilleur endroit pour afficher les DoD est donc, à mon sens, au dessus (ou en dessous) de celles-ci.

Remis en cause sur la forme et sur le fond lorsqu’il est non appliqué

L’un des grands principes d’un standard, tel que le Lean le définit, est qu’il est vivant. La définition d’un standard donnée en début d’article parlait bien d’un instant T. Si à T+1 on observe que le standard n’a pas été appliqué, il faut le remettre en cause.

Si un critère du DoD n’est pas appliqué il est nécessaire de se poser les questions suivantes :

• le critère n’a pas été vérifié car il n’est plus pertinent ?
• le critère n’a pas été vérifié car il n’est pas assez « ergonomique » et clair dans le DoD ?
• le critère n’a pas été vérifié car la personne n’a pas regardé le DoD ?
• le développeur en charge de vérifier le critère a pensé à tort/à raison qu’il s’agissait d’un cas particulier non encore explicité dans le standard de l’équipe ?

Dans le cas où le critère a été mal compris il convient de le modifier. Par exemple si le critère « TEST FONCTIONNEL OK » ne suffit pas car le test peut passer en local mais échouer en environnement sandbox, le reformuler en « TEST FONCTIONNEL OK EN SANDBOX ».

Mais que faire quand on découvre que le DoD a été contourné à tort ?

Déboires

Dans la pratique il s’avère que, même avec des développeurs pleins de bonne volonté, l’application des DoD n’est pas toujours réalisée.

Et pourtant… C’est très frustrant de voir à une rétrospective une US KO, la vélocité chuter, alors que le remède était là, en majuscules et visible partout dans l’openspace :

Jean, en charge de la US à KO : « Ca marchait en local. »

L’équipe : …

Comment garantir le respect des DoD

Quelque chose de simple mais qui fonctionne : le binômage dans le déplacement des Post-It. Un développeur souhaitant faire avancer sa tâche doit avertir un autre développeur. Le but étant de responsabiliser deux personnes sur le respect du DoD mis en place pour ce changement d’état.

De manière générale, il faut à tout prix responsabiliser l’équipe au respect des DoD : « c’est votre standard, c’est-à-dire la meilleure façon que vous avez trouvé jusqu’ici pour réaliser l’objectif. Soit vous l’appliquez à la lettre si il est pertinent soit vous le remettez en cause en équipe».

Un autre outil qui peut déranger mais qui peut fonctionner dans certaines équipes, le « wall of shame ». Très simple… un Post-It géant avec le nom de chaque développeur. Le non respect d’un DoD entrainant un bâton à coté du nom du développeur concerné.

Il suffit d’en faire un jeu plus qu’un outil de « flicage » et c’est à mon avis le meilleur moyen de garantir le respect des DoD. L’équipe est responsable des DoD donc à l’équipe elle-même de fixer, dans un cadre pro, la conséquence du non respect du standard. Le but n’étant pas de sanctionner mais de faire prendre conscience des DoD.

Comment en faire un jeu ?

• 5 bâtons = un fond d’écran « Dora l’exploratrice » pendant 2 jours
• 10 bâtons = des croissants pour l’équipe
• …

Enfin, quelque chose que je n’ai pas encore pu essayer mais qui me semble prometteur, les cases à cocher. De la même manière que pour une check-list classique, il faudrait posséder sur les Post-It matérialisant les User-Stories une case à cocher par DoD. Ainsi un oubli de DoD est clairement visible de tous. Et tout le monde peut participer au respect du standard. Si vous avez des retours d’expériences la dessus, je suis preneur !

Conclusion

On peut maintenant définir un DoD :
« Elément visible de tous, concis et univoque définissant les conditions permettant de passer une tâche d’un état à un autre. Leur ensemble définissant le standard d’un processus ».

Avec l’utilisation des DoD, il devient possible de partager tous les standards d’une équipe sur l’outil que tout le monde utilise et voit en permanence, le scrumboard / kanban board.

Autrement dit, la meilleure façon d’apporter de la valeur au projet connue à ce jour est visible par tous et à tout instant.

Paris Web, c'est quoi ? Paris Web est avant tout une association "loi 1901" dont le but est la promotion du développement web de qualité. Elle plébiscite les standards, le respect des normes, l'accessibilité, l'ergonomie réfléchie et le choix de bonnes méthodes de conception. Son action est notamment visible par l'organisation et sa participation à des manifestations et forums autour de ces thématiques. C'est quoi alors Paris Web 2010 ??? Pour répondre encore mieux à sa mission, l'association (...)

L’un des facteurs clé pour la réussite de la mise en place d’une architecture orientée services, c’est de parvenir à identifier et mettre en Å“uvre des services à forte valeur ajoutée. Cet article synthétise, sous forme de questions pratiques, les principaux éléments et concepts à considérer pour réussir cette transformation du SI.

Cet article sera publié en 3 parties :
Partie 1 – Questions 1 et 2
Partie 2 – Questions 3 à 6
Partie 3 – Questions 6 à 10

1) Qu’est-ce qu’un service ?
Dans le domaine informatique, un service est tout programme exposant une ou plusieurs fonctionnalités à des tierces applications en environnement distribué

2) Comment émergent les services ?
Pour qu’on puisse parler de service, il faut un client et un fournisseur de service.

Dans un processus « Bottom up », un service émerge d’une démarche « Push » initiée par un fournisseur ou « Pull » initiée par un consommateur.

Dans un processus « Top-down », il est la résultante d’une étude plus globale et systémique du SI ou d’un bloc du SI.

Processus Bottom-Up

- Processus « push» – par le fournisseur (Le fournisseur fournit un service le plus « générique » possible)

C’est une démarche initiée par un fournisseur qui expose un service et le propose à ses partenaires. Le fournisseur essaie de proposer un service le plus générique possible qui répond au besoin de tous ses partenaires (exemple : les services exposés par ViaMichelin, Amazon, Google, etc.)

- Processus « Pull» – par le client (Le client demande un service)

Cette démarche est initiée par un consommateur qui exprime le besoin pour un ou plusieurs service(s) lui permettant d’échanger avec des tierces applications. Dans ce cas, le fournisseur essaie de répondre au besoin du consommateur sans forcément prendre en compte des perspectives de réutilisation du service. Cela s’explique par le fait que ce genre de demande se conjugue généralement avec des impératifs « Time To market » imposés par le client du service.

Processus Top-Down (Le service est identifé)

Certains services de ce processus émergent d’une démarche d’urbanisation ou de refonte du SI. Le besoin d’échanges est préalablement étudié et une définition des services est proposée.

Il est vrai que cette démarche garantit une cohérence globale de l’ensemble des services, néanmoins, sa mise en place s’avère un challenge inintelligible dont les bénéfices sont loin d’être acquis.

Quelle démarche favoriser?
Dans l’absolu, il n’y a pas de démarche à favoriser en particulier. Les 3 peuvent co-exister selon le contexte et l’offre de services existante. Néanmoins, en phase de conception et de mise en Å“uvre du service, il est primordial de prendre en considération les points suivants:
1) Favoriser une démarche itérative et collaborative entre clients(s) et fournisseurs de services.

Pourquoi? Parce qu’un service est un processus dont le résultat ne préexiste pas à la demande du client, cela signifie que le client va devoir s’engager vis-à-vis d’un fournisseur avant que la service ne soit réalisée, c’est-à-dire avant qu’il puisse évaluer la qualité de ce résultat, puisque celle-ci ne pourra être évaluée qu’une fois le service réalisé. Ce décalage temporel entre l’engagement de la transaction client/fournisseur et la réalisation du service crée une situation d’incertitude. D’où l’importance des méthodologies de mise en Å“uvre projet concernant ce type de besoin.
2) Penser un service donné en tant qu’offre de services, plutôt qu’un mono-service qui essaie de répondre à tous les besoins
3) Ne pas considérer l’étude d’urbanisation, s’il y en avait une, comme une cible en elle même, mais plutôt comme un fil conducteur pour la cible.

Suggestion d'articles :

1. Le tour des ESB en 10 questions
2. SOA par la pratique

Suite à un certain nombre de demandes de la part de nos clients, nous avons décidé d’ouvrir, à titre expérimental, nos parcours de formation OCTO à des participants extérieurs. C’est ainsi qu’OCTO Academy est né ! Concrètement, il s’agit d’ouvrir la cinquantaine de jours de formation que nous animons tout au long de l’année dans nos locaux.

Ces formations destinées à nos architectes sont la meilleure illustration de notre devise « Apprendre à jouer l’excellence ».

Elles sont animées par :

• les référents OCTO sur un domaine (architectes, experts, agilistes)
• des intervenants prestigieux comme David Anderson sur Kanban, ou Greg Young sur l’Applied DDD.

Elles couvrent 4 thématiques :

• Management de SI
• Architecture et technologies
• Méthodologies et conduite du changement
• Accompagnement de projets

Le site OCTO Academy (en béta) présente un petit catalogue formation avec un formulaire d’inscription.
Le catalogue va s’étoffer progressivement dans les mois à venir…

Suggestion d'articles :

1. Session ALT.NET avec Greg Young ce mercredi à OCTO
2. 4 Formations OCTO Technology – 2 et 3 juillet 2008
3. OCTO propose une formation ScrumMaster le 7 et 8 février 2008

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

• Sortie de RabbitMQ 2.0

Le coin de la technique

• Gestion automatique des ressources dans Java7 (ARM)

Evènements de notre communauté en France et à l’étranger

• Google et les brevets

Lire la suite de cet article …

J’ai récemment eu quelques difficultés à customiser les styles (couleurs, fonts, …) des Tooltips générés par l’API JFreeChart.
Quelques recherches sur le sujet m’ont permis de constater que je n’étais pas le seul à rencontrer des difficultés pour modifier les styles par défaut fournis par l’API JFreeChart.
L’API JFreeChart étant assez mal documentée sur le sujet, j’ai du fouiller dans le code source de l’api pour trouver mon bonheur. Comme dit le proverbe, « Pour avoir de l’eau claire, il n’est que d’aller à la source ».
Ayant finalement trouvé une solution au problème, je me propose de la partager au travers de ce billet.

Lire la suite de cet article …

J’ai fait du RAD il y a quinze ans, était-ce déjà de l’agilité ? Il arrive d’entendre cette question lorsque l’on fait découvrir l’agilité à ceux qui sont passés sur les plateaux de développement il y a quelques années. A tous ceux qui se posent la question, voici une mise au point sur le sujet. Dans [...]

Dans cet article nous verrons comment utiliser Oracle Coherence pour retrouver les mots de passe ayant servi à générer des hash.

Deux approches naïves sont envisageables pour cracker un hash : la force brute et la base de données. La première consiste à essayer toutes les combinaisons possibles de mots de passe, mais le problème est le temps de calcul nécessaire, car les fonctions de hashage sont généralement très lentes. La seconde consiste à calculer en amont les hashs de toutes les mots de passe possible, et à les stocker dans une base de données ; mais cette attaque nécessite un espace de stockage énorme.

Les Rainbow tables sont conçues pour optimiser l'équilibre entre puissance de calcul et la consommation mémoire, à mi-chemin entre les deux approches précédentes.

Rainbow table Une Rainbow table est une variante de la Map classique, dont les clés sont les hashs et les valeurs les mots de passe correspondants. La subtilité est que le hash n'est pas directement obtenu par digestion du mot de passe, mais après l'application successive de fonctions de digestion et de réduction. L'opération de réduction permet... Lire Oracle Coherence et Rainbow table

A l’époque de la bulle Internet, les « brick-and-mortar » étaient destinés tout simplement à disparaître face à l’émergence des « pure-players » internet. Il était alors vital pour toute société « classique » souhaitant survivre de disposer d’un site web, si possible marchand. Un crack et 10 ans plus tard, nombre de pure players ont disparu, certains sont maintenant des géants, et les « brick-and-mortars » sont bien présents sur le marché.

Une nouvelle révolution est entamée avec la mobilité et l’ubiquité d’internet, portées en particulier par l’avènement de l’iPhone et autres smartphones. Internet s’est démocratisé et l’homme de la rue a appris à se servir des outils que ce medium met à portée de sa main. La possibilité de consulter le web à tout moment et en toute occasion vient modifier l’importance accordée à ce medium. Au delà d’offrir un simple site marchand, il s’agit maintenant de tirer partie des synergies possibles entre ces différents canaux et des utilisations faites d’Internet. Le ROPO (Research Online, Purchase Offline) devient par exemple un service nécessaire pour toutes les enseignes pour attirer les clients qui souhaitent s’assurer de la disponibilité de l’article avant de se déplacer ou qui ne veulent pas payer de frais de livraison.

Or du côté des anciens « brick-and-mortar », la mise en ligne d’un site marchand s’est rarement accompagnée d’une réflexion sur les relations entre le canal web et les magasins physiques. Des silos opérationnels et SI séparent souvent la gestion du site web et celle des magasins physiques. Pourtant, c’est le tissage de liens étroits entre le web et le monde physique qui doit permettre non seulement d’accompagner un client sur l’ensemble de son parcours, qu’il soit sur internet ou dans la rue (et donc à le suivre sur différents canaux), ou de lui offrir de nouveaux services tels que le ROPO, mais aussi de dégager de nouvelles synergies dans les organisations. Ainsi, pour commander en magasin un article en rupture de stock et le faire livrer, l’utilisation d’une plate-forme logistique spécialisée dans l’expédition, par exemple la plate-forme adossée au site marchand, se révèle plus efficace qu’une gestion des livraisons par chaque magasin.

Cette capacité à tirer des synergies entre les différents canaux de vente est un facteur de développement majeur. En effet, un distributeur US, Nordstrom, a fait le calcul qu’un client « multi-canal » dépense quatre fois plus qu’un client « mono-canal » et que le recours au stock magasin pour répondre aux ruptures de stock sur le site marchand a permis de doubler le taux de conversion des recherches en ventes (Source : article du International Herald Tribune).

Du point de vue du SI, cette capacité demande en général une révolution copernicienne pour passer d’une orientation purement « produits » historique à une orientation « clients » et mettre en place une gestion des données en temps réel dans un système centralisé. Elle implique donc, non seulement des projets d’organisation, mais également des refontes majeures dans la répartition des systèmes d’information et dans leur mise en oeuvre, avec une gestion délicate du déploiement de ces nouveaux outils. Elle exige également une attention particulière à l’arrivée de nouveaux canaux ou à de nouvelles utilisations des canaux existants. Pour ce faire, le système d’information doit bien sûr rester maîtrisé mais aussi ouvert et évolutif. Plus qu’adapté, on lui demande surtout d’être adaptable. Et sur ce dernier point, les « pure players » ont pris une longueur d’avance sur les « brick-and-mortar » aussi bien dans leurs méthodes de développement que dans la gestion de leur SI…

Après avoir abordé la gestion des fichiers de logs, nous continuons aujourd’hui la série « Applications Java prêtes pour la Production » avec l’audit.

Par audit, nous entendons l’audit des actions importantes réalisées sur une application.

Pourquoi auditer ?

Est-il vraiment utile de générer des informations d’audit dans nos applications ? Sans explications de juriste, quelques exemples suffiront à nous en convaincre :

• Un site web de partage de photos doit pouvoir dire qui a uploadé quelle image, depuis quelle adresse IP et à quelle date.
• L’application d’administration d’un site de e-commerce doit tracer toutes les modifications de prix pour empêcher un employé astucieux de baisser à 1 euro le prix de son téléphone préféré le temps de passer commande.

Pour revenir à des explications plus théoriques, les logs d’audit nous apportent :

• les informations nécessaires à la justice en cas d’infraction,
• la détection d’intrusions,
• la reconstitution des événements en complément des logs d’exceptions pour aider au diagnostique de problèmes.

Nous nous placerons dans le cas le plus fréquent où nous ne développons pas d’outil pour consulter ces informations d’audit et où un accès direct au média de stockage (grep sur fichier texte, sql sur base de données, etc) suffit.

Lire la suite de cet article …

De retour de la conférence Agile2010, je constate que les débats sur la certification Scrum Master sont toujours d'actualité. L'intérêt de la formation Certified Scrum Master de la Scrum Alliance est avant tout, à mon sens, de montrer qu'il existe un framework/cadre pragmatique regroupant des bonnes pratiques de développement et tenant réellement compte de la complexité inhérente du développement logiciel.
Ken Schwaber avec Scrum.org a voulu mettre en avant les principes fondateurs de Scrum en publiant le guide Scrum et en proposant ces formations certifiantes (avec de vrais tests associés).

Scrum Guide

La traduction en français par nos amis québécois : Guide Scrum

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

• James Gosling sur l’affaire Oracle vs Google
• ActiveMQ 5.4.0

Le coin de la technique

• Hibernate ne supporte plus CGLIB

Lire la suite de cet article …

Xebia est à la recherche d’un Ingénieur d’Affaires pour la rentrée.

Nous cherchons une personne ayant, entre autres, les qualités suivantes :

• Dynamisme.
• Exigence de soi.
• Créativité.
• Honnêteté intellectuelle.
• Connaissance de l’écosystème d’un cabinet de conseil.

Vous connaissez peut être la perle rare.

Le cas échéant, n’hésitez pas à lui communiquer nos coordonnées :

• Lire la suite de cet article …
  

J’ai constaté à de nombreuses reprises que des problèmes de montée en charge revenaient souvent dès lors qu’on utilisait WCF. WCF, pour Windows Communication Foundation, est le protocole lié au framework .Net qui permet la communication distante. Cela est, la plupart du temps, du à une vision « magique » de WCF, qui est censé fonctionner tout seul, sans configuration. Sauf qu’en réalité, cela ne marche pas. Voici donc quelques clefs pour comprendre comment configurer et utiliser WCF.

Configuration

WCF possède plusieurs paramètres de configuration qui déterminent sa manière de gérer les requêtes. Une analogie qui permet de bien comprendre leur rôle est celle de Theme Hospital, un jeu datant d’un certain nombre d’années.

Parcours d’un malade

Dans cette métaphore, un appel WCF est comparé à un malade qui va se faire soigner. Tout d’abord il détermine comment se rendre à l’hôpital, s’il y a plusieurs moyens, puis se présente à l’accueil pour créer un dossier, va ensuite en salle d’attente en attendant que soient libre à la fois une salle de consultation et un médecin pour le recevoir. Il va alors à cette consultation, qui représente le traitement effectif de la demande. Les différents éléments de ce parcours sont guidés par des paramètres de configuration, que nous allons détailler.

MaxConcurrentInstance

Ce paramètre représente le nombre de moyens d’accès à votre hôpital (routes, hélicoptère, ambulance, téléportation,…). Selon la manière dont est configuré un autre paramètre, InstanceContextMode, la stratégie des patients sera différente.

• InstanceContextMode=Single : Tout le monde emprunte la même voie d’accès. Le paramètre MaxConcurrentInstance ne sert donc à rien
• InstanceContextMode=PerSession : Tous les patients venant du même endroit (i.e. toutes les requêtes venant du même client) empruntent la même voie d’accès. Il y a donc besoin d’autant de voie d’accès que de clients différents
• InstanceContextMode=PerCall : Chaque patient emprunte sa voie propre. Il faut donc prévoir un nombre important de voies d’accès, et donc une valeur élevée pour le paramètre MaxConcurrentInstance

MaxConcurrentSessions

Ce paramètre représente le nombre de salles de consultation, et donc le nombre de requêtes qu’il est possible de traiter en parallèle. Attention cependant, une salle de consultation sans médecin est inutile. Ce paramètre doit donc avoir une valeur proche de MaxConcurrentCalls, bien que légèrement inférieure, afin de ne pas avoir de salle vide. Il faut également noter que, les malades étant quelque peu élitistes, ils souhaitent une salle de consultation dédiée à eux et aux malades provenant du même endroit. Une session est donc créée par client se connectant.

MaxConcurrentCalls

Ce paramètre représente le nombre de médecins. Il y en faut un peu plus que de salles de consultation, parce qu’il arrive qu’un médecin fasse une pause. Techniquement, cela signifie qu’une fois la session créée, il faut libérer du temps processeur pour traiter l’appel, et que cela se base sur le nombre de threads allouées par le ThreadPool (sur lequel nous allons revenir). Il faut donc prévoir les temps de switch et de concurrence entre threads qui peuvent conduire à la « pause » prise par les médecins.

MaxConnections

Ce paramètre représente la taille de la salle d’attente. Cela est quelque peu biaisé dans la mesure où sont comptabilisés aussi bien les malades en attente que ceux en consultation. Ainsi, l’augmentation de ce paramètre fournira une plus grande possibilité de mise en tampon des requêtes.

ListenBacklog

Ce paramètre représente le nombre de sièges devant l’accueil. Les patients ne sont pas encore enregistrés auprès de l’hôpital et attendent qu’une charmante secrétaire veuille bien s’occuper d’eux. De la même manière que dans le monde réel, ce paramètre doit être maintenu assez bas. Le patient n’est en effet pas encore dans le système et perdra vite patience. Cela correspond à une connexion TCP en état Half-open et se traduit par un timeout assez court au niveau du système. Augmenter ce paramètre conduit donc simplement à délayer la remontée d’erreur au client, et à changer la nature de l’erreur qui passe de « il n’y a plus de place » à « j’ai attendu trop longtemps », ce qui complique le débogage.

Préconisations

Bien qu’il soit impossible de donner des valeurs idéales pour ces paramètres, puisqu’elles dépendent bien évidemment du contexte applicatif, il est possible de donner des relations entre ces paramètres :

• MaxConcurrentInstance doit être dimensionné en fonction de la stratégie définie par le paramètre InstanceContextMode et du nombre de clients.
• MaxConcurrentSessions doit être dimensionné en fonction du nombre de clients.
• MaxConcurrentCalls doit être légèrement supérieur à MaxConcurrentSessions.
• MaxConnections doit être supérieur aux deux précédents et dimensionné en fonction des timeout positionnés. Il faut en effet éviter que les malades en salle d’attente perdent patience, là encore dans l’optique de remonter au plus vite les erreurs.
• ListenBacklog doit être bas.

À part pour ce dernier, il est à noter que sur dimensionner les paramètres n’a que très peu d’influence sur les  performances. En effet, il s’agit de maximums, le système ne créant les ressources qu’à la demande. Il faut cependant tenir compte des pics de communication, afin d’éviter que la création et le maintien des ressources liées à WCF ne prenne tout le temps de processeur disponible.

Autres éléments ThreadPool

Tout est configuré, les paramètres sont bons, et pourtant, cela ne fonctionne toujours pas ? Normal, vous n’avez pas assez de threads dans votre ThreadPool. Avec là encore, l’effet baguette magique, qui pousse à croire que le ThreadPool va fonctionner pour vous dans sa configuration par défaut. Pour comprendre l’influence du ThreadPool, il faut savoir que d’une part, chaque appel WCF est traité dans un thread d’I/O asynchrone, gérée par le ThreadPool, et d’autre part, que le ThreadPool à un fonctionnement particulier.

En effet, l’objectif ultime du ThreadPool, sa raison d’être, est d’amener ou de ramener le nombre de worker threads et de thread d’I/O asynchrones à son idéal, qui est par défaut égal au nombre de cœurs logiques de la machine. Par ailleurs, il est cadencé à 500ms, et obéit à l’algorithme suivant :

Sur un appel :

Si nombre_de_threads < idéal
Alors créer un thread
Sinon mettre en attente

Sur déclenchement du timer interne (500ms)

Si il y a au moins un demande en attente
Alors créer un thread
Sinon supprimer un thread

Pour illustrer son fonctionnement, prenons un cas d’école. Imaginons que chacune de vos threads peut traiter 10 appels par 500 ms, que vous recevez 50 appels par 500 ms et que vous avez 2 cœurs. On obtient le graphe suivant :

Figure 1 Évolution des traitements WCF dans le temps

On s’aperçoit que le fonctionnement du ThreadPool le fait osciller autour de l’idéal. Dans la pratique, le ThreadPool étant optimisé, on finit par arriver à l’idéal de traitement (dans notre cas, 5 threads), mais on s’aperçoit que cela peut prendre du temps et que, pendant cette période de ‘calibration’, les requêtes entrantes peuvent patienter un temps très long, au point même parfois de déclencher des timeouts.

La solution consiste à régler manuellement l’idéal du ThreadPool. Cela se fait par l’appel à la méthode System.Threading.ThreadPool.SetMinThreads, en dimensionnant les paramètres de l’appel en fonction de la capacité de traitement de vos services WCF. Attention cependant à ne pas trop relever ce paramètre, puisque cela conduit à la création de nombreux threads, ce qui peut être dommageable (temps de switch + taille mémoire de chaque thread)

Dans la pratique, ce nombre est largement supérieur au nombre de cœurs logiques de la machine. Il ne faut donc pas hésiter à monter jusqu’à une cinquantaine de threads par cœurs, sans que cela n’impacte réellement les performances, tout en gardant en tête que le dimensionnement idéal est « au plus juste » et se découvre par essais successifs.

Conclusion

Il n’y a pas de baguette magique ! Même si WCF est plus simple à utiliser que ses ainés, il demeure cependant qu’il faut savoir le configurer correctement afin d’en tirer le plein potentiel.

A l’occasion d’un récent projet, j’ai fait un tour des solutions de marshalling JSON, de Sojo à Jackson, en passant par FlexJSON et Jettison. Partant de mes besoins, je vous propose de suivre ce voyage au coeur des API JSON.
Il me faut une API:

1. Capable de sérialiser et désérialiser des arbres JSON sans adhérence aux beans modèles.
2. Pouvant travailler directement sur des flux.
3. Capable de tenir une charge conséquente, donc stable et performante.
4. Avec le minimum possible de dépendances.

Dans mon contexte, Sojo est la solution en place pour convertir des beans Java en chaîne JSON et inversement. C’est donc logiquement par Sojo que commence ce voyage.

Lire la suite de cet article …

Dans les projets agile, on utilise souvent des dashboards ou des tableaux Kanban. On les retrouve, soit sous forme de Post-its au murs :

soit sous forme électronique :

image de kanban electronique est une image de greenhopper prise sur http://www.atlassian.com/software/greenhopper/

La forme électronique présente plusieurs avantages :
- pas de post-its qui se décollent
- possibilité d’interagir entre équipes distantes
- possibilité de suivre automatiquement le temps de réalisation d’une tache
- etc.

Mais on leur reproche de perdre au moins deux gros intérêts :
1) Être visible à tout moment par l’équipe
2) Pouvoir interagir directement avec les Post-Its

Un simple vidéo-projecteur peut suffire a résoudre le premier point.

Le deuxième semble plus compliqué, la vidéo suivante vous montre le contraire.

Suggestion d'articles :

1. Comment concevoir vos applications iPhone ? Avec le post-it OCTO !

Aujourd’hui les grands groupes industriels font face à une multiplication des solutions de gestion dans leurs filiales avec un constat, plus on s’éloigne du centre et plus les solutions se font hétérogènes et exotiques. Ces différentes solutions vont de SAP, leader du marché pour lequel les processus sont presque gravés dans le code jusqu’à un simple ensemble d’outils de bureautique : un tableur pour suivre les commandes et un éditeur de texte pour émettre des factures. Entre ces deux extrêmes il existe quelques acteurs majeurs : Oracle EBS, SAGE, NAVISION… et de nombreux éditeurs locaux.

Comment rationaliser un écosystème aussi diversifié ?

Au niveau du groupe les gains d’une solution uniforme sur l’ensemble des entités sont évidents :

• reporting simplifié
• économies réalisée sur la formation aux outils
• capitalisation des équipes IT
• rationalisation du SI

D’un autre coté, les filiales en devenir veulent être capables d’évoluer rapidement sans être contraintes par un outil mais en ayant la possibilité d’informatiser un processus qui émerge de leur organisation. Et cela passe donc par des choix différents de ce qui est proposé par la maison mère. Il sera souvent préféré une solution ERP intermédiaire au core model pour de nombreuses raisons dont :

• des coûts moindres
• une maîtrise du périmètre des processus implémentés
• la rapidité de mise en Å“uvre

Ces points se résument à un choix entre simplicité et complexité qui est proposé par le centre. Or le coeur est complexe parce qu’il est riche et cette richesse est intrinsèquement lourde, ce qui est un atout au centre mais deviendra un frein dans les jeunes filiales.

Certains éditeurs essaient de pallier à cette problématique en proposant des solutions distinctes pour des BU de tailles différentes, c’est le cas par exemple avec SAP Business One, mais ce modèle ne fonctionne pas. Les synergies entre les solutions sont détruites au fur et à mesure que l’on essaie d’adresser les besoins de l’une ou l’autre des cibles.

Alors comment faire ? Et surtout, comment bien faire ?

A l’approche top-down qui définit une cible au centre, nous allons préférer l’approche bottom-up. Construire une application qui réponde aux besoins des petites entités, puis augmenter le périmètre avec des entités plus importantes jusqu’à rejoindre le core model… peut-être.
Nous allons donc nous inspirer de la méthodologie agile, itérative, pour construire le coeur de cet ERP de façon incrémentale.

La base doit être acceptable par de toutes petites structures et solide afin de pouvoir grandir. Pour cela les critères de choix vont être les suivants :

• des coûts réduits
• une technologie éprouvée
• un périmètre fonctionnel qui couvre 80% des besoins

C’est donc naturellement que nous allons chercher des candidats du coté des projets open source matures : OpenERP, Compiere, Neogia, ERP5…. Souples et robustes, ils sont modulaires ce qui est l’empreinte d’un développement communautaire au niveau de l’architecture logicielle. Cette modularité est la garantie d’une évolutivité future. De plus, les projets open source nous apportent des technologies ouvertes et standardisées facilitant l’intégration avec d’autres systèmes.

Et c’est un point important, l’approche d’OCTO n’est pas de créer un second core model décorélé du centre, en concurrence avec le centre. Il s’agit de réaliser un système qui soit potentiellement une marche vers le système central, une marche qui rapproche du centre. Ainsi cette solution apporte de la valeur à la filiale ET au centre.

Le choix d’une approche incrémentale pour la rationalisation du SI est différenciante dans le sens où il s’agit d’accompagner la création de valeur depuis le début d’une activité. Le système qui va être implémenté doit aider l’organisation cible sur un cycle court en terme de réalisation de « business » et sur un cycle long en l’aidant à s’intégrer dans le core model du centre. Et ceci de façon progressive. La méthode agile va nous permettre de faire évoluer en douceur l’ERP retenu vers les limites fixées : couvrir X% des processus, supporter une charge maximum de X utilisateurs…

Bien que les notions d’ERP et d’agilité puissent paraître antinomiques, il s’avère possible de profiter du meilleur des deux mondes dans ces projets souvent réputés pour être très lourds à cadrer, à réaliser et à mettre en oeuvre.

Dans un prochain article, nous verrons comment aborder ce type de projet d’un point de vue organisationnel et fonctionnel. Les projets ERP forment intrinsèquement un ensemble de fonctionnalités fortement imbriquées et nous verrons comment, avec une approche agile / incrémentale, nous allons pouvoir segmenter ces projets dans des livraisons fréquentes et fonctionnelles apportant de la valeur aux métiers régulièrement.

Suggestion d'articles :

1. Agilité et SOA ?