Pages

dimanche 21 juin 2009

Le ballet et l'agilité

J'ai regardé un peu par hasard ce matin en déjeunant un documentaire sur l'expérience d'un groupe de jeunes Berlinois pour monter un spectacle de danse sur le Sacre du printemps de Stravinski accompagnés par le philharmonique de Berlin. Le documentaire couvre tout le projet, des répétitions et jusqu'à la représentation, et montre toutes les difficultés qu'il rencontre.


En particulier, il y a au bout d'un moment un fossé qui se creuse entre 5 ou 6 des élèves qui se débrouillent bien et le reste des élèves qui freinent la progression. La danse est une activité difficile. C'est fatiguant et parfois douloureux. C'est ennuyeux quand il faut recommencer des dizaines de fois le même enchaînement jusqu'à ce que tout le groupe le mémorise et le réalise en rythme avec la musique et en coordination avec les autres dans ses déplacements. Et au delà de ça, c'est un art. Il faut que les danseurs expriment l'argument du ballet. Et le thème du Sacre du printemps n'est pas facile. C'est un rituel pour le retour du printemps qui se termine par le sacrifice d'un élu pour que le printemps revienne. Donc des sentiments probablement assez perturbants.


En première approche le problème semble être imputable à ceux qui sont à la traîne. Ils ont leurs raisons : ils n'aiment pas la musique classique, ils n'ont aucune idée de ce que signifie faire des efforts, ils se contentent de faire le job parce qu'ils estiment que c'est suffisant. Certains sans forcément le reconnaître ont peur d'échouer et préfèrent échouer parce qu'ils n'ont pas fait ce qu'il faut qu'en ayant fait le maximum.


Le chorégraphe britannique Royston Maldoom dans son approche pédagogique se montre très exigeant. Il leur explique qu'il pense qu'ils peuvent faire mieux (alors que l'encadrement local pense qu'ils sont à leur maximum). Il exprime aussi la frustration que ressentent ceux qui ont déjà compris à devoir refaire encore à cause de ceux qui ne sont pas concentrés. Je ne suis pas sûre que cela ait eu beaucoup d'effet puisqu'ils envisagent quelques temps plus tard de déplacer les meilleurs dans un autre groupe pour qu'ils puissent avancer à leur rythme. Mais il fallait qu'il le fasse pour être cohérent avec lui même.


Ce qui est assez amusant, c'est que lorsqu'ils sont interrogés individuellement, Royston Maldoom le chorégraphe et Simon Rattle le chef d'orchestre reconnaissent que ce sont eux qui sont différents. Qu'ils ont une exigence d'aller toujours plus haut et de ne pas se contenter d'atteindre l'objectif qu'ils ne peuvent partager qu'avec très peu de gens. C'est un discours de passionné plus que d'artiste d'ailleurs. Les élèves qui sortent du lot énoncent aussi cette différence d'une manière moins rationalisée. Ils ont rencontré une personnalité, une activité, une perspective qui leur a donné la motivation de se dépasser.


Finalement le spectacle a lieu. Probablement pas aussi parfait que ce qu'il aurait pu être, mais le but de l'expérience était plus je pense de faire vivre quelque chose à ceux qui ont su en profiter. Certains de ceux qui n'aiment pas la musique classique ont trouvé que certains passages du Sacre du printemps étaient intéressants à sampler. D'autres ont pris confiance en leur capacité à réussir quelque chose.


Alors pourquoi ce grand détour par la danse, alors qu'en gros je parle plutôt d'informatique ?


Parce qu'il y a une similitude avec ce qui se passe dans les projets informatiques, surtout lorsque l'on aborde de nouvelles technologies. On ne se rend pas toujours compte que les techniques que nous maîtrisons ne sont pas forcément maîtrisées par les gens avec qui nous travaillons et que cela a un coût pour eux de les acquérir, voire parfois de reconnaître qu'ils ne les maîtrisent pas. Cela entraîne souvent une certaine frustration chez nous parce qu'on voudrait que ça aille plus vite, qu'ils adoptent ce qu'on leur présente comme la meilleure solution. Pire encore que leur manque de maîtrise, ça ne les passionne pas plus que ça.


Ce documentaire m'a amenée à repenser à des discutions que nous avons eu cette semaine, en particulier avec Eric Le Merdy et Etienne Charignon à propos d'une question posée initialement par Eric sur les stratégies que l'on peut adopter pour amener les gens aux pratiques Agile : est il indispensable de commencer en respectant strictement tous les préceptes ou peut on amener les gens à l'Agile plus souplement par l'exemple ?


Comme le fait remarque Etienne, la première démarche relève encore souvent du projet pilote. On plonge le client en immersion dans un projet géré 100% SCRUM et on leur dit qu'on sait qu'ils peuvent le faire. Cela s'apparente à l'expérience de réalisation d'un spectacle avec des professionnels. L'avantage de ce processus est de permettre une évaluation rationnelle et scientifique d'un ROI. Encore faut-il que les gens suivent. Comme dans l'expérience de ballet plus haut il est probable que certains adhèreront sans réserve et d'autres pas. Je doute que l'on puisse maintenir des pratiques Agiles sur la seule base d'un ROI. L'implication demandée est trop forte pour que le processus fonctionne de manière imposée. C'est probablement pour cela qu'Etienne constate des retours-arrière vers des projets "pâte à modeler". Tout le monde n'a pas vu la lumière mais certaines pratiques ont plu.


D'un autre côté, la méthode souple revient à introduire par l'exemple certaines de bonnes pratiques comme faire des tests unitaires, ou du TDD. Mais est que ça revient à avoir un mode de pensée Agile ? Probablement pas. C'est un peu comme aller en cours de danse 1h par semaine. On fait quelques assouplissements et on se sent plus en forme, allez, on mange bio comme la prof de danse parce que ça à l'air de lui réussir. Mais je doute que l'on comprenne de cette manière ce que représente la préparation d'un spectacle de danse et l'accomplissement de le délivrer en public. C'est face à la difficulté que l'on comprend vraiment les enjeux d'une pratique.


ça n'est pas inutile pour autant. D'abord, faire un peu de sport ça n'est pas si mal. Ensuite, je crois que les technologies se diffusent beaucoup de manière virale. J'ai vu émerger Java, le Web, UML, XML, J2EE. Aucune de ces technologie n'a été adoptée facilement au départ parce qu'elles étaient rationnellement meilleures comme on peut le penser maintenant. Elles ont été portées par des gens passionnés, qui y ont compris les avantages, on expliqué encore et encore, on fait découvrir ces technologies alors qu'ils étaient venus pour tout autre chose. La passion des gens est communicative même si on ne partage pas toujours tous les arguments présentés. Au bout d'un moment, la nouveauté fait partie du paysage, elle ne fait plus peur et on peut poser le problème du choix plus rationnellement.


Je ne vois pas d'opposition entre les deux stratégies. C'est plus une question de timing. La méthode souple amènera certains au grand saut dans un pilote, et voire plus si affinité. Dans le pire des cas, elle facilitera les choses pour plus tard en ayant appris certaines pratiques nécessaires dans un projet Agile ce qui facilitera les pilotes. Il faut juste être conscient que le saupoudrage de pratiques Agile n'est pas un projet Agile, c'est seulement une distribution d'échantillons. C'est peut être difficile à faire comprendre aux gens avec qui on travaille et qui sont tentés par la mode Agile.


Etienne pense que pour la stratégie en douceur, il faudra de la persévérance et de la pugnacité. A mon avis, il en faudra pour les deux stratégies de toute manière. Et peut être encore plus pour transformer les projets "pâte à modeler" en projets vraiment Agile. Ce qui compte c'est de rester passionnés et à l'écoute.


J'avais prévu au départ quelque chose plus lié à la musique suite à d'autres discussions. ça sera pour une autre fois.



La photo Modern Dance est de Kevin Eddy

mercredi 6 mai 2009

Générer un rapport PDF Sonar

Depuis Sonar 1.8, il existe un plugin de génération de rapport PDF.

La mise en oeuvre est très très simple.
Lancez la commande ci-dessous depuis un shell de commande ou l'IDE :
>mvn org.codehaus.sonar-plugins:pdf-report:0.1:generate -Dsonar.base.url=http://nommachine:9000

L'option -Dsonar.base.url n'est pas obligatoire, mais il se trouve que je ne peux pas faire tourner Sonar sur le port standard 9000. Attention, pas de / à la fin de l'url sinon l'url générée contient un // au début du path et il ne parviendra pas à lire les données.

Il n'est pas nécessaire de télécharger le plugin, il automatiquement téléchargé et mis en place via maven.

Le rapport en PDF est généré dans le répertoire target du projet maven racine.
Il contient pour le projet et chaque module, les ratios du dashboard (voir image ci-dessous), les valeurs du radar par catégorie (Efficiency, Maintainability, Portability, Reliability, Usability) et les hotspots Most violated rules et Most violated files.



La page du plugin se trouve là Sonar PDF Plugin.

dimanche 19 avril 2009

Sonar 1.8 et la Sonar Plugin Library

SonarSource vient de rendre disponible la version 1.8 de Sonar et un espace pour les Sonar plugins réalisés par la communauté Sonar.

Pour ceux qui auraient raté les épisodes précédents, Sonar est un produit open source de qualimétrie pour le monde Java.

Cet outil pilote l'exécution des outils d'analyse de code (PMD, Checkstyle, Findbugs) et de test unitaire sous Maven, historise et fait la synthèse de toutes ces informations. Il peut être étendu par plugins (par exemple PL/SQL ou l'intégration Hudson).

Il se montre particulièrement indispensable sur des projets multi-modules où il est difficile d'avoir une vue d'ensemble de la qualité en utilisant chacun de ces outils et Maven Dashboard.
Sonar agrège ces informations selon les catégories ISO (Efficiency, Maintenability, Portability, Reliablity, Usability) et permet une identification rapide du type d'impact sur un radar. La navigation projet / module / package permet d'avoir ces informations à différentes granularités.

Plusieurs systèmes permettent de localiser facilement la classe et la portion de code où il faut agir en priorité pour améliorer la qualité :
- un pavage qui permet de visualiser à chaque niveau l'importance des éléments et leur niveau de qualité
- un nuage qui met en évidence les classes qu'il est facile d'améliorer et celles qui présentent le plus de risque
- depuis la version 1.8, Sonar a ajouté les hotspots, des top5 des classes les plus indisciplinées, les plus longues à tester, les plus complexes, les moins testées ...

En plus des hotSpots, la version 1.8 ajoute en particulier le paramétrage de Findbugs, l'affichage des duplications sur le code source et le support de maven 2.1.

Vous cherchez encore des excuses pour ne pas évaluer la qualité de votre code ?
Allez le voir fonctionner sur Nemo et on en rediscute après.

jeudi 12 février 2009

Deux articles intéressants sur le développement des jeux multijoueurs dans le numéro de Novembre/Décembre du magazine Queue!.
ça se trouve là :
http://mags.acm.org/queue/20081112

mardi 28 octobre 2008

Ksar

image kzar Ksar est un utilitaire open source écrit en Java qui permet de représenter graphiquement l'ensemble des métriques d'un rapport sar. Pratique et efficace.

L'outil possède également différentes fonctions pour générer les rapports à distance en ssh, générer un rapport pdf, modifier la période affichée, etc.

On peut consulter la présentation de l'outil et le télécharger
via source forge http://sourceforge.net/projects/ksar
ou directement par le site Ksar http://ksar.atomique.net/.

jeudi 23 octobre 2008

Utiliser Redmine pour gérer les tests

Redmine serait il devenu aussi un outil de test ? Et non ;-)

Redmine (http://www.redmine.org/) est un outil open source qui se présente lui même comme une application Web de gestion de projet.

Redmine est par défaut orienté développement.
Les demandes que l’on peut gérer sont des évolutions ou des anomalies. Mais il est très facile de créer de nouveaux trackers pour créer des demandes qui concernent des opérations à réaliser sur la plate-forme de test ou des épreuves de test afin d'adapter le vocabulaire et les attributs.

Un outil de rapport permet d’afficher les demandes en filtrant les données selon les trackers et les attributs et de décider des colonnes à afficher. Les demandes qui ont une date de début et de fin sont présentes dans des vues calendrier ou gantt. Il est aussi possible de faire une gestion du temps passé sur ces demandes et de faire des synthèses.

L’outil est bien adapté aux petits projets que sont les campagnes de tests de performance.

Redmine permet de partager via un site Web toutes les informations qui contribuent à un projet de test :
- les documents de spécification ou des rapports via l’onglet document
- des informations de statut au jour le jour via les annonces
- des informations plus permanences sur les tests réalisés, les informations techniques peuvent être notées dans le wiki
- les résultats de test générés sous forme de pages Web peuvent être déployés dans la partie Web statique et référencés dans le wiki

Redmine a aussi quelques fonctions d’intégration intéressantes.
- il permet de gérer une liste de participants et d’envoyer automatiquement des mails via les annonces, lorsque des demandes sont crées ou changent,
- il permet de s’interfacer avec des SCM tels que Subversion pour partager des sources d’utilitaires ou de script
- il existe des plug-ins qui permettent de s’interfacer avec des outils d’intégration continue qui peuvent être utilisés pour générer automatiquement certains documents

En fait j’ai décidé de tester Redmine après une campagne de test ou les participants étaient sur 5 sites en France et en Belgique et où je constatais que je passais une bonne partie de mon temps à renvoyer des informations de planning, des documents et des fichiers de suivi excel par mail à des gens nouvellement arrivés sur le projet ou remplaçant quelqu’un.

Ce qui m’avait arrêtée jusque là pour utiliser des outils comme Trac c’était le temps nécessaire pour installer l’outillage. Je fais des campagnes sur des sites différents à chaque fois et je préfère voyager léger.

Alors pourquoi Redmine ?

Parce que c’est du Rails. InstantRails s’installe (enfin se dézippe) dans le bon répertoire en quelques minutes. Une fois copié l’application rails Redmine dans le bon répertoire, on démarre InstantRails, on lance deux scripts pour créer la base et l’initialiser et l’application est accessible. C’est magique !

Il faut environ une demi journée pour avoir en place les utilisateurs, les sous projets, les trackers spécifiques et les tâches de base ... et beaucoup plus de tranquillité par la suite pour se concentrer sur les tests.

mardi 19 août 2008

Crayon Physics

Un jeu tout mignon basé sur les principes de la physique

Le but du jeu est de déplacer la balle rouge pour qu'elle attrape les étoiles. La balle est déplacée en dessinant des objets qui interagissent avec la balle.


http://www.kloonigames.com/blog/games/crayon