Blog Novedia Solutions

En route pour le JUG Summer Camp 2010 à La Rochelle

Thu, 26 Aug 2010 14:59:52 GMT

Le JUG Summer Camp 2010 c'est quoi ?

On ne présente plus le principe du JUG (Java User Group), population devenue depuis maintenant 2 ans implantée dans nos contrées française. L'année 2010 correspond à une nouvelle étape dans l'évolution de l'animation de ces groupes d'utilisateurs, avec l'apparition de formats plus longs que les rencontres en soirée.

Il y a eu en début d'été l'évènement SophiaConf co-organisé par le Riviera JUG, un autre évènement est imminent et se déroulera à La Rochelle : Le JUG Summer Camp 2010.

Cet évènement d'une journée complète, organisé par le Poitou-Charentes JUG se tiendra le vendredi 10 septembre et sera constitué de plusieurs présentations animées par des professionnels francophones (point très important) reconnus dans l'écosystème Java.

Pourquoi s'y rendre ?

Ce genre d'évènement est encore rare en France et il est plus accessible que les conférences européennes comme Devoxx et Jazoon (que nous vous encourageons tout de même fortement à fréquenter).

Mais ce n'est pas tout : les organisateurs ont fait le maximum pour vous encourager à venir :

dernier jour de la semaine
lieu proche de la gare de La Rochelle
conférence non seulement gratuite, mais également éligible au DIF (Droit Individuel à la Formation)
des speakers francophones et de qualité
des sujets récents et novateurs

Novédia sera représenté

Nous seront 3 consultants Novédia à profiter de la conférence, Matthias, Jean-Max, et Eric.

Outre l'objectif évident de veille et de rencontre de nos pairs, l'un de nos objectifs sera aussi de restituer les sessions suivies aux autres collaborateurs et de les partager avec les lecteurs de ce blog.

Les sessions

Le détail des sessions est disponible sur le site des organisateurs.

La session à ne pas rater :

Eric : Quoi de neuf dans Hibernate : une perspective de JPA (Emmanuel Bernard)
Jean-Max : Google App Engine : le cloud façon Google (Christophe Jollivet)
Matthias : Maven 3 au coeur de la forge logicielle (Nicolas De Loof)

L'agilité dans une organisation traditionnelle - rétrospective et perspectives

Fri, 30 Jul 2010 08:39:12 GMT

Ce billet fait suite à « L'agilité dans une organisation traditionnelle - un sprint de transition » Son objectif est de proposer un premier bilan du sprint de transition dont la préparation avait été décrite. Je vous propose également une restitution de la rétrospective faite par l'équipe sur les 6 derniers mois, avec pour principal objectif de préparer la suite.

Ayant pris du retard dans ma série de billets, il faut savoir qu'à l'heure où je rédige ce billet :

l'application est en production
la suite des développements est en cours et une mise en production est espérée pour fin septembre
l'équipe en est dans son second sprint (sprints de 2 semaines)

Je ne me ferais pas l'écho des interrogations levées à la fin du précédent billet, cela fera l'objet d'un billet à venir se focalisant sur l'analyse des deux premiers sprints.

Retour sur le sprint de transition

Le sprint de transition n'était pas borné dans le temps : sa fin était implicitement définie par le démarrage officiel des nouveaux développements.

Pendant ce sprint, l'équipe a également été sollicitée :

pour corriger les dernières anomalies identifiées en recette
pour préparer la mise en production
pour de premières présentations de spécifications fonctionnelles (générales et détaillées)

Il était clair que tous les items techniques identifiés ne pourraient être traité. En fait l'équipe n'a même pas pu traiter la moitié des items qui avaient été estimés (ceux qui avaient recueilli le plus de suffrages), soit 41 points sur le total de 118 points du périmètre priorisé.

Pour autant, l'équipe n'a pas chômé et a nettement avancé dans la lutte contre la dette technique, mais aussi dans les pratiques de test.

Outre les tâches incontournables concernant la préparation de la production, on notera par exemple les réalisations suivantes :

Améliorer la couverture de code en renforçant les tests unitaires : objectif atteint avec une augmentation de plus de 40 tests et 6% de la couverture sur le module core (nous partions d'environ 60%).
Renforcer les tests Selenium : tâche qui s'est avérée très coûteuse pour un résultat assez décevant et une maintenance périlleuse en prévision. L'objectif initial (nombre de scénarios) n'a pas été atteint, mais l'équipe a accumulé de l'expérience sur les bonnes pratiques dans le contexte applicatif qui est le sien.
Initier les tests Wicket : la bonne surprise avec des objectifs initiaux atteints et un début d'engouement de l'équipe pour les tests unitaires côté IHM. A l'issue du sprint, la couverture du module web avoisinait les 6% et les bonnes pratiques étaient documentées.
Mettre en place des versions locales de WDSLs pour une utilisation en développement : objectif atteint avec désormais un build local (génération des clients via plugin Maven) s'appuyant sur des versions locales de WSDLs, évitant d'être bloqué (freeze Eclipse du fait de l'intégration Maven) en cas d'indisponibilité, tout en ayant un build sur les Urls cibles au niveau du serveur d'intégration continue (permettant de détecter de potentielles erreurs en cas de désynchronisation des WSDLs).
Mettre en place des mocks pour les WebServices utilisés : objectif également atteint, celui de ne pas être bloqué lors de développements par une indisponibilité durable et de pouvoir démarrer l'application avec des mocks. Une variable d'environnement, un alias pour les beans Spring reprenant la valeur pointée correspondant à l'implémentation à utiliser, un peu de configuration Maven et Jetty et il nous est désormais très facile de basculer entre les deux modes.

D'autres éléments à relever :

Le Scrum quotidien a perduré, et à heure fixe (9h45).
L'équipe s'est approprié le nouvel espace Wiki et a largement documenté les éléments les plus pertinents et critiques.(environnements, éléments techniques, base de connaissance sur les pratiques de tests et outils mis en place). Elle est d'ailleurs très loin devant les autres équipes dans son adoption et usage du Wiki.
L'ajout de critères d'atteinte des objectifs d'une tâche au dos des post-its est une vraie révolution dans le rapport de l'équipe avec les tâches : chacun est attentif aux critères et s'assure qu'ils sont biens remplis avant de passer la tâche à « Fait », des discussions s'engagent même en cas de besoin sur l'interprétation des objectifs. Un très bon pas vers l'idée de définition de « Fait ».
Pendant 2 à 3 semaines, l'équipe avait un (tout au plus deux) objectif(s) précis : réduire la dette technique (notamment via le renforcement des tests) et préparer la mise en production. Cela s'est révélé très important en ce qui concerne la motivation de l'équipe, bien plus manifeste que sur de longues périodes lorsqu'elle avançait au radar.
Sans aller jusqu'au binômage, le niveau d'interactions de l'équipe a augmenté : sollicitations pour avis externe, pour relecture de documentation, feedback sur des améliorations pouvant être apportées. Tout le monde est concerné par l'ensemble des tâches présentes dans le backlog de sprint.

Nous verrons dans un billet ultérieur que ce sprint est le point de départ de la montée en puissance de l'équipe dans l'adoption et la diffusion des principes agiles. A cela s'ajoute également la rétrospective d'une bonne demi-journée que j'ai eu l'occasion d'animer et que je vais vous restituer.

Rétrospective des 6 derniers mois

Un programme assez dense :

Inventaire des satisfactions, identification des facteurs clés et des éléments à maintenir / renforcer ;
Projection du projet sur les 12 principes du Manifeste Agile (niveau d'adoption) ;
Petit jeu destiné à faire prendre conscience des méfaits de la parallélisation des tâches (à titre individuel) ;
Déceptions / insatisfactions relevées par l’équipe ;
Définition du FAIT ;
Définition des initiatives complémentaires que l’équipe souhaite mener au cours du projet à venir.

Inventaire des satisfactions, identification des facteurs clés et des éléments à maintenir / renforcer

Pour démarrer la rétrospective, rien de tel que de parler des satisfactions. En voici quelques unes relevées par l'équipe :

Organisation agile de l’équipe de développement, ainsi que la communication qui l’accompagne ;
La transparence au sein de l’équipe de développement et à destination des autres membres du projet / service ;
Richesse du contexte technique ;
Mise en pratique / apprentissage de pratiques agiles ;
L’entraide dans l’équipe de développement ;
La qualité du code ainsi que les feedbacks reçus sur la qualité de l’application ;
Inspiration mutuelle sur le thème de l'agilité : il n’y a pas un unique chef d’orchestre, tout le monde contribue à l’adoption et adaptation des pratiques au contexte projet ;
Les engagements pris par l’équipe ont été tenus.

En matière de facteurs clé amenant à ces satisfactions, ont été mentionnés :

L’implication de l'équipe de développement ;
Les moyens mis en œuvre pour favoriser la circulation de l'information (Daily Scrum notamment) ;
Des développeurs interchangeables et non spécialisés ;
Les échanges et feedback (relecture de code, pédagogie) entre les membres de l’équipe de développement.

Enfin, d'après l'équipe, pour que ces satisfactions perdurent et s'améliorent, les points essentiels à garder dans le viseur sont :

Le Daily Scrum ;
Le courage : avoir du courage même pour les tâches rébarbatives ;
La documentation sur le Wiki et l'appropriation collective du code (cf. syndrome du bus et de la perte brutale d'un membre de l'équipe).

Projection du projet sur les 12 principes du Manifeste Agile (niveau d'adoption)

L'une des motivations de la rétrospective était d'examiner le niveau d'adoption des pratiques agiles à l'échelle du projet (à nuancer, compte-tenu de la configuration en MOA/MOE, par rapport à l'échelle de l'équipe). Se projeter sur les 12 principes du Manifeste Agile m'a donc paru un bon moyen.

Je vais me limiter à décrire l'analyse faite pour quelques uns (l'adoption étant évaluée sur une échelle allant de 0 – nulle – à 5 – totale) des principes agiles, même si chacune des 12 analyses est extrêmement précieuse et sert à guider l'équipe / le projet.

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Evaluation : 5/5
Analyse : L'équipe en est convaincue et l'applique au quotidien dans les interactions touchant au projet.

“Continuous attention to technical excellence and good design enhances agility.”

Evaluation : 4/5
Analyse : L’équipe le met en œuvre, dans la limite du temps qu’elle peut y consacrer (cf. sprint technique de transition), positionne les tests et le refactoring dans ses priorités techniques.

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

Evaluation : 4/5
Analyse : Les membres de l’équipe sont motivés et ont le sentiment d’avoir la confiance de leur management (libertés et autonomie). Quelques progrès lui paraissent cependant possible concernant l’environnement, les moyens, et l’écoute.

“The best architectures, requirements, and designs emerge from self-organizing teams.”

Evaluation : 3/5
Analyse : Même si l’équipe n’a pas atteint une maturité d’auto organisation, elle a l’impression que son mode de fonctionnement contribue à l’émergence de solutions réfléchies. Difficilement applicable sur l’ensemble du périmètre (ex. relation SAP).

“Simplicity--the art of maximizing the amount of work not done--is essential.”

Evaluation : 3/5
Analyse : Tentatives de pratique de TDD. Volonté de faire simple. A l’opposé, beaucoup de temps passé sur les briques complexes d’interopérabilité (SAP / SOA Suite).

“Business people and developers must work together daily throughout the project.”

Evaluation : 2/5
Analyse : Si on considère que « Business people » = MOA, les échanges quotidiens se renforcent de plus en plus malgré la distance et la contrainte organisationnelle. Si on considère que « Business people » = Métier, pas la moindre interaction ni de retour sur l’application qui n’arrive jusqu’aux oreilles des développeurs.

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

Evaluation : 2/5
Analyse : Le rythme des derniers mois était trop soutenu, avec des phases de pics par moment, pour que l’équipe puisse le maintenir. L’équipe pense que son investissement est bien plus important que celui des sponsors et utilisateurs.

Avec des évaluations allant de 2/5 à 5/5, l'adoption sur le projet a été estimé en moyenne à un peu plus que 3/5. Néanmoins, avec un peu de recul, on notera que l'évaluation est parfois confuse car l'équipe a du mal à rester dans un même référentiel (l'équipe de développement vs. l'ensemble des acteurs du projet).

Petit jeu destiné à faire prendre conscience des méfaits de la parallélisation des tâches (à titre individuel)

J'ai voulu faire faire à l'équipe un petit exercice pour la sensibiliser aux problématiques de productivité et notamment les méfaits de la réalisation par une personne de plusieurs tâches en parallèle.

Le principe du jeu est de demander aux participants d'écrire les suites 1..10, A..J et I..X sur une feuille de papier, chaque suite occupant une colonne :

scénario 1 : en construisant chaque suite en parallèle (on commence par une ligne 1 – A – I, suivie de 2 – B – II, etc.)
scénario 2 : en construisant chaque suite en série (première colonne avec les chiffres arabes, puis seconde colonne avec les lettres de l'alphabet, et enfin dernière colonne avec les chiffres romains)

Chronométrer le tout, observer et mesurer :

un ratio allant de 2 pour 1 à 3 pour 1 dans le temps nécessaire à l'exécution de l'exercice entre les deux scénarios (maximum de 115 secondes pour le 1er, minimum de 23 secondes pour le second) ;
des erreurs commises lors de l'exécution du premier scénario (« fini ! … ah non mince ... ») ;
une concentration beaucoup plus grande nécessaire pour le premier scénario.

L'exercice a permis à l'équipe de prendre conscience de l'importance de se focaliser sur une seule tâche à la fois. La petite discussion qui a suivi l'exercice a également été l'occasion de reparler de la notion de perturbation (externe et interne) pour déboucher sur la mention du Pomodoro (même si l'équipe n'est pas forcement mature pour ce genre de pratique).

Un bon point pour l'avenir (imaginez si l'équipe, grâce à du bon sens, arrivait à multiplier sa productivité par 2 ...).

Déceptions / Insatisfactions relevées par l’équipe

Passons aux mauvaises nouvelles. En effet, la situation est loin d'être idéale et la rétrospective est également l'occasion pour l'équipe d'exprimer ses déceptions et mécontentements.

Nous avons fait une première passe de déceptions / insatisfactions, chacun pouvant s'exprimer et les autres l'interroger pour bien comprendre le point soulevé. Nous en sommes arrivés à une liste de 15 items, ce qui fait bien évidemment beaucoup.

Nous sommes ensuite passé au vote : chaque membre disposait d'un jeu de cartes de planning poker et pouvait voter à face cachée (sans être influencé par les autres) de 0 (pas concerné) à 100 (extrêmement impactant). Ainsi, nous sommes arrivés à hiérarchiser les déceptions et avons pu nous concentrer sur les plus marquantes.

Pour chacun des 8 items ayant retenu le plus de vote, l'équipe a réfléchi aux axes et sources d'amélioration. En voici quelques uns.

Jusqu’à peu, le Daily Scrum n'était pas à heure fixe

Impact : 353/500
Axe d'amélioration : Daily Scrum à 9h45 jusqu’à fin juillet, puis rechercher un consensus sur l’horaire satisfaisant toute l’équipe.

Le workflow JIRA empêche l’équipe de s’auto-organiser et le chef de projet devient un point de contention

Impact : 333/500
Axe d'amélioration : Sans révolutionner le workflow, permettre aux développeurs de s’attribuer un ticket serait une amélioration notable pour l’équipe.

Scrum Master n'est pas un véritable rôle dans l'équipe. Soit il est combiné au rôle de chef de projet, soit il est absent à défaut de libérer du temps pour un développeur

Impact : 320/500
Axe d'amélioration : L’équipe souhaiterait prendre le temps de réfléchir aux objectifs du Scrum Master sur Aecetia, et de définir son rôle de manière explicite. L’équipe souhaiterait que chacun puisse endosser le rôle de Scrum Master le temps d’un sprint.

L’équipe a le sentiment de ne pas être prise au sérieux

Impact : 300/500
Axe d'amélioration : A l’image des présentations DBA faite dans le pôle, saisir l’opportunité de faire des présentations courtes sur Scrum et le vécu / l’expérience de l'équipe. Exposer les règles du Daily Scrum et convier les gens en tant que spectateurs.

Nous verrons en conclusion la suite donnée à cette réflexion sur les insatisfactions.

Définition du FAIT

Ayant noté des divergences (post-it déplacé alors que le code n'est pas commité) et difficultés (navigateur cible Internet Explorer, la majorité de l'équipe étant rompue à l'utilisation de Firefox) sur la vision du FAIT, j'avais également mis comme objectif une première définition écrite du FAIT.

Arrivant en fin de journée, le premier jet ne m'a pas paru satisfaisant (la fatigue aidant) et nous avons repris la réflexion plus tard, ce qui nous a amené à la liste suivante :

Code commité sur toutes les branches concernées ;
Existence de test(s) unitaire(s) passant ;
Si l’IHM est concernée, présence de test(s) Wicket ;
Avoir testé la fonctionnalité dans son ensemble sur un cas le plus proche de la réalité possible ;
Avoir réfléchi à la pertinence d’enrichir la documentation ;
Testé avec IE7.

D'autres éléments ont été évoqué, mais n'ont pas obtenu l'unanimité (raison entre parenthèses) :

Fonctionnalité potentiellement livrable (définition floue)
Déploiement avec JBoss (perte de temps)
Testé avec JBoss (perte de temps)

Voilà l'équipe armée avec SA définition de FAIT (portant sur les User Stories), prête à l'appliquer sur les prochains sprints.

Définition des initiatives complémentaires que l’équipe souhaite mener au cours du projet à venir

Dernière réflexion menée par l'équipe en marge de la rétrospective, l'identification d'initiatives que l'équipe peut/doit porter.

En résumé, 3 thèmes ont été abordés :

Les tests d'IHM ;
La méthodologie et gestion de projet ;
Le Scrum Master.

A l'image de la priorisation du backlog technique, chaque membre de l'équipe avait 12 points de valeur à attribuer sur le backlog de 12 tâches identifiées, ce qui a permis de dégager les priorités, à savoir dans l'ordre :

Définir clairement la responsabilité des tests Wicket vs. tests Selenium ;
Faire un suivi des estimés et tracer le burndown de sprint ;
Impliquer toute l’équipe et non le seul Scrum Master ;
Estimer les User Stories / Fonctionnalités en points ;
Faire une démo en fin de chaque sprint (nice to have : en présence d’utilisateurs) ;
Faire une rétrospective tous les 2 sprints ;
L’équipe doit réfléchir continuellement aux rôles qu’elle souhaite que le Scrum Master ait, et les expliciter à l’image de la définition du « FAIT » ;
Permettre à chacun d’endosser le rôle de Scrum Master à tour de rôle. Sprints de 2 semaines, 2 sprints successifs par Scrum Master ;
Découper les User Stories / Fonctionnalités en tâches estimées en heures. Ne pas accepter de tâches de plus de 8h.

Une première définition du rôle du Scrum Master

L'une des décisions à effet quasi immédiat, pour laquelle l'équipe s'est réunie peu après la rétrospective, a été la définition du rôle du Scrum Master.

Cette définition avait plusieurs objectifs :

adapter le rôle à l'organisation et aux conditions dans lesquelles évolue l'équipe ;
permettre à chaque Scrum Master potentiel d'avoir un référentiel suffisant pour mener à bien sa mission sans nécessiter d'avoir reçu une formation ;
diffuser la vision de l'équipe au delà de l'équipe ;
pouvoir rétroagir et affiner les composantes du rôle au fil des sprints.

La vision générale de l'équipe est que le Scrum Master (malgré certaines formulation pouvant laisser penser cela) n'est pas un substitut de chef de projet, n'a pas d'autorité sur l'équipe, mais plutôt doit aider l'équipe à s'améliorer.

Différents thèmes ont été formalisés :

Au service de l’équipe : moyens, protection, amène l'équipe à s'interroger sur la répartition de la charge ;
Respect des pratiques agiles : garant ultime du Daily Scrum, s'assure de l'appropriation de la définition du « FAIT », organise les démos de fin de sprint et s'assure que l'équipe les prépare ;
La gestion du Product / Sprint Backlog : proxy Product Owner ou coaching de ce dernier, backlog priorisé, mesure la vélocité et les indicateurs, facilite les séances de planification ;
Amélioration continue et ambiance : préparation et facilitation des rétrospectives, célébrations, suivi des garants/porteurs d'améliorations/initiatives.

Bilan et actions entreprises

Les retours sur la rétrospective ont été plutôt positifs, permettant à l'équipe de s'exprimer et d'oser communiquer sur ce qui va mais aussi ce qui ne va pas, de s'engager dans la voie de l'amélioration continue en rendant sa réflexion visible de tous. L'équipe a désormais une identité. Le fait d'avoir une vision commune permet à chacun d'en parler, de s'impliquer, par ce qu'il sait (et c'est indéniable : cela rassure les plus discrets / prudents) qu'il a le soutien de l'ensemble de l'équipe.

Faire une rétrospective est une chose, rendre visible le résultat et les enseignements en est une autre. Pour ce faire, j'ai sacrifié un peu de temps dans la rédaction d'un compte-rendu (qui m'aura mine de rien été très utile dans la rédaction de ce billet) déposé dans le wiki et dont les principaux éléments ont été restitués par l'équipe sur son scrum board pour les communiquer à toute personne curieuse :

définition de « FAIT » ;
insatisfactions, pistes d'amélioration, avec une colonne « Garant(s) » permettant à quelqu'un de se désigner pour veiller à ce que les choses évoluent dans la bonne direction ;
liste des initiatives envisagées, avec une colonne « Garant(s) » permettant à quelqu'un de se désigner comme pilote de l'initiative ;
définition du rôle de Scrum Master ;
niveau d'adoption des principes agiles ;
etc.

Si la colonne « Garant(s) » tarde un peu à se remplir (essentiellement remplie avec le garant "Scrum Master" en cohérence avec la définition du rôle de ce dernier) cela ne veut pas pour autant dire que les actions sont oubliées : la grande visibilité garantit que cela ne tombera pas dans l'oubli et même sans garant les choses peuvent évoluer grâce à l'action collective et la vision partagée par l'équipe.

Cette communication a eu pour effet ces dernières semaines de susciter la curiosité de personnes concernées ou non par le projet sur lequel travaille l'équipe (autres équipes de développement, architectes, responsable technique, chargé d'étude, direction, etc.) que les gens passent et marquent un léger temps d'arrêt ou qu'ils lisent et engagent la conversation avec l'équipe.

Le virus est libéré et se propage naturellement par la méthode douce (devrait-je plutôt parler d'inception en référence au film qui tient l'affiche en ce moment ?). Affaire à suivre.

Ma seconde journée à l'USI 2010

Tue, 13 Jul 2010 08:43:43 GMT

La première journée de l'Université du SI a mis la barre relativement haut. Pour ma part, aucune des sessions suivies le jeudi ne m'a déçue, ce que je ne pourrais pas dire pour celles du vendredi malgré un démarrage sur les chapeaux de roues avec Neal Ford et Martin Fowler.

Mon top 3

Keynote « Pourquoi, pas comment » de Neal Ford et Martin Fowler (ThoughtWorks)
Performance des sites web, quoi et comment, par Eric Daspet (SQLI)
Keynote de Derrick de Kerckhove (Université de Toronto)

Les différentes sessions en concentré

Pourquoi, pas comment. Par Neal Ford et Martin Fowler (ThoughtWorks)

Une idée forte : Le pair-programming c'est la combinaison d'un hémisphère gauche d'un hémisphère droit, compensant l'impossibilité pour un être humain d'activer ses deux hémisphères en même temps.

La présentation par deux des modèles des plus Geeks d'entre nous avait pour but de mettre en avant la pensée agile. Notamment axée autour de valeurs prônées par le Manifeste Agile, la présentation a été largement illustrée par des exemples et anecdotes.

Le premier aspect abordé a été le passage d'une approche prédictive (planification) à une approche adaptative. En effet, le succès d'une planification prédictive repose sur le contenu de la planification, lui même dépendant de la stabilité du besoin, chose assez rare. Il est donc bien plus sain d'avoir une planification qui s'adapte à l'évolution du besoin, et ceci avec un délai de réaction / ajustement le plus faible possible.

Le second thème abordé est l'inversion de la relation entre le process et les hommes, illustré par l'expression « people first ». Cela passe notamment par la communication, le feedback et la visibilité (mesure du progrès), des pratiques comme le binômage ou la tenue de rétrospectives.

Dernier thème cher aux intervenants : le fun. En effet, cette composante n'est pas à négliger et contribue à la bonne ambiance tout en améliorant le quotidien des équipes (l'exemple de la lecture d'un son personnalisé par membre après un build passant illustre bien la combinaison du côté fun et de l'amélioration de la communication et de la productivité).

How the web was won, and other useful stories, par Mark Surman (Mozilla)

Une idée forte : « Open is the logic that wins in the digital world »

Mark Surman a retracé l'histoire du Web et notamment la situation du Web en 2003 qui a été l'un des déclencheurs de la création de la fondation Mozilla. Selon lui, les caractéristiques clés de l'internet sont la transparence, l'ouverture, le contrôle partagé, donnant lieu à un phénomène participatif. Il nous a expliqué que le point de départ de la fondation Mozilla a été le constat en 2003 d'une domination à plus de 98% d'Internet Explorer comme navigateur, marquant l'absence totale de standards et donnant lieu à des sites allant jusqu'à réclamer le navigateur à l'utilisateur.

Une affirmation percutante de la part du speaker a consisté à dire que l'ensemble du web était Open Source (on comprend mieux les détracteurs de la technologie Flash entre autres) puisqu'on peut afficher la source d'un document et réutiliser du code à souhait. C'est c'est aspect que défend la fondation par l'intermédiaire d'un extrait de son manifeste : « guard the open nature of the Internet ».

Kanban in Operations, par Mattias Skarin (Crisp)

Une idée forte : L'implication du management est primordiale

Mattias Skarin, co-auteur de Kanban et Scrum - tirer le meilleur des deux, nous a présenté un retour d'expérience sur l'amélioration de la productivité d'une équipe d'exploitation chez l'un de ses clients.

Il a illustré la mise en place d'un board Kanban destiné à aider l'équipe à gérer les priorités et la collaboration entre l'équipe d'exploitation et celle de développement, amenant au fil du temps l'organisation à évoluer vers une service exploitation partie intégrante du service développement (au départ les services étaient indépendant). Un bel exemple illustrant les bénéfices du Kanban en matière de communication, collaboration, et gestion de flux de travail.

A noter que le speaker a insisté sur l'importance d'impliquer le management dans ce type d'initiatives. Pour l'anecdote, le manager avait lui aussi un tableau Kanban à 2 slots pour traiter des points de blocages externes à l'équipe. Et c'est à l'équipe de libérer un slot en décidant si le manager a débloqué la situation ou non.

Performance des sites web, quoi et comment. Par Eric Daspet (SQLI)

Une idée forte : « Moins, c'est plus (de performance) »

L’objectif du speaker était de nous sensibiliser à l’optimisation du frontend des sites web. En effet, il nous a expliqué que bien souvent les mesures de performance se focalise sur le backend, à savoir le temps de génération d’une réponse HTTP. Il préconise justement des mesures complètes incluant l’affichage complet de la page (images, scripts d’initialisation, etc.) pour se rendre compte que la partie liée au frontend (le rendu dans le navigateur) peut représenter parfois 95% du temps total et donc justifier qu’on s’attache à optimiser cette partie.

Parmi les conseils prodigués (dont certains ressembleront sans doute à du bon sens pour les spécialistes du domaine), on notera la diminution du nombre de requêtes HTTP (utilisation du cache HTTP, regroupement d’images en sprites), la diminution du volume (compression HTTP et images pouvant être pris en charge par le serveur Web), le contournement de la séquentialité des appels (répartir des ressources sur plusieurs domaines pour pouvoir les charger en parallèle, utiliser des appels JavaScripts asynchrones). Eric nous a également présenté quelques astuces et recommandé des outils comme Yslow et Google Page Speed.

« Un regard sur l’ouverture ». Keynote de Jean-Philippe Courtois (Microsoft)

Une idée forte : Microsoft veut être parmi les leaders sur le Cloud

Dans le cadre du thème de la demi-journée (Ouverture), Jean-Philippe Courtois nous a communiqué un certain nombre d’informations illustrant le fait que Microsoft s’investit sur le sujet bien plus que ce que les clichés usuels peuvent laisser à penser (mention de Codeplex, des différentes initiatives et collaborations avec de petits éditeurs, ). Il a notamment invoqué des sujets comme la propriété intellectuelle et les brevets, présentant notamment les contraintes que nous avons en Union Européenne (traduction dans toutes les langues des Etats membres) et des initiatives en cours. Il estime notamment qu’il est important que les règles sur les brevets évoluent vers une description précise des concepts à protéger, afin d’éviter les situations qu’on a pu rencontrer par le passé.

Autre sujet abordé, l’interopérabilité entre les produits et concernant les données. Il en ressort que la notion de choix est primordiale. Quelques chiffres pour conclure sur la tendance Cloud : le nombre d’applications payantes déployées sur Azure dépasse les 10 000, 90% des 300 00 développeurs MS sont sur des projets Cloud, 9.5 milliards de dollars d’investissements.

Jean-Philippe Courtois a consacré une bonne partie de sa keynote pour laisser l’audience l’interroger sur des sujets parmi lesquels on aura eu entre autres les brevets, Internet Explorer, la prochaine version de Windows, la position de Microsoft concernant les DRM.

Keynote de Derrick de Kerckhove (Université de Toronto)

Une idée forte : Marshall McLuhan (1911-1980) avait tout prédit dans les années soixantes

Derrick de Kerckhove est le directeur du programme McLuhan « Culture and Technology » et professeur au département de français de l'Université de Toronto. Il nous a invité à prendre de la hauteur sur l’évolution des usages à travers les siècles passés et la prédominance / importance de l’imprimerie et de l’écriture, pour en arriver à la seconde phase de l’ère numérique et l’appropriation du langage.

Il nous a parlé de ce qu’il considère être l’ère du tag, l’a abondamment illustré par des phénomènes plus ou moins connus comme Twitter, Chatroulette, etc., ainsi que des initiatives comme Airtag.

Unleash your Domain, par Greg Young

Une idée forte : L'approche DDD permet de répondre plus aisement à des problématiques d'audit des modifications sur les objets métier

Greg Young, l'un des spécialistes du Domain Driven Design, a essayé de sensibiliser l'auditoire sur les problèmes que se propose de résoudre le DDD. L'un des messages délivrés concerne notamment la notion d'impedance mismatch qui est d'après lui résolue par l'approche DDD, tout comme elle permet un meilleur suivi et plus facile des opérations menées sur un objet métier (être capable de distinguer la différence entre l'ajout de 3 éléments suivi du retrait d'un élément dans un panier, et l'ajout de 2 éléments, l'information de retrait pouvant être très utile).

Session malheureusement trop courte/speed coupée dans son élan.

The challenges of long-term software quality in Open Source, par Juergen Höller (SpringSource)

Une idée forte : Le succès sur le long terme de Spring repose sur un modèle de type Benevolent Dictator

Juergen Höller, après avoir présenté la genèse du framework Spring et dressé l'inventaire du portfolio Spring, a expliqué les enjeux de la maintenance du framework. Ainsi, même si le framework ne repose que sur peu de librairies obligatoires, il intègre un grand nombre de third parties (framework et serveurs d'application) pour en simplifier l'usage pour les développeurs, ce qui nécessite de s'adapter aux évolutions et d'être compatible une gamme de versions.

Il nous a également expliqué que la nature même d'un projet Open Source comme Spring impose à ses développeurs d'être très attentif sur la qualité du code, lequel est visible de tout le monde, car la moindre erreur sera inévitablement vue et rappelée. Sur les échanges de l'équipe de développement avec la communauté (suggestions, rapport de bug, forums, etc.), il estime qu'il est important de répondre dans un délai le plus court possible afin de fidéliser les membres et les encourager à poursuivre le feedback et à s'investir, ce qui est également favorisé par la mise à disposition de builds quotidiens (nightly build) et la présence aux conférences.

Concernant l'évolution du framework au fil du temps, il a décrit celle-ci comme opposée à une révolution (ex. Struts 1 vers Struts 2) qui serait très préjudiciable quant à l'adoption de Spring.

Enfin, parmi les facteurs clé de succès mentionnés, on retrouvera l'importance des outils de communication pour des équipes distribuées à travers toute la planète comme celles de SpringSource (Skype, rencontres physique au moins 2 fois par an), l'importance de se connaître, et le choix d'un modèle de “Benevolent Dictator” (à l'opposé de celui de l'Apache Software Foundation qui se base sur la méritocratie). Ce modèle, prônant une gouvernance par un leader technique s'inscrivant sur la durée, est selon lui adapté à la mise en oeuvre et maintenance de frameworks.

Libérer les énergies de la DSI, par Pierre Pezziardi (Octo Technology)

Une idée forte : La DSI 2.0 passe par la mise en place d'équipes produit

Pierre Pezziardi nous a délivré des conseils basés sur l'accompagnement qu'il a mené au sein de la DSI de Gefco. Il nous propose notamment une nouvelle façon de mixer les gens autour d'un produit et non les regrouper par spécialités, de s'appuyer sur la définition d'un manifeste (référence à Tribes par Seth Godin) et de standards ouverts et émergents.

Parmi les facteurs permettant d'augmenter les performances d'une équipe, il cite notamment l'autonomie, la maîtrise et l'accomplissement, ainsi que le sens / objectif.

Keynote de Juan Enriquez (Biotechonomy LLC)

Une idée forte : “Read it, copy it, write it”

Cette keynote, dont le sujet portait sur la génétique, est difficile à restituer. Juan Enriquez, lequel se dit “I'm not a futurist, I'm an historian” nous a rappelé quelques chiffres fondamentaux liés à la génétique et à la constitution de l'ADN des hommes et autres formes de vie animales. Il a par la suite tiré quelques parallèles entre la génétique et la notion de code (binaire) tel qu'on le perçoit dans le milieu IT : par exemple, la faible différence dans la constitution de la signature génétique d'un homme et d'un rat, avec une différence considérable sur le résultat montrant qu'une simple inversion de 0 et de 1 provoque des changements importants.

Il a axé sa présentation sur l'affirmation “Read it, copy it, write it” largement applicable à notre domaine, en illustrant différentes expérimentation réalisées. Je ne saurais pas tout vous restituer avec fidélité mais une anecdote qui m'a marqué a été la “création” (write it) d'une souris à partir d'une cellule de souris (si j'ai bien compris, une cellule contenant toute la signature génétique, il suffit de “lui indiquer” la fonction qu'elle doit prendre : oreille, pate, etc.).

Un sujet passionnant, peut-être un peu éloigné du métier de l'IT à première vue. C'est sans compter sur le bestseller “As the Future Catches You” dont Juan Enriquez est l'auteur et vous propose une analyse de l'impact de la génétique sur le business et la société.

Conclusion

L'Université du SI est un événement unique de par son positionnement à cheval sur un auditoire Geek et un auditoire Boss : de quoi y trouver son compte, mais aussi aller voir ce qui se passe dans « l'autre monde ».

Dans un lieu soigné et agréable, avec des conditions météo parfaites (même s'il manquait de climatisation dans une des salles), l'organisation a été au rendez-vous notamment sur la logistique (accès internet, espace de recharge des mobiles, fléchage, écrans d'information, etc.) et la restauration.

Parmi mes regrets, on retrouve l'enchaînement des sessions et la contrainte de la diffusion simultanée à Casablanca entraînant l'interruption brutale de certaines sessions et l'impossibilité d'échanger avec le speaker sur des questions / réponses (même si nous étions invités à aller voir le speaker individuellement, ce n'est pas la même chose en terme de partage avec l'ensemble des participants). J'aurai préféré davantage de temps entre les sessions, ce qui aurait permis ces échanges, quitte à rogner sur les 90' de pause déjeuner.

En amont de la conférence les participants étaient invités à remplir leur profil et notamment la liste des sujets d'intérêt, malheureusement ce fameux « Parlez moi de » est resté vierge sur les badges personnalisés distribués à l'entrée : dommage.

Pour autant, le niveau général des sessions a été tel que je ne regrette pas (quasiment un sans faute pour la 1ère journée) ma participation et que je garde en tête les dates du 4 et 5 juillet 2011 tout en espérant que la part de speakers anglophones restera modeste et que la conférence continuera à propulser les professionnels francophones sur le devant de la scène.

Retrouvez également mon résumé de la 1ère journée qui contient en fin d'article l'inventaire des autres retours / compte-rendu de participants.

L'essentiel de la première journée de l'USI 2010

Fri, 02 Jul 2010 06:05:30 GMT

L'Université du SI se déroule sur 2 jours les jeudi 1er et vendredi 2 juillet. J'ai la chance d'y représenter Novédia et je vais partager avec vous la première journée de l'intérieur.

L'organisation

Contrôle d'identité à l'entrée par une hôtesse équipée d'un iPad, retrait du sac du participant, dépôt au vestiaire, puis passage dans le hall pour un petit déjeuner. 15 minutes après le démarrage de la keynote de Chris Anderson, on nous fait le coup de la panne (10 bonnes minutes sans électricité, meublées par une séances de questions / réponses).

Les sessions s'enchaînent, un buffet pour la pause de midi d'une durée d'1h30 avec accès extérieur, suffisant pour se restaurer et discuter. N'oublions pas les postes avec accès Internet, la possibilité de recharger son téléphone, un écran reprenant l'actualité de l'USI via les réactions sur Twitter.

L'après-midi reprend avec une keynote. Les enchaînements rapides du matin, conséquence du retard pris suite à la panne, laissent place à des transitions entre sessions plus calmes, ponctuées par la keynote de Leo Apotheker.

Puis les participants se sont vus offerts une soirée de dégustation de vin.

Mon top 3

Keynote « Let I.T. be » d'Yves Morieux du Boston Consulting Group
Les explorateurs de l'innovation, par Xavier Boileau (Generali)
Keynote de Chris Anderson (Magazine Wired)

Les différentes sessions en concentré

Pour chaque session suivie, en complément de mes réactions à chaud sur Twitter, je vous propose une idée forte perçue ainsi qu'un petit résumé.

Keynote de Chris Anderson (Magazine Wired)

Une idée forte : « give (the enterprise) us freedom, don't stop us to find/explore new solutions to do our job »

Chris Anderson, auteur du livre « The Long Tail: Why the Future of Business Is Selling Less of More », nous explique en analysant la ressource qu'est l'électricité , que l'IT a la chance de disposer aujourd'hui de 3 ressources en abondance : la bande passante, le stockage, et la capacité de calcul. La baisse de leur coût va de paire avec l'augmentation de leur utilisation. Il cite notamment l'annonce en 2007 par Yahoo de la mise à disposition de ses utilisateurs d'un quota illimité pour les mails.

Il en vient à opposer la rareté (scarcity) à l'abondance, en illustrant par des oppositions telles :

Supermarché vs. Amazon
Top down vs. Bottom up
Command & Control vs. Out of Control

Sa réflexion aboutit au constat de limitations/restrictions dans les entreprises allant au détriment des attentes des salariés, pouvant aller jusqu'à brider la performance de ces derniers.

Désordinateurs : quand la fonction des technologies consiste à rebattre les cartes, par Daniel Kaplan (Fondation pour l'Internet de Nouvelle Génération)

Une idée forte : L'un des enjeux de l'internet de demain est la mise en visibilité de ce qu'on ne savait pas voir avant.

Daniel Kaplan dresse le constat d'une informatique limitante pour les entreprises en citant des grands noms : « obstacle à l'innovation » (Jean-Pierre Corriou) ou encore « symbole du côté poussiéreux de l'entreprise » (Philippe Lemoine). Il nous rappelle que depuis le début, l'informatique a deux histoires parallèles : celle sous l'angle positif de l'optimisation (simplification), et celle sous l'angle parfois négatif de la transformation/adaptation.

Il nous propose un monde résultant du mariage du physique et du numérique, faisant éclore de nouveaux objets et des applications pertinente d'un point de vue social mais sujettes à conflit d'intérêt (partage d'information vs. Surveillance), tel l'exemple de la « montre verte » (mesure de l'air et de la pollution sonore).

Les explorateurs de l'innovation, par Xavier Boileau (Generali)

Une idée forte : L'innovation est l'affaire de tous (Marketing, Métier, DSI) et nécessite qu'on libère du temps aux personnes volontaires pour y travailler.

Après avoir rappelé les enjeux de l'innovation, Xavier Boileau a présenté les démarches menées chez Generali qui a notamment suivi une approche Top Down en lançant sur des thématiques (territoires) des similis de Startups internes constituées de personnes (explorateurs) de tout bord volontaires et auxquels du temps a été mis à disposition pour participer au processus d'innovation. Il a notamment expliqué que l'innovation reposait sur un état d'esprit, qu'il était primordial d'être prêt à accepter les échecs et erreurs, et que chez Generali la récompense pour les acteurs de l'innovation était la reconnaissance par les pairs (présentation à la Direction Générale d'un projet issu du processus d'innovation).

Jardinage et innovation : comment cultiver son potentiel ? Par Yves Casseau (Bouygues Télécom)

Une idée forte : L'innovation va de paire avec le Lean et l'Entreprise 2.0

L'originalité de la présentation réside dans la mise à disposition d'une référence bibliographique sur chaque idée/slide. Parmi les idées véhiculées : innover c'est adapter, le taylorisme s'arrête à la communication, ne pas négliger les « liens faibles » et participer (mais aussi partager) au delà de ce qui est interne à l'entreprise.

Let I.T. be, par Yves Morieux (Boston Consulting Group)

Une idée forte : Si on réduisait tous les projets à 9 mois, les gens seraient davantage impliqués car contraints d'assumer leurs actes.

Je ne résumerai pas la session, comme je l'ai dit à chaud sur Twitter : « Let I.T. Be par Yves Morieux #usi2010 un must see. Grande prestation et maîtrise pour expliquer des choses de façon simple. ». Il ne vous reste plus qu'à attendre patiemment la mise à disposition de la vidéo.

Le Lean ou le management par la résolution de problèmes, par Michael Ballé (ENST)

Une idée forte : Faire les bonnes choses avant de faire les choses bien.

Michael Ballé a commencé par nous sensibiliser sur la différence entre le système de production de Toyota et le TPS (Toyota Production System). Puis, il a rappelé un certain nombre de principes Lean pour l'apprentissage (Kaizen, Kaikaku) et à insister sur le fait que la mise en place d'un principe Lean comme le Kaizen nécessite une rupture destinée à placer le Kaizen avant le travail quotidien. Selon lui, le succès repose sur la vision du produit et la somme des compétences individuelles, et non sur les processus.

La société numérique, l'économie de la contribution : l'ère postconsumériste, par Bernard Stiegler (Philosophe, Centre Georges-Pompidou)

Une idée forte : Les entrepreneurs et investisseurs d’antan se sont transformés en managers et spéculateurs. Toute la société est en train de se désinvestir.

Le philosophe analyse la société actuelle qu'il qualifie de société de l'obsolescence (en référence aux cycles courts de vie des produits) qui produit des déchets toxiques. Il illustre la société de consommation par le résultat d'un sondage de 2004 lors duquel 54% des personnes interrogées affirmaient que ce qu'il y avait à la télévision était nul mais qu'elles la regardait néanmoins : un vrai discours de toxicomane. Bernard Stiegler, après avoir lourdement insisté sur le désinvestissement de la société, nous explique, en citant l'exemple de Wikipédia et décrivant certains sujets sur lesquels il travaille, qu'une nouvelle révolution industrielle est à venir.

Collaboratif, Réseaux Sociaux, 2.0 : on y va, on y va pas ? Laetitia Riveron (OCTO Technology) et Sara Lucet (SL & Partners)

Une idée forte : Choisir l'information et non la subir

Après avoir rappelé les statistiques des principaux réseaux / outils sociaux grand public, quelques facteurs clé de succès ont été présentés (notamment « Oser faire confiance ») et les outils et pratiques d'OCTO Technology ont été mentionnés. Après un slide matérialisant un panel d'outils du marché destinés aux entreprises, il nous a été expliqué que l'outil ne suffit pas et qu'il fallait chercher à définir la valeur métier attendue. Pas mal de bon sens : commencer petit, voir grand ; s'appuyer sur les « champions » et impliquer le management. Pour finir, le public a également été sensibilisé sur les risques en cas d'usage détourné des outils collaboratifs (discussions de type remise en question de la stratégie de l'entreprise).

La stratégie des tribus chez les Geeks : recruter, conserver, et développer les talents. Nicolas Martignole (Indépendant)

Une idée forte : Pour conserver ses talents, il faut permettre le partage dans et en dehors de l'entreprise.

Difficile de résumer une session dont j'ai pu suivre l'élaboration, comme bon nombre de personnes de la communauté Java, tout au long des derniers mois. Nicolas a présenté son parcours et son épanouissement en tant que Geek. Il a présenté les résultats des différents sondages menés auprès des Geeks et recruteurs pour en arriver à sensibiliser ces derniers sur les attentes des passionnés du développement informatique, soulignant certaines initiatives d'entreprises alignées avec ces attentes.

Building the Next Generation of Technical Leaders, par Patrick Kua (ThoughtWorks)

Une idée forte : The unspoken truth about managing geeks

Patrick a expliqué qu'actuellement les regards sont encore trop tournés vers les outils, les processus et les technologies, et pas assez vers les hommes. Or le succès ou l'échec de projets dépend également fortement des personnes qui le mènent. Le leader technique est-il un « super dévéloppeur » ? Pas du tout, et le speaker l'illustre en opposant les attentes qu'on peut avoir de chacune de ces populations (et en mentionnant certains comportements de « mauvais » leaders techniques). On peut notamment attendre du leader technique d'être l'acteur de la résolution de conflits, de contribuer au développement des talents, et de porter une vision auprès des équipes.

Keynote de Leo Apotheker (ex. SAP)

Une idée forte : Nous allons passer de l'informatique à l'information

Leo Apotheker partage avec l'assemblée sa vision de l'avenir : une révolution initiée par le hardware (ex. mémoires vives d'1To, processeurs plus rapides et moins consommateurs, etc.) permettant l'émergence de bases de données temps réel. Il nous a expliqué que le backoffice étant désormais automatisé grâce aux solutions de type ERP, le challenge à venir sera dans la communication inter-entreprise : joindre des processus et données non structurées dans une collaboration inspirée des réseaux sociaux. Il considère d'ailleurs que l'émergences de futurs systèmes temps réel, qui nécessiteront de fait 40% de code en moins par rapport aux systèmes existants (suppression de tiers comme la persistance et de problématiques comme la mise en cache), qui générerons beaucoup de challenges et de réécriture de SI.

Il envisage également l'éventualité d'une disparition dans une dizaine d'années des sociétés de Software, ce dernier étant amené à devenir une composante essentielle des entreprises.

D'autres retours de participants ou compte-rendu

Liste complétée au fil du temps :

USI 2010 : résumé de la première journée en attendant plus et USI 2010 : journée 2 par Nicolas Martignole (ensemble des articles)
USI 2010 – Premières impressions
Retour sur l'Universite du SI 2010 : geek et boss une equipe qui gagne par Emmanuel Bernard
Pourquoi recruter un geek ? Le Monde Informatique
Accompagner le développement collaboratif en entreprise Le Monde Informatique

L'agilité dans une organisation traditionnelle - un sprint de transition

Fri, 25 Jun 2010 07:20:16 GMT

Le contexte

Une organisation interne sur un modèle MOA/MOE avec une MOA détachée de la DSI depuis peu
Des équipes de réalisation d'un bon niveau technique, composées d'internes et de prestataires. L'équipe type : un chef de projet et des développeurs
Une infrastructure technique encourageante (projets structurés, intégration continue)
Un projet démarré il y a 6 mois avec la volonté initiale du middle management de faire les choses bien et de se réconcilier avec des applications existantes qui coûtent cher à maintenir
Une mise en production prévisionnelle pour mi mars qui aura finalement lieu ces prochains jours

Lorsque le projet a démarré, il y avait cette volonté unanime dans l'équipe de réalisation (composée de 5 personnes dont certaines formées / sensibilisées à Scrum) de mettre en oeuvre un ensemble de pratiques agiles. Les objectifs ? Améliorer la communication, l'autonomie de l'équipe, favoriser les prises d'initiatives, combattre l'effet tunnel, entre autres.

Bien entendu, à la vue du contexte, le lecteur avisé devinera que cette initiative est locale et non globale, qu'il n'y a aucune adhésion de la part du top management dans les démarches agiles, et que le périmètre ne s'étend pas aux interlocuteurs MOA.

Résumé des 6 derniers mois

Vous vous doutez bien de la difficulté d'introduire des pratiques agiles à un niveau local dans un tel contexte. Après une première tentative lors de la mise en place du projet à partir des informations contenues dans le draft des spécifications fonctionnelles du premier lot, l'équipe accuse le coup. Manque de repères, des tâches techniques estimées tant bien que mal, des spécifications fonctionnelles qui n'en finissent pas de bouger et de décaler le véritable démarrage des développements, obligeant l'équipe à s'impliquer dans la relecture proactive des spécifications.

Le management veut des dates, l'équipe finit par constituer son carnet de produit (product backlog) à partir des spécifications et en estimant les histoires (user stories) … en jours. Le Scrum quotidien (Daily Scrum) tourne vite au reporting des activités au chef de projet (Scrum Master volontaire et désigné) ainsi qu'à des séances collectives de conception / résolution de problèmes peu productives : l'équipe subit et personnellement j'ai l'impression de perdre mon temps lors du daily De plus, l'équipe, avec son Scrum board, ses post-its et ses rituels, devient vite l'attraction de l'Open Space : moqueries maladroites et décrédibilisation pas évidentes à accepter pour une équipe qui se veut volontaire et sérieuse.

Enfin, la complexité des histoires rend le premier sprint fonctionnel très peu productif et l'équipe, après avoir fait le constat de l'impossibilité de constituer des sprints de durée fixe (pas de priorisation, livraisons en recette par lots), amène l'équipe à mettre en suspens le Scrum quotidien tout en maintenant l'utilisation d'un Scrum Board (à faire / en cours / fait) avec désormais un découpage des histoires en tâches.

Quelques semaines plus tard, au cours d'une rétrospective improvisée, l'équipe dresse un bilan dont un des constats est la faible circulation de l'information (imputée à l'abandon du Scrum quotidien). L'équipe décide donc de remettre au goût du jour le Scrum quotidien en prenant soin d'éviter les travers du passé. Les délais se faisant de plus en plus pressants, l'organisation évolue de façon à spécialiser les développeurs par domaines fonctionnels, situation délicate par rapport à l'appropriation collective du code. Les retours de la recette du premier lot sont extrêmement positifs : encourageant !

Quelques évolutions fonctionnelles plus tard, nous avons livré il y a plus de deux semaines l'application en recette, commençons à traiter les premiers retours et absorber les ajustements occasionnés par les incohérences détectées et problématiques d'intégration. C'est également officiel : l'équipe va enchaîner sur un nouveau périmètre dont la mise en production est fortement souhaitée pour septembre.

Que faire donc pendant cette période de creux ? Fort d'une formation récente de type Scrum Master, et compte-tenu de ma frustration à voir l'équipe s'investir dans la douleur (l'équipe est "sans cesse en train de sprinter") sans obtenir de satisfaction, j'ai donc décidé la semaine dernière de porter mon énergie sur cette période transitoire afin de donner à l'équipe les moyens de se mettre dans de bonnes conditions pour la suite.

Préparation d'un sprint transitoire à connotation technique

L'équipe a tout au long du projet fait des efforts sur le thème des tests, mais elle a conscience que la couverture est plus que moyenne. L'équipe est également en souffrance dans certaines tâches qui lui coûtent beaucoup (trop) de temps.

Construction d'un backlog

Objectif : identifier les tâches, actions, que l'équipe juge pertinente de faire durant les prochains jours en prévision du démarrage des développements sur le nouveau périmètre

J'ai réuni l'équipe, expliqué l'objectif, puis l'équipe s'est mise à discuter et à décrire de manière concise des items touchant à des sujets comme :

le partage d'informations critiques sur le Wiki
la documentation technique
les préparatifs pour la mise en production
la maintenance et l'enrichissement des tests
la réorganisation de code existant
la recherche ou construction d'outils améliorant la productivité de l'équipe
etc.

Durée : 1h30'

Résultat : 36 items sous la forme de post-its

Rendez-vous fût pris avec l'équipe pour le lendemain 10h et une journée supposée riche en contenu.

Objectif : classer les items identifiés la veille en en estimant la valeur ajoutée relative

Je distribue à chaque membre de l'équipe une feuille reprenant les 36 items (que j'ai pris soin de numéroter) et leur permettant de prendre des notes pour préparer l'identification de la valeur ajoutée relative de chacun d'entre eux.

1ère étape : Présentation des 36 items pour que l'équipe se les approprie

J'ai proposé à l'équipe que chacun présente à tour de rôle un item, l'illustre, ou à défaut pose des questions à l'équipe pour préciser sa compréhension.

Durée : 20'

Résultat : Une bonne vision du backlog et une amorce de réflexion individuelle sur l'apport de chaque item

2ème étape : définition des valeurs ajoutées relatives

J'ai distribué à chaque participant 30 pastilles de couleur à coller au dos des post-its en fonction des valeurs ajoutées estimées. Chacun emploie la méthode qui lui convient, pioche dans les post-its et leur attribue des points de valeur.

Court débriefing et confrontation de points de vue en attendant un membre pris par d'autres priorités, lequel finira pas apporter sa pierre à l'édifice en attribuant lui aussi ses 30 points (sans être influencé par la vision des post-its).

Nous écartons pour la suite les 15 post-its ayant le moins de valeur ajoutée.

Durée : 30' en groupe + 20' avec le retardataire

Résultat : Un backlog ordonné par valeur ajoutée

Estimation des items constituant le backlog

Objectif : Définir les attentes et critères d'acceptation pour chaque item constituant le backlog

Toujours au dos des post-its, l'équipe décrit pour chaque item ce qui est attendu pour considérer que la réalisation de ce dernier est terminée. Un mélange d'échange de visions et de prémices de conception : le tout s'avérera très utile pour la suite.

Durée : 90' pour 21 items

Résultat : un référentiel commun à l'équipe permettant de mieux cadrer les estimations de complexité

Objectif : Estimer la complexité de chaque item

Un classique avec le Planning Poker. J'impose néanmoins au préalable à l'équipe de se mettre d'accord sur l'une ou l'autre tâche qui lui paraît élémentaire et sur laquelle un consensus d'estimation peut être trouvé. Je lui impose également une estimation en points de complexité et non en jours. L'équipe trouve son étalon et lui attribue la complexité de 1. Les estimations démarrent et se passent relativement bien. Grâce aux critères d'acceptation définis auparavant, l'équipe converge beaucoup plus facilement (parfois dès le premier vote) tout en focalisant la négociation sur la complexité et non le périmètre.

Durée : 90' pour 21 items

Résultat : Un backlog à la fois estimé en priorités et en complexité

Consolidation et remplissage du Scrum Board

Après un repos bien mérité, j'attaque la matinée suivante par le calcul du ROI (la valeur ajoutée relative ramenée à la complexité) de chaque item et le report sur la face avant de chaque post-it du triplet (valeur ; complexité ; ROI).

Je réordonne le tout dans un tableur pour classer les 21 items par ROI, puis nous reprenons l'ensemble dans le backlog du sprint (de durée indéterminée) de transition.

Peu de surprise quand à la présence d'items touchant à la mise en production. Voici quelques exemples de couples (résumé - ROI) :

Recherche d'une solution de visualisation d'un (ensemble) de DataSets DBUnit - 2 (4 / 2)
Préparation préproduction et production - 2 (10 / 5)
Décrire le processus de livraison - 1 (5 / 5)
Restructurer le code lié aux écrans de recherche / résultat et du mécanisme de recherche, et le documenter - 0.3 (6 / 20)
Ecran de consultation / recherche : évaluer les requêtes SQL jouées et en optimiser la quantité pour les scénarios de recherche - 0.6 (8 / 13)
Améliorer la couverture de code en renforçant les tests unitaires - 1.1 (9 / 8)
Initier les tests Wicket - 1.6 (8 / 5)
Renforcer les tests Selenium - 0.5 (7/13)
Mutualiser la règle de gestion pour la date XX - 6 (6 / 1)
Mettre en place des versions locales de WDSLs pour une utilisation en Développement - 2.5 (5 / 2)

Quelques ajustements pour le lancement du sprint :

Une tentative de Scrum quotidien à heure fixe (9h45, soit 15' avant que certains ne soient potentiellement indisponibles pour cause de réunion)
L'ajout d'une colonne « JIRA » sur le Scrum Board pour accueillir les tickets, présentés à l'équipe et affectés (traités en priorité) au cours du Scrum quotidien. L'ajout de colonnes « Livré » et « Recetté » dédiées à cette catégorie d'items.

Quelques observations

21 items allant d'une complexité de 1 à 13, c'est amplement suffisant (peut-être trop sachant que réunions et corrections d'anomalies agrémentent notre quotidien) pour occuper l'équipe pendant les 2 à 3 semaines de transition.

Nous travaillons bien entendu sur 2 branches : l'une pour le produit destiné à partir en production, l'autre pour préparer l'avenir. Si les corrections d'anomalies sont reportées sur chaque branche, nous n'excluons pas de faire de même pour certaines tâches dont le risque de mettre en péril la mise en production est faible.

Nous nous surprenons à retourner les post-its pour nous assurer de bien garder en tête les objectifs de l'item traité ainsi que les conditions qui nous permettent de le passer dans la colonne « Fait ».

Nos deux pilotes côté MOA ne se sont jamais autant arrêtés devant le Scrum Board, la faute sans doute aux post-its de type JIRA et aux quelques items relatifs à des tâches fonctionnelles. L'un d'entre eux nous a même déplacé des post-its de « Livré » à « Recetté » et a participé à quelques Scrum quotidiens. Et jusque là, personne ne s'est plaint de l'abandon partiel de l'application JIRA (qui reste utilisée pour expliciter les tickets et décrire leur résolution, mais dont la contrainte du workflow imposant une affectation des tickets par le chef de projet a été contournée pour une meilleure implication de l'équipe et appropriation du processus).

Conclusion

Ce sprint un peu particulier s'avère riche en enseignements et semble avoir une portée bien plus importante que ce qu'on pouvait penser au départ en le qualifiant de sprint technique. L'équipe a bon espoir de s'en servir pour démarrer les prochains développements fonctionnels dans de bonnes conditions. Elle pourra également compter sur une rétrospective à venir portant sur les 6 derniers mois.

Il nous reste néanmoins quelques inconnues pour l'instant :

Allons nous réussir à tirer profit de ce sprint pour enchaîner avec des estimations en points de complexité et non en jours ?
Allons nous réussir à impliquer la MOA pour fonctionner sous forme de sprint avec une priorisation des histoires, même si « tout ce qui sera spécifié sera indispensable » pour la mise en production de septembre ?
Allons nous pouvoir agrémenter les prochains sprints de quelques items « techniques » extraits de notre backlog technique afin de combattre la dette technique ?

La gestion des Ressources Humaines grâce aux réseaux sociaux – une composante essentielle de l'Entreprise 2.0

Thu, 24 Jun 2010 13:30:14 GMT

Non je ne vais pas vous faire le compte-rendu de la dernière conférence sur le portfolio Spring ou sur les langages pour la JVM que sont Groovy et Scala. Dans nos sociétés d'ingénierie en informatique, le geek est au coeur du processus RH et, de part son immersion naturelle dans le Web 2.0, peut également jouer un rôle dans le fonctionnement interne de l'entreprise.

Les nouvelles voies de la Gestion des Talents

Alors que nous arrivons à la fin de la 7ème édition de la Semaine pour la Qualité de Vie au Travail, j'ai eu l'occasion avant-hier soir d'assister à une conférence intitulée « Les nouvelles voies de la Gestion des Talents » qui se tenait dans les locaux de l'Université Léonard de Vinci à Courbevoie.

Organisée par la communauté 362.0, modérée par Luis Alberola, la conférence était constituée de 3 interventions dont 2 ayant retenu mon attention (Madame Benrubi m'excusera de ne pas m'attarder sur son intervention sur le thème de l'impact de la collaboration sur le développement des dirigeants).

Introduction par Luis Alberola - Talent Club

En guise d'introduction, Luis Alberola a planté le décor en expliquant que les réseaux sociaux, tels que nous les connaissons actuellement, ne sont que le point de départ de changements amenés à révolutionner de façon exponentielle nos modes de travail.

Pour illustration, deux changements inspirés par la démocratisation des réseaux sociaux dans les sociétés :

la transition vers une organisation s'appuyant sur des rôles et non plus des postes
une cartographie de l'entreprise sous forme de business graph et non plus d'organigramme

En résumé, une société résolument centrée sur la personne, avec son lot de remise en question :

l'abandon de processus, héritages d'une vision industrielle de la société
une remise en cause de la gestion des compétences
un bouleversement des mécanismes de prise de décision souvent alignés avec la cartographie hiérarchisée façon organigramme (remontée d'information, analyse, prise de décision, redescente d'information) et longs

Vous avez certainement entendu parler de Community Manager ces derniers temps ? C'est l'exemple du moment d'un nouveau rôle dans l'Entreprise 2.0 : la personne qui est en charge de la mise en avant de la marque d'une société et de l'animation d'une communauté centrée sur celle-ci. D'autres rôles pointent leur nez lorsqu'on parle de talents : animateurs, relais, influenceurs, etc., et les outils orientés réseaux sociaux sont des moyens pour ces nouveaux rôles de contribuer à l'essor de la société.

Si vous connaissez LinkedIn, vous connaissez sans doute le principe des recommandations. N'avez-vous jamais songé à avoir un tel système sur un réseau social interne à l'entreprise ? Constituer vos propres groupes / communautés au sein de l'entreprise ? Mobiliser – à l'image de twitter – l'intelligence et la capacité d'analyse collective pour alimenter une réflexion ? C'est une partie des changements que peuvent apporter des réseaux sociaux d'entreprise ou par extension outils Web 2.0.

En quoi cela aurait-il une incidence sur la gestion des talents ? Il est fort à penser que l'instigation de tels changements est du ressort de la fonction RH qui va la première procéder à une mutation :

de propriétaire des pratiques en vigueur dans la société, elle va devenir un véritable éclaireur sur les nouveaux modes de travail
d'administrateur du personnel, elle va devenir animateur du réseau

et de permettre à de nombreux acteurs de contribuer à la gestion des talents de la société.

L'impact des réseaux sociaux chez un éditeur de solutions logicielles - Pierre Polycarpe - Directeur Commercial de Taleo

Taleo est un éditeur de logiciel SaaS de Gestion des talents, notamment utilisé par Renault pour la gestion des entretiens d'évaluation.

Ce que l'éditeur cherche à mettre en avant via son produit, c'est une évaluation de la performance au fil de l'eau, et non lors d'un cérémonial classique annuel lors duquel on demande au collaborateur de se mettre en avant face à un manager auquel il n'aura éventuellement pas été rattaché tout au long de l'année.

En s'appuyant sur des réseaux sociaux d'entreprise, et des pratiques comme le feedback (cf. recommandations sur LinkedIn), le collaborateur accumule tout au long d'une année et d'interventions/collaborations potentiellement diverses et variées les éléments qui pourront servir à son manager pour évaluer sa performance, son atteinte d'objectifs, et ses axes d'amélioration. Petite parenthèse dans le cas particulier de l'activité de prestation de services : ce n'est malheureusement pas évident d'intégrer ces précieuses informations émanant d'un client (à moins d'avoir un processus reposant sur le relais de feedback par les ingénieurs d'affaire), d'où l'importance des réseaux externes tels LinkedIn et Viadéo (je le répète assez aux consultants que je suis).

Seulement, il faut également faire face à la barrière culturelle française illustrée par une pratique peu répandue des recommandations. L'adoption en est d'autant facilitée dans les sociétés davantage pragmatiques et non focalisée sur la crainte, le contrôle et la sécurisation de l'information.

Un autre exemple apporté par Pierre Polycarpe : la constitution d'un catalogue de formations façon Amazon. En effet, ne trouveriez vous pas naturel de constituer un référentiel de formations que vos collaborateurs évalueraient après les avoir suivies, donnant un feedback à toute personne susceptible de rechercher une formation qui puisse lui convenir. Non seulement cela contribue à la visibilité du portefeuille de formations, mais permet également de développer la dimension sociale au sein de la société en permettant aux collaborateurs d'échanger et de rentrer dans une démarche de réflexion active sur leurs projets de formation.

Pour illustrer son propos, l'intervenant a d'ailleurs rappelé le principe «70/20/10» (Morgan McCall, Robert W. Eichinger, Michael M. Lombardo : Center for Creative Leadership) qui, appliqué à l'apprentissage, stipule que 70 % de l’apprentissage se fait au travail, 20 % par le feedback et le coaching, et 10 % de manière formelle (formations).

Pour ceux que cela intéresse (pour les autres, les idées développées sont toujours bonnes à prendre et à mettre de côté), Taleo propose différents modules répondant aux problématiques que sont :

le recrutement
l'accueil de nouveaux collaborateurs
la performance et les objectifs
les plans de rémunération

Il a également pour ambition de pouvoir s'appuyer sur des plateformes sociales existantes.

Comment la DRH se transforme-t-elle ? - Julien Trichaud - Directeur du Développement des talents chez Coty

« Comment la DRH se transforme-t-elle ? », telle était la question à laquelle l'intervenant s'est proposé de répondre.

Après avoir défini les rôles de la RH que sont :

le Talent Management
le Change Management

Julien Truchaud a lourdement insisté sur le fait que la RH est le parfait pilote d'initiatives autour des outils Web 2.0 : selon lui, c'est son devoir d'expérimenter, de le vivre, de l'appliquer à elle même, pour par la suite accompagner et éduquer. La RH prend ainsi toute la portée de son rôle de Process Owner et par son action permet à de plus en plus de personnes de contribuer à la gestion du talent.

L'intervenant est notamment revenu sur l'expérience menée par l'ensemble des équipes RH chez Coty durant 1 an, laquelle a consisté à la mise en place de communautés de pratiques accompagnées de l'outillage répondant à leurs besoins, comme par exemple :

Lotus Sametime pour la messagerie instantanée
Diigo pour le social bookmarking
SurveyMonkey pour les questionnaires / enquêtes
Lotus Quickr pour le partage documentaire
Webex pour la visio-conférence

Les apports de la démarche soulignés par l'intervenant concernent avant tout le développement des compétences de la population RH. En effet, comme annoncé dans les objectifs, les gens ont eu l'occasion de se familiariser avec des outils, de se construire des processus (ex. l'organisation d'une vidéo conférence, la gestion d'un travail collaboratif, etc.), sans oublier la détection de talents au sein même de la RH.

Puis il suffit de laisser se diffuser la viralité de ces expériences au sein de l'ensemble de la société pour voir différentes initiatives facilitées par la RH : organisation et animation de communautés Green et Lean distribuées, visio conférences entre CEO et Comité Exécutif comme solution aux restrictions budgétaires consécutives à la crise, formations en mode distribué façon webex, etc.

En conclusion, l'une des facettes de l'Entreprise 2.0 nécessaire à une gestion des talents est la mise en place de processus et outils utilisés dans une démarche collaborative.

Pourquoi ce billet ?

Simplement pour illustrer qu'il existe cette notion de rôles chez Novédia, majoritairement en complément de postes de consultants (ingénieurs d'études, architecte, chef de projet, etc.). Animateurs de communautés (techniques, métier, ou sociales), consultants manager (dénomination interne pour le rôle d'accompagnateur et de coach d'une population plus jeune que le consultant), participant à la qualification de candidats, etc.

La gestion des talents passe donc en quelque sorte aussi par ces rôles qui, de par leur activité, deviennent un soutien à l'équipe RH. Pour reprendre l'exemple de l'intervention de Julien Truchaud, au sein de cette population existent vraisemblablement des talents, des personnes qui par leurs actions contribuent à l'évolution de la gestion des talents à travers l'adaptation des processus et des outils sur la base des idées attenantes aux mouvements 2.0.

A mon sens, avec l'Entreprise 2.0, tout le monde devient un acteur direct ou indirect de la gestion RH, donnant l'opportunité aux équipes RH de jouer pleinement un rôle de « Process Owner » et de sponsor des initiatives autour des démarches collaboratives. Alors qu'on parle beaucoup en ce moment de Recrutement 2.0, les équipes RH ne sont pas en reste face à certains constats fait dans le passé sur la faible implication de la RH dans l'évolution vers l'Entreprise 2.0. En s'appuyant sur les rôles évoqués, l'équipe RH peut ainsi se donner les moyens d'être un acteur de cette évolution.

Comme on me l'a fait remarquer lors de la finalisation de ce billet, la gestion des talents a également pour objectif de guider le collaborateur dans sa propre évolution : celle du Collaborateur 2.0 qui va adopter les outils et démarches collaboratives.

Aller plus loin

Pensez Applications Composites !

Thu, 22 Apr 2010 07:57:18 GMT

Depuis que je suis petit, je regarde "Le Bon, la Brute et le Truand" avec un plaisir qui ne s'estompe pas. Comme dans tout bon western, les colts et autres revolvers sont aussi importants que les gueules cassées, les saloons et les chevaux. Une scène m'a toujours frappée : celle où Tuco sortant du désert, se construit l'arme idéale en puisant dans les vitrines d'un armurier. Il assemble la crosse de l'un, le barillet de l'autre en y ajoutant le canon d'un troisième. Une belle cordelette pour suspendre le tout, et le voilà doté d'une arme redoutable, adaptée à ses besoins et à ses usages...

Finalement, Tuco ne réalise-t-il pas le rêve de la plupart des directions métiers ? Puiser dans le réservoir des applications existantes ou potentielles pour se construire des applications métiers, répondant à des besoins et usages spécifiques. Les composants s'estompent au profit de l'ensemble. La crosse tombe bien dans la main, l'arme est équilibrée, les dangers sont réels pour les adversaires, le duel peut commencer.

Bien sûr, cela est bien plus facile à dire qu'à faire. Les entreprises possèdent des actifs SI historiques importants, sous la forme d'applications verticales ou horizontales, résultant de l'intégration de solutions éditeurs ou de développements ad hoc. Ces applications ont très rarement été pensées et développées dans l'optique d'être utilisées par morceaux ou distribuées vers d'autres solutions. Dans les deux cas le temps et les ressources pour les faire évoluer manquent.

Pourtant les demandes des utilisateurs sont grandissantes...

Les demandes sont d'abord fonctionnelles : rassembler et assembler dynamiquement des fonctions se trouvant aujourd'hui dans plusieurs applications. Par exemple pouvoir concentrer les divers éléments concernant un client, depuis qui il est (nom, activité, chiffre d'affaire...) à comment il paie (conditions de paiement, nombre de litiges...), en passant par ce qu'il achète (portefolio produit, volume et récurrence, poids dans le total...). Une véritable vision 360° en somme. Sans être une nouveauté sur le fond, les demandes sont aujourd'hui beaucoup plus transverses qu'avant, avec un nombre croissants d'applications à intégrer : du collaboratif, des alertes, l'accès à des données historiques. Quand il y a quelques années il suffisait d'attendre une nouvelle release éditeur ou de mener un projet d'intégration entre deux applications, aujourd'hui ces solutions sont inadaptées pour combiner 3, 4 voir 10 applications. Complexe techniquement, impensable budgétairement.

Les demandes, est cela est nettement plus récent, vont très clairement vers des interfaces aux applications simples et ergonomiques, voire même, belles et designs. Dans ce domaine les exigences des utilisateurs professionnels convergent vers celles du grand public. Les révolutions digitales successives (Internet, smartphones...) imposent des standards d'interfaces au monde de l'entreprise. Est-il envisageable de faire un portail d'entreprise moins ergonomique que Facebook ? Peut-on mettre en oeuvre un poste conseillé moins bien pensé que le site d'une banque ?

Comment faire alors pour concilier les attentes des utilisateurs et les contraintes SI ? En s'affranchissant autant que possible des contraintes des applications d'origine pour reconstruire une nouvelle application composite. Les applications d'origine deviennent donc des enablers qui alimentent de nouvelles interfaces. Jusqu'à présent très théorique, les conditions sont aujourd'hui remplies pour que cette approche soit tout à fait réalisable d'un point de vue pratique :

Pour quasiment chaque application, des moyens de distribuer des services existent : certaines applications le permettent déjà (ex: architecture SOA) et d'autres fois il est possible de capitaliser sur les fronts existants (html, green screens...) pour construire des webservices structurés. Signe du temps et de la tendance, les éditeurs de verticaux eux-mêmes rendent leurs applications plus facilement distribuables (ex : Oracle ouvre désormais les couches basses de ses applications).
Ensuite, les services issus d'applications très diverses peuvent désormais être orchestrés entre eux. Les solutions de mashup d'entreprise offrent la possibilité côté back ou côté front de combiner dynamiquement des sources (en mélangeant par exemple les données d'un CRM avec les données d'un annuaire le tout sur un fond cartographie afin de construire et d'optimiser des itinéraires pour des commerciaux terrains).
Enfin, les solutions pour développer des interfaces riches prolifèrent (Flex, Air, Silverlight, HTML5...). Il devient facile et abordable de concevoir des interfaces professionnelles riches en exploitant les technologies RIA qui émanent d'Internet. Les technologies sont maîtrisées, les rendus sont très qualitatifs et les coûts de licence de développement et d'exploitation ridiculement bas.

En bref, ce qui n'était pas possible, le devient. Ce qui n'était pas envisageable en terme de coûts et de délais devient tout à fait réaliste.

Reste alors la question de la gestion du changement, et la capacité des directions métiers et des DSI à trouver, dans cette nouvelle philosophie, de nouveaux modes de fonctionnement. Les uns devront faire l'effort de clairement exprimer et hiérarchiser leurs besoins côté front, les autres devront "ouvrir" leur SI tout en assurant cohérence, pérennité et solidité.

Avec Windows Phone 7.0, Microsoft contre-attaque...

Sun, 11 Apr 2010 20:04:27 GMT

La semaine dernière, Novedia a eu le privilège d'assister au briefing Windows Phone 7.0 organisé à Paris par Microsoft.

Devant une assistance d'une centaine de personnes, venues de toute l'Europe, la firme de Redmond à présenter les nouveautés concernant sa nouvelle plateforme mobile.

Sans révéler les quelques informations confidentielles qui ont été dévoilées durant ce rendez-vous, il convient de partager un ensemble d'information qui ont été égrénées par l'éditeur depuis le Mobile Congress Of Barcelona et le Mix de Las Vegas.

Effectivement, l'un des mots d'ordre des concepteurs de cette nouvelle plateforme, a été de repartir de zéro. En d'autres termes, tout ce qui a été développé dans le cadre de Windows Mobile jusqu'à la version 6.5 mise sur le marché l'année dernière, est mis définitivement de coté.

Avec la formidable montée en puissance d'Apple dans le secteur des Smartphones et les appétits à peine voilés de Google, Nokia, RIM ou encore Samsung, les équipes de Microsoft n'ont pas voulu se laisser distancer sur ce marché prometteur. C'est un peu "Think different" chez Microsoft... et pourquoi pas car ils ont une véritable carte à jouer en tant que précurseur sur le marché mobile.

Aussi, pour susciter l'intérêt des développeurs et des éditeurs, Microsoft a donc décidé d'appuyer sa stratégie sur l'utilisation de sa plateforme de développement .NET et la mise à disposition gratuite de différents outils de programmation.

La bonne idée de Microsoft est d'utiliser plus largement ses solutions de développement pour PC et console Xbox pour adresser le canal mobile.

La technologie Silverlight, présentée comme concurrente de Flash d'Adobe, permettra dans sa version pour Smartphones Windows Phone, de concevoir des applications mobiles riches en expériences multimédia.

Par ailleurs, la plateforme de développement XNA utilisée pour créer des jeux sur Xbox, pourra être sollicitée par les développeurs de jeux sur mobiles. A ce propos, les éditeurs du secteur, ont de grandes attentes autour de nouvelles expériences utilisateurs sur les jeux mobiles temps réel et multijoueurs...

Ainsi, la communauté des développeurs déjà familiarisés avec ces technologies, n'aura aucun effort particulier pour appréhender la plateforme Windows Phone 7.0.

Avec une philosophie et des interfaces qui se distinguent véritablement de la concurrence, Microsoft s'engage avec une plateforme mobile très intéressante et bien plus intégrée à l'ensemble des solutions logicielles de l'éditeur.

Pour accompagner le déploiement international de Windows Phone 7 Series, une place de marché (Windows Market) sera lancée en même temps que la commercialisation des nouveaux Smartphones Windows. A la rentrée prochaine, les utilisateurs pourront accéder à cette boutique logicielle, riche de multiples applications et permettant notamment, de tester une appli avant de l'acheter...

Avec ce grand retour sur le mobile, Microsoft entend non seulement viser les entreprises mais aussi le grand public. Nul doute que cette offre globale et offensive permettra de conquérir de nouvelles parts de marché.

Par conséquent, dans le cadre du partenariat Novedia & Microsoft et de nos fortes compétences dans le domaine de la mobilité, nous espérons accompagner nos clients sur cette nouvelle plateforme avec laquelle l'éditeur américain engage d'énormes moyens.

Source Microsoft.

Quel modèle industriel pour les applications mobiles ?

Fri, 05 Mar 2010 10:00:09 GMT

S'il est raisonnable de douter (pour l'heure) du succès de la nouvelle tablette tactile Apple (l'iPad), on aura tous pu constater que l'année 2009 a marqué un tournant pour le marché des smart-phones qui a littéralement explosé sous l'impulsion notamment du mètre-étalon qu'est devenu l'iPhone sur ce segment. Indissociables de ce succès, les désormais fameuses "applications" ont donné un grand coup vieux aux sites mobiles classiques. Si 2009 fut de toute évidence une année exceptionnelle, 2010 sera à n'en point douter un encore meilleur cru : les ventes de l'iPhone, comme celles de ses concurrents, désormais de plus en plus performants et nombreux, continuent de croître à un rythme toujours plus soutenu.

Un défi industriel

A la manière de ce qui se produit actuellement pour les plates-formes 2.0, ce sont les usages du grand public qui ont permis ce succès spectaculaire, avec pour corollaire que l'équipement et les services des particuliers sont désormais presque toujours plus performants que ceux des professionnels. Avec un petit temps de retard, les entreprises commencent donc à s'intéresser de très près à ces plates-formes applicatives mobiles qui équipent déjà, que ce soit de leur fait ou non, une part importante de leurs cadres. L'équipement des entreprises en terminaux et services mobiles sera donc très certainement au coeur des préoccupations des entreprises pour les années qui viennent.

Si l'écosystème des services mobiles est aujourd'hui très largement piloté par les usages ludiques et pratiques des particuliers (jeux, infos, multimédia, réservations, etc.), l'émergence des usages professionnels risque d'en bouleverser fortement les contours en le mettant face à des contraintes propres aux systèmes d'informations métier : la maîtrise des déploiements, la restriction des accès, la protection des données sensibles, l'exploitation des services existants, etc. sont quelques uns des nombreux points à adresser avant de déployer des services métier professionnels. A contrario, le système d'information traditionnel devra faire face aux contraintes spécifiques à la mobilité : interface tactile, ressources du terminal, débit en ligne, limites du forfait data, connexion irrégulière, etc. Les services mobiles sont par ailleurs appelés à être déployés sur des terminaux de natures très variées (netbooks, ebooks, tablettes, smartphones, ordinateurs de bord, etc.) s'appuyant sur des plates-formes applicatives tout aussi hétérogènes (iPhoneOS, Blackberry, Androïd, Windows Mobile, etc.) : dans la plupart des cas d'usage, la généralisation va devenir problématique.

On le pressent, plutôt que de s'additionner, ces contraintes risquent fort de multiplier la complexité des projets embarquant une composante mobile. Dans sa conquête de la mobilité, l'entreprise est donc face à un véritable défi industriel qu'elle devra résoudre sous peine de voir le coût de possession de ses services mobiles atteindre un niveau injustifiable.

Le nouveau web des applications nomades

Le "problème industriel" que nous évoquons ici n'a rien de très nouveau sur la planète digitale : l'hétérogénéité matérielle et logicielle est le lot des fournisseurs de contenus et de services digitaux depuis ses origines. Pour faire face à ce problème, les industriels ont jusqu'ici toujours répondu avec la même stratégie : faire consensus autour d'un socle de standards pour bâtir des services portables et interopérables à moindre coût. Cela rappellera des souvenirs aux vieux loups de la nouvelle économie. C'est ainsi que l'argument de la portabilité porta aux nues le langage Java à la fin des années 90 : l'arrivée de la plateforme et de sa machine virtuelle proposent un développement standardisé de services indépendants de leur infrastructure de déploiement et d'exécution. C'est encore l'argument de l'interopérabilité qui poussa à l'adoption des standards de services distribués sur le réseau comme CORBA ou encore SOAP.

Mais si il est un standard dès plus structurant pour l'industrie digitale depuis maintenant plus de dix ans, c'est bien entendu le web. Ce socle extrêmement stable a apporté une grande simplification du déploiement des contenus digitaux. Accompagnant la maturation de l'infrastructure et des usages, le web a progressivement opéré sa mutation de plateforme de contenus en véritable plateforme d'applications : la majeure partie des systèmes d'informations métier déploient désormais leurs services sur l'intranet des entreprises à travers des applications respectant les standards du web ; suivant la voie ouverte par les Google, Force.com, Zoho et consorts, les progiciels bureautiques et métier migrent progressivement dans le nuage, confirmant l'émergence du "web office" ; les géants de l'IT préparent à grand renfort de milliards l'infrastructure destinée à faciliter et accélérer la "webification" du monde digital.

Au vu des forces engagées, il est difficile de croire que l'irruption de la problématique mobile ne vienne remettre en cause un modèle vers lequel convergent quasiment tous les acteurs. Pour preuve, le socle standard du web, qui n'avait plus évolué significativement depuis 1999, vient de connaître une petite révolution avec la sortie de la spécification HTML 5. Élaborée notamment par Google, Opera, Apple et la fondation Mozilla, cette dernière vise non seulement à remettre le standard en phase avec les usages actuels, aujourd'hui supportés par des technologies propriétaires (Flash), mais elle introduit surtout le support explicite du web des applications (espace de stockage local, tâches de fond, push de données, etc.) et du web nomade (géolocalisation, gestion du mode déconnecté, etc.). Ce standard nouvelle formule pourrait bien être le trait d'union entre le monde du web et celui du mobile.

La machine virtuelle universelle ?

Cette nouvelle mouture propose ainsi aux fournisseurs de services de développer pour un environnement normalisé de déploiement et d'exécution d'applications riches, portables et mobiles : le navigateur web.

Mais cette promesse est-elle bien crédible ? Certains signaux poussent à répondre dès maintenant par l'affirmative :

La liste des fournisseurs de navigateurs web ayant déjà implémenté au moins partiellement cette nouvelle norme dans leur produit est déjà longue (Google, Opera, Apple, Mozilla, pour ne citer que les plus connus) et de nombreux smart-phones du moment sont déjà équipés de la version mobile d'un de ces navigateurs "nextgen" (c'est le cas par exemple des iPhone, des Androphones, du S60, etc.).
Les applications web mobiles atteignent un niveau de qualité élevé à tel point qu'il est parfois difficile quand on utilise un smartphone de déterminer si l'on utilise une application web ou une application native.
HTML 5 entérine définitivement le trio HTML/CSS/JavaScript comme étant la plateforme de référence du web des applications, ce qui permet aux fournisseurs de services mobiles de s'appuyer sur des compétences qu'ils possèdent déjà du fait de leur expérience du web ou du moins qu'ils peuvent trouver facilement sur le marché.

Un modèle de masse et des alternatives de niche

Attention toutefois à ne pas prendre HTML 5 comme une solution miracle ! Comme pour toute plateforme technologique, il faudra expérimenter, faire des choix, assoir ses pratiques et s'outiller correctement. Si les applications web représentent j'en suis convaincu le moyen le plus efficace de fournir des services digitaux riches et nomades à ses utilisateurs, elles ne pourront pas non plus couvrir 100% des usages. Le standard web, bien que toujours plus couvrant, ne permet pas d'accéder à toutes les fonctions du terminal, comme par exemple le carnet d'adresse ou encore la caméra vidéo. Certains usages bénéficieront donc toujours du développement embarqué. D'autres techniques comme l'hybridation web/natif peuvent enfin trouver leur place pour adresser certains besoins (on voit ainsi apparaître des kits de développement d'applications natives développées en technologies web).

Il est en tout cas certain que l'effervescence qui agite le monde du web autour des technologies RIA est en train de gagner l'univers de la mobilité et qu'il conviendra d'élaborer une stratégie rationnelle de conversion à la mobilité de ses services digitaux.

Voir aussi :

Expertise

Ergonomie & Design

Technologies Web et Mobile

Blog

"Les éditeurs de contenus sur mobile : après la course à l’audience, la course aux budgets", par Marianne Fily - 25/03/2009

"iPhone & co: une appli ou pas ?", par Yves le Jan - 13/02/2009

"Appli embarquée ou service mobile – Partie 1: Définitions", par David Mas - 06/10/2009

"Appli embarquée ou service mobile – Partie 2: Le jeu des différences", par David Mas - 06/10/2009

"La musique sur mobile : à quand la "killer app" ?", par Nicolas Blaisot - 04/02/2009

Actus

France Télévisions fait appel à Novedia pour réaliser son application gratuite sur iPhone

Novedia lance son centre de services dédié aux applications mobiles et WebApps : Novedia Apps

Dior a choisi Novedia pour créer l'application iPhone associée à sa campagne "The Lady Noir Affair"

Slate.fr confie la réalisation de son application iPhone à Novedia Agency

Warner Music France et Novedia Agency lancent la première application iPhone consacrée à un artiste pop français : Sliimy

Novedia confirme son expertise en géolocalisation avec Géopablo

Novedia Maroc surfe sur la vague iPhone

Dans les médias

Médias et Mobiles - Stratégies

Des applications mobiles pour des entreprises plus réactives ? - Atelier

Les agences mobiles se spécialisent - Stratégies

iPhone apps : un relais naturel pour les médias - Le Journal du Net

Les "mobinautes" sont invités au voyage - Tour Hebdo

Sliimy en live sur Apple Store - Zikeo

Comment réconcilier BI Entreprise et BI Personnelle ?

Thu, 04 Mar 2010 09:57:46 GMT

Un nouveau tournant s'opère dans la pratique de la BI. Il n'aura échappé à personne l'intérêt grandissant des solutions de BI Personnelle auprès des Directions Métiers au détriment d'une politique décisionnelle globale, cohérente et efficace conduite par la BI d'entreprise. Ces deux approches ne doivent pas être opposées, elles sont complémentaires et participent toutes deux à l'enrichissement de l'expérience décisionnelle. Conscients de cet écueil, les éditeurs de solutions BI revisitent leur offre pour une plate-forme logicielle mieux intégrée. Les organisations, quant à elles, s'orientent vers une nouvelle gouvernance BI partagée DSI-Directions Métiers.

Le grand dilemme de la BI

Traditionnellement la BI se veut institutionnalisée autour d'un ensemble de méthodes, de processus, d'architecture et de technologie à des fins de valorisation du capital informationnel de l'entreprise. Au carrefour du SI, des Directions Métiers et de la Direction Générale, la DSI s'est toujours imposée comme un acteur incontournable de la BI d'entreprise jusqu'à ce que le niveau d'exigence des métiers dépasse les capacités de la DSI. Fait isolé il y a encore peu de temps avec des utilisateurs métiers plus enclins à utiliser des outils de productivité comme Excel pour s'affranchir des équipes et process IT, la vague de démocratisation de la BI semble se dresser en rempart contre le manque d'agilité et de réactivité de la DSI. De là à imaginer que les métiers puissent se passer de l'informatique, il n'y a qu'un pas qui mérite la plus grande attention.

Si la BI personnelle offre de nouveaux champs d'analyse, d'exploration, de prise de décision, quasi sans limite et sans contrainte elle n'est pas sans risque. Comment garantir une même vision de la BI à tous les niveaux de l'organisation ? Quel degré de confiance accorder à une source d'information ? Comment cadrer les réalisations hégémoniques ? La multiplicité des approches impose de repenser la pratique de la BI dans l'entreprise et de repositionner les compétences de la BI dans l'organisation de l'entreprise.

Dans les faits, cette bipolarisation de la pratique BI Personnelle-Entreprise révèle deux aspects d'une même réalité : une BI d'Entreprise comme élément d'infrastructure informationnelle fondateur de la BI personnelle. Solidement ancrée à une pratique d'Entreprise Information Management (intégration des données, Qualité de donnée, structuration d'entrepôts de données...) et de Gouvernance la BI d'Entreprise se porte garante de la précision des informations délivrées. Plus tactiques, les initiatives de BI Personnelle répondent à des besoins situationnels en tirant partie d'une vision intégrée et complète de l'information et participent à l'enrichissement continu des standards BI de l'entreprise.

Les éditeurs de solutions BI prennent position

Il n'empêche que les solutions de BI Personnelle séduisent par leur simplicité d'accès à toute source de données, par leur expérience utilisateur intuitive et visuelle accessible à tous, à en oublier toutes les autres dimensions de la BI. La popularité de la solution Qlikview est révélatrice du phénomène. Face à la forte adhésion des utilisateurs on se doit de pérenniser toute démarche de BI Personnelle. Si Qlikview offre en propre des facilités de partage et d'intégration à des solutions de portail comme SharePoint, les principaux acteurs du marché - Microsoft, IBM, Oracle, SAP... - misent tous sur l'intégration de leur offre de BI Personnelle à un ensemble de produits du portfolio de la marque. Les perspectives d'ancrage de la BI Personnelle à la BI d'Entreprise par le biais de solutions d'infrastructure de portail et de collaboration E 2.0 sont prometteuses (BI Mashup, Collaborative Decision Making, BI Temps-Réel, BI Search...). L'intégration des solutions de BI Personnelle et d'Entreprise aux solutions d'Enterprise Information Management constitue le cœur de nouvelles offres dites d’"Intelligence Platform"

Vers une nouvelle gouvernance de la BI

Limiter l'intégration de la BI Personnelle-BI Entreprise à des considérations technologiques ne saurait suffire. Cette démarche n'a de sens que si elle s'accompagne d'une véritable stratégie de mise en place d'une gouvernance BI. Les Centres de Compétence et de Services BI constituent un élément clé du processus de réconciliation. Adaptés au contexte de chaque organisation, ces Centres de Compétence se doivent d'être plus réactifs, de mieux répondre aux attentes des métiers, d'industrialiser les initiatives individuelles, de standardiser les pratiques et d'aligner le Système d'Information Décisionnel avec les besoins et les objectifs de l'organisation.

Quand les nouveaux usages sont sur le point de redessiner les contours de la BI, il devient impératif pour les organisations de réfléchir dès maintenant aux changements à venir au premier rang desquels figure la refonte du Système d'Information Décisionnel suivant une logique plate-forme intégrée de BI Personnelle et Entreprise. Cela va de pair avec une transformation du mode relationnel DSI-Directions Métiers. Il s'agira de poser sans tarder les fondations d'une nouvelle gouvernance BI sur la base d'une clarification des rôles, d'un redéploiement des compétences et d'une construction d'un catalogue de services.

Voir aussi :

Expertise

Externalisation du processus BI

Conseil en Business Intelligence

Blog

"Accroître la performance des systèmes décisionnels grâce à la « richBI »", par Etienne Bureau - 22/12/2009

Actus

Le CHU de Toulouse devient le 1er CHU à s’équiper massivement de la solution OBIEE

VISA informatique, éditeur de progiciels destinés aux collectivités locales, organise la refonte de son offre de gestion financière

Novedia Régions déploie son offre de Business Intelligence sur JDEdwards

Novedia déploie l'offre Oracle Business Intelligence (OBI) chez Brake France

Bouygues Telecom vient de sélectionner Novedia pour l'accompagner dans la mise en place de son nouvel outil de BI : OBIEE

Dans les médias

Comment mettre le développement durable en équation ? - ITR Manager

Inventer une expérience décisionnelle spécifique au mobile

Thu, 04 Mar 2010 08:09:38 GMT

Le mobile n'est pas le web. Les usages, les services, les technologies, tout y est très différent. Le décisionnel ne peut pas déroger à cette réalité. Que valent alors les démarches éditeurs de solutions décisionnelles qui proposent des interfaces mobiles standardisées? Probablement une solution temporaire acceptable pour un petit nombre d'utilisateurs qui recherche simplement à accéder à la donnée brute, mais en aucun cas une solution pouvant être déployée et utilisée massivement.

Que faire alors?

Tirer partie des spécificités du mobile pour accroître l'exploitation des systèmes existants, aussi bien en termes d'usage que d'adoption, afin de faire du mobile un écran secondaire, complémentaire du PC. Il s'agit de ne pas tenter de simplement copier/coller le web mais de construire une nouvelle expérience décisionnelle sur le mobile.

Oui mais comment?

En exploitant les caractéristiques de push et de pull du mobile, en association avec les capacités de représentation visuelle et d'interactivité avec les données. Cela se concrétise potentiellement par l'association fine des éléments d'un dispositif à plusieurs étages :

Un homescreen: encore peu utilisé, la capacité à remplacer la page d'accueil du terminal permet la présentation d'éléments clés au plus proche de l'utilisateur. Cet élément du dispositif, pendant longtemps réservé au constructeur de terminaux et aux opérateurs, est désormais plus largement ouvert. C'est potentiellement le siège naturel des futurs portails mobile d'entreprise.
Des moyens de notification et d'alertes : écran secondaire, le mobile n'est pas un bon support d'exploration. C'est par contre un merveilleux moyen d'action. Cette capacité d'action est très souvent déclenchée par des alertes ou des notifications, émanant d'applications distantes (ex : diminution d'un chiffre d'affaires remontée par le contrôle de gestion) ou gérées plus localement dans le terminal (ex : annulation d'une commande d'un client répertorié dans le carnet d'adresses du téléphone).
Des icônes dynamiques : finies les icônes passives, simples boutons raccourcis vers une application ou un site. Les icônes sont désormais "riches", changeant de formes ou de couleurs, fournissant un premier niveau d'information ou de criticité. Largement déployée pour des services tels que la météo, cette fonctionnalité est tout particulièrement pertinente dans le cadre d'applications décisionnelles.
Des applications embarquées ou des sites mobiles : siège du service lui-même, c'est là que se joue le succès final de l'expérience décisionnelle mobile. Les interfaces devront présenter bien d'autres visages que sur le web. Impossible d'imaginer des arborescences complexes pour accéder à une information. Impossible de concevoir des interfaces de requêtages "expertes". Impossibles de restituer de l'information sous forme trop brute. Au contraire il va falloir faire des choix. Des choix pour simplifier. Des choix pour hiérarchiser. Des choix "métiers" répondant à des besoins fonctionnels en mobilité.

Rêves ou réalité?

Un peu des deux, mais de plus en plus réalité. Comme sur le web, les services grands publics sont souvent en avance sur le monde de l'entreprise. C'est le cas également pour le décisionnel mobile ! De nombreuses applications mobiles décisionnelles grand public émergent, permettant de suivre les cours de la Bourse, ses consommations mobiles, son budget, son poids ou encore ses performances sportives. Les sujets sont certes peu B to B mais les préoccupations sont les mêmes : fournir une information quantitative pertinente et contextualisée en situation de mobilité. Il est fort à parier que ces services vont montrer la voie au décisionnel d'entreprise en termes de fonctionnalité, de principes d'ergonomie et, in fine, d'usage. Ils vont aussi poser des standards de qualité, de simplicité et d'efficacité que les utilisateurs dans le monde de l'entreprise exigeront. Reste alors un challenge : concilier des attentes d'utilisateurs grand public avec des contraintes de développement, de déploiement et de maintenance de systèmes d'entreprises.

Soirée open source au paris JUG

Sat, 30 Jan 2010 17:52:03 GMT

A l'occasion des deux ans du Paris JUG, une soirée spéciale sera organisée le 09 février 2010. Le thème sera l'Open source en France avec un key note de Sacha LABOUREY, ancien CTO de JBoss. Suivront ensuite des quickies animés par des acteurs majeurs de l'open source français. Pour cette soirée spéciale, il ne devrait pas y avoir de problème de place puisque l'équipe du Paris JUG a vu les choses en grand avec un amphitéatre de 500 places dans une annexe de la sorbonne (17eme arrondissement). Un espace sera dédié à des exposants. Renseignement et inscriptions sur le site du Paris JUG.

Voir aussi :

Actus

VISA informatique, éditeur de progiciels destinés aux collectivités locales, organise la refonte de son offre de gestion financière

Blog

"Paris JUG : compte-rendu de la session du 13 octobre 2009", par Zouheir Cadi - 15/10/2009

"Paris JUG : compte-rendu de la session du 15 septembre 2009", par Zouheir Cadi - 16/09/2009

"Soirée RIA au Paris JUG", par Zouheir Cadi - 01/07/2009

"Soirée DDD au Paris JUG", par Zouheir Cadi - 11/06/2009

"Non, ce n'est pas un tardif poisson d'avril !", par Alexis Lesage - 20/04/2009

"Paris JUG : compte rendu de session 14 avril 2009", par Zouheir Cadi - 20/04/2009

"Rencontre/débat sur l'open-source le 14 janvier 2009 avec le Paris JUG", par Zouheir Cadi - 20/01/2009

Accroître la performance des systèmes décisionnels grâce à la « richBI »

Tue, 22 Dec 2009 09:42:15 GMT

Les portails, les mashups, le communautaire, les wiki, le Cloud, les widgets…autant de solutions issues de l’internet grand public qui commencent à se diffuser massivement dans le monde des entreprises où elles révolutionnent les pratiques et les usages. La BI semble pourtant en reste alors que l’utilisation des technologies web d’enrichissement des interfaces permettrait de résoudre un problème chronique: la sous-exploitation des solutions déployées, aussi bien en interne par les collaborateurs, qu’en externe par les clients, partenaires ou fournisseurs.

Des solutions décisionnelles trop orientées « fonctionnalités » au détriment de l’expérience utilisateur.

A bien y regarder le succès du web repose fondamentalement sur l’association de la facilité d’accès à une multitude de services, avec une expérience utilisateur riche et optimisée. Pour s’en rendre compte il suffit de comparer l’évolution du web au cours des 10 dernières années pour constater que globalement les fonctions proposées ont peu évoluées au regard des progrès au niveau de l’expérience utilisateur:

· Interfaces à la fois claires et enrichies,

· Processus et parcours clients simplifiées et normalisés,

· Capacité de personnalisation et de customisation,

· Distribution maximale des services (widgets, flux rss…) et fédération dans des fronts uniques (portails, réseaux sociaux…).

Transposées dans le monde de l’entreprise ces tendances ce traduisent par l’émergence d’une Entreprise 2.0, révolutionnant les pratiques collaboratives, revisitant les solutions métiers et créant des ponts entres les silos historiques.

Face à cette lame de fond web, le monde décisionnel évolue également. On voit effectivement de plus en plus:

· Des accès aux solutions proposées via des interfaces web légères, plutôt que des applications locales,

· Une évolution des modes de déploiement vers les Clouds permettant d’améliorer les performances techniques, la rapidité de déploiement et de la facilité de maintenance / supervision

Les solutions, déjà très performantes d’un point de vue technologique, le sont encore plus, avec malheureusement peu d’impacts au quotidien pour les utilisateurs. Les énergies sont concentrées vers les fonctionnalités plutôt que vers le service. Pourtant les carences sont flagrantes:

· Les taux d’actifs et d’usages des systèmes déployés sont très faibles,

· Les utilisateurs sont globalement insatisfaits au point de développer, de manière autonome, des solutions plus souples, plus opérationnelles, plus tactiques,

· Les solutions restent très cloisonnées, peu intégrées dans les dispositifs Entreprise 2.0

Heureusement cette situation n’est pas une fatalité car les technologies d’enrichissement des interfaces web cohabitent particulièrement bien avec le décisionnel.

Les fonctionnalités sont là, maintenant place à l’usage grâce à la «RichBI»

En dix ans le web est passé de l’affichage statique de page HTML à la mise en œuvre massive des RIA, Rich Internet Applications, dont Flash et maintenant Silverlight directement dans le navigateur. Rien ne s’oppose à ce que ces RIA soient exploitées par la BI, pour donner naissance à la richBI:

· Les systèmes décisionnels sont capables désormais de générer des flux de données standardisées (xml par exemple), exploitables par les RIA,

· Les navigateurs sont assez performants pour traiter des volumes importants de données, tout en conservant rapidité et fluidité dans l’affichage et les transitions.

Au-delà des aspects techniques les conditions sont clairement réunies pour capitaliser sur la maturité et les usages des utilisateurs eux-mêmes. De par leurs pratiques personnelles au quotidien, les utilisateurs professionnels sont avant tout des utilisateurs grand public. Ils explorent, produisent et partages des contenus, Ils effectuent des achats, paient leurs impôts ou gèrent leur patrimoine. On peut se demander pourquoi il apparaît souvent beaucoup plus compliqué de générer un rapport d’activités mensuelles que de réserver un billet de train sur le web.

Une nouvelle approche est donc possible, mais elle nécessite une remise en cause des pratiques «historiques» afin:

· D’exploiter au plus proche les codes et pratiques du web,

· De designer des interfaces simples, riches et intuitives,

· De faire preuve de créativité pour proposer de nouvelles manières de regarder les données,

· De mettre en œuvre les moyens de partager et d’échanger.

Offrir un service c’est bien, mais l’animer c’est encore mieux. Là encore les méthodes développées pour le segment grand public viennent à la rescousse du décisionnel. Campagnes de recrutement, accompagnement au développement des usages, actions de relance ou de fidélisations doivent devenir le quotidien des services décisionnels.

En bref, on ne déploie pas une solution, on lance un service. On n’administre pas des comptes, on anime une communauté d’utilisateurs.

Voir aussi :

Expertise

Externalisation du processus BI

Conseil en Business Intelligence

Tierce Maintenance Applicative

Blog

"Comment réconcilier BI Entreprise et BI Personnelle ?", par Jean-Lin Crecelle - 04/03/2010

Actus

Bouygues Telecom vient de sélectionner Novedia pour l'accompagner dans la mise en place de son nouvel outil de BI : OBIEE

Le CHU de Toulouse devient le 1er CHU à s’équiper massivement de la solution OBIEE

VISA informatique, éditeur de progiciels destinés aux collectivités locales, organise la refonte de son offre de gestion financière

Novedia Régions déploie son offre de Business Intelligence sur JDEdwards

Novedia déploie l'offre Oracle Business Intelligence (OBI) chez Brake France

Novedia crée un outil décisionnel rapide, souple et ergonomique : Navboard

Novedia Decision confirme son expertise dans l'industrie pharmaceutique

Dans les médias

Comment mettre le développement durable en équation ? - ITR Manager

Communiqué de presse

Evialis enrichit son système décisionnel actuel avec les solutions Oracle, implémentées par Novedia Régions - Oracle

Office 2010

Thu, 22 Oct 2009 13:11:00 GMT

La sortie de Microsoft Office 2010 devrait voir le jour en février 2010 pour les entreprises et en mai 2010 pour le grand public. Les produits concernés sont :

• Office

• Outlook, Exchange

• Sharepoint

• Project et Visio

• Groove

Dans cette nouvelle version de la suite Office Microsoft beaucoup de nouvelles fonctionnalités font leur apparition. En voici une liste non exhaustive par application. Sharepoint et Groove sont laissé de côté pour être détaillés dans un post ultérieur.

Les nouveautés de la suite dans son ensemble

Le ruban

Pour commencer toutes les applications intègrent le ruban, ce qui amène une expérience utilisateur largement améliorée. De plus ce ruban devient personnalisable dans son intégralité (pas uniquement la barre d'outil de lancement rapide) et vous pouvez ainsi créer de nouveaux onglets avec les commandes qui vous servent tous les jours. Petit plus, cette personnalisation peut s'exporter sous forme de fichier XML et peut donc passer d'un poste à l'autre assez facilement.

Co-authoring

C’est le mode collaboratif instantané avec indicateur de présence (utilisation d’Office Communication Server). Cette fonctionnalité est disponible sur l'ensemble de la suite Office et permet la rédaction d’un document à plusieurs avec mise à jour en direct et interactions directe entre les différents auteurs par messagerie instantanée.

Le Backstage

Il est commun à l'ensemble des applications de la suite, Le Backstage permettra de gérer de manière uniforme les coulisses d'un document : Enregistrement, impression, partage, gestion des droits, propriétés avancées, publication sous forme de WebApp dans Sharepoint.

Nouveautés dans Excel

L'apparition de deux fonctionnalités phares qui sont :

• les lignes de tendances ("SparkLines") qui permettent de dégager une tendance visuelle (sous forme de courbes) et peuvent servir d'indicateurs à intégrer dans les tableaux de bords.

• les Slicers permettent de vous réorganiser un tableau en fonction d’éléments recherchés (ex : vous recherchez tous les achats effectués par un client : Slicer vous réorganise un tableau contenant tous les produits achetés). Cela permet une utilisation des tableaux croisés dynamiques très intuitive.

PowerPivot (nom de code du projet : Gemini) est un add-in Excel qui vous permet de traiter un très grand nombre de lignes(plus de 100 millions contre 1 million pour Excel 2007 et ce grâce à la version 64 bits) sur le poste client. Repoussant les limites des capacités d'analyse d'Excel tant au niveau de la volumétrie que des temps de réponse. Excel 2010 va s'imposer comme le client BI de premier plan pour manipuler et faire du reporting sur des données métiers d'entreprise (possibilité d'intégrer des données de bases de données non Microsoft), avec en outre des capacités nouvelles dans le domaine de l'OLAP (manipulation de cube, génération de cube en local à la volée..).

Nouveautés dans PowerPoint

PowerPoint est très axé multimédia avec de nouvelles transitions 3D (le moteur a été entièrement redéveloppé et utilise maintenant Direct X), la possibilité de faire du montage vidéo (découpe, effet de luminosité etc..) et photo ceci permettant de se passer de logiciels de retouche d'image connus ;)
De plus, la fonction Powerpoint Broadcast, permet la diffusion en streaming sur le web d'une présentation en se connectant depuis une URL produite à la volée avec un rendu en tout point identique à la version bureautique au niveau des transitions et animations. Cette nouvelle fonctionnalité est la bienvenue pour les Conference Call et plus généralement la collaboration online.

Nouveautés dans Outlook et Exchange

Affichage de conversation sur Outlook. Ce principe reprend celui de Gmail, c'est à dire que vos échanges avec une personne (ou groupe) donnée sur un sujet donné seront regroupé en une seule et même conversation, ceci permet de réduire de manière conséquente le nombre d'email qui apparaissent à première vue dans votre boîte au lettre. Vous pouvez ensuite en un clic dérouler le fil d'une conversation et choisir d'y donner suite ou non.

Avec Exchange Server 2010, votre boîte de réception est universelle: messagerie électronique, messagerie vocale (avec prévisualisation textuelle du message), messagerie instantanée et maintenant SMS. Vous pouvez écrire vos SMS directement depuis Outlook ou Outlook Web Access. Pour cela choisissez le destinataire dans l’annuaire de l’entreprise, parmi vos contacts ou entrez le numéro de téléphone de votre interlocuteur. L’interface vous précise le nombre de caractères présents dans le message et combien de messages textes vous envoyez.

Office WebApps

La fonctionnalité la PLUS IMPORTANTE à mon avis est l'arrivée des Office WebApps. Celles-ci vont nous permettre la visualisation/édition en ligne de document Word, Excel, Powerpoint et OneNote et ce, pour IE, Firefox et Safari. Il s'agit d'une version allégée proposant un accès à tous les documents depuis n'importe où et via n'importe quel périphérique ( PC, téléphone mobile, navigateur Web ). Ce service sera gratuit pour tous les utilisateurs de Live.

A titre informatif Office 2010 sera disponible en version 32 et 64 bits et sera supporté à partir de Windows XP SP3. Les pré requis matériel pour l'installation sont les même que pour 2007.

Quelques Liens :

Backstage 2010

Espace Office 2010

The Movie

Etape Parisienne de l'Agile Tour 2009 l'après-midi (partie 2)

Wed, 21 Oct 2009 06:16:41 GMT

Retour sur les dernières sessions de la journée Parisienne de l'Agile Tour 2009.

Retours d'expériences, par Xébia, Aybea, Astria & Octo

Le but de cette session double (2 créneaux horaires) était de partager 3 retours d'expérience sur la mise en place et l'adoption de méthodes agiles.

Retour d'expérience sur la mise en place de Scrum - Nicolas Jozwiak, Xébia

Sous une forme très académique, l'intervenant (qui avait le rôle de Scrum Master) nous a narré les premiers sprints d'un projet client (application critique du fait de générer directement des revenus), illustrant en cela une mise en place progressive de briques de méthodes agiles, et notamment l'importance des différentes étapes de préparation et transition de sprint.

Lors du premier sprint (4 semaines), il a été constaté que le Product Owner (un avant vente) n'avait pas eu suffisamment de disponibilités pour mener à bien son rôle, et que ce dernier manquait de maturité dans la gestion des user stories. Ce qu'ont illustré les manques vécus lors de ce sprint a justement été le rôle du Product Owner, l'importance des user stories, ainsi que la nécessité d'une définition claire du statut DONE (critères déterminant qu'une fonctionnalité est terminée).

En conséquence, lors du second sprint (qui est passé à 3 semaines pour raccourcir le cycle et profiter d'un feedback plus rapide), le Product Owner a été coaché par le Scrum Master sur son rôle. En particulier, le Product Owner a été épaulé pour la formulation des user stories, lesquelles n'ont pas été construites/formulées de manière collégiale, ceci étant justifié par l'intervenant par la jeunesse de l'équipe dans les pratiques agiles.

Lors du sprint suivant, le Scrum Master a pu saisir l'opportunité d'introduire la notion de Story Point et le Planning Poker, et il a également insisté sur un problème rencontré en cours de sprint : le couplage de User Stories sur un même sprint. Effectivement, la réalisation perd en flexibilité dans le cas de couplages inter sprint dans la mesure où on risque un enchaînement séquentiel à la fois limité par la durée du sprint et occasionnant un besoin plus important de communication/synchronisation.

L'intervenant a également expliqué la phase de passage de relai lors de laquelle il a formé son remplaçant Scrum Master, et donc été amené à jouer le rôle de coach pour ce dernier. Les bénéfices qu'il a relevé lors de ce passage de relai ont notamment été la prise de recul et par conséquent une meilleure analyse.

Les idées que le speaker a voulu partager avec l'audience :

la mise en place progressive est indispensable
il est vital de respecter la discipline agile
il y a des rôles clé dont il ne faut pas sous estimer les fonctions
l'adoption des pratiques de développement est également un point important

Changez pour l'agile ! Alexis Monville et Martin Rigaud-Vin, Ayeba

La présentation par les intervenants Ayeba a été très ludique, sous forme de sketch / échange entre les deux speakers.

Ils ont commencé leur présentation en énonçant 3 facteurs de succès :

le sponsor : pour débuter, un projet éventuellement stratégique, mais le plus isolé possible
l'équipe : d'un côté un chef de produit impliqué et disponible, de l'autre un Scrum Master intéressé et dynamique (car, d'après les intervenants, son rôle ne l'occupera pas forcement à temps plein, ce qui implique qu'il sache se rendre utile par exemple sur des tâches de réalisation)
le management : son soutien est précieux, il est le garant des décisions et de la transparence des informations

Outre le côté interactif et vivant de la prestation des speakers, cette présentation était intéressante de par les anecdotes rapportées sur un projet (en cours) d'accompagnement d'un client vers un mode de réalisation agile (nouveau pour ce client). En effet, malgré qu'il se soit montré réceptif et convaincu par la méthodologie qui lui a été présentée, plusieurs situations ont montré qu'il n'avait pas forcement tout saisi et encore moins appréhendé les changements fondamentaux qu'il allait devoir apporter sur son processus.

Ce que les speakers retiennent de cette expérience, c'est l'idée de faire passer à leurs interlocuteurs une session de simulateur agile d'au minimum une demi-journée, ceci dans le but d'évaluer leur compréhension.

Osez le changement, risquez le succés, obtenez des résultats remarquables - Bénédicte Taillebois, Astria - Frédéric Friess, Octo

Dernier retour d'expérience, celui fait par la société Astria, accompagnée par la société Octo dans sa mise en place d'un processus agile (l'objectif de Bénédicte Taillebois lorsqu'elle est arrivée en poste). Le contexte initial chez Astria était le suivant : 1600 jours de spécifications sans la moindre réalisation, 1 directeur de projet et 3 chefs de projets.

L'arrêt des spécifications a été décrété, et un dossier d'architecture réalisé par Frédéric Friess, suivi d'un accompagnement au changement.

Quelques améliorations chiffrées après 18 mois :

une livraison après chaque itération (2 semaines), contre une livraison par semestre auparavant
12 000 tests automatisés et des spécifications exécutables (FitNesse), contre 30 jours de tests de non régression auparavant

D'autres constats ont été faits, tel le regain de confiance dans l'IT et une augmentation de la valeur métier, le retardement des décisions structurantes du fait d'une approche incrémentale, mais également des frictions dues au changement (remise en question du poste de chef de projet).

Quelques pratiques relatées :

une immersion de 2h à 1 jour dans les équipes métier
tester l'innovation pour se rendre rapidement compte de ses avantages et inconvénients

Il est intéressant de noter que dans les caractéristiques du manager agile mentionnées par Bénédicte Taillebois, il y a la vulnérabilité. En effet, elle affirme que plus sa vulnérabilité est grande, plus l'équipe est forte.

Là aussi, nous avons eu droit à des recommandations, sous la forme d'un kit de survie :

KISS (Keep It Simple and Stupid)
négocier le contenu, pas la date
ralentir quand ca va mal

Comment concilier les pratiques Agiles et le contrat au forfait ? David Samreth, SQLI

La présentation s'est faite en 2 temps : un état des lieux / classification des caractéristiques des pratiques Agiles et du contrat au forfait, suivi d'un énoncé d'axes d'adaptation pour répondre à l'idée de conciliation entre les deux pratiques.

Les projets au forfait sont caractérisés par un triplet (budget, périmètre, planning) qui a pour conséquence d'imposer au prestataire une gestion des risques et d'introduire une conséquence importante de négociation (potentiellement conflictuelle) avec son client (ce qui est antagoniste aux valeurs énoncées par le manifeste agile).

Au sujet de sa combinaison avec des pratiques agiles, il existe un certain nombre d'idées reçues telles que :

le fait que les méthodes agiles pourraient permettre de proposer des forfaits moins chers
le fait que les méthodes agiles sont incompatibles avec les notions de maîtrise de coût et de périmètre

Dans le cadre de sa réflexion sur le sujet, l'intervenant nous a présenté 5 axes d'adaptation :

l'engagement budgétaire ne peut se faire qu'en redéfinissant de nouvelles unités d'oeuvres. Le story point étant un bon candidat, on peut très bien envisager un engagement contractuel sur la base d'un nombre de points
pour tirer profit des gains apportés par le mode itératif des pratiques agiles, il est indispensable d'introduire une flexibilité sur le périmètre plutôt que de chercher à le contractualiser au départ
l'engagement sur le planning peut passer par la contractualisation d'une vélocité moyenne, permettant de cadrer l'avancement en terme de richesse de fonctionnalités livrées au terme de la période définie
le partenariat entre "client" et "fournisseur" se doit d'être contractualisé afin de gérer l'arbitrage et la priorisation, mais aussi de maîtriser les risques en cas de faible implication du client (point de blocage pour le démarrage d'un nouveau sprint)
intégrer une démarche orientée ROI qui consiste à prioriser les fonctionnalités considérées comme à forte valeur ajoutée, et à savoir s'arrêter lorsqu'on atteint des fonctionnalités coûteuses à mettre en oeuvre et à faible valeur ajoutée (d'autant plus si elle ne sont pas indispensables).

En suivant ces axes d'adaptation, on peut arriver à la notion de forfaire agile, caractérisé par :

un budget fixe
un délai fixe
une vélocité fixe

En prenant cette approche et définissant un contrat chapeau, puis en assurant un suivi contractuel lors de chaque sprint (en définissant un mini forfait auquel est par exemple rattaché le contenu du spring backlog), il semble envisageable de mixer pratiques agiles et projet au forfait tout en apportant une flexibilité au client sur la gestion du changement. En effet, tout n'est alors plus que gestion du product backlog et de la priorisation.

Tout cela parait évidemment simple sur le papier, mais cela ne doit pas masquer les points critiques qui sont d'après moi :

la concrétisation de la valeur d'un point sur le plan budgétaire
le consensus sur l'estimation de coût en points des user stories
le consensus sur la qualification d'une tâche réalisée lorsque le résultat ne répond pas à ce que souhaitait le client : est-ce une anomalie à corriger à la charge du fournisseur ? Est-ce qu'une nouvelle enveloppe de points va être utilisée dans le cadre contractuel ?
l'évaluation par le fournisseur de la charge à reporter sur chaque sprint pour ce qui est des tâches de correction d'anomalies, et à inclure dans la détermination budgétaire (coût du point) et dans le planning (vélocité moyenne) sans que cet aspect ne soit réellement exposé à son client

Les deux derniers points montrent la limite de la combinaison agilité / forfait dans la mesure où la notion d'anomalie est un critère important dans le cadre d'un forfait en ce qui concerne la maîtrise du budget et qu'elle introduit inévitablement des conflits, lesquelles sont supposés réduit à néant avec les pratiques agiles dans un cadre classique.

Pour finir

L'Agile Tour est un évènement très précieux tant pour les initiés que pour les débutants. Son expansion dans plusieurs grandes villes de France permet de rendre l'évènement plus accessible que des messes annuelles dans une grande ville comme Paris. Ceci combiné à la gratuité (ou une faible participation) devrait vous encourager à saisir l'opportunité si elle se (re)présente.

Quelques liens pour ceux qui sont intéressés par le sujet :

Voir aussi :

Blog

"Etape Parisienne de l'Agile Tour 2009 l'après-midi (partie 1)", par Eric Siber - 19/10/2009

"Retour sur l'étape Parisienne de l'Agile Tour 2009", par Eric Siber - 18/10/2009

Etape Parisienne de l'Agile Tour 2009 l'après-midi (partie 1)

Mon, 19 Oct 2009 06:25:23 GMT

L'après-midi de l'étape Parisienne de l'Agile Tour 2009 a été bien plus dense que la matinée. Au programme, jusqu'à 6 sessions d'une durée de 45' (sachant que certaines sessions s'étendaient sur 2 créneaux).

Creating Leaderful Teams for High Performance - Deborah Hartmann Preus

Deborah Hartmann Preus a tenu une présentation sur le thème de l'équipe et de la performance, à commencer par une définition du terme "team" : individuals who committed to work together in a common goal.

Définition sur laquelle elle a rebondi pour expliquer que la répartition des membres d'une équipe dans plusieurs bureaux est une faiblesse pour ce qui est de la collaboration. Quant à la position dominante du chef, elle en a illustré les conséquences par la façon dont certaines équipes appréhendent le Chair Game (figure imposée à réaliser avec les chaises des participants et en n'ayant recours qu'à de la communication non verbale), attendant que le leader hiérarchique donne l'impulsion, perdant ainsi beaucoup en efficacité.

L'intervenante a mentionné de nombreuses références d'ouvrages pour chacun des thèmes abordés, comme par exemple Wave Rider: Leadership for High Performance in a Self-Organizing World pour illustrer le comportement du surfeur qui ajuste son mouvement en fonction des évènements (auparavant, elle avait rappelé que si la météo ne pouvait être prévue avec un degré de certitude décent pour plusieurs jours dans le futur, il n'est pas choquant que les tentatives de planification dans le temps d'un projet informatique puissent rencontrer cette même incertitude).

Il a également été question de Double Loop Learning en opposition à Single Loop Learning, soit une remise en question du statut quo plutôt qu'une simple boucle d'ajustement qui se contente de réagir de manière itérative aux conséquences plutôt que d'analyser les causes d'un état donné. En termes anglais, ce qu'il faut retenir de cette opposition est : "do the right thing" not only "do the thing right".

On a également droit à la citation d'une définition de coaching : "partnering with clients in a thought-provoking and creative process that inspires them to maximize their personal and professional potential"

Autre livre mentionné, Teamwork Is an Individual Skill: Getting Your Work Done When Sharing Responsibility au sujet du processus de responsabilité/responsabilisation.

Pour ceux qui ne veulent pas attendre que les slides soient mis à disposition par les organisateurs de l'Agile Tour, vous les trouverez déjà en ligne sur le site de l'intervenante.

Illusions et Désillusions - Patrice Petit, Agilii, Agilbee, Université Paris Ouest

Patrice Petit vient alimenter une réflexion joliment illustrée (slides) sur les illusions (problèmes) et désillusions (solutions) qu'on peut rencontrer dans un cadre agile. Il a entamé cette réflexion à la suite de l'échec rencontré par une équipe sur un projet agile, équipe qui avait pourtant été très performante avant de s'effondrer.

Tout commence par une petite définition : groupe = individus + interactions = système complexe. L'intelligence du groupe serait notamment optimale lorsque celui-ci est constitué de 5 ou 7 personnes.

Concernant le scénario classique de problème de qualité rencontré sur un projet, Patrice a présenté et commenté les 2 alternatives qui se présentent aux équipes :

la réécriture de l'application, qui peut donner l'illusion d'avoir résolu le problème, sans pour autant l'avoir réellement identifié et combattu
la mise en place d'une méthode agile, qui a pour effet entre autre de laisser place à une décharge cognitive collective et individuelle

Pourquoi parler de décharge cognitive ? L'intervenant a illustré cela par différents exemples, dont celui des rétrospectives : réunions d'équipes permettant de partager les observations faites pour ne pas trainer individuellement les défauts observés. La constitution de tests a non seulement l'effet positif de libérer le cerveau des développeurs/testeurs (qui peuvent s'appuyer sur ces tests plutôt que de devoir conserver dans un coin de leur tête les règles qu'ils illustrent), mais elle soulage également le travail d'architecture puisque celui se fait assez naturellement grâce aux tests.

On en arrive aux illusions liées à l'introduction de méthodes agiles, on peut par exemple citer :

le client ne viendra pas sur site
le manager ne nous sert plus à rien

Premier élément de réponse à la réflexion initiale de Patrice (comment une équipe performante peut-elle soudainement s'effondrer), l'illusion d'invulnérabilité qu'une équipe performante peut avoir, rendant difficile l'ajout ou le remplacement d'une personne étant donné que l'équipe est exigeante quant aux compétences des nouveaux. Tout cela peut donc aboutir à une équipe capable de se détruire à la moindre perte bousculant son biorythme. La remise en question perpétuelle, amélioration continue, est donc de mise, ce qui se traduit par différentes désillusions :

self awareness, doute et curiosité
Advocatus Diabolu (éviter le conformisme, éviter l'endormissement des pratiques, auto-réguler les rumeurs)
améliorer la qualité du consensus et de la coopération entre individus

Que faudrait-il retenir de cette session ? Sans doute que le coach agile n'est pas juste un gestionnaire de projet, mais qu'il est encore davantage et gestionnaire RH et un psychologue, casquettes pour lesquelles il a également besoin de compétences fortes.

A Themed Based Analysis of the Expectations and Concerns of the Developers prior to the Introduction of an Agile Development Methodology in a Large Software Development Team - Mary Giblin

Sous cet intitulé très long se cache tout simplement une étude de cas réel sur les craintes et convictions d'informaticiens (développeurs, testeurs, concepteurs) suite à l'annonce par leur hiérarchie de l'adoption de pratiques agiles dans leur entreprise. L'intervenante étant là pour nous présenter le contexte, la méthode employée, et les résultats.

Après une courte présentation du contexte, à savoir un société de taille importante découpée en plusieurs unités, dont celle étudiée lors du changement d'organisation. Cette unité est constituée de 250 personnes avec principalement des rôles de développeurs, testeurs, concepteurs. De plus, elle possède des adhérences avec d'autres unités de la société. A noter que le terme large software development team n'a pas été explicité plus en détail (en particulier au niveau de la taille d'équipes logiques, facteur important dans la façon dont une organisation agile se décline).

L'intervenante a rappelé que la conséquence naturelle d'une organisation (au sens société) de taille importante était la rigidification du/des processus, justifiant le fait qu'un changement dans l'organisation passait quasi systématiquement par une décision de la direction imposée à ses salariés.

L'organisation historique de l'unité étudiée est une organisation en silos, dans laquelle on retrouve :

des Business Managers et Product Managers
des System Engineers
des Developers
des Features Testers
des Integration Testers et System Testers

sans oublier les utilisateurs en entrée et sortie de cette organisation.

L'objet de l'étude a été de sonder le personnel après l'annonce par la direction de la volonté d'adopter des méthodologies agiles, avec un début de transition consistant en :

la mise en place de pratiques Scrum et XP
la création d'un Product Owner issu de l'équipe de conception (System Engineers)
l'immersion d'un testeurs (Feature Tester) dans l'équipe de développement pour améliorer le travail main dans la main entre ces deux populations

Les interviews se sont faites en 2 étapes suite à cette annonce : une première série de questions ouvertes, puis, partant de ces premiers retours, la soumission d'affirmations auxquelles les sondés devaient répondre en fournissant un degré d'adhésion (adhésion totale, forte, mitigé, faible, aucune adhésion).

Les résultats de l'enquête qualitative ont permis les constats suivants :

un existant fortement piloté par la documentation a été dénoncé
la relecture de code et les tests unitaires se faisaient à la marge, et leur adoption complète dans le processus est vue d'un bon oeil
malgré les bénéfices reconnus, des doutes ont été émis sur le Pair Programming, notamment le risque de conflits entre équipiers
au sujet du TDD, les sondés se posaient des questions concernant le code existant, et avouaient que leur adoption passeraient par un changement de vision assez important
le fait d'avoir des itérations plus courtes et fréquentes était vu comme potentielle source de pression
le rassemblement des équipes dans un Open Space était considéré comme un risque de distraction et une source de nuisance (bruit)

Quant aux questions quantitatives, les tendances qui se sont dégagées étaient :

plus de 60% d'adhésion sur la faible utilité de la documentation
une adhésion à 100% sur l'idée d'essayer de nouvelles méthodes et de s'améliorer continuellement, pour autant 23% des sondés auraient préféré conserver la situation existante et tenté de l'améliorer
87% de convictions que les méthodes agiles allaient adresser au moins certains, si ce n'est tous, des points noirs du processus existant
seulement 19% de sondés trouvent qu'il risque d'y avoir trop de concepts à introduire en une seule fois

Au final, assez peu de scepticisme, si ce n'est ceux qui auraient préféré améliorer le processus existant, ainsi que des avis assez mitigés sur le fait que les méthodes agiles étaient une mode ("buzzword").

Aspect important à préciser dans l'interprétation des résultats, la plupart du personnel avait déjà plusieurs années d'expériences, ce qui signifie qu'il faudrait sans doute rajouter le qualificatif experienced à la description "Large Software Development Team".

Seconde partie de l'après-midi

Rendez-vous dans le prochain (et dernier) billet pour ce qui concerne des retours d'expérience et une réflexion sur la contractualisation de forfaits agiles.

Voir aussi :

Blog

"Etape Parisienne de l'Agile Tour 2009 l'après-midi (partie 2)", par Eric Siber - 21/10/2009

"Retour sur l'étape Parisienne de l'Agile Tour 2009", par Eric Siber - 18/10/2009

Retour sur l'étape Parisienne de l'Agile Tour 2009

Fri, 16 Oct 2009 14:24:35 GMT

Seconde édition, après le succès des 7 étapes de l'Agile Tour 2008 (700 participants), l'Agile Tour 2009 voit plus grand et parcourt 18 étapes mondiales en ce mois d'octobre avec une prévision de 2500 à 3000 participants.

Le programme pour l'étape Parisienne était le suivant avec constamment 3 sessions en parallèle dans les locaux de l'université Paris Ouest Nanterre La Défense :

orientées Recherche et Méthode, dans un (grand) amphi
orientées Managers dans une salle d'une capacité d'environ 50 personnes
orientées Coaching et Equipes dans une salle d'une capacité d'environ 50 personnes

D'après les organisateurs, entre 200 et 250 personnes étaient attendues, mais il faut croire que le côté gratuit de l'évènement incite certaines personnes à s'inscrire sans forcement se rendre à l'évènement (un peu dommage pour la logistique, pour la peine ils n'auront pas droit à un t-shirt offert ainsi qu'aux réductions pour les formations partenaires).

De grands noms ? Il faut bien tenir tête aux organisateurs locaux de Grenoble qui ont mis la barre très haute (Henrik Kniberg, auteur de « Scrum et XP depuis les tranchées » et Elisabeth Hendrickson, membre du board de l'Agile Alliance), et donc d'inviter - en complément d'universitaires - des membres de renommée internationale comme Jean Pierre Vickoff (PUMA) et Déborah Hartmann Preuss.

Tout a commencé vers 9h30 avec l'accueil de Patrice Petit (fondateur et organisateur de l'Agile Tour, dirigeant des sociétés Agilii, Agilbee, et enseignant en Universités) qui présente l'édition 2009, la journée parisienne, et remercie les sponsors.

C'est donc avec 20 minutes de retard que débutent les sessions, ce qui aura un léger impact pour ceux qui, comme moi, changeront de salle / thème après la première session.

Mais de quoi parle-t-on à l'Agile Tour 2009 ?

De pratiques agiles voyons. Vous avez certainement déjà entendu parler de Scrum, d'XP (eXtreme Programming), Scrum Master, Product Owner, Coach Agile, Sprint, TDD, Pair Programming. Non ? Dans ce cas vous avez raté l'opportunité de mettre un pied dans l'engrenage et d'apporter un souffle nouveau à vos projets … voire à votre entreprise. Sachez que Novédia Vision, pôle Conseil Technique et Méthodologique de Novedia, saura vous accompagner dans la découverte et l'adoption de ces pratiques. Mais commençons tout de suite en parlant plus concrètement de l'évènement qui nous intéresse.

Ils étaient 69% (inscrits) à l'étape parisienne à déclarer peu connaître l'agilité, contrebalancé par 18% (inscrits) à déclarer en avoir fait une adoption totale. La journée s'annonçait donc sous le signe des extrêmes, et le découpage opéré par les organisateurs salutaire pour que tout le monde y trouve son compte.

Difficile de se dédoubler, il faut donc faire des choix et accepter de passer à côté de conférences, retours d'expériences, ou encore ateliers intéressants sur le papier.

Je vous propose quelques morceaux choisis des sessions de la matinée auxquelles j'ai eu l'occasion d'assister.

Embarquez avec SCRUM - Mise en place de SCRUM à la Direction Internet de GENERALI Christophe Leonard, Generali

Lors de cette session, à mi-chemin entre la conférence et le retour d'expérience, le speaker nous explique la démarche de la société Generali qui a abouti à l'adoption de pratiques agiles. L'objectif de la présentation est notamment de démystifier ces dernières.

Contexte : création d'une direction Internet début 2008 avec pour objectif d'ajouter une composante B2C (« espace client ») au site institutionnel de la société … en 6 mois. Compte-tenu des délais, le choix des méthodologies agiles s'est imposé, en particulier la méthodologie Scrum dont le crédo est « d'apporter la plus grande valeur métier sur la durée la plus courte », ce qui est complètement en phase avec la contrainte initiale de délais.

Les piliers du Manifeste Agile ont été rappelés :

« Individuals and interactions over processes and tools », ou l'importance des hommes et du travail en équipe
« Working software over comprehensive documentation », ou le fait de privilégier un logiciel qui fonctionne et apporte de la valeur, face à une documentation abondante et parfois dépassée
« Customer collaboration over contract negotiation », ou le recentrage sur la notion de partenariat plutôt que la relation (source de conflits) de type client / fournisseur (même au sein d'une même organisation)
« Responding to change over following a plan », ou l'importance de s'adapter au changement plutôt que de s'enfermer dans une planification et un échéancier précis

ainsi qu'une cinquième valeur chère au speaker : « le mode itératif et l'optimisation continue ».

Lorsqu'on parle d'itération, on en vient à introduire 2 termes :

le sprint : terme propre à Scrum qui désigne une itération élémentaire lors de laquelle l'équipe se focalise sur la mise en oeuvre d'un ensemble fini de fonctionnalités. Sa durée va en général de 1 à 4 semaines
la release : mise en production d'une nouvelle version du logiciel (dans un contexte Scrum, regroupe le résultat d'un ou plusieurs sprints)

Reprenant le 1er pilier du Manifeste Agile, l'intervenant décrit les 3 rôles intervenant dans un projet mené avec la méthodologie Scrum :

le Product Owner, ou encore celui qui représente les intérêts de l'utilisateur final
le Scrum Master, ou encore celui qui est en charge d'appliquer tous les préceptes de Scrum, à commencer par animer le projet, protéger l'équipe, et dénouer les problèmes. Selon l'intervenant, il est préférable que cette personne soit à temps plein, et également qu'elle joue pleinement son rôle sur la période d'un sprint en défendant les intérêts du projet face aux demandes du Product Owner (analogie avec le capitaine d'un bateau qui est seul maitre à bord entre 2 ports et qui peut décider de ne pas prendre le large si on surcharge son bateau).
l'équipe, ou encore toute personne (développeur, testeur, etc.) intervenant dans le processus de production de valeur

Egalement mis en évidence, le Daily Scrum, meeting d'équipe quotidien de 15' à 30' servant à l'auto organisation de l'équipe (avancées des dernières 24h, problèmes / difficultés rencontrées, tâches envisagées pour la journée), pour lequel le speaker a souligné qu'il n'était pas le lieu pour la résolution de problèmes (pris en charge par le Scrum Master, à moins que des membres de l'équipe ne s'auto-organisent dans la journée pour y remédier).

Concernant le second et le troisième pilier, on mentionnera le Planning Poker qui est un outil destiné à évaluer en groupe la complexité des User Stories (à rapprocher de la notion de cas d'utilisation pour les novices), mais aussi à en affiner le contenu en confrontant les estimations, pour aboutir à une décomposition en tâches.

Pour finir, l'intervenant a décrit deux évènements post Sprint (itération) :

la revue de sprint : réunissant l'équipe (au sens large) et toute personne concernée par le logiciel produit (utilisateurs par exemple) pendant 1 à 2h pour présenter de manière informelle (et sans grande préparation, laquelle ne doit pas dépasser 2h selon l'intervenant) le contenu du sprint via des démonstrations concrètes, permettant au Product Owner de valider les fonctionnalités, voire de s'appuyer sur des éléments concrets pour envisager de les compléter
le bilan de sprint (plus connu sous le nom de « rétrospective ») : réunissant l'équipe (au sens large) pendant 30' à 2h pour faire un bilan du sprint et identifier les progrès réalisés ou à faire, les erreurs ou problèmes rencontrés, dans le but d'en tirer des leçons (amélioration continue)

Quels sont les gains mesurés par la direction Internet de Generali ?

Une meilleure communication, confiance, transparence
Une visibilité et maîtrise du coût
Une mise en valeur des équipes de réalisation
Une réactivité face au marché

Reprenant le dernier point, l' « Espace Client » a bien été mis en ligne dans les délais, et les premières analyses comportementales des utilisateurs ont permis de revoir les priorités par la suite pour aller d'abord vers la réalisation des fonctionnalités les plus propices à générer des retombées financières.

Des conseils ? Voici ce que le speaker retient après 18 mois de pratiques :

l'importance de se faire accompagner par des experts
l'importance du sprint 0 (mise en place du projet, choix des outils et orientations techniques)
ne pas commencer la 1ère itération avant d'avoir un backlog produit (liste de fonctionnalités) assez fourni pour occuper l'équipe
le recours à l'intégration continue et aux tests automatisés
préférer des petits projets sans adhérences pour une première expérience de projet agile
suivre de près les adhérences

Profil d'un coach Agile – Oana Juncu, SFEIR

Comment définir un coach Agile ? Ou alors retour d'expérience et vision du coach intervenante ? Difficile de le dire car la présentation était quelque peu tournée autour d'anecdotes et du vécu de la speaker, et moins autour de l'élaboration du portrait robot du coach Agile.

Résumons la session sous ces 2 angles :

Le coach Agile

Le coach peut être vu dans sa définition classique comme un entraineur, quelqu'un qui va apporter son soutien, qui aide les gens à être performants. Dans un contexte agile, le coach ne se situe pas nécessairement au niveau « projet », mais plutôt au niveau organisationnel : son champ d'action va au delà de celui qu'on pourrait attribuer à un Scrum Master, population que le coach est souvent amené à former, tout comme le Product Owner.

Les qualités / valeurs que doit porter un coach agile sont, d'après la speaker :

être pragmatique
observer et non imposer
promouvoir
encourager l'adoption du binômage au delà du cadre de la production de code, mais à tous les niveaux
savoir accompagner le changement avec respect (être capable de faire un état de lieux de l'adoption des pratiques agiles, observer les comportements, et réfléchir aux changements que l'équipe peut absorber à un instant t)

Les réflexions de l'intervenante

La coach est revenu sur son parcours qui l'a amené d'un contexte de projets (il y 4 ans de cela) réalisés dans un modèle de cycle en V incompatible avec les fortes contraintes Time To Market, au statut de coach et promotrice des pratiques agiles, en étant passée par les étapes intermédiaires de « coachée » , d'intervenant agile, et de partenaire agile. De quoi vous montrer qu'on passe par différentes étapes avant de se sentir / être reconnu comme un coach.

Selon elle, le coach agile a pour objectif d'aller plus loin que le périmètre IT d'un projet logiciel. Il a son rôle à jouer dans l'établissement et l'animation des communautés utilisateurs, en commençant par l'accompagnement du Product Owner dans la découverte de son rôle dans le cadre d'un projet Scrum.

Elle a également cité le Shu-Ha-Ri, principe d'apprentissage clé des arts martiaux japonais, repris par Alistair Cockburn dans une déclinaison agile sous la forme « Pratiquer / Améliorer / Evoluer » qui peut définir les fondements du coaching agile.

La suite ?

L'après-midi a été riche de contenu et d'enseignements, mais ceci fera l'objet d'un autre billet.

En attendant, je vous propose quelques lectures pour patienter :

Scrum et XP depuis les tranchées, par Henrik Kniberg (traduit en français par Guillaume Mathias, Bruno Orsier, Emmanule Etasse, Christophe Bunn)
Le site de l'Agile Tour (vous pourrez toujours y guetter l'arrivée des supports de présentation)
Un forum d'entraide sur les Méthodes Agiles, avec notamment quelques débats intéressants

Voir aussi :

Blog

"Etape Parisienne de l'Agile Tour 2009 l'après-midi (partie 1)", par Eric Siber - 19/10/2009

"Etape Parisienne de l'Agile Tour 2009 l'après-midi (partie 2)", par Eric Siber - 21/10/2009

Paris JUG : compte-rendu de la session du 13 octobre 2009

Wed, 14 Oct 2009 15:06:08 GMT

Quelques annonces importantes

DEVOXX. Les inscriptions à LA CONFERENCE sur java en Europe sont toujours ouvertes. Elle se déroulera à Anvers du 16 au 20 novembre.

Parleys. M. Quiz, un des membres de l'équipe du Paris JUG a commencé la retranscription des vidéos des anciennes sessions. La première vidéo reprend la session qualité logicielle.

JSF2

La première session traitait de JSF2 et a été animé par Damien GOUYETTE et François PETITIT. L'objectif de la session était de faire découvrir les bases de JSF ainsi que les nouveautés apportées par la version 2.0. La présentation qui était structurée, fluide et claire comprenait quatre parties : introduction, présentation, les outils et la conclusion.

En introduction, les speakers ont rappelé l'historique de JSF qui est le premier framework jee pour le développement d'IHM riches. La version 1.0 date de 2004. Nous en sommes aujourd'hui à la version 2.0 qui s'appuie sur la JSR 314.

Les auteurs ont ensuite montré quelle était la place de JSF par rapport aux frameworks de présentation du marché. Signalons, que Struts est absent de leur schéma, comme ils l'ont eu même noté. Pour ma part, je pense que Struts a actuellement beaucoup de concurrents mais il n'est pas prêt de disparaître complétement chez nos clients. Par ailleurs, JSF, à l'instar de Wicket est un framework orienté composant, alors que Spring MVC et Struts sont des frameworks orientés action.

Damien et François sont ensuite rentrés dans le vif du sujet avec une présentation des fonctionnalités de JSF.

JSF se positionne comme le framework ihm de jee. Il fait d'ailleurs partie du profil web de jee6.

Il obéit au pattern MVC2. Le controller est configuré dans le fichier web.xml. Il gère une vue et un managed bean, coté serveur. La présence d'un fichier faces-config ou sont déclarés la navigation et les managed beans est facultative.

Concernant le cycle de vie, JSF permet la conversion automatique de la valeur d'un attribut de la requête en objet java, le support des primitifs et des dates, le support de convertisseurs personnalisés et configurables ainsi que plusieurs dispositifs de validation (dans la vue, dans le managed bean et dans les entities et/ou les managed beans en utilisant la JSR 303, qui fera prochainement l'objet d'une présentation au Paris JUG).

Le managed bean est la classe contenant la logique de présentation connectée au métier. Le scope du bean peut être de niveau Application, Session, View ou Request. Le scope View a été introduit dans JSF 2.0 : l'objet ayant cette portée aura la même durée de vie qu'une conversation web. Un autre apport de la version 2 est la simplification de la configuration puisqu'on passe de déclaration dans le fichier xml faces-config aux annotations. Le lien entre la vue et le managed bean se fait via l'Expression Language.

JSF est un framework orienté composant. C'est un élément d'interface utilisateur, configurable et réutilisable. Un composant vit sur le serveur. Chaque action dont il fait l'objet donne lieu à des traitements pour mise à jour coté serveur. L'état des composants est restauré puis sauvegardé à chaque cycle requête/réponse. Avec JSF 2 la création de nouveaux composant se fait en deux phases: déclaration d'un fichier xml situé dans une arborescence particulière (si mon composant s'appelle hello, il se trouvera sous /webapp/resources/hello/hello.xhtml), et utilisation dans la vue avec déclaration préalable du namespace du nouveau composant. Ainsi, JSF 2 facilite la création de nouveaux composants.

Il existe des bibliothèques de composants référencés sur le site www.ajaxjsf.net.Parmi les différentes librairies, les speakers ont recommandé RichFaces, PrimeFaces et IceFaces.

L'ancienne critique sur une intégration inexistante avec Ajax n'est plus d'actualité. JSF 2 propose une gestion native d'Ajax avec la balise .

JSF 2 vient nativement avec Facelet. Il intègre donc le templating de page.

La présentation des fonctionnalités a été illustrée par une demonstration.

Les speakers ont ensuite évoqués les outils. Ils ont rappelés notamment que le serveur d'application le plus avancé avec un support natif de JSF était Glassfish.

En conclusion, Damien et François ont rappelé les nouvelles fonctionnalités. Ils ont également signaler que l'équipe en charge de la spécification était à l'écoute des demandes des utilisateurs.

Les slides ainsi que le code source de la démonstration son disponible sur le site du Paris JUG et sur le site de Damien Gouyette.

Voir aussi :

Actus

VISA informatique, éditeur de progiciels destinés aux collectivités locales, organise la refonte de son offre de gestion financière

Blog

"Soirée open source au paris JUG", par Zouheir Cadi - 30/01/2010

"Paris JUG : compte-rendu de la session du 15 septembre 2009", par Zouheir Cadi - 16/09/2009

"Soirée RIA au Paris JUG", par Zouheir Cadi - 01/07/2009

"Soirée DDD au Paris JUG", par Zouheir Cadi - 11/06/2009

"Non, ce n'est pas un tardif poisson d'avril !", par Alexis Lesage - 20/04/2009

"Paris JUG : compte rendu de session 14 avril 2009", par Zouheir Cadi - 20/04/2009

"Rencontre/débat sur l'open-source le 14 janvier 2009 avec le Paris JUG", par Zouheir Cadi - 20/01/2009

Appli embarquée ou service mobile – Partie 2 : Le jeu des différences

Tue, 06 Oct 2009 07:30:46 GMT

Après avoir défini ce que sont les applications et les services mobiles, nous allons analyser les avantages et inconvénients de chacun afin que les non-initiés puissent se faire une opinion objective.

Pour commencer à différencier une application mobile d’un site mobile, il convient par exemple de comparer :

le service mobile iPhone et l’application iPhone Facebook,
le service mobile iPhone et l’application iPhone Gmail.

Dans le premier cas, l’application est tellement bien réalisée que la Web App iPhone de Facebook n’est plus tellement attractive.
Dans le second cas, la Web App Gmail est tellement plus riche, plus simple d’utilisation et plus ergonomique que l’application iPhone Gmail devient pour le moment moins attractive.

Ces jugements qui peuvent paraitre subjectifs, montrent néanmoins qu’il n’y pas une supériorité définitive de l’application sur le service mobile et inversement.

En effet, c’est souvent en fonction du contexte fonctionnel du projet, de la cible souhaitée, des coûts de réalisations, etc. que le développement est orienté vers l’application embarquée ou le service mobile.

Comme cela été évoqué précédemment, l’application est réalisée dans un langage de programmation (Objective C pour iPhone, J2ME pour terminaux supportant Java, etc.) alors qu’un service mobile est réalisé avec des langages issus des familles HTML / JavaScript. Il est facile de constater à ce niveau que la tendance est au rapprochement à grande vitesse des technologies Web / Web mobile.

Le service mobile à l’avantage “d’être plus facilement compatible” avec un parc conséquent de terminaux. Il est par ailleurs encore plus aisé de faire des modifications sur un site mobile que sur une application.

Pour bien marquer les différences entre ces deux notions voici quelques points clés de comparaison :

• Portabilité : le service mobile l’emporte s’il est réalisé/hébergé sur une plate-forme capable de gérer l’adaptation à un parc de terminaux indépendamment de l’hétérogénéité des environnements technologies mobiles (OS mobiles). L’application mobile peut être compatible avec un seul ou plusieurs environnements. Dans le second cas, il y a de fortes probabilités de recoder l’application et parfois dans différents langages de programmation. Il est toutefois possible de se limiter qu’à un seul environnement : exemple appli iPhone ou appli Androïd ou appli Windows Mobile, etc.

Avantage pour le service mobile

• Développement/ Coût : une application semble encore plus longue à développer avec les outils actuels (cela risque de ne pas durer peut-être) qu’un service mobile qui utilise de plus en plus les standards du web.

Avantage pour le service mobile

• Maîtrise et réactivité de la mise en ligne : un service mobile peut être hébergé comme n’importe quel site Web. La seule différence réside dans la compatibilité du service avec les multiples navigateurs Internet équipant les terminaux mobiles.
Aussi, il est souvent conseillé de réaliser un service mobile au sein d’un environnement capable de gérer automatiquement la détection d’un terminal et de lui fournir les pages et contenus adaptés. Cet environnement peut être une plateforme de services mobiles.
Le service mobile offre une grande souplesse dans sa gestion puisque comme un site Web, un CMS (Content Management System) suffit à l’animation du service (Ajout d’images, gestions éditoriales, mise en avant, etc.)
Au-delà, la mise en ligne et les modifications opérées sur un site mobile ne sont pas obligatoirement soumises à une validation d’un tiers modérateur. Ceci est à relativiser dans le cas où le service doit être référencé sur un kiosque de services comme Gallery, Plazza ou autres. Dans ce cas précis, les opérateurs de télécom, propriétaires de ces kiosques, demandent en effet, le respect de différentes chartes graphiques ou déontologiques.
Toutefois, la politique éditoriale d’un site mobile sera beaucoup plus libre que celle d’une application embarquée validée par un tiers pour être disponible sur un App Store. La politique d’Apple en est le parfait exemple.

Avantage pour le service mobile.

• Accessibilité : il s’agit d’un problème de communication et d’usage principalement. En effet, pour accéder à un service mobile, il est nécessaire d’avoir l’url du service sur son téléphone mobile (enregistrée sous forme de signet dans les favoris du téléphone) ou de faire une recherche sur les moteurs de recherche de l’Internet mobile (Gallery, Google mobile, Yahoo mobile, Bing, etc) pour peu qu’il soit bien référencé.
Pour une application embarquée, il est nécessaire de télécharger l’application compatible avec son téléphone mobile et de l’installer. Évidemment sur l’iPhone ou les Google Phones HTC, ce mécanisme a été simplifié.
D’une manière générale, l’utilisateur utilise les Apps Store pour trouver une application, la télécharger et faire apparaître une petite icône représentative de l’appli sur le tableaux de bord du téléphone mobile.
Cependant les Apps Store sont victimes de leurs succès et il devient difficile de pratiquer une politique de référencement sur ces boutiques offrant des milliers de logiciels de toutes sortes. Pour être accessible, il faut être vu et donc pratiquer des buzz médiatiques et/ou faire de la publicité sur des mobile adserver, etc.
Aussi et bien qu’il y ait eu beaucoup d’efforts effectués dans le domaine des applications embarquées, il reste plus facile d’accéder à un service mobile. Cela reste effectivement proche des cas d’utilisation du Web : utilisation de moteur de recherche, ajout de favoris, référencement par Google/Yahoo et consœurs.

Avantage pour le service mobile.

• Utilisation en mode connecté/déconnecté : le gros avantage d’une application mobile est son usage en mode déconnecté. Les jeux sur mobile sont un parfait exemple de cas d’utilisation. Peu de jeux sur mobile permettent encore de jouer en réseau.
Un service mobile ne peut pas être accessible s’il n’a pas d’accès au réseau Internet (mode déconnecté) à partir du téléphone mobile.
Certains expliqueront qu’avec un site mobile de type Web App et en mode déconnecté, il est possible d’utiliser des fonctionnalités du site mobile en s’appuyant sur le cache du navigateur du téléphone. Il est vrai que l’on peut « bricoler » quelques astuces mais à dire vrai ce n’est pas une véritable solution.
Bref une appli mobile peut être utilisée en mode connecté et déconnecté si cela est nécessaire et s’il y a des fonctionnalités qui le permettent.
Un service mobile ne peut être accessible et utilisable qu’à partir du moment où il y a un accès (2G/3G, Wifi) à Internet à partir du téléphone mobile.

Avantages pour l’application embarquée.

• Les effets Waouh: il s’agit en fait de la capacité d’un service mobile ou d’une application embarquée de surprendre son utilisateur par des effets visuels ou d’usages.
Avec l’arrivée des téléphones équipés d’écrans tactiles et la révolution des usages de nouveaux effets sont apparus.
La mise à disposition de boites à outils (Software Development Kit) permettant d’interagir avec les fonctionnalités des téléphones mobiles, a par ailleurs favorisé l’utilisation de ces effets au sein des applications embarquées.
Parmi les effets, nous pouvons parler de la 3D, de la réalité augmentée, de l’effet Shake (secouer), Tilt (basculement mode paysage), du glisser/déposer, du pointer, du slideshow (cf. présentation pochettes albums sur iTunes), etc.
Il est effectivement possible de faire quelques effets sympa sur un site mobile de type Web App pour les téléphones Web Phones (iPhone, Google Phones, etc.)
Cependant les applications embarquées peuvent intégrer toutes les possibilités natives offertes par les systèmes d’exploitation des terminaux (la 3D et la réalité augmentée par exemple).
Aussi, les effets Waouh sont durablement plus spectaculaires sur une application embarquée.

Avantages pour l’application embarquée.

• Utilisation des fonctionnalités du téléphone: Avec la mise à disposition des SDK, il est plus facile pour un développeur d’application embarquée de faire appel aux fonctionnalités natives du téléphone mobile.
Il y a effectivement quelques progrès du coté de la mise au point des Web Apps pour interagir avec les composants du téléphones mais cela reste encore (et pour le moment) incomparable avec les possibilités d’intégration d’une application mobile.

Avantage pour l’application embarquée.

• Relation avec les clients : Le service mobile a l’avantage d’être facilement accessible par une grande majorité de terminaux mobiles. Si par exemple, vous réalisez une campagne SMS avec un lien cliquable pointant sur le service, il sera facile de générer de l’audience. Ce type de communication directe doit néanmoins être utilisée avec modération car la pratique pourrait s’apparenter à du spam pour les principaux destinataires.
Toutefois, l’application mobile présente un avantage car sur certains terminaux, il est par exemple possible de notifier/réveiller à distance une appli installée sur un téléphone mobile (le Push). Cette fonctionnalité permet d’avertir l’utilisateur d’une mise à jour d’une manière simple et discrète.

Avantage pour l’application embarquée.

• Billing : Il est possible d’ajouter des modules de paiement sur un service mobile afin de monétiser des contenus multimédias ou encore des services premium:

pour de petits montants, paiement via les kits de billing des opérateurs (Orange Wh-a, SFR, Bouygues Telecom, etc.)
pour un service mobile rattaché à un portail opérateur ou un kiosque des services (Gallery, Plazzza),
paiement via Carte Bancaire via un Web Service proposé par le commerçant propriétaire du service m-commerce,
paiement par Carte Bancaire via des facilitateurs de paiement (PayBox, Payline, etc.),
paiement via un compte de paiement (Paypal, Google Check out, etc.).

Sur les applications mobiles, les solutions sont encore (pour le moment) à leurs balbutiements. En effet, même si Apple a annoncé qu’il serait possible de réaliser des micro-transactions au sein même d’une application, ces mécanismes restent limités.
Il est cependant possible de facturer le téléchargement d’une application à partir d’un service mobile ou d’un quelconque App Store digne de ce nom.

Par ailleurs, il est important d’étudier les commissionnements exigés du fait de l’utilisation de ces solutions de paiement :

pour les kits de paiement des opérateurs de télécom : 30% pour l’éditeur, 70% pour l’opérateur,
pour l’utilisation de facilitateurs de paiement : quelques centimes par transaction et un coût mensuel variable calculé sur le CA réalisé,
pour l’utilisation du système de micro-transaction ou de facturation d’applications via Apple : 70% pour l’éditeur, 30% pour Apple.

Au regard de ces informations, il est facile de comprendre que la “monétisation” d’un service mobile reste intéressante bien que les réticences des utilisateurs à payer sur un service mobile constituent encore un obstacle non négligeable.

>Avantage pour le service mobile.

Conclusion:

Cette petite étude ne prétend pas être exhaustive tant les critères d’analyse peuvent être nombreux.

Pour résumer, il est indispensable avant de se lancer à la conquête du mobile de se poser quelques questions sur les cibles que l’on souhaite adresser avec un service ou une application mobile.

Le service mobile peut facilement concerner une grande partie d’un parc de téléphones en étant bien conçu et simple d’utilisation. la rapidité de sa mise œuvre et sa gestion au quotidien, permettent de bien débuter sur ce canal de communication.

Une application mobile confère une image différente, plus classieuse. Elle constitue une belle vitrine pour la marque qui choisit ce type de support. Toutefois, une application devra cibler une niche restreinte car le portage de ce petit logiciel sur différentes plateformes mobiles peut devenir dans beaucoup de cas, onéreux.

David Mas

Voir aussi :

Expertise

Stratégie mobile pour les médias

Ergonomie & Design

Technologies Web et Mobile

Blog

"Quel modèle industriel pour les applications mobiles ?", par Alexis Lesage - 05/03/2010

"Les éditeurs de contenus sur mobile : après la course à l’audience, la course aux budgets", par Marianne Fily - 25/03/2009

"Appli embarquée ou service mobile – Partie 1: Définitions", par David Mas - 06/10/2009

"iPhone & co : une appli ou pas ?", par Yves le Jan - 13/02/2009

"La musique sur mobile : à quand la "killer app" ?", par Nicolas Blaisot - 04/02/2009

Actus

Livre Blanc Smartphonisation

Novedia développe une approche inédite pour convertir efficacement un site Web en dispositif mobile

Novedia accompagne un portail web panaméricain dans sa stratégie mobile

Le site mobile de la Fnac fête son 2 millionième visiteur unique !

France Télévisions fait appel à Novedia pour réaliser son application gratuite sur iPhone

Novedia lance son centre de services dédié aux applications mobiles et WebApps : Novedia Apps

Dior a choisi Novedia pour créer l'application iPhone associée à sa campagne "The Lady Noir Affair"

Slate.fr confie la réalisation de son application iPhone à Novedia Agency

Warner Music France et Novedia Agency lancent la première application iPhone consacrée à un artiste pop français : Sliimy

Novedia confirme son expertise en géolocalisation avec Géopablo

Novedia Maroc surfe sur la vague iPhone

Dans les médias

Novedia et Convertigo développent une approche inédite pour convertir efficacement un site Web en dispositif mobile - Le Figaro

Médias et Mobiles - Stratégies

Des applications mobiles pour des entreprises plus réactives ? - Atelier

Les agences mobiles se spécialisent - Stratégies

iPhone apps : un relais naturel pour les médias - Le Journal du Net

Novedia accompagne les cybermarchands sur le mobile - Marketing Direct

Les "mobinautes" sont invités au voyage - Tour Hebdo

Sliimy en live sur Apple Store - Zikeo

Quel modèle industriel pour les applications mobiles ? - Le Journal du Net

Appli embarquée ou service mobile – Partie 1: Définitions

Tue, 06 Oct 2009 07:19:51 GMT

Si vous ne savez pas très bien quelle est la différence entre les deux voici quelques éléments pour vous permettre de comprendre ces notions :

- Définition d’une application embarquée :

Une application embarquée est un logiciel qui se télécharge et s’exécute sur un appareil électronique mobile comme par exemple un téléphone portable.

Ce petit logiciel s’appuie d’une manière générale sur le principe de widgets que nous connaissons sur nos ordinateurs.

Pour télécharger une application sur un téléphone mobile, il existe différentes possibilités:

transfert depuis un ordinateur via un câble de connexion,
à partir d’un service mobile,
via une boutique logicielle accessible depuis un téléphone mobile (App Store d’Apple, Windows Market Place, Nokia OVI, Android Market, etc.)
le cas échéant l’application est dite native ; elle est déjà dans le téléphone lors de l’achat du téléphone (l’opérateur ou le fabricant l’a ajouté comme fonction de base)

Une application embarquée est réalisée à partir de différents langages de programmation car il existe des environnements très hétérogènes au niveau des plateformes (les OS mobiles) installées sur les téléphones portables.

Aussi une application réalisée dans une technologie n’est pas nécessairement compatible avec toutes les plateformes (c’est d’ailleurs impossible). On parle alors de portabilité et de compatibilité de l’application avec le parc de téléphones que l’on trouve sur le marché mondial.

Les applications pour mobiles existent depuis l’apparition des téléphones portables.

Certaines sont de types professionnelles et d’autres orientées divertissement. Nous connaissons ces dernières à travers les jeux mobiles, un marché très important en termes de volumes et de titres de jeux vidéo adaptés pour les terminaux mobiles. Gameloft, société française issue d’Ubisoft, IPlay, Electronic Art sont les principaux éditeurs de la planète.

Toutefois, l’iPhone d’Apple a considérablement dépoussiéré l’image de l’application embarquée au point que beaucoup de développeurs, d’entreprises et les concurrents d’Apple s’intéressent de nouveau au phénomène. Les raisons principales du succès sont :

la mise en place d’une boite à outil de codage d’application relativement simple et financièrement accessible,
la diffusion mondiale d’un terminal ergonomique et puissant (puissance > à une console de type Nintendo DS),
un rendu très sympa,
une diffusion des applications facilitées via une seule et même boutique l’App Store,
un partage des revenus en faveur du créateur,
une bonne image d’Apple (ils sont bons sur le savoir-faire et surtout sur le faire-savoir),
etc.

- Définition d’un service mobile ou Web App:

Le vocabulaire Web App est apparu avec la sortie de nouveaux terminaux de type Web Phone comme les séries iPhone ou encore Google Phone pour ne citer que les plus connus du marché.

On parle de Web Phones car ces téléphones mobiles embarquent en leur sein des navigateurs Internet capables de supporter des technologies Web : Javascript, Ajax, etc.webapp

Ces navigateurs permettent ainsi de surfer sur le Web à travers un petit écran. Les sites Web ne sont toutefois pas si facilement visibles et ergonomiques sur ces terminaux.

Aussi, pour améliorer l’expérience de l’utilisateur par rapport à l’accès à l’Internet via ces téléphones, quelques acteurs ont inventé la notion de Web Mobile.

L’objectif est que le Web vienne sur le mobile alors que jusqu’à présent l’hétérogénéité des technologies de l’internet mobile conduisait à faire l’inverse.

Le Web Mobile s’appuie sur la capacité des navigateurs des Web Phones pour proposer des versions adaptées de sites Web pour ces téléphones.

Le but est de présenter l’information et de mettre en avant certaines fonctionnalités d’un site Web par exemple, afin qu’elles soient facilement utilisables en situation de mobilité avec un petit appareil électronique.

Parmi ces navigateurs mobiles, citons Safari sur iPhone, MiniMap sur Nokia, le navigateur mobile d’Android, etc.

Ces navigateurs mobiles ou leurs versions Web intègrent un moteur de rendu commun : WebKit. Ce moteur de rendu respecte des standards et normes définies dans les technologies Web.

Le développement et la compatibilité d’une Web App avec les différents navigateurs mobiles est facilité par le respect de ces normes.

A ce stade, il devient plus facile de comprendre qu’une Web App est une sorte d’application qui s’exécute au sein d’un navigateur mobile qui fait office de conteneur. On parle d’ailleurs pour bien simplifier la vie des non-initiés “d’appli browsée” ou de Web Application, en définitive de Web App.

Au-delà, le Web Mobile comme les applications embarquées subissent l’influence de la redéfinition des usages proposés par les téléphones mobiles ayant des écrans tactiles et capables de gérer des évènements liés aux interactions Homme-Machine : cliquer, glisser, double cliquer, pointer, secouer, tourner, parler, etc.

Ces nouvelles façons d’interagir avec un appareil ont un impact sur la possibilité de naviguer sur le Web Mobile. Finalement, Internet est accessible sans utiliser de clavier ou de souris et sans que cela ne nuise à la navigabilité au sein d’un service.

A travers l’ergonomie et les fonctionnalités supportées par les OS et les navigateurs des Web Phones, il est possible de modifier l’expérience des utilisateurs dans leur rapport à l’Internet en situation de mobilité.

Ainsi dans une Web App, il est possible de faire appel à des technologies du Web pour enrichir les possibilités d’un service mobile et d’utiliser si le Web Phone le permet, la gestion des évènements comme d’un écran tactile pour révolutionner les usages.

Pour les Web& Mobile Agencies, il devient plus intéressant de parler de Web App aujourd’hui car cela fait plus tendance, plus glamour de présenter un site mobile attractif visuellement et fonctionnellement.

Une Web App est un service mobile plus évolué. Il est vrai que le terme de site mobile souffre d’une mauvaise connotation dans le secteur. Cela rappelle sans doute trop l’époque du site mobile WAP (XHTML/WML) ou i-Mode (CHTML) peu engageant ou de qualité médiocre.

Bien que les Web Apps soient en vogue, il n’en reste pas moins que les terminaux Web Phones sont encore loin de constituer la majorité des téléphones mobiles du marché mondial.

Il est vrai que les fabricants de terminaux s’orientent vers ce type d’appareils pour leurs futures générations de produits. Pour une grande majorité de téléphones mobiles et des navigateurs mobiles embarqués, il n’est pas possible de profiter des technologies Web ou encore de la révolution des usages que nous connaissons tous.

Ainsi, nous assistons à une forte segmentation du marché à ce niveau :

Site mobile de type Web Apps pour les terminaux Web Phones qui participent à l’augmentation des usages du Web Mobile,
Site mobile classique XHTML pour les terminaux haut et moyen de gamme,
Site mobile basique WML pour les terminaux bas de gammes.

A ce jour les Web Phones ne concernent qu’une vingtaine de modèles de terminaux dans le monde et devraient sauf rupture technologique majeure, continuer de croitre dans les mois à venir.

Ce qu’il est important de garder à l’esprit est qu’un service mobile est un site adapté à un terminal mobile et qu’il est accessible depuis un navigateur d’un téléphone portable disposant d’une connexion internet. Cette définition marque l’opposition à l’application embarquée.

Maintenant que les idées sont claires, il devient plus facile d’aborder le sujet concernant les avantages et les inconvénients entre une application embarquée et un service mobile.

Nous aborderons ce point dans un prochain billet. (Suite: Appli embarquée ou service mobile – Partie 2: Le jeu des différences)

David Mas

Voir aussi :

Expertise

Stratégie mobile pour les médias

Ergonomie & Design

Technologies Web et Mobile

Blog

"Les éditeurs de contenus sur mobile : après la course à l’audience, la course aux budgets", par Marianne Fily - 25/03/2009

"Appli embarquée ou service mobile – Partie 2: Le jeu des différences", par David Mas - 06/10/2009

"iPhone & co : une appli ou pas ?", par Yves le Jan - 13/02/2009

"La musique sur mobile : à quand la "killer app" ?", par Nicolas Blaisot - 04/02/2009