Situation professionnelle

Freelance
Ouvert aux opportunités

Présentation

Passionné par l'édition logiciel, je souhaite concilier réalisations exceptionnelles, satisfactions des utilisateurs, qualité et plaisir de produire, grâce aux possibilités offertes par les nouvelles technologies, le tout dans un contexte agile.

Visitez mon blog et mes profils, et surtout, n'hésitez pas à me contacter !

A bientôt ...

Xavier blogue un peu ...

Agilité et ingénierie agile - Développement logiciel

http://xnopre.blogspot.com/
Agile Grenoble 2015 : atelier l'agilité de l'intérieur
23 nov. 2015

Ce jeudi 19 novembre avait lieu Agile Grenoble 2015. Avec Laurent Tardif et quelques autres personnes, nous avons animé toute la journée un atelier "L'agilité de l’intérieur". Voici sur mon retour sur cette expérimentation !

Historique


Le 8 octobre 2015, je vois passer un tweet de Laurent :


Passionné par le développement, le craftman, et l'agilité, je prends tout de suite contact avec Laurent. Il m'en dit un peu plus, le projet est effectivement un peu fou, mais je suis très motivé par cette expérience, alors je m'implique immédiatement, nous n'avons que quelques semaines pour préparer l'atelier !

L'idée


L'idée est simple : pendant Agile Grenoble, tout au long de la journée, développer un projet en mode Agile/Scrum pour permettre aux participants de la conférence (plus de 540 personnes) de voir comment se déroule un projet agile.

Le sujet


Laurent est fan de nouvelles technos, de devops et de bigdata. Il a donc une idée : aspirer les tweets #AG15 avec Flink, et générer un nuage de mots dans une page Web.

Objectif(s)


D'après moi, le piège d'un tel atelier est d'avoir trop d'objectifs : montrer l'agilité en action, faire participer les gens, et notamment les développeurs présents à la conf, avoir des feedbacks de tous les participants à la conférence, montrer des technos modernes et sympas, montrer les bonnes pratiques et l'excellence technique, etc...

J'ai partagé avec Laurent mon retour d'expérience sur un atelier similaire que j'avais vu à Mix-IT, et qui à mon avis n'avait pas trop marché, en tout cas, en tant que développeur, j'étais passé 5' voir les gars et je n'avais pas osé ou trouvé le moyen de contribuer.

Nous nous sommes donc donné comme principal objectif de montrer l'agilité, en espérant que du monde vienne voir, observer, et poser des questions. Nous savions que le Product Owner et le Scrum Master serait probablement moins occupés que les développeurs, et qu'ils pourraient donc assurer l'accueil des visiteurs et réponses à leurs questions.

Nous avons tout mis en oeuvre pour permettre l'intégration de développeurs motivés, mais sans compter dessus, donc en s'assurant d'avoir un minimum de ressources dans la journée (merci les copains !).

Quelques biais


L'atelier est expérimental, l'objectif est ambitieux, nous devons prendre quelques biais, et faire quelques concession. Les cérémonies doivent être rapides et animées oralement, pas le temps de mettre en oeuvre des atelier ou supports, par exemple pour les rétrospectives. Le produit est un POC (Proof Of Concept), tout comme l'atelier d'ailleurs, et le produit sera éphémère et jeté le soir même, la qualité et notamment les tests automatisés ne sont pas prioritaires. Et côté outillage et devops, nous faisons au plus facile (différent du plus "simple") : le serveur BackEnd sera celui de développement présent sur l'atelier, et l'application sera déployée par un simple "rsync" entre mon poste et le serveur Web.

Déroulement


Arrivés dès 8h, nous avons installé notre atelier dans le coin qu'on nous avait réservé dans l'Atrium, le grand hall principal de la conférence : tables en ilot pour développer, 1 poste pour vidéo-projeter le résultat, 1 poste pour développer le BackEnd, 1 ou 2 postes pour développer le FrontEnd, 1 tableau blanc avec post-its pour les retours utilisateurs, le backlog et ses "User stories", etc... L'installation prend du temps, mais nous sommes prêts à accueillir les visiteurs à l'heure des premières sessions après la keynote.




Itération 1 : les premiers pas


Nous expliquons le contexte et le projet aux personnes présentes. Le product Owner nous présente les histoires qu'il a imaginé et nous échangeons. Nous en retenons 2 pour commencer :

  • BackEnd : aspirer les tweets (nous avons déjà une base) et générer un fichier avec les noms des twittos
  • FrontEnd : afficher un nuage de points "en dur"

C'est parti, nous avons 30' pour livrer quelque chose pour les prochains changements de sessions de la conférence. C'est très court, nous rencontrons évidemment des problèmes techniques, mais heureusement, nous avions quelques billes de côté et nous pouvons livrer un premier nuage de mots pas très beau, codé en PHP, et basé sur un fichier texte en dur.

Itération 2 : pression


Comme prévu, nous commençons par une rétrospective qui fait ressortir que tout le monde est content, satisfait, s'amuse, mais... que ça va très très vite et qu'il faut vraiment travailler en "baby baby steps" ! Donc des histoires vraiment très petites et progressives !

Pour l'itération 2, nous nous engageons donc pour un affichage plus joli du nuage de mots, basé sur l'exploitation d'un fichier généré par le BackEnd, contenant les noms des twittos avec un poids en fonction de leurs nombres de tweets, quitte à pousser manuellement ce fichier sur le serveur Web. Malgré de nouvelles difficultés techniques, ainsi que des perturbations importantes subies par l'équipe, l'objectif est atteint de justesse, et nous finissions la matinée avec le résultat attendu :-)



Pause déjeuner : plaisir


Nous commençons tout juste à bien rentrer dans le projet, à produire quelque chose de sympa, l'excitation est telle que le repas est rapidement avalé et qu'on se remet à coder en "off" :-), comme cela peut arriver dans la vraie vie, lorsqu'on arrive à composer une équipe soudée et motivée sur un chouette projet ! ....

Itération 3 : pression toujours...


Nous attaquons le "sprint planning" (réunion de planification de l'itération à venir) par une nouvelle info des Product Owner : vers 13h30, nous aurons un créneau de 5' pour présenter notre atelier et notre produit en amphi, aux 540 participants ! Ouch....... La pression monte, mais l'excitation également : GO GO !!

Pour cette itération, les Product Owner nous demandent de peaufiner l'affichage et d'ajouter en haut de page le nombre de tweets collectés. Objectif raisonnable, on s'engage, et 3/4h plus tard, nous sommes sur l'estrade de l'amphi pour la présentation, yeah ! :


Pour l'anecdote, la présentation des mots est aléatoire (position, inclinaison), donc le résultat est différent d'un affichage à l'autre. De plus, juste avant de livrer cette version, j'ai pas mal tweeté pour tester. D'où la présence de mon nom bien visible sur le nuage présenté en amphi, je ne m'en suis pas rendu compte sur le coup, et ça n'était pas truqué, mais nous sommes des devs qui testons notre appli ! ;-)

Itération 4 : on s'éclate !


Après l'euphorie de notre présentation en amphi qui s'est bien déroulée, nous attaquons une nouvelle itération. Nouvelles demandes des Product Owner : alterner l'affichage entre les noms des twittos et les mots les plus twittés. Encore une fois, l'objectif sera atteint, mais avec un résultat logique mais que personne n'avait anticipé : nous obtenons un nuage avec des dizaines de mots, écrits tout petits et illisibles, sauf 1 qui est en gros au milieu du nuage..... #AG15 !! Evidemment, c'est le mot le plus twitté ! Nous en tirons les conséquence pour l'itération suivante : il faut filtrer ce mot, ainsi que d'autres non significatifs.

Itération 5 : encore du plaisir !


Nous finissions la journée avec une 5e itération en mode beaucoup plus cool, le plaisir prend le dessus sur la pression, tout le monde sent que l'objectif est atteint, aussi bien celui de l'application qui tourne bien et est visible en grand sur le mur, mais également l'objectif de l'atelier !


Conclusion sur l'atelier


Au final, après une journée très intense, mais riche en rencontres et en découvertes, l'objectif est atteint. Sur la journée, nous estimons avoir eu environ 50 personnes qui sont passées nous voir, et qui ont participé en posant des questions ou en donnant un coup de main pour coder une itération.

Nous avons eu tous les profils (Product Owner, Scrum Master, développeuses et développeurs, managers, ...) et tous les niveaux (grands débutants, pratiquants, ...).

Quelques moments m'ont particulièrement marqué et m'ont amené à me dire qu'un tel atelier avait sa place :

  • A la première itération, en plus de notre Product Owner de départ, nous en avions 7 autres : 7 personnes venues voir en quoi consiste le rôle de PO, comment se déroule un projet agile, une itération, une planification d'itération, les échanges entre PO et devs pour être sûr de bien se comprendre, comment tester et voir ce que ça donne sans trop anticiper, etc... Et toutes ces personnes ont pu profiter du déroulement des itérations pour tranquillement échanger et questionner notre PO et notre SM, qui du coup ont été moins disponibles pour l'équipe ;-)
  • Deux personnes sont arrivées pour la 2e itération, elles sortaient de la session "L'agilité pour les nuls" et dans les échanges que j'ai pu avoir avec elles, je me suis rendu compte à quel point c'était un excellent enchainement dans leur programme pour découvrir l'agilité
  • A l'itération 4, nous avons implémenté le nuage des mots les plus twittés, et tout le monde a été surpris, mais finalement pas étonné, de voir sortir en gros "#AG15" : l'agilité est également là, essayer, tester, voir ce que ça donne, ne pas anticiper, et être capable de rapidement s'adapter
  • ...


Certains choses ont peu ou pas marché :

  • A mon avis, l'application en ligne a été beaucoup moins visitée que nous le pensions
  • Le tableau de feedbacks des utilisateurs n'a reçu aucun post-its
  • Le "concours" du meilleur twittos a peu fonctionné, à part pour certains, ils se reconnaitront... ;-)

Mais globalement, cet atelier s'est très bien déroulé, probablement mieux que je ne m'y attendais, et ce fut un grand succès. En plus, nous avons pu noter plein de points d'améliorations pour que cet atelier soit encore plus performant, accueillant, didactique, etc... Que demander de plus ? :-)

Conclusion sur mon Agile Grenoble 2015


Depuis des années, je participe à Agile Grenoble, en tant qu'orateur, ou en tant que simple visiteur. Cette année, j'ai vu la conférence sous un autre angle, très différent des 2 premiers. J'ai passé ma journée à l'atelier, je n'ai vu aucune keynote et quasiment aucune "surprise" (si quelqu'un a filmé l'impro et les post-its, je suis preneur !!!), j'ai fini la journée épuisé, mais quel plaisir, quel bonheur, aussi bien de coder en live une application tout de même bien sympa en si peu de temps, de faire du pair-programming avec des bons copains ou des inconnus, de renseigner les visiteurs sur l'agilité, Scrum, l'état d'esprit agile, l'organisation, les façons de faire, etc...

Une grand merci à Laurent pour son initiative, aux personnes impliquées dans la préparation de cet atelier, à l'équipe d'orga qui nous a permis de tenter cette expérience, et bien sûr, à toutes celles et ceux qui sont passés nous voir, nous questionner, nous aider, nous perturber, nous encourager, ... MERCI !!


Crédits photo : Alex, Fred, Franck et moi
Voir l'article
Un proto d'appli Web en moins de 2 jours grâce à AngularJS
18 nov. 2015

Retour d'expérience et pourquoi j'ai pu réaliser un prototype d'application Web en 2 jours grâce à AngularJS et un peu d'outillage.

Le code source "exemple" (légèrement remanié et simplifié par rapport à l'original) est en ligne :
https://github.com/xnopre/proto-with-angular

Contexte

Début octobre, j'ai attaqué une nouvelle mission au sein d'une startup d'état au SGMAP à Paris. Je dois développer une application Web pour fournir aux personnes qui vont partir en retraite, une liste planifiée des démarches qu'elles doivent effectuer. L'application doit se composer d'une succession de 4-5 écrans permettant à l'utilisateur de saisir quelques informations, de répondre à quelques questions, puis de consulter la liste des démarches à effectuer.

Le groupe de travail du projet se regroupe toutes les 2 semaines, et il fallait rapidement leur montrer un prototype de l'application Web pour qu'ils puissent mieux se rendre compte de ce à quoi l'application pourrait ressembler.

J'avais donc 3 jours pour produire un prototype !

Les besoins, les contraintes et les concessions

J'ai commencé par recenser les besoins, et notamment de montrer au groupe de travail comment pourraient se passer les points suivants :

  • Enchainements des différents écrans
  • Saisie de données de l'utilisateur (étape 1) 
  • Poser des questions simples comme le choix du régime (étape 2)
  • Afficher certaines questions selon les réponses à d'autres questions (étape 4)
  • Présentation des résultats de la dernière étape, avec un découpage en chapitre ayant chacun un numéro, un titre, une échéance, et la possibilité "d'ouvrir" le chapitre pour consulter son contenu

J'ai rapidement évalué que je n'avais pas forcément besoin d'un véritable serveur (au sens applicatif, comme par exemple Play! ou NodeJS), ni d'une base de données. Les données des différentes écrans pouvaient être en dur, et le proto jetable.

Solution initiale : des pages statiques

La première solution retenue était de faire des pages statiques, avec textes et liens en dur. Mais finalement, très rapidement les contraintes sont apparues, et instinctivement, je me suis dis que je gagnerai du temps en faisant une "Single Page Application" (SPA) avec AngularJS.

Solution finale : AngularJS

Je vais essayer de synthétiser en quoi AngularJS m'a fait gagner du temps.

Pas besoin de serveur d'application

Avec Grunt, et la commande "Grunt serve", un serveur NodeJS est lancé sur le port 9100, la page de mon application est automatiquement ouverte dans mon navigateur, et puisque je suis en "live reload", dès que j'enregistre des changements dans mon éditeur (j'aime bien Brackets pour les applis JavaScript et Angular), la page en cours est rechargée automatiquement dans le navigateur : très productif !

A noter également que l'opération "grunt serve" (tout comme un "grunt build", non configuré dans le proto), grâce à la tâche "injector", permet d'injecter automatiquement dans le fichier "index.html" tous les fichiers CSS et JS, issues dans dépendances Bower, mais également créées dans l'architecture de l'application. Ainsi, les sections suivantes (entre les "injector" et "endinjector") sont automatiquement remplies et mises à jour :

<!doctype html>
<html lang="fr">

<head>

...

<!-- injector:bowercss -->
<link rel="stylesheet" href="lib/bootstrap-css-only/css/bootstrap.css">
<link rel="stylesheet" href="lib/textAngular/src/textAngular.css">
<!-- endinjector -->

<!-- injector:css -->
<link rel="stylesheet" href="css/main.css">
<!-- endinjector -->
</head>

<body ng-app="Proto" >

...

<!-- injector:bowerjs -->
<script src="lib/jquery/dist/jquery.js"></script>
<script src="lib/bootstrap/dist/js/bootstrap.js"></script>
<script src="lib/angular/angular.js"></script>
<script src="lib/angular-resource/angular-resource.js"></script>
<script src="lib/angular-cookies/angular-cookies.js"></script>
<script src="lib/angular-animate/angular-animate.js"></script>
<script src="lib/angular-touch/angular-touch.js"></script>
<script src="lib/angular-sanitize/angular-sanitize.js"></script>
<script src="lib/angular-bootstrap/ui-bootstrap-tpls.js"></script>
<script src="lib/angular-ui-utils/ui-utils.js"></script>
<script src="lib/angular-ui-router/release/angular-ui-router.js"></script>
<script src="lib/rangy/rangy-core.js"></script>
<script src="lib/rangy/rangy-classapplier.js"></script>
<script src="lib/rangy/rangy-highlighter.js"></script>
<script src="lib/rangy/rangy-selectionsaverestore.js"></script>
<script src="lib/rangy/rangy-serializer.js"></script>
<script src="lib/rangy/rangy-textrange.js"></script>
<script src="lib/textAngular/src/textAngular.js"></script>
<script src="lib/textAngular/src/textAngular-sanitize.js"></script>
<script src="lib/textAngular/src/textAngularSetup.js"></script>
<script src="lib/angular-mocks/angular-mocks.js"></script>
<!-- endinjector -->

<!-- injector:js -->
<script src="js/app.js"></script>
<script src="js/app.module.config.js"></script>
<script src="js/main-controller.js"></script>
<!-- endinjector -->

</body>
</html>


Et la configuration de la tâche "injector" pour Grunt est la suivante :

        injector: {
options: {
addRootSlash: false,
ignorePath: 'app/',
bowerPrefix: 'bower',
},
localDependencies: {
files: {
'app/index.html': [
'app/js/**/*.js',
'app/css/{,*/}*.css'
]
}
},
bowerDependencies: {
files: {
'app/index.html': ['bower.json'],
}
}
},

Moins d'HTML

Avec une SPA, j'ai simplement besoin d'un fichier index.html pour le cadre général, puis de petits morceaux d'HTML pour chaque page ("templates").

Le module 'Proto'

La déclaration du module applicatif Angular est très simple :
'use strict';

angular.module('Proto', [
'ui.bootstrap',
'ui.router',
'ngSanitize'
]);

Il faut alors indiquer avec l'attribut "ng-app" dans la page principale index.html qu'on veut utiliser ce module :

    <body ng-app="Proto">


Et toujours dans cette page, indiquer avec "ui-view" l'endroit où doivent être insérés les templates de chaque vue :

    <div class="container">
<div ui-view="">
</div>
</div>


Le routage

Pour le routage avec AngularJS, j'aime bien ui-router qui permet de travailler avec des "états". Pour mon proto, je déclare donc 5 états avec pour chacun : son nom, son URL, son template HTML, et le même controller pour tous les états, je ne fais pas comme cela dans la "vraie vie", mais dans le cas présent, ça me suffit et me simplifie le code :

'use strict';

angular.module('Proto').config(function ($urlRouterProvider, $stateProvider) {

$urlRouterProvider
.otherwise("/step1");

$stateProvider
.state ('step1', {
url:'/step1',
templateUrl: 'views/step1.html',
controller: 'MainCtrl'
})
.state ('step2', {
url:'/step2',
templateUrl: 'views/step2.html',
controller: 'MainCtrl'
})
.state ('step3', {
url:'/step3',
templateUrl: 'views/step3.html',
controller: 'MainCtrl'
})
.state ('step4', {
url:'/step4',
templateUrl: 'views/step4.html',
controller: 'MainCtrl'
})
.state ('step5', {
url:'/step5',
templateUrl: 'views/step5.html',
controller: 'MainCtrl'
});

});


Enchainement des écrans

Dans chaque écran (step1.html, step2.html, ...), je mets un formulaire "form", avec en bas, un bouton "Etape suivante" de type "submit", et j'indique à AngularJS que lors de la soumission du formulaire, je veux exécuter la fonction "nextStep()" :

<form ng-submit="nextStep()">

...

<input class="btn btn-success" type="submit" value="Etape suivante" />

</form>

Comme je suis fainéant, et que les états se suivent (1, 2, 3...), j'ajoute le numéro de "step" dans chaque état du routage :

    $stateProvider
.state ('step1', {
url:'/step1',
step: 1,
templateUrl: 'views/step1.html',
controller: 'MainCtrl'
})
.state ('step2', {
url:'/step2',
step: 2,
templateUrl: 'views/step2.html',
controller: 'MainCtrl'
})
...
});

Il suffit alors d'ajouter la fonction "nextStep()" dans le $scope du controller, cette fonction récupère l'état courant (ex : step2), ajoute 1 à son numéro, et demande au routeur de naviguer vers le nouvel état (ex : step3) :

'use strict';

angular.module('Proto').controller('MainCtrl', function ($scope, $state) {

...

$scope.nextStep = function() {
var currentStep = $state.current;
$state.go('step'+(currentStep.step+1));
};

...

});

Par la suite, j'ai facilement ajouté des boutons "Etape précédente" en appelant une fonction "prevStep()" qui exécute la navigation vers "step - 1".

Données pour chaque écran

Dans les étapes 1 et 3, j'ai des listes déroulantes pour choisir des dates (jour, mois, année). Toujours comme je suis fainéant, et pour ne pas copier-coller des tas de ligne "<option>", je remplis ces listes dans le contrôleur :

    $scope.listeAnneesNaissance = [];
for(var i = 1945; i < 2015; i++) {
$scope.listeAnneesNaissance.push(i);
}

$scope.listeAnneesDepart = [];
for(var i = 0; i < 10; i++) {
$scope.listeAnneesDepart.push(2015+i);
}

$scope.listeMois =['Janvier','Février','Mars','Avril','Mai','Juin','Juillet','Août','Septembre','Octobre','Novembre','Décembre'];


et je les utilise dans les pages avec des "ng-repeat" sur les "option" :

            <select name='naissance.mois' class='form-control proto-select' required >
<option ng-repeat='mois in listeMois'>{{mois}}</option>
</select>
<select name='naissance.annee' class='form-control proto-select' required >
<option ng-repeat='annee in listeAnneesNaissance'>{{annee}}</option>
</select>

De même, j'avais besoin de liste de régimes ("caisses") pour l'étape 2, et d'une checklist et son contenu à afficher à l'étape 5. J'ai donc créé des structures de données dans le contrôleur :

    $scope.caisses = [
{
nom: "MSA",
description: "Exploitants et salariés agricoles"
},{
nom: "CNAV",
description: "Régime général",
details: [
"Salariés de l'industrie, du commerce et des services",
"Agents non titulaires de l'Etat et des collectivités publiques",
"Artistes et auteurs d'oeuvres originales"
]
},{
nom: "Je ne sais pas"
}
];

$scope.checkList = [
{
titre: "Je reconstitue ma carrière",
delai: "Dès aujourd'hui",
infos: "Avez-vous déjà vérifié que les données de votre relevé de situation individuelle sont exactes et complètes ? Si oui, passez à l’étape suivante. Sinon, suivez les étapes ci-dessous",
actions: [
"Je crée mon espace privé sur le site Internet de ma caisse MSA pour avoir accès aux services en ligne personnalisés ICI.",
"Dans mon espace privé « Mon compte », je choisis « Internet » comme préférence de mode de réception des documents et des informations de mon dossier personnel.",
"Dans mon espace privé, je consulte mon relevé de situation individuelle.",
"Je vérifie que les données de mon relevé de situation individuelle sont exactes et complètes.",
"Si j’identifie des périodes manquantes ou informations erronées, je demande une régularisation de ma carrière en envoyant par courrier ou en déposant à mon agence les pièces justificatives correspondantes."
],
precisions: [
"Je peux à tout moment adresser mes questions par mail à mon conseiller depuis mon espace privé."
]
},{
titre: "Je contacte mon / mes régime(s) complémentaire(s)",
delai: "Dès que possible",
infos: "Nous avons détecté que vous dépendez pour votre retraite complémentaire de [XXX] . Vous devez effectuer une demande distincte auprès de ce régime.",
actions: [
"Je prends contact avec mon/mes régimes de retraite complémentaire ICI afficher les coordonnées des régimes concernés telles qu’extraites de l’annuaire retraite.",
"Je note ci-dessous les démarches à effectuer pour obtenir ma retraite complémentaire."
]
},{
...


Ensuite, j'utilise simplement ces données dans chaque page, avec là encore des "ng-repeat" sur différents éléments HTML imbriqués.

J'avais pressenti que pendant ces 2-3 jours de préparation du proto avec le Product Owner, ces données allaient changer, mais également les façons de les présenter. Ca n'a pas raté, et j'étais bien content de ne pas avoir dupliqué des paquets de "div" HTML, mais d'avoir un "ng-repeat" sur un "div", et donc de n'avoir que ce "div" à modifier... :-)

Les animations

A l'étape 4, on pose quelques questions complémentaires à l'utilisateur, et certaines questions doivent apparaitre selon les réponses à la question précédent.

Pour cela, avec AngularJS, c'est très simple sans code. Les boutons radio pour les réponses sont classiques, et j'utilise "ng-model" pour stocker "false" ou "true" dans la variable "inactivite" qui sera automatiquement créée dans le scope (pas besoin de la déclarer explicitement) :

    ...
<input ng-model="inactivite" type="radio" value="false" name="inactivite" />
    ...
<input ng-model="inactivite" type="radio" value="true" name="inactivite" />
    ...


Et ensuite, le "div" suivant est complété avec un attribut "ng-show" pour afficher le "div" si la variable "inactivite" a la valeur "true" :

    ...
<div ng-show="inactivite === 'true'">
...

Aussi simple que cela !

Conclusion

Après moins de 2 jours de travail, y compris un peu de CSS non mentionné ici, je disposais d'un prototype qui répondait aux attentes, qui présentait l'enchainement des écrans, des données fictives et quelques animations. Ce prototype a permis un premier travail d'échanges avec le Product Owner, qui a demandé quelques changements. Et dès le lendemain, nous avons pu le présenter au groupe de travail qui a tout de suite pu se projeter plus concrètement dans l'outil imaginé depuis plusieurs réunions de préparation du projet.

C'est après ces 3-4 jours de prototypage et démonstration, et avec un peu de recul, que je me suis vraiment rendu compte que c'est grâce à AngularJS que j'avais pû produire un tel résultat en si peu de temps, et je voulais partager ce retour d'expérience.

A noter que dans les semaines qui ont suivi, ce prototype a fait émerger l'idée de développer un BackOffice pour permettre au Product Owner et aux personnes du métier de configurer en ligne les règles métier de l'application et ses contenus. Et ce BackOffice a été développé avec AngularJS.

Par contre, en parallèle, les développements ont également avancé sur l'application destinée aux usagers, le FrontOffice, mais finalement (pour d'autres raisons, notamment de tests) en mode "classique", avec des pages HTML servies par un serveur Play Framework, et donc sans AngularJS...
Voir l'article
Laissez l'équipe faire ses choix techniques !
16 mars 2015

Introduction


Ce que j'aime bien dans l'agilité, c'est le côté "bons sens" et pragmatique. Et ce que j'aime particulièrement dans Scrum, c'est le nombre limité de rôles, et la précision du périmètre de responsabilité pour chacun de ces rôles. Voir mon précédent article "Scrum : quel est le rôle le plus important ?".

Pour un projet de développement logiciel, les équipiers sont essentiellement des développeurs. Tout comme le Product Owner a la responsabilité de la partie fonctionnelle (quelles fonctionnalités et pour quand ?), les équipiers ont la responsabilité de tout ce qui est technique : choix des technologies, choix de l'architecture de l'application, règles communes de codage, qualités, innovation, etc ...



Qu'est-ce que j'entends par "Innovation" ?


Nous sommes dans un métier d'artisanat, nous faisons rarement 2 fois la même chose, et l'éco-système bouge très vite, il y a très souvent des nouvelles technos intéressantes, de nouveaux langages, de nouvelles méthodes ou façon de développer, etc ... 

Donc par "innovation", j'entends tout ce qui va permettre de faire du développement moderne, non pas pour être à la mode, mais pour mieux répondre aux besoins en profitant au mieux des nouveautés. Il y a donc bien sûr les nouveaux outils et les nouveaux frameworks. Mais il y a également les changements (nouveautés ou remises en questions) sur la façon d'écrire le code, le commenter ou pas, le présenter, l'organiser, l'architecturer, etc ... Cela porte donc sur des choix structurant pour l'ensemble du projet (choix d'architecture par exemple), mais également sur les choix quotidiens du développeur pour écrire son code, comme par exemple mettre en place une API fluent parce que le code sera plus lisible et bien plus facile à utiliser pour les successeurs !

Innover ou pas ? 


J'observe que la question est souvent posée, et parmi les réfractaires, on peut trouver des managers et des développeurs.

De mon point de vue, les managers devraient pousser plus à l'innovation. Mais il y a malheureusement plusieurs raisons pour qu'ils ne le fassent pas. Par exemple, ils peuvent avoir peur que cette innovation soit excessive par rapport aux besoins et aux contraintes du projet. Ou encore, ils ont un manque de compétences pour en juger.

Et d'un autre côté, certains développeurs sont eux aussi septiques par rapport à l'innovation, mais c'est souvent par peur de l'inconnu en sortant de leur zone de confort.

Pour ma part, c'est évident, il faut innover en permanence. Nous sommes dans un métier qui bouge en permanence, tant du point de vue outils que méthodes, il est important que les développeurs suivent un minimum les évolutions, à la fois pour produire des logiciels modernes, et également pour entretenir leur employabilité !

Mais bien sûr, cette innovation doit être dosée et maitrisée. Il ne faut pas être excessif et se jeter en permanence sur les nouvelles technos à la mode. De même, il me semble très dangereux de faire cohabiter, au sein d'un même produit, plusieurs librairies qui rendent le même service. Idéalement, l'architecture doit permettre, si besoin, de remplacer une librairie par une autre, s'il y a réellement un intérêt.

Une erreur : l'innovation par certains !


Parmi les erreurs que j'ai pu observer ou vivre, il y a la solution de confier l'innovation à une personne (ou un groupe de personnes). Pour un manager, c'est rassurant, certes. Mais les effets négatifs sont nombreux.

Déjà, cette solution est très frustrante et démotivante pour l'ensemble de l'équipe. Bon nombre de développeurs sont intéressés pour chercher et tester de nouvelles technos. Et s'ils ne le sont pas, il faut les y inciter, car cela fait partie de notre métier.

Par ailleurs, cette approche limite l'innovation, puisqu'elle est confiée aux idées et aux visions d'une seule personne.

Et enfin, cette façon de faire limite énormément l'implication de l'équipe pour l'intégration de ces nouvelles technologies, induisant prise de distance et démotivation.

Une autre erreur : la validation par tous !


Parmi les profils de développeurs, il y a ceux qui sont plus dans "la production" et ceux qui sont plus dans "l'apprentissage" (j'essaierai de publier un article à ce sujet). Je ne suis pas sûr que ces profils puissent travailler ensemble au sein d'une même équipe "projet" (i.e. travaillant ensemble sur un projet). Mais ces profils cohabitent au sein de tout service développement logiciel, et cela peut être une réelle et importante difficulté à gérer pour les managers.

Mais pour revenir à l'innovation, une erreur me semble-t-il, est de faire valider toutes les innovations par l'ensemble des développeurs d'un même service. En faisant cela, on met en dualité les 2 types de profils précédent, pour lesquels il ne peut pas y avoir de consensus. Soumettre l'adoption d'une innovation à l'approbation générale a comme seule issue de limiter cette innovation, puisque les profils les plus "conservateurs" ou "craintifs", refuseront toutes innovations.

Le premier effet est donc une innovation extrêmement limitée.

Le second est un désengagement et un découragement de ceux qui sont dans "l'apprentissage" et qui pourraient pousser ces innovations indispensables. Le service de développement logiciel n'évolue pas, et en quelques années, il est dépassé et produit des logiciels d'un autre temps. Dommage...

Conclusion


Chaque développeur est un artisan, qui doit être passionné par son métier, et qui a la responsabilité d'innover régulièrement.

Et chaque manager doit avoir conscience de cette nécessité, de l'aspect indispensable de l'innovation, sans excès et maitrisée, il doit donc laisser une marge de manoeuvre aux développeurs pour cette innovation, il doit leur faire confiance pour les choix d'innovation qu'ils feront pour le projet en cours, il doit inciter tous les membres de l'équipe vers cette innovation, et il doit accompagner les "conservateurs" pour que ces derniers puissent comprendre les enjeux, dépasser leurs craintes et sortir de leur zone de confort.






Voir l'article
Scrum : quel est le rôle le plus important ?
19 janv. 2015

Introduction


Pour l'organisation agile d’un projet de développement logiciel, Scrum propose un cadre simple et précis, avec notamment 3 rôles, ni plus ni moins :

  • Scrum Master
  • Product Owner
  • Equipier

Ces derniers mois, à plusieurs reprises, je me suis posé la question de savoir lequel de ces rôles était le plus important, voici mes éléments de reflexion.


Le « ScrumMaster » est le rôle le plus important


Je pratique l’agilité depuis des années, et quasiment depuis le début, j’ai estimé que le rôle du ScrumMaster était le plus important. En effet, c’est grâce à ce « facilitateur », ni fonctionnel, ni technique, que l’approche agile peut être bien mise en place et garantir le succès de l’agilité.

Le ScrumMaster a un rôle primordial en s’assurant que chacun des acteurs respecte bien le sien, en protégeant l’équipe des interférences extérieures, en la guidant dans ces choix de priorités, d’optimisation de la valeur produite, de solutions techniques et d’architecture, etc …

Mais le ScrumMaster a également un rôle très important, et souvent difficile, sur les aspects humains, pour fédérer l’équipe, en l’aidant à exprimer ses difficultés et trouver les meilleures solutions, pour atteindre l’efficacité maximum.

Le rôle de ScrumMaster est donc très important pour garantir la bonne mise en oeuvre de l’agilité et sa réussite.

« ProductOwner », un rôle encore plus important ?


Dans mon cheminement de découverte de l’agilité, par la suite, j’ai mieux compris le rôle du Product Owner, le « responsable du produit ». Cet acteur maitrise le métier, les besoins des utilisateurs, leurs attentes, et comment y répondre au mieux. Il a une vision d’ensemble sur le projet, le planning, les étapes clés, les contraintes, et les contextes (vision d’entreprise, budget, autres projets, …).

Il n’a pas de compétences techniques, idéalement, il a des notions pour comprendre certains choix ou contexte, en oubliant le reste. Il se polarise donc entièrement sur le fonctionnel, pour optimiser la valeur produite par l’équipe, en priorisant les histoires du backlog, et en les rédigeant au mieux (précisions, exemples, critères d’acceptation).

Il est en contact avec l’extérieur de l’équipe (clients, utilisateurs, managers, autres équipes, …). Il s’assure de bien capturer les besoins des utilisateurs, de présenter au mieux le contexte à l’équipe, et il est en charge de transmettre les informations relatives au projet : avancement, difficultés éventuels, planning prévisionnel remis à jour régulièrement, etc …

Le rôle du Product Owner est donc très important pour garantir de faire le bon produit, avec le meilleur budget, et dans les meilleurs délais possibles.

Mais finalement, le rôle d’ « Equipier » est primordial !?


Je trouve que les équipiers sont souvent négligés, ou sous-estimés, voire dénigrés. Et pourtant, ce sont eux les « faiseurs ». Sans cette force vive de réalisation, le produit n’existerait pas. Ils sont donc au coeur du projet, au service du produit, mais à la servitude de personne.

Pour un projet de développement logiciel, les équipiers sont le plus souvent des développeurs qui doivent avoir toute latitude dans leur organisation et leurs choix technique, l’équipe est auto-organisée.

Pour une itération, l’équipe prend un engagement sur un ensemble de fonctionnalités qu’elle va implémenter au cours de cette itération. Elle est donc engagée sur le « quoi », et fait les choix qui lui semble bons sur le « comment », du moment qu’elle atteint son objectif.

Personne en dehors de l’équipe ne peut juger ou commenter les choix suivants dont seuls les équipiers ont la responsabilité :

  • traiter les histoires dans l’ordre du backlog ou pas, 
  • faire du pair-programming ou du dojo à plusieurs, 
  • investir du temps pour refactorer des parties du logiciel ou innover (tant que c’est au service du produit), 
  • etc …

En contre-partie, les développeurs ont la charge et la responsabilité de la qualité, sous tous ses aspects : logiciel sans défaut et maintenable, architecture évolutive, code propre et lisible, outillage performant, etc …

Le rôle d’Equipier est donc très important pour que le logiciel soit produit, et qu’il soit bien réalisé, en toute qualité.

Conclusion


Vous l’avez compris, finalement, chacun des rôles proposé par Scrum a son importance, et il est primordial que chaque rôle soit bien compris et bien respecté.

En résumé, le Product Owner est en charge de tous les aspects fonctionnels (le « quoi »), les équipiers sont en charge de tous les aspects techniques (le « comment »), et le Scrum Master est là pour que « tout roule », pour que l’équipe soit efficace, productive, créative et en permanente amélioration continue.

Personnellement, dans une époque du « no-ceci », « no-cela », je me rapproche de plus en plus des fondamentaux de l’agilité, et dans la mise en oeuvre précise de Scrum.

Et vous ? Quel est votre vision sur les rôles de Scrum ?
Voir l'article
Calendrier niko-niko : l’équipe surveille son moral !
23 oct. 2014

C’est quoi ? Quel est l’objectif ?


Le "niko-niko" est un calendrier, mis en œuvre par l’équipe et pour l’équipe, sur lequel chaque membre de l’équipe reporte à la fin de chaque journée son ressenti avec une pastille de couleur.

Par "équipe", j’entends bien entendu l’ensemble des équipiers, le Product Owner s’il est bien impliqué au quotidien, et le Scrum Master (sauf peut-être s’il est uniquement un animateur ou facilitateur). En fait, il me semble intéressant que toutes les personnes participant tous les jours au stand-up, contribuent à cet indicateur !



L’objectif du "niko-niko" est d’avoir un suivi le plus visuel possible du moral général de l’équipe. Il permet à l’équipe de déceler au plus tôt une tendance à la baisse de ce moral général, et d’y réagir le plus vite possible. La présence d’une pastille rouge (ou de plusieurs) permet également de déceler une difficulté pour un ou plusieurs membres de l’équipe, de l’évoquer lors du stand-up dès le lendemain matin, et si besoin, de prendre un temps d’échange et de réflexion pour trouver une solution et tout de suite désamorcer un poids pour la suite de l’itération.

Lorsque je suis Scrum Master (ou coach), mon objectif est que le calendrier soit le plus vert possible …

Mise en œuvre

Pour moi, l’idéal est de faire, sur une simple feuille de papier, un tableau représentant les jours et semaines pour l’itération à venir (voir image), avec des cases suffisamment grandes pour que tous les membres de l’équipe puissent y coller une pastille.

Ce calendrier est à positionner dans la pièce où travaille l’équipe, de façon à ce qu’il soit très facile d’accès, idéalement près du "Scrum board" pour l’avoir sous les yeux lors des stand-up du matin, et pas loin de la sortie de la pièce pour que chacun pense à mettre sa pastille le soir avant de partir.

Les pastilles sont disponibles en 3 couleurs pour répondre à la question "Comment as-tu ressenti ta journée ?" :

  • Vert J : la journée a été bonne
  • Bleu (ou jaune ou autre) : K : journée moyenne, ni bonne, ni mauvaise
  • Rouge L : la journée a été mauvaise

Il est important d’échanger au sein de l’équipe sur l’échelle d’évaluation, et donc sur ce qu’est une "bonne" journée, une "mauvaise" journée, ou une journée "moyenne". Certains auront facilement tendance à mettre un "vert", et d’autres le garderont pour une journée plutôt "exceptionnelle". Moi, je propose "vert" si on sort avec la banane J, et "rouge" si on repart le soir en fronçant les sourcils ou en bougonnant L, et "bleu" sinon.

Lors d’un projet, nous nous étions posé la question : faut-il évaluer ma journée par rapport à mon avancement, ou si j’ai apprécié ce que j’ai fait. Certaines journées, on n'avance pas trop mais on est content de soi. Ou inversement. Nous avons donc testé, le temps d’une itération, un double calendrier pour ces 2 critères. Au final, cela nous a semblé compliqué à maintenir, mais également à exploiter. Nous sommes donc revenus à un seul calendrier.

Une autre question portait sur l’anonymat. Il arrive assez souvent que des membres de l’équipe oublient de mettre leur pastille le soir en partant. Sans initiales (et sans nom), difficile de savoir qui a oublié. De plus, lorsqu’il y avait une pastille rouge, il pouvait être intéressant de demander des précisions à la personne concernée pour comprendre le pourquoi du "rouge", et essayer, ensemble, de trouver une solution. Nous avons, là encore, essayé en mettant nos initiales sur nos pastilles. Pour différentes raisons, nous sommes revenus à l’anonymat, qui finalement, n'est pas réel au sein d'une petite équipe soudée, et les échanges lors du stand-up permettent de trouver les causes puis les solutions. Par contre, vis-à-vis de l'extérieur (management), l'indicateur est bien anonyme ...

Pièges ou erreurs 

Avant tout, il faut que le "niko-niko" soit utile. Lors d’une de mes premières expérimentations, il y avait un maximum de "rouges", ça nous confirmait bien le fait que le projet s’annonçait mal (planning irréaliste et grosses difficultés techniques), mais objectivement, l’indicateur ne servait pas à grand-chose, et surtout, nous n’en avons pas fait grand-chose. Il faut donc veiller à ce que ce soit utile, renseigné, surveillé, et utilisé pour l’amélioration de l’équipe.

Comme dit en introduction, c’est une indicateur mis en place "par" l’équipe et "pour" l’équipe. Une erreur constatée est une utilisation de cet indicateur par le management dans une approche plus "commande-contrôle" que "management agile". Je ne dis pas que cet indicateur ne doit pas être visible pour les managers, au contraire, ça peut leur être utile pour avoir discrètement et rapidement une évaluation du moral de l’équipe, mais c’est à l’équipe de l’utiliser pour réagir et s’améliorer.

Une autre erreur, qui limite la représentativité de l’indicateur, et la non participation de certains acteurs du projet, par exemple le Product Owner, parce qu’il est dans une autre pièce, alors qu’il est tous les jours au stand-up du matin, et en collaboration quotidienne avec l’équipe. Pourtant, s’il passe une mauvaise journée, il est probablement intéressant pour le reste de l’équipe de le savoir, et de réagir si elle y est pour quelque chose.

Conclusion

Le "niko-niko" est un indicateur très facile à mettre en place, et à mon avis, très intéressant dans un fonctionnement agile et d’amélioration continue. Le principe de base est simple, mais vous pouvez l’adapter à votre contexte, l’important étant d’essayer, en évaluant objectivement des essais, et de rester simple ! Sans oublier d’être vigilant aux pièges ou dérives, comme ceux mentionnés ici ou d’autres, pour que cet outil garde tout son intérêt et son apport à l’équipe.

Alors n’hésitez plus, lancez-vous, testez-le, et faites-moi part de vos retours d’expériences !

Voir l'article
On parle de TDD autour d’une bière …
28 avr. 2014
Il y a quelques temps, j’ai eu des échanges très intéressants avec un copain qui m’interrogeait sur ma vision et ma pratique du TDD. Voici une retranscription un peu arrangée de nos échanges ...

Lui : Récemment, je me suis intéressé à des librairies Open Source Java, accompagnées de plus ou moins de tests. Le TDD permet-il de garantir que le code est bien testé ?

Moi : Il faut bien distinguer le TDD et les tests unitaires. Le TDD est une “pratique”,
une façon d’écrire le code et ses tests unitaires. Lorsque tu récupères du code, par exemple une librairie Open Source, ce que tu y trouves, ce sont des “tests unitaires”, écrit ou non en TDD, à priori tu ne le sais pas. Et pour répondre à ta question, la présence de tests unitaires ne garantit pas que le code est bien testé, ni que tout le code est testé. Mais, si le développeur a bien fait son boulot, normalement le code fourni est de bonne qualité, du moins de meilleure qualité que sans tests. Les tests unitaires présent garantissent un certain fonctionnement du code, et permettront plus facilement de corriger le code, voire le faire évoluer.

On dit que le TDD permet de mieux documenter le code, par l’exemple. Tu en penses quoi ? 

Là encore, ce n’est pas le TDD qui fera office de documentation, mais les tests unitaires, puisque c’est bien ce code qui est disponible et que tu peux relire. Je me répète, mais le TDD est une “pratique”, ça n’est pas un résultat qu’on peut ensuite consulter. Par contre, pour l’aspect “documentation”, je ne crois pas que le TDD garantisse une “bonne” documentation du code. Qu’ils soient écrits en TDD ou pas, si des tests unitaires sont mal écrits, s’ils ne sont pas simples, faciles à relire, ils n’aideront pas le relecteur à comprendre ce que le code fait. En revanche, une bonne pratique du TDD peut guider le développeur vers de meilleures tests, donc un gain sur cet aspect documentation.

Dans ton cas, est-ce que tu produis de la documentation, autre que les tests ? 

Déjà, concernant les tests unitaires, je m’efforce de les rendre les plus lisibles et explicites possible, je n’hésite pas à mettre en place un DSL (“Domain Specific Langage”) spécifique au contexte métier et fonctionnel de mes développements, avec une API la plus “fluent” possible. Mon objectif est que mes tests puissent se lire comme des phrases, comme un texte qui raconte une histoire. Ensuite, concernant les commentaires, je n’en mets pas. Tout comme Oncle Bob dans son livre “Clean Code” (que je recommande encore et encore ….), je considère les commentaires comme un échec de nommage et de présentation de mon code. J’ai une exception : je mets éventuellement de la JavaDoc pour une librairie “externe” qui sera utilisée par d’autres personnes, mais attention, le maitre mot pour une documentation : elle doit être utile et tout le temps à jour ! Et pour compléter le tableau de la documentation, je préconise quelques notes d’architectures, non pas rédigées avant les développements, mais rédigées pendant et après les développements, et surtout, maintenues à jour, pour présenter les grands principes d’architecture retenus pour le produit développé.

Et justement, question architecture, on dit que le design doit émerger grâce au TDD, qu’en penses-tu ?

Pour moi, il y a une mésentente sur le fait que l’architecture doit émerger grâce au TDD. Je suis convaincu qu’on ne peut pas développer une application de taille moyenne ou grosse, en partant d’un test et d’une seule classe, avec l’architecture de l’ensemble de l’application qui émerger petit à petit. A mon avis, de cette manière, on arrive à une architecture “spaghetti”. Ou alors, le développeur est très fort, ou plus probable, a en fait en tête l’architecture vers laquelle il veut aller.

En développement agile, on parle bien de “vision”. Il faut avoir une “vision” du produit qu’on veut développer, aussi bien au niveau fonctionnel (savoir dans les grandes lignes ce que devra faire le produit), mais également au niveau architectural, qui consiste à prévoir à grande échelle le découpage en modules ou librairies. Au démarrage d’un projet, je conseille aux équipes de réfléchir et définir cette “vision” de l’architecture à grande échelle du produit. Par contre, hors de question de définir, avant de coder, le design interne d’un module ou d’un package. Là, c’est bien le TDD qui va nous aider à faire émerger l’architecture, en partant des besoins fonctionnels, et des besoins en code testable. 

OK mais de quoi pars-tu dans ce cas ? 

Prenons le cas d’un package en Java. C’est un ensemble qui a une cohérence fonctionnelle, qui va donc répondre à un ensemble de besoins, cohérents entre eux. Cela va s’exprimer, par exemple, par la mise en place d’une API proposée par une classe du package, ce sera le “point d’entrée” du package. En TDD, on va donc pouvoir partir de cette classe et de son API pour commencer par écrire des tests, probablement en “mocking”, approche dite “London school”, en utilisant des mocks pour les 3 ou 4 collaborateurs de cette classe. Une fois que ces tests passent avec succès, on va pouvoir s’attaquer à chaque collaborateur qui vient d’être mocké pour écrire les tests de ce collaborateur et son implémentation, peut-être là encore avec l’usage de mocks. Et ainsi de suite, jusqu’aux “classes terminales”, celles qui n’ont pas de collaborateurs (les “feuilles” de l'arborescence des classes), et pour lesquels on écrit des tests unitaires “purs” (sans mocks). Pour moi, elle est là l’émergence du design par le TDD !

Est-ce que pour toi il y a un lien entre TDD et code propre ? 

Oui, bien sûr ! Lorsque j’interviens auprès d’une équipe, avec par exemple une formation “Tests unitaires et TDD” sur 2-3 jours, je leur parle de tests unitaires et de TDD, bien sûr, mais ces journées sont également le moyen pour moi de les interpeller sur pleins d’autres aspects du développement : le “Code Propre” (ou “Clean Code”), la présentation du code, sa lisibilité, sa simplicité et son expressivité, les commentaires (ou pas ...), les bonnes pratiques d’équipes, la maîtrise de son outil (IDE), les erreurs d’architectures, comme par exemple les problèmes liés à l’héritage, etc … Tous ces thèmes sont étroitement en relation et nécessitent d’être tous mis en oeuvre pour aller vers le succès, et le code propre est une des premières pierres !

A quel problèmes d’héritage fais-tu allusion et pourquoi ?

En programmation objet, on fait souvent un mauvais usage de l’héritage. Moi le premier, pendant des années, j’étais le “maître” en la matière, je produisais des architectures avec des héritages de folie ! Jusqu’à ce qu’un jour, un jeune collègue, plus jeune que moi (comment est-ce possible ? … ;-) ..) est venu m’expliquer que c’était mal … J’ai mis du temps à le comprendre et à l’accepter, mais il avait raison. 

Trop souvent, on utilise l’héritage pour apporter des fonctionnalités à un objet, c’est pratique. Mais c’est une erreur, car ces apports de fonctionnalités sont une facilité mais ne caractérisent pas réellement ce qu’est cet objet. C’est de “l’héritage technique”. La bonne solution n’est pas l’héritage mais l’aggrégation, c’est-à-dire fournir à l’objet un collaborateur qui va pouvoir l’aider dans ses tâches en venant avec ses propres fonctionnalités. 

Et concernant les tests unitaires, l’héritage est un véritable fléau et posent bon nombre de problèmes. Par exemple, pour tester une fonctionnalité héritée, dois-je le faire dans la classe fille ? Ça n'est pas logique et ça démultiplie mes tests, et pourquoi le faire plus dans cette classe fille là plutôt que dans une autre. OK, alors je teste la classe mère. Oui, mais elle est (souvent) abstraite avec plein de fonctions virtuelles … Voilà pourquoi lors de mes formations, je suis obligé d’aborder plein de sujets connexes aux tests !

L’héritage doit être utilisé à bon escient, avec modération, et beaucoup moins souvent que ce qu’on a l’habitude de voir. Lors de mes formations, je propose souvent aux équipes une architecture qui distingue les objets de traitement des objets de données (voir mon article "Développement et conception : mon approche P(N)OO"). Et avec cette approche, je ne fais jamais d’héritage sur les objets de traitement, et les héritages sur les objets de données doivent toujours respecter la règle “est un(e)”, ces objets de données ayant peu ou pas de traitement.

Pour en revenir au TDD, son but, c’est bien de tester le code, non ? 

En développement agile, l’approche consiste à ne pas anticiper sur les développements de l’itération suivante. Mais lorsque j’en serais à la prochaine itération, je devrais ajouter des fonctionnalités à mon produit, et mon code n’est pas forcément adapté. Pour ajouter ces nouvelles fonctionnalités, je vais donc devoir “refactorer” (remanier) mon code. Pour pouvoir faire cela en tout tranquillité, mon code doit être testé. Le meilleur moyen d’avoir du code testable et donc testé, c’est d’écrire d’abord les tests, le fameux TDD.

OK, donc le TDD, c’est du code testé et une émergence du design à moyenne échelle ?

Oui, mais pas seulement. Commencer par écrire les tests, c’est se focaliser sur ce que doit faire le code, sur le “quoi”. Sans le TDD, le développeur se plonge dans le code, dans le cambouis, il se polarise tout de suite sur le “comment”, et souvent, il fixe son attention sur les points qui vont être difficile à coder. Et finalement, il ne se pose pas vraiment, en profondeur, la question de ce qu’il doit développer, de ce que son code doit réellement faire. Moi le premier, j’étais comme ça. Se mettre au TDD implique un gros changement d’état d’esprit, cela nécessite des efforts, mais ensuite, tout parait plus simple, plus logique et tellement plus plaisant !

En conclusion, pour moi, le TDD est la meilleure pratique pour obtenir du code testé, évolutif et qui fait ce qu’il faut !


Merci à ce copain, qui préfère garder l’anonymat, pour ces échanges et pour sa collaboration à la rédaction de cet article. A noter que son niveau de connaissances (tests unitaires, TDD, architecture) est bien supérieur à ce que les questions ci-dessus peuvent laisser penser … ;-)

Voir l'article
Mon retour sur Devoxx France 2014
21 avr. 2014

Cette année, pour la première fois, je me suis payé Devoxx France. Voici mon retour sur ces 2 journées intenses et riches.

Ce que j'ai particulièrement apprécié :

  • La qualité générale de la conférence et le choix dans les sessions et quickies
  • La restauration, avec notamment un bon accueil petit-déjeuner, et du café ou des sodas à disposition toute la journée
  • Un moment et un espace propice aux nombreuses rencontres et échanges
  • Les différents formats de sessions, notamment les quickies (excellents pour certains) et les BOF (je n'ai finalement pu en faire qu'un seul, mais c'était très sympa)
  • L'application Android Devoox France (je ne sais d'ailleurs pas si c'est "l'officielle") où j'ai particulièrement apprécié de pouvoir marquer en favoris les sessions qui m'intéressaient, et les retrouver directement dans le planning
  • Le programme papier, pratique pour consulter le programme en détail et faire ses choix
  • La "boite à vote" à la sortie des salles, même si le système présente des inconvénients, et si je n'ai pas trouvé où consulter les résultats des votes ...

    

    Ce que j'ai moins apprécié :

    • Le repas de midi (organisation compliquée, du monde, du bruit)
    • Certaines sessions vraiment pas terribles : je ne sais pas vraiment pourquoi, peut-être le prix, mais je m'attendais à avoir un niveau minimum de qualité pour toutes les sessions, mais je sais bien que pour l'organisation, il est difficile de faire le tri et le choix dans les sessions, et qu'il est possible de se tromper
    • Le nombre de personnes par sessions : toutes les sessions auxquelles j'ai assisté étaient bien remplies, voire pleines, voire même archi-pleine, et même parfois inaccessibles (tellement y'avait de monde) : je me suis donc demandé si certaines autres sessions étaient moins remplies, ou s'il y avait un problème de logistique au regard du nombre total de participants ...
    • Les buzzwords font fureur dans les titres des sessions qui, au final, pour certaines, sont vraiment décevantes !
    • Je suis toujours déçu par les sessions techniques sans code (voir live coding), et je ne supporte plus les XML dans les diaporama (c'est illisible et ch....)
    • Le prix, tout de même pas vraiment donné pour un indépendant ...

      Ce qui va me servir prochainement :

      • RESTX
        • RESTX devrait m'aider pour 2 projets RESTful à venir, je vais regarder ça de plus près, merci Xavier Hanin, qui fait pour moi partie de ces quelques "super développeurs" !
      • git-deliver
      • DbSetup
        • "Le bon testeur il teste.... et le mauvais testeur il teste aussi..." : un bon titre, plein d'humour, pour une excellente session animée par Agnès Crepet et Guillaume Ehret, j'étais content d'entendre un discours similaire au mien (code de test propre et lisible, bon usage des mocks, etc ...), et j'ai découvert DbSetup, une bonne alternative à DBUnit, que j'irai voir plus en détails sans traîner ! Sans compter le petit message final d'Agnès, que je porte également dès que je le peux: la qualité est notre problème et notre responsabilité, à nous les développeurs, donc à nous de la défendre et de la promouvoir !

          

        Ce que j'ai vu et retenu :

        • Keynotes : on parle de plus en plus du statut et de la reconnaissance des développeurs, c'est pas encore ça, pas sûr que ceux qui ont parlé changent vraiment quelque chose, mais au moins, ça va dans un sens que je trouve bon, et plus on en parle, plus ça bougera ... espérons ...
        • Cédric Champeau m'a donné envie d'aller voir de plus près Gradle, et point appréciable, il n'a pas tapé bêtement sur Maven ;-)
        • J'ai apprécié les "Promesses et Yield" de JavaScript dans le Quicky de Florent Le Gall, ça va nous simplifier le code, mais va falloir changer nos approches et s'adapter !
        • Puppet ou Chef, ça a l'air génial d'après François le Droff et Romain Pelisse (qui est très énergique parle un peu trop vite), mais je suis vraiment loin de ce monde-là (mais faut savoir être curieux !)
        • Samuel le Berrigaud m'a fait découvrir le principe de "développer en mode kick-ass" ("qui déchire") qui pour moi est totalement compatible avec ma vision de l'agilité (qui n'est donc pas mort !)
        • Au BOF BrownBagLunch, nous avons partagé sur 1 an d’existence de cette approche qui mériterait d'être plus connue ...
        • Nous sommes à l'aube des "objets connectés", et Jean-Philippe Encausse nous a montré le framework SARAH qui se propose en passerelle dans un monde de protocoles (pour l'instant) hétérogènes
        • Florent DUVEAU a fait un très bon Quicky pour présenter Sinon.JS, j'avais déjà aperçu de loin ce framework, y'a de bonnes choses, mais sur le fond, ça ne m'apporte toujours rien pour ma recherche de "bonnes" solutions pour "bien" tester mon JavaScript ....
        • Au delà des lambdas, des streams et des Collectors, j'ai découvert plein de nouveautés sympa de Java 8 grâce à José Paumard qui est un excellent orateur et a fait salle plus que comble !
        • Pour ma dernière session, je n'ai pas pu m'empêcher d'aller à la session "Extremist Programming : l'art de s'amuser avec du code" excellemment animée par Eric Lefevre-Ardant et Cyrille Martraire, qui nous présente des approches débiles ou absurdes (mais pas toujours tant que ça) autour du code, et qui lancent le compte @weirddev à suivre pour recevoir régulièrement des idées bizarres pour s'amuser avec son code ! 
        • Et pour finir la journée, je suis allé à l'enregistrement live de la 100e (101e au final) du podcast Les Cast Codeurs, avec un retour sur Devoxx 2014 dans une super ambiance !
            

        Petite précision : je ne reviens que sur le positif, je me mentionne donc pas les sessions qui m'ont déçu, en sachant qu'à 2 reprises, j'ai quitté la salle en cours de session, ce que je ne fais pourtant jamais ...

          Conclusion

          Effectivement, ce qu'on dit est vraiment : Devoox France, c'est super ! J'ai passé 2 journées intenses et fatigantes, mais j'ai vu plein de choses intéressantes, je repars avec des idées à mettre en oeuvre rapidement, et merci à tous ceux que j'ai croisé ou rencontré et avec qui j'ai pu avoir de beaux échanges !

          PS : quelques ajouts le 21/04 : application Android, programme papier, boite à votes
          Voir l'article
          Scrum Tower Game
          23 mars 2014
          Le "Jeu de la tour Scrum", ou comment découvrir les concepts de base de l'agilité et de Scrum en s'amusant ...

          Introduction


          Il y a quelques années, sollicité par une entreprise pour sa transition vers l'agilité (merci à eux), j'ai mis au point un jeu permettant de découvrir quelques aspects de l'agilité, et les concepts de base de Scrum. Baptisé depuis "Scrum Tower Game", j'ai déjà déroulé plusieurs fois cet atelier, qui tient ses objectifs à chaque fois.

          Après en avoir parlé au détour d'une bière, je l'ai fait jouer lors d'une soirée agile du CARA à Grenoble, avec des retours intéressants des personnes présentes. 

          Lors de la dernière session de Agile Game France, je n'ai pas osé l'amener dans mes valises, mais certaines personnes me l'ont fait regretter, et m'ont motivé à diffuser cet article pour le présenter (1).

          La Genèse 


          Mon client de l'époque avait insisté pour intercaler un jeu dans le déroulement de la journée de formation. C'est d'ailleurs une bonne idée, ça permet de casser le rythme d'une journée intense. 

          L'idée était donc de proposer un jeu permettant de découvrir les concepts de base de Scrum, après une grosse matinée d'introduction à l'agilité, et de présentation des principes de base de Scrum. 

          Il y a pas mal d'années, lors d'une formation "Scrum Master", j'avais participé à un atelier qui m'avait pas mal déplu notamment pour un point : le "temps accéléré". Dans cet atelier, nous faisions des itérations "accélérées", de plusieurs minutes. Mais prenons le cas d'une rétrospective : on peut raccourcir le temps pour faire une rétro de 2', mais on ne parle pas plus vite pour autant (à la manière d'un 78 tours, pour les anciens ...). Je voulais donc absolument éviter ce "temps accéléré".

          Par ailleurs, je ne suis pas forcément "créatif", surtout lorsque je participe à une formation. Je souhaitais donc éviter de polariser l'attention des participants sur ce qu'ils doivent produire, pour leur permettre de se concentrer sur les rôles, les règles, les principes, etc ...

          Et bien sûr, il fallait un côté jeu, un côté plaisant : j'ai ressorti les "Duplo" basiques de mes enfants.

          C'est ainsi qu'est né ce jeu, à base de "légo", à une époque où on en parlait pas du tout dans la communauté agile ....

          Un jeu "cadré", oui mais ...


          Le déroulement de ce jeu est assez contrôlé et guidé, mais cet aspect n'est normalement pas trop ressenti par les participants, et surtout, le fait que ce soit calculé et dimensionné, me permet de faire apparaître des "problèmes", des situations particulières, qui sont alors des occasions pour présenter certains particularités importantes de l'agilité : re-découpage, frustration, renoncement, ...

          Rôles 


          Les rôles sont répartis parmi les participants, éventuellement en collant aux futurs rôles de chacun pour le projet à venir :
          • 1 animateur (rôle que j'assume à chaque fois) : l'idée est de veiller au bon déroulement du jeu, en m'arrangeant pour amener l'équipe dans des situations particulières, et en insistant tout au long du jeu sur les particularités liées à l'agilité
          • 1 ScrumMaster (SM) : je lui fournis des feuilles A3 prêtes pour tracer les "Burndown Charts", il prépare le "Scrum Board", et devra s'assurer de l’enchaînement des différentes étapes et cérémonies. Ce rôle est assez léger, en général les personnes sont trop novices, je les assiste pas mal
          • 1 Product Owner (PO) : je lui fourni une feuille avec des illustrations de ce qui doit être produit. Je l'incite à répondre aux questions de l'équipe, sans trop en dire ni devancer les informations à fournir. Je lui explique notamment 2 points qui seront importants : la nécessité de redécouper une histoire, et en fin de jeu, le renoncement à la totalité de la tour
          • 4 équipiers : ils devront fournir les estimations, en questionnant le PO, puis produire le résultat attendu
          • les autres participants sont observateurs et participeront à la rétrospective de l'atelier

          On voit / On ne voit pas ...


          Ce jeu permet d'appréhender :

          • les rôles de Scrum
          • la production itérative
          • le rythme de Scrum et ses cérémonies
          • certaines situations inattendues que l'agilité permet de gérer

          Par contre, on ne peut pas tout mettre en oeuvre, et notamment :

          • la notion de terminé (du moins très réduite ici)
          • l'initiative technique et les choix par l'équipe
          • la gestion "humaine" d'une équipe sur le moyen et long terme
          • ...

          Objectif pour l'équipe


          L'objectif pour l'équipe est de produire une tour en légo comme celle-ci :



          Les équipiers ont à leur disposition le matériel suivant, avec des Pièces Grandes (PG), des Pièces Moyennes (PM) et des Pièces Petites (PP)  :


          La tour est composée de fondations, de 3 étages de couleurs différentes, et d'un sommet:



          Le bloc de fondations est composé de 3 PG et 3 PM :


          Chaque étage est composé de 6 PM de même couleur (1 couleur par étage) :


          Le sommet est composé de 7 PP (dont "l’œil") :


          Déroulement


          Logistique

          On s'organise pour avoir de l'espace devant le Scrum Board et pouvoir y faire les stands-up de chaque jour. L'équipe s'installe sur une table qui servira d'espace de travail "quotidien", et on prévoit un autre espace dit "d'intégration" ou seront déposés les éléments complets.

          Démarrage

          Le jeu se déroulera en 3 itérations de 3 jours. Il comme donc par la réunion de planification de la première itération, cumulant un peu un "sprint 0". L'équipe découvre l'objectif présenté par le PO, le matériel, et les règles.

          Le PO présente les "Histoires" ("'Stories" (2)) initiales du "Carnet de produit" ("Product Backlog") et demande aux équipiers de lui donner des estimations. Pour simplifier le jeu, 1 jour de production pour 1 équipier = 1 pièce de légo posée = 1 point.

          Après un échange de questions-réponses entre l'équipe et le PO, on aboutit à ces estimations :
          • Fondations : 6 points
          • Étages (une seule histoire initialement) : 18 points (3 x 6)
          • Sommet : 7 points
          Le SM demande alors à l'équipe d'estimer sa vélocité, donc sa capacité de production pour 1 itération. Donc 3 jours à 4 équipiers = 12 points.

          L'équipe et le PO doivent alors décider ce qui sera réalisé pendant la première itération. Le premier "problème" apparaît : l'histoire pour les "3 étages" est trop grosse !

          Redécoupage

          Le SM demande alors au PO s'il serait possible de découper cette histoire. On obtient alors 3 histoires différentes estimées chacune à 6 points : "étage 1", "étage 2", "étage 3".

          L'équipe peut alors s'engager pour la première itération sur : les fondations pour 6 points et l'étage 1 pour 6 points, puisque sa vélocité estimée est de 12 points.

          On peut alors préparer le Scrum Board avec les post-its pour les histoires, pour chaque tâches (1 tâches = 1 pièce de légo), le Burndown Chart, etc ...

          Oui mais .... les aléas ....

          C'est alors que j'introduis une élément supplémentaire, une règle "oubliée" : avant de fournir sa production quotidienne, chaque joueur doit lancer ce dé "spécial" :


          Et s'il tombe sur la face rouge, la journée ne s'est pas passée comme prévue, il passe son tour et ne produit rien.

          Multi-tâches (multi-histoires) ?

          Et pour "gagner du temps" (enfin ....), j'incite fortement l'équipe à se répartir le travail en "binôme" pour attaquer en même temps les fondations et l'étage.

          Itération 1 : Aïe !

          On déroule alors l'itération de façon "classique", en s'appuyant sur les cérémonies de Scrum. Chaque journée commence par un stand-up devant le Scrum Board qui est mis à jour ne fonction de ce qui s'est passé la veille, et de ce qui est prévu pour la journée à venir.

          Durant cette itération, je m'assure que chaque "binôme" a au moins un "obstacle" avec le dé, sinon, j'interviens pour forcer la face "rouge" [NDLA : en général, cette intervention néfaste est tout de même bien acceptée par l'équipe qui comprend qu'il y a un objectif pédagogique].

          En fin d'itération, si tout s'est déroulé comme prévu (du moins pour moi), aucune des histoires n'est terminée, l'équipe n'a donc rien à montrer .... Je lui laisse donc le soin de faire venir le PO pour le lui dire ... A ce moment-là, souvent, des équipiers essaient de trouver une solution pour tout de même montrer quelque chose, mais la règle est claire : on montre ce qui est terminé ! Donc rien à ce stade du jeu ...

          On enchaîne alors sur la rétrospective pour évoquer ce qui s'est passé, et évidemment, le fait que d'attaquer plusieurs histoires en parallèle n'est pas un bon choix. L'équipe devrait alors décider, pour l'itération suivante, de mettre les efforts pour finir les histoires commencées, puis de travailler plus collectivement sur les histoires suivantes.

          On fait également le bilan concernant la vélocité qui est en générale mesurée à 9 ou 10, et souvent revue à la baisse à 10.

          En général, l'équipe attaque cette première itération dans une certaine euphorie ludique, mais la finit dans une ambiance plus morose ...

          Itération 2 : Yeah !

          Avant de lancer la deuxième itération, on commence évidemment par une réunion de planification. On est alors dans une situation particulière. L'équipe voit bien qu'elle peut s'engager à terminer les fondations et le première étage, et qu'elle peut également s'engager sur le deuxième étage. Mais il reste quelques points de vélocité ...

          Avec mon approche pragmatique, je leur propose de voir avec le PO sur quelle histoire ils pourraient avancer si tout se passe bien, mais sans "engagement" sur cette histoire supplémentaire qui ne sera pas terminée.

          La deuxième itération se déroule mieux. Les participants ont compris les règles, ils commencent à intégrer tout doucement le cycle des itérations, et surtout, en 1 tour de jeu ou 2, ils finissent les 2 premières histoires, et ressentent le plaisir de produire (enfin) quelque chose de terminé.

          Au cours de cette itération, je m'arrange pour que les "aléas" du dé "à face rouge" ne permette pas à l'équipe de commencer une nouvelle histoire, tout en finissant celles prévues (j'interviens donc dans un sens ou dans l'autre sur le dé).

          On peut également tomber sur une autre situation particulière, à savoir qu'un équipier risque de ne pas terminer sa tâche s'il a un obstacle alors qu'un autre a un peu d'avance et pourrait attaquer l'histoire "bonus". J'accompagne alors l'équipe pour qu'elle s'organise au mieux, notamment dans l'ordre des tours de jeu, pour assurer l'engagement pris, quitte à ce qu'un équipier change de tâche au dernier moment, pour ne pas attaquer l'histoire bonus mais vienne en aide à un équipier en difficulté.

          L'itération se termine donc mieux que la précédent, avec notamment une démonstration au PO de ce qui est produit : les fondations et 2 étages. Si le temps le permet, on peut faire une rétrospective, sans qu'il y ait (pour cet exercice) de points particuliers à décider à ce stade du jeu.

          Itération 3 : oups !

          Comme précédemment, on attaque la troisième itération par la réunion de planification. Un constat apparaît tout de suite : l'équipe ne pourra pas tout faire : avec une vélocité à 9 ou 10, on ne peut pas faire le troisième étage (6 points) et le sommet (7 points). 

          Je laisse donc l'équipe et le PO échanger librement, en observant ce qui se passe, puis en intervenant pour pointer les bons ou mauvais réflexes. Souvent, des équipiers proposent, voire prennent des initiatives pour choisir ce qui sera fait, voir découper des histoires. J'insiste alors sur le fait que c'est au PO de trancher, fonctionnellement, et le PO, précédemment briefé, choisit alors de renoncer au 3e étage mais insiste pour avoir le sommet.

          Il y a donc un "surplus" de vélocité qui amène souvent des questions, mais je présente souvent cette dernière itération comme la fin du projet, le temps restant permettant, dans la vraie vie, de fignoler certaines parties, de finir la documentation, etc ...

          Le déroulement de la 3e itération est souvent accéléré, le sommet est rapidement réalisé, on n'oublie pas la démo finale, sans se priver de faire une photo de toute l'équipe (PO et SM compris) autour de la tour produite !

          Synthèse

          • Matériel : Duplo (en nombre suffisant), 1 dé "spécial", tableau blanc, post-its, feutres
          • Nombre de participants : 6 + 1 animateur + observateurs
          • Durée : environ 1h30
          • Objectif : Scrum, ses rôles, son rythme, ...

            Conclusion


            Plus intéressant à dérouler qu'à expliquer (longuement) dans un article, ce jeu me donne à chaque fois entière satisfaction, il répond vraiment à mes attentes, dans un contexte de formation d'introduction à l'agilité et à Scrum. 

            Outre le fait de permettre aux participants de mettre en oeuvre certains rôles, certains supports, le rythme de Scrum, etc ..., ce jeu me permet également tout au long de son déroulement de pointer et insister sur certaines particularités de l'agilité. 

            Il pourra également me servir de référence lorsque, par la suite, j'accompagnerai l'équipe dans sa transition agile, nous pourrons alors nous remémorer certaines scènes du jeu.

            N'hésitez pas à me laisser des commentaires pour me faire part de vos réactions et interrogations. Bien sûr, vous pouvez me laisser vos question, ou me contacter pour plus de détails, ou si ce jeu (et la formation dans laquelle il s'intègre) peuvent vous intéresser pour votre entreprise, pour votre équipe !

            Merci !



            (1) Remerciements et dédicace à D. ... ;-)
            (2) Lorsque je parle de Scrum, j'aime bien utiliser du vocabulaire Français, dans la mesure du possible
            Voir l'article
            Un bon titre pour une bonne session TDD et coding-dojo
            10 févr. 2014

            Introduction

            Je me permets de solliciter la(les) communauté(s) pour recueillir des avis et propositions pour un titre de session.

            La session

            A l'automne, j'ai animé une session "L'apprentissage du TDD en Coding-dojo" lors des conférences agiles de Marseille, Montpellier et Grenoble. Cet atelier d'environ 2h me permet de présenter un peu de théorie sur les tests unitaires et le TDD, puis de faire une rapide démo live avant d’enchaîner sur un coding-dojo de type randori (donc sur un seul poste vidéo-projeté) pour permettre à une partie des participants de s'essayer, en pair-programming, au TDD pendant 5-6', sur un sujet simple, avec mes conseils, mes remarques et le soutien de l'assistance.


            Objectifs

            Cet atelier me permet de présenter le TDD (indispensable à un développement agile, mais vraiment pas assez répandu) mais également le coding-dojo, qui n'est finalement pas si connu que ça, et qui est un format que j'apprécie énormément, soit lors de mes interventions en entreprises, soit à mettre en place régulièrement au sein d'une équipe.

            Public visé

            Cette session s'adresse aussi bien à des développeurs, ayant plus ou moins de connaissances sur les tests unitaires et le TDD, mais également aux managers ou décideurs pour les sensibiliser à la nécessité d'accompagner leurs équipes vers cette pratique, et de leur apporter formations et accompagnements.

            La question du jour 

            Devant le succès et les nombreux retours que j'ai eu suite aux sessions de l'automne, j'ai proposé cette session pour Agile France 2014, et je prévois de la proposer pour Mix-IT 2014. Mais j'ai récemment eu quelques retours sur mon titre qui n'est pas assez accrocheur pour attirer du monde. Soit !

            Je me permets donc de vous solliciter aujourd'hui pour m'aider à trouver un meilleur titre. Alors n'hésitez pas à me laisser un petit commentaire avec vos avis, vos propositions, vos suggestions ....

            Merci !

            Voir l'article
            Développeur : un métier de passion !
            16 déc. 2013
            Pour faire suite à mon article Développeur : une passion et un métier, sinon rien !, et conforme à ma motivation du moment pour diffuser ce point de vue, mardi dernier (10 décembre), j'ai proposé d'aborder ce sujet lors des Human Talks Grenoble.

            Ma session de 10' a été filmée, vous pouvez donc la consulter ici (la qualité d'image n'est pas géniale, mais le son et les slides y sont, c'est l'essentiel) :



            Un grand merci à l'équipe @HTGrenoble pour l'organisation de ces soirées bien sympa, à Victor pour la vidéo et aux participants pour les nombreux échanges très intéressants !





            Voir l'article
            Agile Grenoble et Agile Innovation cuvée 2013
            27 nov. 2013
            Les 21 et 22 novembre dernier, j'ai assisté à Agile Grenoble 2013 et Agile Innovation 2013. En voici quelques éléments de retour.


            Qualité :

            • Il n'y aurait pas "la" qualité mais "les" qualités ?
            • Du moins, il y a plusieurs éléments de qualité, selon qu'on regarde le code, la stabilité de l'application, sa réponse au besoin, son utilisabilité, etc ...
            • Mais pour commencer, l'important est déjà de se poser des questions, quelques soient les critères d’évaluation : quelle est la qualité attendue ? quelle est la qualité de l'application actuelle ?

            #NoXxx :

            • Le courant des NoXxx peut être source de discussions nombreuses et variées ! 
            • Il n’est pas forcément question de supprimer (sauf pour les commentaires …), mais bien souvent de remplacer : NoSQL, NoEstimate, NoFramework, NoSprint (les "sprints" de Scrum), etc … 
            • Et tout cela dépend du contexte, le "No" n’est pas un objectif en soi. Une base de données NoSQL est préférable dans certains cas, alors qu’une base relationnelle SQL le restera dans d’autres. 
            • De même, Scrum n’est pas forcément une étape de passage, avec Kanban l’objectif final : 
              • Une approche en flux peut être adoptée dès le début de la migration à l’agilité (pas de passage obligé par Scrum), ou lorsque l’équipe a acquis une certaine maturité et que le contexte s’y prête
              • Mais une organisation de type Scrum peut rester la meilleure dans certains cas, avec respect strict des règles de base de Scrum, règles simples mais essentielles


            Divers :

            • Animer une session lors d’une conférence en fait zapper une bonne partie (1 matinée pour moi)
            • Mais j’ai vraiment de plus en plus de plaisir à partager et échanger sur des points techniques de dév
            • La loi des 2 pieds proposée pour les rencontres de type "espace ouvert" ("open space") est également valable si on n'est pas trop bien dans son boulot actuel (un peu ce que je disais )
            • Le TDD rend-il heureux ? Moi, oui ! Mais pas seulement sa phase "verte", c'est lorsque je peux mettre en oeuvre une approche TDD que je suis content, et donc lorsque je n'ai pas de tests unitaires que je suis malheureux. Et plus largement, le travail bien fait (le code propre, qui fait ce qu'il faut, etc ...) me rend heureux, tout comme l'apprentissage et le partage
            • Le jeu "La crevasse" est vraiment excellent pour pointer la confiance envers l’autre, la confiance en soi, l’engagement, etc ...
            • La sociocratie peut apporter des pistes intéressantes pour les échanges au sein d’un groupe, et pour les choix et les prises de décisions (prise de décision par consentement)


            Et pour finir, et revenir à l’agilité :

            • Par rapport aux années passées, j’ai moins entendu d’agilistes qui cherchent à aller au-delà de l’agilité, au-delà de Scrum, donnant l’impression que eux, plus que d’autres, auraient vraiment compris les choses pour passer à un stade "supérieur" : personnellement, j’ai l’impression de plutôt revenir de plus en plus aux fondamentaux, au manifest et ses valeurs, à Scrum et ses règles simples mais précises …
            • J’ai beaucoup plus entendu parler des développeurs, de leur bonheur, de leur plaisir au travail, aux tâches bien faites, au code propre, etc … De plus en plus de personnes semblent comprendre ce que j’essayais de dire l’an dernier (session "N’oubliez pas les développeurs") : dans l’édition logicielle, les développeurs sont bel et bien au cœur du système, et ils ne peuvent pas faire de développement agile sans faire évoluer leurs outils et leurs pratiques. Ce n’est pas inné, et cela peut nécessiter formation et accompagnement


            Conclusion :


            J’ai donc passé 2 journées vraiment excellentes et très riches de rencontres et d’échanges, un grand merci à tous ceux (impossible de tous les nommer) que j’ai pu croiser lors de ces journées et qui m’ont apporté par leurs questions, leurs points de vue, leurs oppositions : Merci !

            Voir l'article
            Développeur : une passion et un métier, sinon rien !
            18 nov. 2013

            Introduction


            Dans le développement logiciel depuis plus de 20 ans, je réalise depuis 2 ans (seulement mais réellement), et de plus en plus, à quel point le métier de développeur doit être une passion !

            C'est un métier d'artisanat, où l'on fait rarement 2 fois la même chose, où il faut innover tous les jours. L'éco-système bouge très vite, les langages existants évoluent (pas très vite, mais tout de même), de nouveaux langages voient le jour (sont-ils adaptés à mon besoin ou pas ?), de nouvelles librairies sortent régulièrement, une techno révolutionnaire aujourd'hui sera remplacée par une autre encore mieux dans 3 ou 6 mois. Sans compter les bonnes pratiques que je vois évoluer et s'affiner sans cesse ...

            Le métier de développeur est difficile ...


            Evolution du développeur : chef de projet !?


            NON ! Ca n'est pas le même métier, ça n'a rien à voir !

            Et pourtant, cette "logique" a la vie dure, portée par l'industrie du développement logiciel depuis des années et les grosses sociétés de service. Mais pas seulement ! Il y a 2 semaines, j'ai animé une journée "Tests unitaires et TDD" à l'université, auprès d'élèves en master, en commençant par sonder les élèves : 1/3 seulement se projette dans le métier de développeur, et tous m'ont confirmé qu'on leur explique qu'ils feront développeur pendant 5 ans, jusqu'à être sénior et expert, avant de passer chef de projet ... Il faut que le système scolaire se mette au gout du jour !

            Heureusement, d'autres voix s'élèvent et se font entendre, permettant peut-être à chaque développeur de sortir de cette fausse logique, de reconnaître ce qu'il aime faire et de se positionner ... (1)

            Mais que faire ?

            Je suis développeur et ça me passionne !


            Et bien tant mieux, ne lâche pas l'affaire, et assume : tu n'es pas le seul !

            Par contre, une passion ça s'alimente, ça se nourrit. Et si ça n'est pas le cas dans ton quotidien au boulot, tu dois te prendre en main, personne ne s'occupera de ta carrière à part toi (2).

            Cela veut dire qu'il te faut lire des livres, lires des articles de blog, te créer un compte Github, participer (au moins un peu) à des projets, voire créer les tiens, participer à CodeStory, blogger, aller à des rencontres près de chez toi, à des JUG, des coding-dojo, faire des talks aux Human Talks, voire même faire des sessions dans des conférences, etc...

            Et tout cela bien sûr, probablement en dehors de tes heures de boulot, car la passion ne s'arrête pas à 18h ;-)

            Je fais du développement mais ça ne me passionne pas ...


            A vrai dire, il y a alors 2 possibilités.

            La première est que le développement te passionne, mais tu ne le sais pas. Du moins, tu es dans un contexte qui ne te permet pas de le savoir : ton environnement est dans la "logique" citée précédemment, ton job ne te permet pas de t'éclater ou d'innover, ton patron ne veut pas entendre parler tests unitaires, TDD et qualité, et pourtant au fond de toi, ça te titille, tu en as parlé mais tu t'es fait remballer. Alors là, c'est simple : casse-toi ! (3) Et oui, n'aies pas peur du changement, qu'est-ce que tu risques ? Trouve toi une bonne boite ou tu pourras prendre conscience de ta passion, l'assumer et l'assouvir.

            La deuxième solution est que, vraiment, le développement ne te passionne pas et soit pour toi un travail, probablement passager. Dans ce cas, n'hésites pas à faire tout ce que tu peux pour faire rapidement autre chose, sans forcément passer par les cases "sénior" et "expert" qui ne sont pas indispensables pour ton évolution.

            Je suis manager


            Commence par reconnaître tes développeurs à leur juste valeur, individuellement et collectivement. Tu es dans l'édition logicielle : le boulot est fait grâce à eux, ne l'oublie pas !

            Ensuite, comprend que c'est un métier difficile, qu'il faut se former tout le temps, et si possible, pas sur le code de production : libère du temps R&D pour tes développeurs, laisse-leur du temps libre (en rapport avec le boulot) leur permettant de faire de la veille techno, de s'essayer au TDD, de recoder mieux une partie de l'appli, de tester de nouvelles solutions ou ergonomies, etc... Incite les à organiser régulièrement, au sein de l'entreprise, des coding-dojo qui seront des lieux protégés d'entrainement, de partage, et de fédération de l'équipe.

            Et pour compléter, propose leur d'aller dans des conférences (agilité, techno WEB, conf dédiées, etc ...) voire même d'animer eux-même des sessions pour partager leur passion (et ça fera de la pub pour ta boite).

            Pour finir, laisse-les assumer leur passion du développement logiciel, laisse leur les initiatives et choix (techniques, architectures, etc...), et embauche des chefs de projet, mieux des Product Owner, au lieu de forcer des développeurs vers cette "évolution" qui n'en est pas forcément une ...

            Je suis recruteur


            Pour bien recruter, il faut connaitre et comprendre. Alors, va à la rencontre des développeurs, va dans les conférences ou les soirées, va discuter avec eux, va comprendre leur passion pour le travail bien fait, le "clean code", la qualité, les bienfaits des tests unitaires et du TDD, etc ...

            Tu pourras alors comprendre ce que tu cherches, de quoi tu parles, ce que tu écris dans ton annonce. Peut-être même que tu ne passeras plus d'annonces et que tu comprendras que les bons développeurs, tu les trouveras autrement. Et lorsque viendra l'entretien, la discussion avec le candidat, tu pourras un peu mieux comprendre à qui tu as à faire, et déceler (ou pas) la passion qui anime ton futur recruté.

            Et pour encore plus réussir ton recrutement, va rencontrer l'équipe qui devra accueillir le nouveau, va comprendre comment elle fonctionne, qui ils sont, ce qu'ils font, ce qui les anime, quelles sont leurs particularités. Et lorsque tu penses avoir trouvé l'oiseau rare, n'hésites pas à lui présenter l'équipe, à les laisser échanger et vérifier les éléments de leur adéquation.

            Je suis client


            Et tu vas me dire que tu n'y connais rien, et que ce qui t'importe c'est le résultat produit ? Non bien sûr, tu as déjà compris. Toi aussi, tu dois rencontrer et échanger avec les développeurs. Tu dois comprendre quel est leur métier, quelles sont leurs difficultés, qu'est-ce qui les passionne et les satisfait. Mais eux aussi ont tout intérêt à te connaitre, à t'avoir rencontré (pour penser à toi lorsqu'ils développeront), à comprendre ton contexte, tes attentes, tes craintes, tes rêves, et ce qui fera que tu seras content du résultat et heureux !

            Conclusion


            Développeur, c'est un "métier" et une "passion". Les développeurs doivent en prendre conscience, avec les apports qui vont avec, mais également les obligations. Mais tout le monde a un rôle à jouer, quelque soit son poste, son job, et sa proximité avec les développeurs !

            N'hésitez pas à réagir et commenter, ça me fera plaisir, et pourra être l'occasion d'échanger sur le sujet.




            (1) L'origine pour moi, cet article de Nicolas Martignole que je remercie aujourd'hui ! 
            (2) Jean-Baptiste DUSSEAUT, La voie du programmeur ici et
            (3) Antoine Vernois , Software Craftsmanship (j'espère que la vidéo sortira bientôt)
            Voir l'article
            Mon retour sur Agile Tour Montpellier 2013
            21 oct. 2013

            Le 18 octobre 2013, j'ai passé une excellente journée à l'Agile Tour Montpellier 2013, en voici quelques éléments de retour.

            Avec la longue route que j'avais à faire, je suis arrivé pendant la keynote de Pablo Pernot sur "La Horde Agile". L'ayant déjà vu à Marseille, je suis allé directement prendre un café et m'installer pour ma session.

            Et comme ça, je n'ai pas entendu "L'agilité c'est pas le code" ... ;-)


            "L'apprentissage du TDD en Coding-dojo" - Xavier Nopre

            Après l'Agile Tour Marseille, c'était la 2e fois que je jouais cette session. Pour moi, les 2h sont intenses tellement je veux partager et expliquer de choses concernant les tests unitaires et le TDD.
            Salle bien remplie : cool !
            (Photo Etienne PERRA)

            Je commence ma session par des petits sondages pour connaitre un peu le public. Cette fois, j'avais un maximum de développeurs qui, apparemment, écrivent peu de tests unitaires, galèrent pas mal, et ne font pas de TDD (ce qui est probablement lié au "tests after" et donc au TDD ...).

            Je suis surpris de constater que les tests unitaires sont encore très peu répandus. Sans s'en rendre compte, on peut se retrouver à fréquenter toujours un peu les mêmes cercles de personnes, ou de communautés, et finir par croire que l'écriture de tests unitaires, voir la pratique du TDD, sont bien répandues ... Et bien non !

            Dès le début de la session, les questions tombent, assez nombreuses. Elle révèlent un intérêt certain pour les tests unitaires et le TDD, les développeurs sentent que ça peut être intéressant, mais les questions montrent également une vraie galère, un manque de formation, et un manque d'espace d'entrainement. Et je comprends d'autant mieux toutes ces difficultés car moi-même, j'ai dû les surmonter lors de mon parcours personnel.

            Le coding-dojo, une bonne opportunité
            pour expliquer des points précis
            (Photo : @seb_fournel )

            Le positif de tout cela, est que ça me conforte dans l'envie d'animer de telles sessions, et que ça me motive pour continuer à essayer de propager le partage d'informations, de connaissances et d'expériences dans ce domaine ... Passionnant !

            "Et un carpaccio ! Un !" - Géry Derbier - @Gery7



            Après une matinée entre développeurs, et des échanges intéressants le midi sur des sujets similaires, mon programme de l'après-midi est resté en lien avec la technique ! J'assume ! ;-)


            Après une courte introduction, Géry nous propose un exercice vraiment basique (calcul de prix avec taxe et réduction), mais qu'il nous demande de découper en étapes, les plus petites possibles (d'où la notion de "carpaccio") pour pouvoir montrer quelque chose sur des cycles de quelques minutes.


            Le tour de salle pour écouter les propositions est très surprenant, les étapes proposées peuvent être encore découpées en 3 ou 4, elles sont donc déjà bien trop grosses ! Cela m'a surpris car, de mon côté, j'avais effectivement imaginé des étapes vraiment petites. Et ma binôme (désolé, j'ai oublié son nom ....), qui était à ma session TDD le matin, me fait remarquer que c'est peut-être en lien avec mon approche TDD : mais oui, bien sûr ! Le TDD impose également d'avancer par toutes petites étapes, intéressante révélation !

            Je n'en dirais pas plus pour ceux qui auraient l'occasion de pratiquer cet atelier que je recommande. Juste, que Géry nous explique, graphes à l'appui, qu'une approche classique (avec démonstration et livraison tardive) pénalise l'apprentissage (qui est quasiment nul pendant une longue durée), alors que l'approche agile, avec démonstration à court terme, favorise l'apprentissage sur différents points : la technique, l'écosystème, le produit ciblé, l'équipe, etc ... Vraiment très intéressant !

            Lien intéressant : http://alistair.cockburn.us/Design+as+Knowledge+Acquisition

            "Software Craftsmanship" - Antoine Vernois - @avernois

            Quand je vois "Software Craftsmanship", j'ai du mal à ne pas aller voir ... Et j'avais déjà croisé Antoine ici ou là, mais je ne l'avais jamais vu en conférence.

            Et bien, je n'ai pas été déçu. J'espère que cette session a été filmée et sera mise en ligne, et je recommande vivement à tout le monde de la voir, ou mieux, d'assister à cette session, si Antoine la rejoue. Même si ça trolle pas mal (bon, pour le .Net et les architectes, ça se comprend .... oups ...), Antoine enchaîne des vérités (tellement vraies mais tellement négligées) avec humour (mais pas que) et mimiques théatrales. Comme m'a dit un voisin à la fin : "ça fait du bien !".

            Quelques idées :
            • Indépendant, Antoine ne sait pas quoi mettre sur sa carte de visite puis finit par mettre "Artisan logiciel" : ben oui !
            • Le développement est une passion, assumons-le
            • Tests unitaires : pas le temps ? Ok, alors prenez le temps de faire les choses bien
            • La meilleure manière d'arriver en retard c'est d'agir en homme pressé
            • La seule manière d’aller vite c’est d’y aller en faisant les choses bien. Oncle Bob
            • "Faut que ça marche", oui, mais faut que ce soit bien fait ! 
            • Tout est dans le manifest agile (valeurs et principes) mais souvent mal perçu
            • Hé ! Développeur, on ne te responsabilise pas ? Barre toi ! Va voir ailleurs ! Toi seul est responsable de ta carrière ...  
            • Faire simple c'est pas une injure, c'est un compliment
            • Des architectes, oui, mais si ils codent !
            • etc ...
            Le code legacy selon Antoine ... ;-)

            "LE" lien à visiter : http://manifesto.softwarecraftsmanship.org/
            Une communauté "fr" : French Software Craftsmanship

            "Métier Développeur" - Brice Favre - @briceatwork

            Après la super et regonflante session d'Antoine, je ne pouvais qu'aller voir Brice qui nous proposait d'échanger sur le métier de développeur !

            Une session courte, dans une ambiance trop chaude, et des participants probablement déjà fatigués en cette fin de journée, mais des échanges intéressants sur le métier de développeur, l'âge du développeur, le lien entre le développeur et le client (ou pas), le développeur qui doit se mettre à la place des utilisateurs (ou pas), ce que l'agilité peut nous apporter, le développement comme passion (tient, encore ...), la difficulté d'être reconnu, les possibilités pour évoluer (ou pas), etc ...

            Très intéressante, cette session était pour moi un peu frustrante, j'aurais aimé en dire plus, échanger plus en détails avec certains, aller en convaincre d'autres (dans le genre "ton job ne te plait pas ? barre-toi, c'est TA carrière"), mais je suis content de voir que ce courant de pensée est de plus en plus courant, et de plus en plus visible, j'aurais aimé entendre cela il y a plusieurs années, ça m'aurait aidé ...

            Conclusion

            Une journée très riche en découvertes, en rencontres, en échanges. Je me suis volontairement fait une journée "je suis développeur, j'aime la technique et je l'assume" et ça m'a fait du bien.

            Un grand merci à tous ceux que j'ai pu croiser, voir avec qui j'ai pu discuter un peu, je ne les nommerai pas, je suis sûr d'en oublier ...

            Et un grand merci à l'équipe d'organisation pour avoir retenu ma session, et ainsi m'inciter à venir à #atmtp, et bravo pour l'organisation au top (lieu sympa, bonne logistique avant et pendant, repas sympa en extérieur, équipe super dispo pour tout et n'importe quoi, ...). Bravo et merci !


            Voir l'article
            Tests unitaires : comment en ajouter sur du code existant?
            08 oct. 2013
            Suite à cette question de Jérôme Avoustin, Nicolas Noullet pose une autre question très intéressante :
            "Comment faire avec une énorme base de code sans test ? N'en écrire que pour les bug fixes et nouvelles features ?"
            Cette question rejoint celles qui me sont souvent posées lors de mes formations en entreprises ou lors des conférences.

            Les tweets étant trop courts pour un tel sujet, je poste quelques éléments de réponses ici, en espérant en éclairer certains, et susciter des réactions ...

            Le mieux ...

            Avant tout, il faut bien avoir en tête que l'ajout de tests sur du code existant (legacy) est le plus dur !

            Un premier point important à prendre en compte est donc le niveau de maturité des développeurs en tests unitaires. S'ils sont débutants, il vaut mieux qu'ils commencent sur du code neuf, pour un nouveau projet.

            Mais la réalité du quotidien est qu'on n'attaque pas souvent un nouveau projet ...

            Une première approche

            Sur un projet existant, la solution peut consister à écrire les nouvelles fonctionnalités non pas dans des classes existantes, mais dans de nouvelles classes qui seront des "collaborateurs" de la classe existante. Le code de cette nouvelle classe sera plus facilement testable, d'autant plus s'il est écrit en TDD . Si le développeur a un niveau suffisant, et que le code existant le permet, l'inter-action entre la classe existante et la nouvelle classe peut être testée en "mockant" la nouvelle classe. La meilleure approche, mais pas du tout la plus simple, étant de commencer par là en TDD bien sûr !
            Truc : éviter le statique ! 

            Ensuite ...

            Une autre approche consiste à écrire des tests unitaires de plus haut niveau, couvrant une plus grande partie du code (mais la moins grande possible ...), "tests d'intégration" ou "tests fonctionnels", en évitant les "tests IHM" (tests par l'IHM). Une fois ces tests écrits, on peut alors se lancer dans un refactoring pour découper et découpler le code existant, pour extraire les traitements dans des classes séparées, en visant le principe "1 classe = 1 rôle", et ainsi aller vers une architecture (plus) testable.

            Attention, car pour que ces tests soient "bons" et jouent pleinement leur rôle de "filet de sécurité" pour le refactoring, il est nécessaire d'avoir déjà une bonne expérience des tests unitaires et de ce que sont les "bons" tests ...
            Truc : ciblez le code de traitements algorithmiques, plus facile à tester unitairement, et attaquez vous plus tard au code qui interagit avec une base de données ou un équipement extérieur ...

            La couverture de code

            Pour ceux qui auraient un doute, il s'agit de mesurer le % de code exécuté en jouant un test, une série de tests, ou tous les tests. Mais les outils pour cette mesure peuvent nous fournir une autre information, complémentaire et extrêmement intéressante : quel code est exécuté (en général en vert), et surtout, quel code n'est pas exécuté (en rouge), donc pas couvert par les tests.

            Dans la première approche évoquée précédemment, le code nouveau, ou extrait d'une classe, doit impérativement être bien couvert.

            Dans la seconde approche, la visualisation des lignes de code, des classes, voire des packages non couverts, peut nous aider à renforcer les tests de haut niveau pour garantir un meilleur filet de sécurité pour le refactoring à venir.

            Conclusion

            Les tests unitaires sont indispensables ! Se mettre à en écrire n'est pas facile. Le TDD est la meilleure solution, c'est une partie intégrante de la pratique de développement (et de conception), mais c'est véritablement un "état d'esprit" qu'il faut acquérir par la pratique et l'entrainement.

            Accrochez-vous, ça vaut le coup !
            Voir l'article
            Mon retour sur Agile Tour Marseille 2013
            07 oct. 2013
            Jeudi 3 octobre 2013, je suis allé passé ma journée à l'Agile Tour Marseille 2013 où j'animais une session "TDD en coding-dojo". Voici quelques éléments de retour en suivant mon programme de la journée ...

            Keynote "La horde agile" par Pablo Pernot

            Après un accueil café-madeleines, nous avons attaqué la journée avec Pablo pour une keynote digne de ce nom, du moins comme je les aime : sujet en lien avec l'agilité, mais sujet décalé par rapport à ce qu'on peut avoir dans les sessions.

            Pablo remonte le temps pré-historique pour retrouver certaines valeurs de l'agilité, et certains principes, dans les us et coutumes de nos lointains ancêtres, qui nous ont beaucoup laissé en héritage, au fond de nous, et que souvent nous oublions ou repoussons.

            Un enchaînement de réflexions intéressantes, même si je n'ai pas toujours tout capté (fatigue de la route, réveil matinal ? ....).



            "BDD appliqué" par Benoit Gantaume

            Passionné par le développement logiciel, les techniques, les outillages, et connaissant Benoit, c'est sans hésiter que je suis allé le voir nous parler de BDD.

            Benoit partage un retour d'expérience, "qui n'engage que lui", sur ses expérimentations et sa mise en oeuvre du BDD. Il nous rapporte que l'aspect "rédaction de spécifications exécutables compréhensibles par le client" est un apport très positif, mais par contre, ces spécifications exécutables ne lui servent pas du tout en phase de recette avec le client, mais lui sont bien utiles pour ses propres développements.

            Benoit travaillant souvent seul (comme moi), il nous partage la difficulté d'être alternativement "spécifieur" ou "développeur", les petites voix de chaque rôle venant s’entremêler sans cesse.

            Je pense que la présentation de Benoit en a éclairé plus d'un sur le sujet. Pour ma part, cette session a augmenté ma motivation pour dégager du temps et expérimenter par moi-même ce sujet très important pour notre métier.

            J'aurais juste aimé que Benoit nous montre l'exécution de ces spécifications, voir nous fasse une petite démonstration en live du passage de la spec rédigée dans un fichier texte, au test qui échoue (voire réussit) en passant par la création et l'écriture du "code glue".

            "Améliorez et industrialisez vos feedback produit" par Jean-Philippe Gilibert

            Après une courte introduction, Jean-Philippe passe tout de suite à la démo : une session qui attaque par une démo, c'est pas mal du tout !

            Et sa démo est claire et impressionnante ! Dans un produit "standalone" (client lourd en .Net) et autonome (travaillant à partir d'un fichier local, sur le poste utilisateur, comme un traitement de texte par exemple), assez tôt dans le projet, l'équipe a intégré un système de rapport d'erreurs, soit déclenché manuellement par l'utilisateur, soit proposé automatiquement lorsqu'il y a une exception. Pour l'utilisateur, la manip est extrêmement simple : il lui suffit de saisir un résumé du problème, puis un mail est généré, prêt à partir, avec toutes les pièces jointes nécessaires. C'est tout.

            Lorsque le développeur reçoit le mail, il peut trouver dans les pièces jointes tout le nécessaire pour reproduire immédiatement le problème, et notamment le fichier de travail de l'utilisateur et le scénario d'actions que l'utilisateur a réalisé jusqu'au problème, ce scénario est alors rejoué par l'application lancée en mode debug dans l'IDE.

            La solution est très intéressante car très simple pour tout le monde. Et ce que j'ai trouvé malin, c'est que le scénario est un ensemble de commandes à jouer, présentées sous forme de tests fonctionnels en C# .Net (c'est donc du code de test qui est généré lors du report d'erreur par l'utilisateur). Le développeur peut donc par exemple commenter ce code et l'intégrer à sa batterie de tests existants.

            Bien sûr, le cas d'une application standalone et autonome se prête plus facilement à une telle mise en oeuvre qu'une application WEB client-serveur, mais le sujet est intéressant et les idées sont à creuser.

            "Sommes-nous (tous) nés pour collaborer ?" par Romain Vignes

            Courte session pendant laquelle Romain s'est penché sur le lien entre les profils possibles pour chaque membres d'une équipe, et la communication et l'efficacité au sein de cette équipe. Il s'est un peu plus attardé sur le profil "extraverti / introverti", les difficultés qui peuvent en découler, les points d'attention, les solutions, ...

            Une des valeurs de l'agilité porte sur la communication entre les individus. Il est évident que l'aspect humain prend une place importante dans une organisation agile. S'intéresser aux profils, aux personnalités de chacun, mieux comprendre ce qui peut se passer, ce qui peut bloquer, ce qui peut marcher, est évidemment très intéressant ! Dommage du peu, cette session mériterait plus de temps ! ...

            "L'apprentissage du TDD en Coding-dojo" : ma session

            J'ai commencé l'après-midi en animant ma session avec pour objectif de montrer et faire expérimenter, à la fois le TDD, mais également le coding-dojo.

            J'ai encore et toujours un grand plaisir (peut-être de plus en plus) à partager mon expérience des tests unitaires et du TDD, et de le mettre en pratique en codant ensemble !



            La salle était bien pleine, les gens ont bien joué le jeu, et le ROTI était positif, mais toutes les personnes présentes ne se sont pas exprimées.

            Je dois juste revoir et raccourcir la partie théorie pour avoir un peu plus de temps pour la pratique ...


            Pour ceux qui pourront, RDV le 18 octobre à l'Agile Tour Montpellier, et le 21 novembre à Agile Grenoble !

            "Découvrir Scrum grâce aux LEGO®" par Romain Vignes

            Pour finir la journée en douceur, je suis allé "découvrir Scrum grâce aux Lego" avec Romain. A plusieurs reprises, j'avais entendu parler de cet atelier, et vu des photos. Je voulais l'expérimenter.

            L'atelier est très intéressant pour découvrir plusieurs notions et principes de Scrum : le Product Backlog, le Product Owner, les estimations, la vélocité, l'engagement, les itérations, le "done", etc ...

            La session était un peu courte, surtout qu'après la 2e itération, de nombreuses questions ont émergé donnant lieu à des échanges très intéressants.

            Une session que je recommande pour ceux qui veulent découvrir Scrum en s'amusant !

            Conclusion

            Une bonne journée, toujours et encore des idées ou réflexions à collecter, et de nombreuses rencontres et échanges toujours intéressants !

            Merci à toute l'équipe pour l'accueil et bravo pour l'organisation !

            Merci à Thierry pour le co-voiturage.

            Crédit photo : L'Esprit Agile : http://www.flickr.com/groups/esprit-agile/pool/

            Voir l'article
            Play Framework : pourquoi j'ai migré de V2 à V1
            06 mai 2013

            Introduction

            Utilisateur mordu de Play Framework, il y a plusieurs mois, j'ai migré mon projet en cours de V2 à ..... V1 ! L'information a un peu circulé, j'ai pu en parler ici ou là, et on m'a souvent demandé de partager mes raisons, ce que je vais faire dans ce post. 

            Avec le temps, j'ai un peu oublié toutes les raisons qui m'ont poussé à cette migration, je m'en excuse par avance, mais les principales sont là !


            La découverte

            Courant 2010, je découvre Play Framework 1.x (dans ses premières versions). Je fais quelques essais "Hello world !", c'est vraiment nouveau, ça semble cool, c'est magique !

            A la base, Play est conçu par les développeurs pour les développeurs, avec une volonté de faire plus simple que les usines à gaz JEE ou Spring, avec lesquels, finalement, on assemble toujours à peu près les mêmes briques, et ça nous prend un temps fou.

            Facile à télécharger et à installer, Play permet tout de suite de créer le squelette du projet ("play new myapp") et de lancer le serveur play ("play run") pour avoir déjà une page d'accueil. La suite est un régal notamment grâce à quelques points forts :

            • La présence par défaut de toutes les briques nécessaires : connexion base de donnée, mapping, rendu HTML, modèle MVC, ...
            • Une gestion des erreurs bien travaillée qui indique clairement dans la page HTML l'origine du problème
            • Une recompilation à la volée et rapide qui permet de voir immédiatement le résultat d'une modification simplement en sauvegardant le fichier et rafraîchissant la page WEB
            • Plein de modules disponibles pour étendre les fonctionnalités de Play, et notamment 2 modules essentiels : "secure" pour la sécurisation d'accès aux page, et "crud" pour avoir une génération automatique de pages d'administration des données
            • Déploiement facile sous forme de WAR
            • Un site très didactique et une document très bien faite; et pleine d'exemples de code
            • etc .... (j'en oublie certainement qui sont devenus évident pour moi)

            Bref, un gros coup de coeur que j'ai ainsi résumé à l'époque : simplicité, rapidité, productivité ! L'application est toujours utilisée et maintenue sous Play V 1.2.5.

            Première véritable application

            Eté 2010, je démarre un nouveau projet perso, application SaaS WEB, donc je pars sur Play. Et là, bonne surprise, le framework n'est pas cool que dans une phase de découverte "Hello world", il l'est également sur un véritable projet. La productivité est vraiment impressionnante, j'arrive à faire pas mal de choses (simples) en quelques heures.

            Au final, je passe plus de temps sur la partie IHM et JavaScript, d'autant plus que Play me facilite la partie serveur.

            Je déploie mon application en 1 clic sous forme de WAR sur une plateforme PaaS gratuite.

            Nouveau projet

            Début 2012, je décroche un contrat pour développer une application SaaS pour un client final. Play V2 est sorti depuis quelques temps, et on en parle beaucoup. Je sais qu'il n'y pas compatibilité entre les 2 versions, mais pour un nouveau projet, ça n'est pas gênant. Et je me dis que les gars qui avaient fait Play1 avait fait un truc tellement génial, que Play2 ne peut être que mieux, puisqu'ils auront tiré de l'expérience Play1 tout ce qui pourrait permettre de faire un truc encore mieux ! 

            Je décide donc de partir sur Play2 en développant mes contrôleurs en Java, je n'ai pas la possibilité de me lancer dans Scala (pour l'instant). J'ai commencé par la V 2.0.1, puis 2.0.2 et enfin 2.0.3.

            Les débuts se passent bien,  l'adaptation à la V2 est sans problème, je retrouve mes petits et mes habitudes : la structure MVC, le style de développement, les fichiers de configuration, de messages, etc ...

            Et l'utilisation de Scala dans les templates de vues n'est pas un problème, malgré une légère complexité supplémentaire dans les déclarations et la syntaxe.

            Le désenchantement

            Mais petit à petit, divers problèmes sont apparus me faisant perdre de plus en plus de temps. Je vais en passer en revue quelques uns dans le désordre.

            Mapping base de données

            Le stockage de données ne se fait plus par Hibernate mais par Ebean. Ça n'est pas un problème, surtout que les entités sont annotés avec JPA. En fait, j'ai eu des difficultés avec des mapping un peu plus complexe, et j'ai surtout perdu du temps avec le système de scripts d'évolution du schéma de la base : ce système est puissant mais m'était totalement inconnu. Pour ce point, c'est plus mon manque de compétences qui m'a gêné mais la documentation du framework n'était pas au RDV, et la V2 étant relativement nouvelle, les forums donnaient plutôt des solutions pour la V1, d'où pas mal de confusion et de galères.

            Et en fait, la V2 fonctionne par défaut avec Ebean, mais on peut faire de l'Hibernate. Et sans m'en rendre compte, et par manque de documentation, je me suis retrouvé à plusieurs reprises avec un mélange des deux apportant encore plus de difficultés !

            Lenteurs

            Dès le début, j'avais noté que le serveur V2 était plus long à se lancer. Mais là où ça devenait pénalisant, c'était pour la recompilation à la volée qui prenait beaucoup plus de temps qu'avec la V1 : un changement dans une vue et dans un contrôleur, sauvegarde des fichiers, rafraichissement de la page et ..... une attente bien longue ... Combien ? Je ne sais plus exactement, mais peut-être parfois près d'1 minute. OK, c'est moins long que la relance d'un serveur Spring ou JEE, mais par rapport à mes habitudes avec la V1 où une telle opération prenait environ 5", la productivité n'était plus du tout la même !

            Documentation

            Depuis la sortie de la V2, le site avait été refait, je le trouvais plutôt sympa. Mais à l'usage, surtout pour trouver de la documentation, ça n'est plus la même histoire ... OK, la V2 supporte Java et Scala pour les contrôleurs, donc la documentation à produire et maintenir est double, mais la V2 apportait pas mal de nouveautés qui étaient très peu documentées, souvent juste quelque lignes et un tout petit exemple de code. J'ai vraiment galéré sur certains points (cf Ebean précédemment), et les forums et mailing-list n'étaient pas d'un grand secours (ils le sont beaucoup plus maintenant, d'ailleurs il est plus difficile de trouver maintenant des infos sur la V1 ....).

            Modules

            Contrairement à la V1, la V2 est sortie avec peu de modules disponibles, sachant qu'il n'y a pas compatibilité entre les versions pour les modules. L'équipe de développement comptait peut-être sur la communauté déjà acquise à la cause Play ? Et notamment, pas de module "CRUD" sur lequel je comptais pour faire rapidement et simplement le back-office pour mon application. OK, c'est pas bien compliqué, mais les 2h prévues pour faire ça se sont transformées en quelques jours :-(

            Compilation Eclipse

            J'utilise Eclipse, je l'aime bien et j'assume ! ;-)

            Tout comme pour la V1, une commande "play eclipsify" permet de préparer un projet à importer facilement dans Eclipse. La grande nouveauté dans la V2 est la compilation des template de vues qui sont écrites avec un mélange de Scala et d'HTML, puis compilées. L'appel à la vue depuis le contrôleur est donc typé, ce qui limite grandement les risques d'erreurs pour le passage de paramètres entre le contrôleur et la vue.

            Dans le principe, c'est une bonne chose, même si avec la V1, j'ai rarement eu de gros problèmes à cause de ce passage de paramètres contrôleur-vue. Le problème dans mon cas était que lorsque je modifiais une vue dans Eclipse, la recompilation ne se faisait pas (ou pas bien) et je me retrouvais avec du rouge de partout, notamment dans le contrôleur puisque les appels n'étaient pas bons. Et pourtant, l'application fonctionnait bien puisque le serveur Play devait certainement recompiler l'ensemble. Et parfois, après certains rafraîchissements dans Eclipse, les erreurs de compilation disparaissaient.

            Au début, je me suis dit que ça n'était pas gênant et que je pourrais faire avec, mais à la longue, c'était devenu très pénalisant !

            Tests unitaires

            Pour moi, ce fut le gros points noir au quotidien. Je suis un inconditionnel des tests unitaires et je développe en TDD le plus possible. Ce qui veut dire, pouvoir lancer toutes les 10" le test sur lequel je travaille actuellement (voir utiliser infinitest). 

            Mais je n'ai jamais réussi à configurer correctement Eclipse pour pouvoir y lancer les tests unitaires. Des fois, ça a fonctionné, mais la plupart du temps, j'étais dans une situation où il m'était impossible de lancer une classe de test. La seule solution était de lancer les tests en console, mais la commande ne permet de lancer que l'ensemble des tests, donc un certain temps d'attente à chaque fois, et les éventuelles erreurs étaient noyées dans la masse d'informations tracées, et qui plus est, les erreurs n'étaient pas retranscrites clairement, à peine le nom du test en échec sans la raison et les valeurs concernées. Donc impossible de travailler en mode TDD !

            La migration  (downgrade)

            Je commençais donc à me rendre à l'évidence : pour moi, la V2 était beaucoup moins bien que la V1. Mais je n'arrivais pas à y croire. Je me suis accroché pendant pas mal de temps, j'ai fait des recherches sur internet, et lancé des appels sur des mailing-list ou sur Twitter. Cela ne m'a pas vraiment apporté de solutions. Par contre, je commençais à me rendre compte que je n'étais pas le seul déçu de la V2, ce qui n'était pas pour me rassurer.

            Et un jour, me rendant à l'évidence des pertes de temps que j'accumulais, et de mon manque de productivité, j'ai décidé de repasser mon projet en cours sous la V1. Les 2 versions en sont pas compatibles, mais à ma grande surprise, la migration n'a été ni longue ni très compliquée (quelques jours de boulot, très vite rentabilisés !).

            J'ai alors retrouvé la simplicité et l'efficacité de la V1, le plaisir de développer (que je commençais à perdre) et une réelle productivité : aujourd'hui mon projet est sous V 1.2.5 et je ne le regrette pas !

            Conclusion

            Mon impression est que l'équipe qui a sorti la V2 a fait des choix techniques pour apporter de la scalabilité à Play, et peut-être certaines innovations, mais au détriment de ce qui, à mes yeux, faisait la force de Play1 : simplicité, efficacité et productivité.

            Je ne développe pas des applications visant des millions d'utilisateurs, avec des calculs nécessitant de répartir les actions sur des clusters de serveur via des "agents" (la fameuse scalabilité). Par contre, je veux aller vite sur les choses simples et mettre mes efforts sur les points à valeurs ajoutées (IHM et JS).

            Aujourd'hui, lorsqu'on me demande quelle version de Play je conseille, je réponds ainsi :

            • Tu veux découvrir un framework novateur et cool, et tu veux tester concrètement Scala, just for fun : prends la dernière version de Play V2
            • Tu dois développer une grosse application, visant des millions d'utilisateurs, avec des traitements lourds, probablement à répartir sur plusieurs machines : regarde du côté de la V2, c'est certainement préférable
            • Tu veux développer une application modeste ou "classique", la charge sera normale et pourra être supportée par un serveur sur le cloud, mais tu veux te faire plaisir, aller vite pour la partir serveur, aller très vite pour des pages d'administration (via CRUD) et te concentrer sur l'IHM : prends la dernière version V1 (1.2.5) et régale toi !


            Voir l'article
            Mon retour sur Mix-IT 2013
            29 avr. 2013

            Introduction

            Les 25 et 26 avril 2013, j'ai participé à Mix-IT 2013, avec une particularité cette année puisque j'étais "speaker" : voici mon retour sur ces 2 journées de folie !


            Les sessions que j'ai suivies

            Cloud Patterns - Nicolas De Loof

            Nicolas maîtrise le cloud et ses particularités, il nous a proposé de passer en revue différents points dans l'idée, par exemple, de migrer une application existante vers le cloud: scalabilités verticale et horizontale, latence, RESTful et stateless, les API standards, les pièges du Filesystem, les pièges des instances multiples, ou des mono-instances qui se retrouvent double un court instant, le découpage en services, le rapprochement DevOps, les outils et frameworks adaptés, le déploiement "Green/Blue", etc ...

            Une session intéressante, bien menée et dynamiques, sans impact concret et rapide pour moi, mais des notions et idées bonnes à entendre et intégrer.


            Web Components, l'avenir des développeurs web - Julien Vey

            Pas de chance, j'étais au fond, on ne voit que la moitié haute des diapos, le reste était assez illisible (problème de vidéoprojecteur ?), le son était très mauvais, sans compter le bruit de la clim, il faisait très chaud, et j'avais peut-être un coup de barre : bref, pour moi, la pire de mes sessions.

            Dommage car le sujet est intéressant, même si la présentation était peut-être un peu trop monotone et très (trop ?) techniquement détaillée. Mais le problème avec ces technos HTML5, c'est l'instabilité de l'API et la disponibilité (actuelle et future). Il me semble donc intéressant de savoir ce qui est en court, ce qui nous attend, et de voir que certains frameworks JavaScript (exemple : AngulasJS) vont déjà dans le "bon" sens.


            Bâtir une équipe à partir de ses valeurs - Jean-François Jagodzinski

            Pour me réveiller un peu, j'ai décidé d'aller dans un atelier. J'ai donc assisté à celui de Jean-François qui nous a fait quelques rappels autour de l'agilité et des valeurs. Nous avons ensuite expérimenté un atelier consistant à recenser les valeurs qui caractérisent notre équipe, puis en se projetant dans le contexte d'un projet, voir comment nous pourrons appliquer les 12 principes du manifest agile, notamment en décelant ceux qui seront difficiles à mettre en oeuvre, et imaginer les "fruits" qui pourront en découler.

            Un atelier intéressant, un bon moment agréable et enrichissant.

            Dart : one language to rule them all - Sébastien Deleuze

            Très bonne présentation sur une technologie intéressante, qui semble bien pensée et bien équipée, notamment en API (on sent qu'il y a Google derrière). Sans trop rentrer dans les détails, Sébastien passe en revue les points essentiels : le langage (ojets, fonctions, ...), les API, le Web UI, les environnement d'édition et de runtime, les perfs, l'outillage, etc ...

            C'est intéressant, mais ce qui me gêne, c'est que ce soit une techno poussée par un seul gros éditeur, supportée nativement dans son navigateur (Google), ce qui ne sera jamais le cas pour les autres navigateurs : le code doit donc être transpilé en JavaScript .... Techno à tester prochainement ...


            The Clean Architecture - Thierry Cros & Guillaume Saint Etienne

            J'ai finit la journée avec Thierry et Guillaume, pour une présentation tranquille et détendue (peut-être un poil trop molle et décousue ?) pour nous parler d'architecture en couches, de concepts comme SOLID, OPC (Open Close Pinciple), ISP (Interface Segregation Principle), DPI (Dependency Inversion Principle), CRP (Common Reuse Principle), dépendances acycliques, etc ...

            Certains principes sont connus mais pas forcément appliqués, d'autres sont appliqués sans savoir qu'ils ont un nom, bref, des rappels toujours intéressants pour construire de bonnes architectures agile.


            Collaborer, et si on improvisait ? - Vincent Daviet

            J'ai attaqué la 2e journée avec la volonté de faire un peu plus d'ateliers. J'ai donc commencé par celui de Vincent, qui parlait agilité et théâtre d'improvisation : le théâtre en tant que comédien ne m'attire pas, et j'ai horreur de l'improvisation. Donc, je me suis fait un peu violence pour aller à cette session, histoire de sortir de ma zone de confort, et je n'ai pas été déçu !

            Nous étions peu (peut-être trop peu) mais Vincent anime son atelier de façon très progressive, en commençant par des exercices très simples et ludiques, pour ensuite passer à des scènes ou tableaux (l'effet collectif et muet lève les freins), et pour finir par une histoire à raconter en improvisant.

            Les parallèles avec les valeurs de l'agilité sont évidents : confiance, collaboration, communication, respect, etc ... et la pratique d'un tel atelier pour fédérer une équipe naissante ou existante me semble très intéressant. Un excellent moment !


            Backbone, Ember et Angular sont dans un bateau - Loïc Frering

            J'utilise Backbone depuis 1 an sur mon projet en cours, je ne connais pas trop Ember, et j'entends de plus en plus parler de Angular, je suis donc allé sans hésiter à cette présentation où Loïc a effectué un comparatif méthodique et objectif sur différents thèmes, pour voir comment ils sont adressés par chaque framework : le modèle de donnée, le modèle MVxx, l'API client-serveur, le routage, etc ...

            En conclusion : je ne suis pas trop attiré par Ember (pour ses choix, mais également pour le contexte, la version 1.0 semble avoir du mal à sortir), et Angular me semble moins "magique" que les exemples simplistes qu'on voit souvent, surtout lorsqu'on aura besoin de construire une véritable application avec un peu de complexité d'IHM.

            Comment tester une application html5 ? - Jean-Laurent De Morlhon

            Le sujet m'intéressait, il est même dans mes préoccupations du moment, et connaissant un peu Jean-Laurent, je pensais que ce serait bien : et bien, c'était super bien !

            Après quelques diapos pour rappeler quelques principes de base, Jean-Laurent passe en revue les différentes solutions par lesquelles il est passé pour faire des tests d'IHM, et nous explique pourquoi il est arrivé à la solution qu'il nous présente.

            S'en est suivi une démo de test d'IHM, sur une application WEB avec du JavaScript (type e-commerce), à base de CucumberJS (Cucumber porté sous JS, notamment avec Node.js), ZombieJS (navigateur "headless" en JS et super rapide) et Chai (librairie d'assertion "fluent") : vraiment excellent et impressionnant !

            Sans aucun doute, ma meilleure session sur ces 2 jours avec des idées à tester concrètement et très rapidement !


            C’est le moment de se lancer dans s’cas là ! - Ludwine Probst, Jean Helou, & Mathieu Chataigner

            J'avais dit journée "atelier", en plus, j'essaie de suivre les cours de Scala chez Coursera, et c'était l'occasion de revoir Jean : je suis donc allé à cet atelier sur Scala. Le handout fourni est très bien fait, basé sur des tests unitaires et un outils à lancer en ligne de commande pour compiler et lancer les tests à chaque fois qu'un fichier est sauvegardé. Les commentaires dans le code nous explique les principes de bases de Scala, de façon très progressive, avec tout de suite des exemples concrets et des cas à résoudre pour faire passer les tests unitaires et passer à l'étape suivante. 

            Pas possible d'aller bien loin en 1h30, mais le principe est excellent et très bien préparé, et je suis reparti avec le handout dans ma machine pour poursuivre tranquillement de mon côté : une bonne session !

            Développeurs Anonymes - Johan Martinsson & Rémy Sanlaville

            Pour finir la journée, je suis allé aux "Développeurs anonymes" pour échanger sur mes problèmes de développeurs .... "Bonjour, je m'appelle Xavier, et je ne suis pas toujours satisfait de mon code ...." ;-)

            J'avais raté la session de Johan et Rémy lors d'Agile Grenoble 2012, et vu les retours, j'avais vraiment regretté. Pas de chance, ils ont changé le format pour en faire un atelier. Mais les compétences, les apports et le plaisir sont là. Sur base d'un code plutôt mal foutu et illlisible, les animateurs nous présentent "Object Calisthenics", une méthode à base de 9 étapes, pour nous amener à une meilleure conception objet. L'expérimentation est immédiate, et les résultats sont surprenants : en très peu de temps, le code ignoble du départ s'éclaire peu à peu.

            J'ai beaucoup apprécié cet atelier, les orateurs sont bons et maîtrisent le sujet, ils en profitent pour bien insister sur un meilleur usage de l'IDE (document papier fourni à l'appui) et la méthode est intéressante, pas forcément à mettre en place tout le temps à 100%, mais pour avoir les idées en tête dans notre travail de tous les jours ...

            En plus, j'ai eu le plaisir de binômer avec Damien, un ancien collègue, ça nous a rappelé les coding-dojo d'antan ...

            Point de vue en tant qu'orateur

            J'ai eu la chance d'être retenu comme orateur pour ma session "Agilistes : n'oubliez pas la technique". J'étais donc attendu dès mercredi soir pour le dîner des orateurs, excellent moment permettant de connaitre les autres intervenants, de rencontrer également l'équipe d'organisation et de sympathiser un peu plus avec certains.

            J'ai beaucoup apprécié les attentions de l'équipe d'organisation vis-à-vis des orateurs, aussi bien dans les semaines et jours qui précèdent en nous donnant des informations précises pour faciliter notre organisation, que sur place pendant 2 jours et demi (logistique, logement, ...), mais aussi sur le lieu de la conférence pour nous mettre à l'aise et nous permettre de donner le meilleur de nous-même lors de nos sessions.

            Ma session a été suivie par Ellen, Caroline et Eric qui font partie de l'organisation d'Agile France où je redonnerai ma session : ils ont donc pu me faire des retours rapides pour me permettre d'améliorer ma session, un grand merci à eux et rendez-vous à Agile France !

            Conclusion

            Le passage de Mix-IT sur 2 journées est probablement ambitieux et plus complexe, mais au final, c'est une excellente chose, avec une grosse immersion pendant 48h dans des sessions riches et variées, et une soirée (jour 1) permettant de prendre le temps de discuter avec les uns et les autres (plus difficile à faire pendant la journée).

            Pour moi, le slogan "Des idées pour tout de suite" est concrétisé, et avec mes 2 passions agilité et développement, je me sens vraiment bien dans cette conférence "mix" dont le niveau de qualité commence à être bien élevé.

            Félicitations à toute l'équipe d'organisation 
            et un grand merci pour ces 2 superbes journées !
            Voir l'article
            TDD : une démo en 10' ?
            15 avr. 2013
            Le 9 avril dernier, lors des Human Talks de Grenoble, j'ai proposé de tenter une démo live de TDD en 10'. La session n'a pas pu être filmée, et apparemment, bon nombre de personnes ont regretté de ne pas avoir pu être là. J'ai donc rejoué et enregistré cette session que je vous propose aujourd'hui sous forme de "CodeCast".



            Visionnez la vidéo ici même ou directement sur YouTube en cliquant sur le lien.

            Attention : vérifiez que la qualité de lecture est d'au moins 480p pour que le code soit lisible ! et passez en plein écran pour en profiter pleinement.

            N'hésitez pas à poster vos questions ou remarques ci-dessous, ou à me contacter pour plus de renseignements ! Merci



            Le code source de la session live des Human Talks :
            https://github.com/xnopre/tdd-htgrenoble-2013.04.09

            Les slides :

            Voir l'article
            Pomodoro : première expérimentation (REX)
            02 avr. 2013
            J’entendais parler de la « technique Pomodoro » depuis quelques années, j’avais échangé sur ce thème avec quelques praticiens passionnés et convaincus lors d’Agile Innovation, et à la dernière soirée du CARA, Luc nous en a fait une rapide présentation avec son retour d’expérience qui m’a donné envie de tenter l’expérience, persuadé que cette méthode pourrait m’aider à mieux gérer mon temps.


            La technique Pomodoro 

            Résumé en quelques éléments :

            • La journée de travail est découpée en « pomodoro » 
            • Un pomodoro est une période active de 25’ suivi d’une pause de 5’ 
            • Tous les 4 pomodoro, la pause doit être plus longue, 15’ 
            • En début de journée, on liste les tâches prévues pour la journée en les estimant en pomodoro (« je prévois de faire cette tâche en 1 pomodoro puis celle-ci en 2 ») 
            • Un pomodoro est consacré à l’exécution d’une seule tâche, on s’y concentre à 100%, on ne fait rien d’autres 
            • On ne peut pas écourter un pomodoro : si la tâche semble finie avant la fin du pomodoro, on prend le temps restant pour la vérifier, la peaufiner, la perfectionner, … 
            • Lors des pomodoro, on note sur une feuille chaque interruption, chaque perturbation, chaque pensée qui n’est pas en lien avec la tâche en cours 
            • En fin de journée, on fait le bilan des interruptions à prise de consience 
            • On fait également le bilan des tâches réalisées et le nombre de pomodoro qu’on y a consacré à amélioration continue (des estimations) 
            • A ne pas utiliser pour les loisirs ou autres moments de détente 

            Les objectifs de la technique Pomodoro 

            • Meilleure organisation de son travail (en mode "mono-tâche" car l'humain est mono-tâche, qu'il soit homme ou femme ... si, si !)
            • Meilleure gestion des perturbations
            • Moins de chronophagie et de procrastination
            • Meilleur visibilité du temps passé sur les tâches
            • etc ...

            Mon activité et mon besoin

            Indépendant, lorsque je ne suis pas en entreprise (coaching, formation, accompagnement), je suis à mon bureau avec essentiellement une activité de développement. Mais je dois également répondre à mes clients (mails ou téléphone), échanger avec d'autres intervenants sur mes projets, suivre Twitter et quelques blogs, sans oublier les tâches administratives.

            J'ai donc décidé de tester cette organisation sur ces journées de développement. Par contre, difficile pour moi de découper cette activité en tâches de 25', certaines stories me prenant d'une demi-journée à 2 jours.

            Par contre, dans une journée de développement, j'ai d'autres tâches comme celles citées précédemment ... Et à bien y réfléchir, certaines de ces tâches me prennent beaucoup de temps, probablement trop, et leurs répartition dans la journée n'est pas structurée, donc certainement pas efficace.

            D'où ma motivation à tester cette méthode !

            Mon implémentation

            • Pas de découpage planifié de mon activité de développement en pomodoro
            • Par contre, une organisation de ma journée en tranche de 25' :
              • 1 pomodoro en début de journée pour traiter les mails et jeter un coup d'oeil à Twitter
              • plusieurs pomodoro pour l'activité de développement
              • des pomodoro "unitaires" dans la journée selon les besoins : tâches administratives regroupées, écrire un article, faire le point sur mon projet en cours avec le client ou les partenaires, etc ...
            • Essayer de respecter les pauses, au moins celles de 5' toutes les 25'
            • Utilisation d'un timer sur mon ordinateur :
            • Suppression des notifications (popups) pour Twitter et pour les mails
              • J'ai gardé la notification sur mon téléphone, ça me permet de vérifier en 3" si ce n'est pas urgent
            • Pas de planification précise de toute ma journée en pomodoro et donc pas de bilan en fin de journée
              • Mon souhait était de mieux gérer le temps qui passe, et mieux répartir les actions en les groupant
              • J'ai tout de même essayé de noter les pomodoro réalisé et la tâche associée

              Ce qui s'est passé

              • 1er pomodoro : pas vu passé, j'ai eu l'impression qu'il avait duré 10-15', une horreur
              • Idem pour la pause suivante, rien le temps de faire
              • Et idem pour le 2e pomodoro et sa pause
              • Étrangement, le 3e pomodoro m'a semblé bien plus long (pour la même activité de développement), j'ai regardé le timer pensant être au bout et il restait 10' : adaptation ?
              • Et idem pour la pause qui a suivi
              • Lors de la fin d'un des premiers pomodoro, j'étais trop frustré de devoir m'arrêter, j'ai voulu continuer, mais j'avais laissé active l'option du timer Workrave qui permet de bloquer clavier et souris : résultat ... je suis parti en pause !

              Les difficultés

              • S'arrêter au bout de 25' et vraiment faire autre chose : on est tenté d'aller voir ses mails ou Twitter, le blocage clavier-souris de Workrave est une bonne aide !
              • Ne traiter réellement qu'une seule tâche lors d'un pomodoro, pas toujours facile selon ses habitudes (en tout cas dans mon cas)
              • Impossible de ne pas répondre à un appel téléphonique d'un client, même s'il demande s'il ne dérange pas (= arrêt du pomodoro en cours, mais ce n'est pas grave)

                Les points positifs

                • Une réelle prise de conscience du temps qui passe : je trouve que ça a pour effet de se booster un peu plus pour terminer ou éviter de traîner sur certaines tâches
                • Une bien meilleure organisation journalière, et un gain de productivité : éviter de passer d'une tâche à l'autre, et se concentrer sur une action pendant 25' est vraiment plus efficace
                • Meilleur gestion des perturbations, notamment celles liées aux NTIC et au monde hyper-connecté : on peut vraiment s'organiser autrement pour traiter ses mails et suivre Twitter, et un délai max de 25' ne nous empêche pas d'être "réactif"
                • Je me suis rendu compte à quel point je ne faisais pas de pauses (tout en m'éparpillant parfois) : là encore, le timer Workrave est très utile, en plus, en début de pause, il propose 3 exercices pour se décontracter physiquement, vraiment sympa !

                Conclusion

                Pour moi, une expérimentation vraiment positive que je vais poursuivre cette semaine, par exemple pour l'écriture de cet article (3 pomodoro pour 2 prévu ...). Je vais garder mon organisation qui consiste à "timeboxer" certaines tâches de début de journée (mails, Twitter, blog) puis à enchainer sur des pomodoros de développement. Je vais également essayer de mieux noter le déroulement de ma journée pour, peut-être, mieux me rendre compte de ce qui s'est réellement passé, et si possible, noter les interruptions (à voir si ça m'apporte). 

                A suivre ....

                Et vous, vous avez testé ? Ou sinon, ça vous tente ? 


                Références :



                Voir l'article
                CodeStory 2013 : l'addiction inattendue
                11 févr. 2013

                Introduction

                Qui ne connait pas CodeStory ? Voir cette page pour tout savoir, mais j'imagine que les développeurs passionnés, comme moi, connaissent, au moins de nom.

                Pour ma part, j'avais suivi l'édition 2012 de loin. J'étais allé voir le sujet de pré-sélection, et je ne m'étais pas lancé dans l'aventure : je ne me sentais pas à la hauteur, et le sujet ne m'inspirait pas vu le peu de temps que je pouvais envisager d'y consacrer.

                Pourquoi pas ? Pour voir ...

                Cette année, lorsque j'ai vu passer l'annonce sur Twitter, par curiosité, je suis allé voir le sujet. Et là surprise, pas grand chose, à part qu'il faut implémenter et déployer un serveur WEB pour répondre à une seule requête "Quelle est ton adresse mail ?".


                En plus, quelques semaines plus tôt, au coding-dojo du CARA, nous avions étudié le code Kittenmash de David Gageot, et je voulais tester Simple Framework que j'avais déjà noté dans mes tablettes depuis un bon moment.

                Dernier facteur déclenchant, Nicolas Deloof propose via Twitter un hébergement sur CloudBees pour CodeStory.

                J'avais donc là un sujet tout trouvé pour faire quelques expérimentations, et assouvir ma curiosité : mais qu'y a-t-il dans ce CodeStory après cette première requête ? Donc, 16 janvier, c'est parti pour la mise en place du squelette de mon application, avec une première implémentation minimale pour la première question.

                C'est parti !

                Après avoir un peu bataillé avec quelques mises au point pour mon déploiement, et la mise en place d'un script pour déployer au plus vite, en tout agilité bien sûr, ça y est, mon serveur reçoit la première requête et dans la foulée la seconde question "Es tu heureux de participer(OUI/NON)". Facile, j'implémente ma réponse "OUI" et je déploie. 

                A peine le temps de chercher un café et une nouvelle question : "Es tu abonne a la mailing list(OUI/NON)". Arg, quelle liste ? Mince, j'ai pas l'info, je ne suis inscrit nulle part ... Et la requête se répète toutes les 10'. Je ne vais tout de même pas rester coincer à ce stade ? .... Je cherche, j'écris à David, je fouille sur twitter, ça parle d'une liste, je la trouve, Jean-Laurent me répond : ça y est, je suis inscrit : yes ! J'implémente un joli "OUI" et je déploie ...

                En fin de journée (et oui, pas que ça à faire), je regarde les logs de mon serveur, et nouvelle question "Es tu pret a recevoir une enonce au format markdown par http post(OUI/NON)". OK, pas de problème, j'implémente encore un "OUI" ! 

                Je me prépare pour aller me coucher mais voilà la nouvelle question "Est ce que tu reponds toujours oui(OUI/NON)". Ah les gars, vous êtes des rigolos, je me marre un bon coup et j'implémente cette fois un joli "NON" pour aller me coucher.

                L'addiction

                Mais non ! Voilà l'énoncé qui arrive pour "L'échoppe de monade sur Scalaskel". Quel délire cet énoncé, mais trop tard pour réfléchir et faut se coucher.

                Mais la question suivante arrive : "As tu bien recu le premier enonce(OUI/NON)". OK je répond "OUI" et j'arrête, on verra demain ...

                Arg, la première requête arrive avec la valeur "1". OK, pas encore besoin de réfléchir à l'algo, suffit de répondre "1 foo". Par contre, mon code n'est plus propre. Pas de problème, j'adore le CleanCode : je refactore, je structure, je met en place l'architecture pour traiter cet exercice, et je réponds simplement "1 foo", et je déploie ...

                Il est 1h du matin, je me rends compte que je suis devenu addict à ce truc de fou, et je ne peux plus m'arrêter ! La requête suivante m'envoie la valeur "2", suffit de répondre "2 foo". Et la troisième enchaine avec la valeur "3".

                OK, je vais pas implémenter des "if" pour toutes les valeurs possibles, à ce stade il me suffit de renvoyer le même nombre de foo que la valeur reçue. J'implémente, je déploie, et là, évidemment, sur le serveur, les requêtes s’enchaînent pour "3", "4", "5" .... mais ça bloque à "8", la réponse est évidemment plus complexe !

                Bon, j'arrive enfin à décrocher, je m'endorre sur le clavier. Je vais me coucher, mais cet algo me travaille, je ne m’endors pas ... et après quelques minutes, je trouve une solution simple ... je ne vais quand même pas me relever ? Non, l'ordi est éteint ...

                Ça déroule ! ...

                Le lendemain, c'est samedi, pas trop beau temps, alors ... CodeStory ! J'implémente mon algo, je déploie et je surveille les logs : les requêtes s’enchaînent rapidement, avec des valeurs de plus en plus grandes, mon algo semble bon puisque les requêtes ne sont pas répétées, cool !

                Puis c'est la surprise avec une requête "1 1" ... Quoi ? Comment ? "1 1" ? Ca veut dire quoi ? Le temps de me réveiller un peu (et oui, j'avais repris assez tôt le matin, arg), et je me souviens avoir vu passer sur Twitter "Je réponds quoi à '1 1' ?" puis, par le même auteur, "Ah oui, que j'suis bête !" ... Mince, serais-je bête, moi ? 

                OK, l'explication arrive vite, la requête reçu est "?q=1+1" que mon implémentation décode en "1 1" (le + est utilisé pour les espaces dans les requêtes). Bon, ben j'implémente la réponse en dure, donc "2". Ca passe, et je reçois la suivante "2+2". Dans la même logique d'approche agile, itérative et minimaliste, j'implémente la réponse "4" avec un "if". Et une nouvelle requête arrive "3+3".

                C'est le moment de réfléchir et de faire mieux que des "if". Après une première idée et des tests non motivant d'utilisation de javax.script.ScriptEngine, j'ai rapidement l'idée d'utiliser Groovy que je n'ai jamais pratiqué mais je sens que ça pourrait être pas mal. Effectivement, GroovyShell permet d'évaluer une expression. Quelques validation avec les tests unitaires (que j'utilise depuis le début, évidemment mais non précisé) et je deploie cette solution.

                Je dois avouer avoir eu ensuite un grand plaisir à voir passer rapidement des requêtes de plus en plus compliquées et ma solution qui répondait juste ! A part quelques mises au point (entre "," et "."), je suis rapidement arrivé au bout de cet exercice. J'ai également eu apparemment un peu de chance, sur les très grands nombres, puisque Groovy a une implémentation qui les supporte bien.

                ... puis ça se complique !

                Après une question détente ("As tu passe une bonne nuit malgre les bugs de l etape precedente(PAS_TOP/BOF/QUELS_BUGS)"), je reçois l'énoncé du second exercice : "Location d’astronef sur Jajascript". 

                Le sujet n'est pas si compliqué, je commence à penser à un algo simple, mais les tweets qui passent et les résultats (qui stagnent) sur http://status.code-story.net/ me laisse présager quelques difficultés.

                Après un bon refactoring pour faire évoluer l'architecture et répondre à ces nouvelles requêtes, je commence comme pour les autres exercices : le plus simplement ! La première requête donne 1 voyage, la réponse est donc simple avec ce voyage. La seconde requête donne 2 voyages, la réponse est simple, c'est la somme des 2 voyages. C'est donc à partir de la 3e requête que j'ai implémenté mon algorithme.

                Une fois déployé, je suis content, ça répond à un bon nombre de requêtes qui sont de plus en plus grosses puis .... ça se bloque. Petite analyse de la situation : mon serveur met trop de temps à répondre ! Aïe, c'est bien ce que je pensais, ces histoires de "performances" vont se jouer ici !

                Après une première amélioration de mon algo, je réponds à 1 requête supplémentaire mais pas plus. 

                C'est la fin 

                C'est l'heure du bilan car j'ai consacré à Code Story 2013 largement le temps initialement prévu, c'est-à-dire pas beaucoup (ou du moins pas trop). Et puis, je voulais juste "voir" et au final, je me suis bien marré ! Sans compter que du côté classement, je suis dans la première moitié, mon honneur est sauve.

                Je tenterai quelques optimisations mineures, qui n'apporteront pas grand chose, et je resterai un peu frustré tout de même d'être obligé de jeter l'éponge à ce stade, pour une histoire d'algo sur lequel je ne peux pas me pencher plus pour trouver une bonne solution.

                Conclusion

                Je me suis lancé dans cette aventure sans rien en attendre de particulier, juste par curiosité, parce que le sujet initial était simple, et par un concours de circonstances.

                Au final, je me suis éclaté en passant de bon moment de coding.

                J'ai particulièrement bien aimé le côté "découverte" de ce qu'il fallait faire, au fur et à mesure, sans explications, mais toujours avec des éléments très intuitifs.

                Et en agiliste pratiquant, j'ai également bien apprécié cette approche ne permettant pas de savoir ce qu'il faudrait faire par le suite, forçant à des implémentations simples pour commencer, mais nécessitant régulièrement des refactorings pour faire évoluer l'architecture de sa solution.

                La surprise !

                Début février, j'avais croisé David Gageot lors de #iutagile, je lui avais fait un petit retour de ma participation, et il m'avait dit qu'une cinquantaine de personnes serait retenues pour la finale à Paris. Je ne comptais pas être sélectionné, ça n'était pas du tout dans mes objectifs, et d'ailleurs, je n'avais rien reçu, et je n'étais pas dans la liste que j'avais vu passer ...

                Mais ce matin, surprise dans les mails, message de Jean-Laurent de Morlhon : "Tu as été sélectionné pour la phase finale de CodeStory 2013". J'avoue être très surpris, à la fois content mais un peu stressé à l'idée de me retrouver en final avec des personnes ayant atteint un score de 35/35, et surtout une note de performance de 10000/10000, je me suis arrêté à 5/10000 ;-). Mais bon, pourquoi pas, surtout pour aller chez Google, si je me trouve un binôme "Java, CleanCode et solutions simples" qui, comme moi, irait à cette soirée pour se marrer et passer un bon moment ...

                A suivre ? .....
                Voir l'article
                L'agilité dans les IUT : #iutagile (REX)
                08 févr. 2013

                Introduction

                Les 31 janvier et 1er févier 2013, j'ai été invité par Isabelle Blasquez et Sébastien NEDJAR pour participer aux Journées IUT Agile 2e édition à Aix-en-provence. En voici mon retour.

                Les journées #iutagile sont auto-organisées par les enseignants en IUT informatique de toute la France pour se former à l'agilité, en savoir plus, partager, et trouver des idées et solutions pour faire entre l'agilité dans les IUT et les programmes.

                C'est sans hésiter que j'ai répondu à l'invitation car, fervent partisan de l'ingénierie agile indispensable à l'agilité, je suis convaincu qu'il faut parler de l'agilité, et des aspects techniques associés, à la source, c'est-à-dire dans les cursus scolaires, auprès des étudiants.



                Mon programme des 2 jours

                Jeudi

                Jeudi matin, nous avons commencé avec "La voie du programmeur" par Jean Baptiste Dusseaut. J'avais découvert JB par la vidéo de son lightning talk à Mix-IT 2012, j'avais adoré ! J'avais pu voir la vidéo de sa session d'1h lors de l'Agile Tour Bordeaux : toujours excellent ! J'ai enfin pu le voir en chair et en os, et c'est encore mieux ! Le ROTI a montré que cette session a beaucoup plu, et c'est tant mieux. J'espère que le message est passé auprès des profs : le métier de programmeur/développeur est noble, il faut le valoriser, et arrêter de le présenter comme une étape intermédiaire vers le statut ultime de "chef de projet". [*]

                Note : JB semblait un peu tendu, peut-être à cause du parterre de profs, pourquoi ? Et j'ai l'impression qu'il a rallongé un peu sa présentation puisqu'il avait plus de temps : dommage, ça dégrade légèrement la présentation qui n'est plus vraiment dans le même rythme.

                Ensuite, c'est Nicolas Deverge qui nous parlé de Lean Startup sur base d'un REX de développement "éclair" pour un concours. Nicolas a fait participé la salle qui n'était pas très intéressée par son produit : je n'est pas compris si c'était voulu ou vraiment un bide ... Malgré une présentation un peu trop "promo" à mon goût, j'ai complété mes notions encore assez faibles sur ce sujet, et je pense que ça fait partie de la palette de connaissances que les profs doivent avoir.

                En début d'après-midi, Claire Hernandez nous a fait une double présentation avec une introduction à Scrum puis un retour sur son parcours professionnel. Je ne sais pas si ce REX a beaucoup apporté aux profs présents, par contre l'introduction à Scrum m'a semblé indispensable, tous les profs présents ne maîtrisent pas forcément ces concepts de base.

                J'ai pris la suite de Claire avec ma session "Agilistes : n'oubliez pas la technique !" qui succèdent à ma présentation donnée aux derniers Agile Tour Marseille et Agile Grenoble.

                La session a apparemment bien plu à en croire le ROTI et les discussions qui ont suivi :

                 

                Puis c'est Claude Falguière qui nous a parlé de Git que j'utilise, donc je n'ai rien appris de révolutionnaire mais ce genre de présentation permet toujours d'approfondir ses connaissances sur des "détails" (qui n'en sont pas toujours). Parler à des profs de gestion de sources modernes, comme Git évidemment, me semble essentiel pour que les étudiants soient opérationnels tout de suite sur des technos d'avenir.

                Nous avons terminé la journée par une rétrospective collective bien menée en toute agilité par les organisateurs  S'en sont suivi quelques actions immédiates pour améliorer la 2e journée, et j'ai notamment proposé d'animer un coding-dojo sur le thème du TDD pour répondre à plusieurs demandes issues de la rétro.

                Vendredi

                Vendredi matin, j'ai enfin pu assister à la session "Clean Code" de Jérôme Avoustin. Je n'y ai pas appris grande chose puisque le livre "Clean Code" (ou "Coder proprement") d'oncle Bob m'a beaucoup inspiré il y a quelques années. Mais c'est toujours bon à ré-entendre. Et surtout, il est impératif de diffuser cette bonne parole auprès des profs pour que les futurs développeurs partent sur de bonnes bases !

                Et la matinée a continué à me gâter puisque j'ai enfin rencontré David Gageot, en chair et en os, et j'ai pu le voir à l'action autrement qu'en vidéo. Sa démo de refactoring de code existant est bien rodée et se déroule impeccablement. David maîtrise son IDE ce qui est essentiel, je l'ai toujours dit. Mais son panel de connaissances en techniques, patterns, et technos lui permet d'aller très loin, et rapidement à l'essentiel : c'est impressionnant. Je retiens notamment une approche : "Augmenter la duplication pour mieux la supprimer". OK, mais à voir en pratique, le résultat est bluffant ! Montrer à des profs cette maîtrise poussée à l'extrême de l'art de développer est là encore indispensable. Petite parenthèse pour une mention spéciale à David qui est sympa mais surtout simple, humble, et très accessible, et le remercier pour nos échanges sur CodeStory (REX de ma participation dans un prochain article).

                Lors de la pause déjeuner, comme convenu la veille, j'ai animé au pied levé un coding-dojo sur le thème du TDD pour montrer le TDD en action et le faire pratiquer, mais également montrer ce qu'est un coding-dojo et les nombreux apports d'un tel format de formation. Les motivés étaient assez nombreux, et je remercie les volontaires courageux qui se sont lancés pour coder devant tout le monde : pas toujours si facile. Et là encore, remerciements à David pour sa participation en toute simplicité !



                L'après-midi, Jérôme Avoustin était à nouveau à l'honneur pour nous parler "pilotage par les tests" avec une approche détaillée, bien argumentée et, je l'espère, convaincante pour les profs présents.

                La journée s'est terminé par un débat sur la place des IUT dans les communautés, animé sous la forme d'un atelier "Remember the Future" : nous sommes le 15 février 2015, l'agilité est une évidence dans les IUT qui sont impliqués et représentés dans les différentes communautés : que s'est-il passé ?

                Et en fait, la journée s'est réellement terminée par un coding-dojo Kata (démo) où Fabrice Nourisson nous a montré et expliqué Erlang avec Le Jeu de la Vie comme exemple. Erlang est un langage fonctionnel, ayant apparemment pas mal de similitudes avec Haskell, où on trouve : typage dynamique fort, affectation unique, évaluation stricte, etc ... Je l'avoue, je n'ai (pour l'instant) aucune expérience de ces langages, et pas forcément l'esprit adapté, donc pas facile. Par contre, ce type de langage, très proche des maths, semble bien plaire aux profs présents qui étaient très excités et anticipaient pas mal les propos de Fabrice par leurs questions. Ce fut donc un bon moment que je n'ai pas pu suivre jusqu'au bout (cause départ) : merci Fabrice !

                Conclusion

                Deux très bonnes journées, pleines de rencontres, d'échanges, de bons moments. Donc merci à l'organisation de m'avoir sollicité ! Merci aux participants pour la bonne ambiance et les discussions.

                Ces rencontres me confirment qu'il faut bel et bien parler à la source, aux étudiants, d'agilité, d'ingénierie agile, de tests et TDD, de code propre, etc ... Mais j'ai été surpris de constater le manque de moyens pour les profs, notamment en formations, pour leur permettre de s'adapter au mieux au contexte actuel, les poussant à s'auto-organiser de tels journées pour se former : bravo à eux pour leur motivation !


                [*] NDLA : je ne dis pas que tous les profs affichent ce point de vue et le monde du travail y est pour beaucoup (SSII en tête)
                Voir l'article
                Human Talks Grenoble du 11 déc 2012
                14 déc. 2012

                Introduction


                Mardi dernier, 11 décembre 2012, j'ai assisté et participé en tant que "talkeur" aux Human Talks à Grenoble. En voici un petit retour.

                Principe : Une rencontre autour de présentations de 10' par des développeurs pour des développeurs.

                Pour notre soirée, il y avait 5 présentations au programme.




                À la découverte de Redis
                par Maxime Garcia @maximegarcia


                Nous avons commencé la soirée avec Maxime qui nous a parlé de Redis, une base de données clés-valeurs orientée performance. La présentation était bien technique, très axée sur les commandes possibles, et notamment la manipulation atomique de bits permettant, par exemple, un suivi de fréquentation sur un site par les utilisateurs enregistrés, le tout nécessitant moins de place de stockage qu'un SGBD classique.

                La présentation était rythmée et facile à suivre, peut-être un poil abstraite, et finalement, dès le début, je me suis demandé où je dois utiliser les commandes présentées dans mon programme (Java par exemple) : il manquait donc peut-être une information de contexte, sur l'architecture et les possibilités pour se connecter et utiliser une telle base. J'ai trouvé des éléments de réponse sur le site : http://redis.io/clients.



                Design introduction pour développeur curieux
                par fabrice liut @SlaapMe


                Ensuite, c'est Fabrice qui a pris la parole. Fabrice n'est pas développeur et designer. Il nous a donc parlé de son métier, des différentes phases d'un projet pour un designer. Il a bien insisté sur le fait que son travail n'est qu'à 30% sur le graphisme, le reste est étude, conception, etc ... Une présentation sympa, vivante, enthousiaste, j'ai appris plein de choses !

                Et j'ai trouvé ça super, qu'un acteur non-développeur de la production logicielle viennent parler de son métier  aux développeurs, il est important que chacun connaisse un peu (mieux) le métier des autres !



                TDD ou comment coder à l'endroit
                par moi-même


                Il y a 1 mois, j'avais tout de suite repéré le lancement des Human Talks, regrettant de ne pouvoir y aller. Sous l'impulsion de Jonathan, qui m'avait lancé une (grosse) perche, j'ai proposé de parler TDD, d'une part parce que c'est mon sujet de prédilection actuel, mais également pour soutenir cette initiative des Human Talks, car pour que ça marche, il faut .... des talks !

                Mine de rien, une présentation de 10', c'est pas si simple. Jonathan me l'a bien ré-éxpliqué lors de la soirée, l'idée est de faire des présentations "pop-corn", c'est-à-dire simples, sur un sujet qui nous passionne, sans passer des heures à préparer.

                Mais en ce qui me concerne, la préparation m'a pris presque toute la journée (mind-map, fil conducteur, puis diaporama), déjà parce que je suis un peu perfectionniste et que je veux faire "bien" les choses, mais aussi parce que parler TDD à un public hétérogène en 10', c'est tout de même un challenge.

                Mais j'étais justement très intéressé par ce défi: comment expliquer le TDD en 10', faire comprendre le pourquoi, le comment, et les valeurs qui se cachent derrière cette pratique ? Je pense avoir relevé ce défi, l'auditoire semblait intéressé, le ROTI était bon : cool !


                Introduction aux WebApps
                par Flaburgan


                Après ma présentation, c'est Antoine qui nous a parlé des WebApps, qui sont apparemment simplement des sites WEB auxquels on ajoute un fichier manifest, et qui est alors considéré par le navigateur comme une application qu'il peut télécharger et installer sur le poste. Si j'ai bien compris, car ça me semble (trop) simple, mais très intéressant bien sûr, face au problème actuel des développements mobiles multi-plateformes, puisqu'il s'agit en fait de développer en HTML5 et CCS3, sachant qu'on peut alors accéder aux fonctions du mobile (vibreur, appareil photo, etc ...) après autorisation par l'utilisateur bien sûr !

                La présentation d'Antoine était claire et passionnée, juste un manque de précisions (claires) sur la situation actuelle puisque, si j'ai bien compris, seul Firefox supporte cette technologie ... Encore et toujours la guerre des éditeurs de navigateurs ? ....

                En tout cas, un thème à creuser ...

                (suivre le lien Github, récupérer le contenu, ouvrir presentation.html)

                Comment sortir 3 projets web en 1 mois
                par Evan Genieur @Evangenieur


                Pour terminer la soirée, c'est Fabien qui nous a expliqué son approche du développement logiciel pour sortir très rapidement (24h, 48h), des applications WEB simples mais fonctionnelles, permettant de fournir un premier service, et avoir rapidement du feedback avec peu d'investissement.

                J'ai apprécié cette approche inspirée des tendances actuelles (agilité, lean startup, ...), avec comme idée forte, de commencer par le plus simple, en évitant de se lancer tout de suite dans des usines à gaz ou des frameworks trop lourds et trop contraignants.

                Je suis toujours impressionné par cette nouvelle génération de développeurs qui semblent être nés avec un clavier dans les mains et du code dans la tête. Mais je suis également septique sur la suite de telles développements, la pérennité et le côté professionnel, la lisibilité du code (très loin de mes pratiques) et sa maintenance, l'extension à des applications plus conséquentes, la qualité, etc ... Il me semble qu'il y a un monde entre ces "développeurs flash" et mon sujet sur le TDD, et ça ne me rassure pas ...


                Conclusion


                Un très bon moment, des sujets variés et intéressants, globalement pas de perte de temps (comment perdre son temps sur des sujets de 10' ?), des rencontres et discussions sympa : bref, bonne initiative, que je recommande à tout le monde ! Mais attention, nombre de places limitées ... La prochaine sera le mardi 8 janvier avec déjà des sujets intéressants !

                Un grand merci aux intervenants, à toute l'équipe pour ces rencontres, et à Jonathan pour m'avoir incité à participer !

                Bonus vidéo


                Les organisateurs avaient eu la bonne idée de filmer les présentateurs depuis le poste de vidéo-projection, c'est pas le top, mais c'est mieux que rien. Les présentations sont sur le site des Human Talks, voici la mienne, et merci pour vos commentaires que vous pouvez laisser ci-dessous !

                Voir l'article
                Speed Boat pour état des lieux
                03 déc. 2012

                Introduction

                Il y a quelques mois, j'ai réalisé une mission de formation auprès d'une équipe pour l'aider à migrer de développements d'applications autonomes en .Net C#, vers des applications client-serveur avec interfaces WEB. En résumé : formation au développement WEB.

                Lorsque j'ai débuté mon intervention, l'équipe avait déjà commencé à faire de la R&D et à développer, et rencontrait bon nombres de difficultés.

                Je ne connaissais pas du tout cette équipe de 6 personnes, ni leur compétences du moment, ni les difficultés rencontrées, ni les attentes par rapport à mon intervention.

                J'ai donc proposé de commencer par faire un état des lieux, avec l'équipe. Pour cela, j'ai choisi le "Speed boat" qui fait partie des Innovation Games, et qui me semblait tout à fait adapté au besoin. En voici un retour.

                Déroulement de l'atelier

                L'équipe a été séparée en 2 groupes, chacun travaillant dans son coin, sur un tableau papier (paper board), sans voir celui de l'autre équipe.

                Le déroulement pour chaque équipe :

                1. Dessiner un bateau et définir ce qu'il représente (en général, l'équipe)
                2. Dessiner un point d'arrivée pour ce bateau (port, plage) et définir l'objectif qu'il représente
                3. Lister les ancres ou autres freins que l'équipe rencontre pour atteindre cet objectif, en disposant des post-its sous ou près du bateau
                4. Prioriser ces freins : plus les ancres sont profondes, plus elles freinent
                5. Lister les moteurs ou autres éléments qui aident l'équipe à atteindre cet objectif

                Ensuite, nous avons rendu visible chacun des tableaux à l'autre groupe, et j'ai demandé à chaque groupe de présenter et expliquer son travail.

                Après de nombreux échanges, j'ai extrait de ces travaux une liste de points sur lesquels l'équipe avait besoin d'apports, d'aides, de formations, et nous avons procédé à un "dot voting" : chacun vote pour 3 sujets (en mettant un bâton au feutre à côté des post-its).

                Nous en avons alors tiré notre plan de formation prévisionnel pour les semaines à venir, le "backlog" pour mes journées d'intervention : Java, JavaScript, jQuery, quel choix côté serveur (JEE, Spring, Play, ...), HTML-CSS, architecture, etc ...

                Nous avons conclu la matinée par une rétrospective. Les managers nous ont rejoint et j'ai demandé à l'équipe de leur faire une présentation commune du travail de la matinée, en expliquant les "speed boats" réalisés et en insistant sur les points communs et les différences.

                Observations

                Lors de l'atelier, il était intéressant de constater que pour les 2 groupes, le bateau symbolisait "l'équipe", on pouvait s'y attendre. 

                Mais les 2 groupes avaient également choisi des objectifs similaires : proto démontrable,  puis produit de qualité, sexy, professionnel, ... Donc intéressant de constater que les 6 membres de l'équipes sont en phase sur les objectifs à moyens termes.

                Le déroulement de l'atelier proprement dit, et surtout le fait de donner du temps, m'a permis de constater de nombreux échanges entre les personnes présentes. C'était visiblement un nouvel espace d'expressions, d'écoutes et d'échanges, qui leur a permis d'unifier l'équipe sur ces problèmes actuels, ses attentes, ses objectifs.

                La présentation par chaque groupe de son travail à l'autre groupe a également été un moment très riche, les 2 groupes ayant noté des points différents mais complémentaires, d'où l’intérêt d'avoir fait 2 groupes.

                Le debriefing final en présence des managers a permis à ces derniers d'avoir des informations nouvelles et importantes pour eux, globalement sur l'état d'esprit de l'équipe. Mais pour moi, le plus marquant pour les managers se situait dans les "moteurs" exprimés par l'équipe (les points positifs), comme par exemple "travail sur nouvelles technologie", "formation et accompagnement", "volonté de la hiérarchie", etc ... C'est toujours bon à dire et à entendre !

                Enfin, pour moi, cette séance a vraiment répondu à mes attentes car elle m'a permis de faire un état des lieux précis sur la situation. Les ancres et freins nous ont permis d'établir un plan de formation. Et les moteurs m'ont indiqué des points forts de l'équipe, points d'appuis pour mes interventions. Mais cette séance m'a également permis de faire connaissance avec les membres de l'équipe et de favoriser mon intégration pour les journées suivantes.

                Conclusion

                Je connaissais depuis longtemps cet atelier du "Speed boat", je l'avais mieux découvert et pratiqué lors de la formation "Innovation Games" avec Alexandre Boutin et Claude Aubry. Cet atelier permet à une équipe d'exprimer ses freins, ses difficultés, ses forces. Par contre, il est important de très bien préciser ce que représente le bateau, et très important, ce que représente le port ou l’île visé ...
                Voir l'article
                [Maven] Générer un ZIP contenant un autre ZIP
                29 nov. 2012
                Pour changer un peu, un article bien technique pour répondre à un besoin que j'ai rencontré : générer un premier ZIP puis un second contenant le premier ZIP, et éventuellement d'autres fichiers.

                Je partage ici la solution, avec quelques explications, si toutefois ça peut servir à d'autres.

                Point de départ

                Avec le plugin maven-assembly-plugin, je sais générer un ZIP contenant des dépendances (ou des fichiers).

                Il me faut un fichier pom.xml contenant le plugin :
                Et un fichier assembly-final-classic.xml comme par exemple celui-là pour assembler les dépendances (avec le chemin "libs" dans le ZIP) et les fichiers du répertoire "zip-final" :


                Solution avec module

                Une première solution, déjà éprouvée  pourrait consister à créer un module pour générer le premier ZIP, et mettre cet artefact comme dépendance. Le ZIP final contiendrait alors bien le premier ZIP issu du module.

                Pour différentes raisons, je ne pouvais pas trop m'orienter vers cette solution, il me fallait trouver une solution pour faire cette double génération au sein du même projet/module Maven.

                Générer le premier ZIP

                La solution consiste :

                • à ajouter une section <execution>
                • à l'attacher à la phase "prepare-package" pour être sûr qu'elle soit exécutée avant l'autre <execution>
                • à créer un autre assembly.xml pour décrire le contenu de ce premier ZIP
                • à ne pas "attacher" le fichier généré à l'artefact courant Maven (<attach>false</attach>), car on ne peut attacher qu'un seul fichier généré par artefact 
                • à spécifier un répertoire de destination spécifique pour faciliter la suite (<outputDirectory>${project.build.directory}/inter</outputDirectory>)

                Le fichier pom.xml final est alors de la forme :
                Et le fichier assembly-inter.xml peut par exemple assembler des fichiers d'un répertoire "zip-inter" comme ceci :

                Intégrer ce ZIP dans le ZIP final

                Il faut maintenant compléter le fichier "assembly-final.xml" pour y ajouter le (ou les) fichier(s) précédemment générés dans "${project.build.directory}/inter" :
                Et voilà, on obtient un fichier "test-0.0.1-SNAPSHOT-final.zip" qui contient, en autre, le fichier "test-0.0.1-SNAPSHOT-inter.zip".

                Tous les extraits ci-dessus sont là : https://gist.github.com/4164987

                Voir l'article
                [Java] Différences entre == et equals()
                17 nov. 2012
                Suite à une question de Jérôme Avoustin sur Twitter, quelques éléments de réponses ...

                Première approche

                Comme l'a dit Guillaume Lours, pour simplifier, == vaut VRAI si les 2 objets sont les mêmes, et equals() vaut VRAI si les 2 objets ont un contenu équivalent.

                Illustration

                Si je crée une classe User, ainsi que 2 instances de cette classe, le == entre ces 2 objets sera
                FAUX:

                Pour que equals() soit VRAI si les contenus sont les mêmes, je dois implémenter moi-même cette méthode, en y comparant tous les attributs de mon objet. En effet, par défaut, dans Object (la super classe de tous les objets Java), la méthode equals() fait un ==

                Exemple :


                Cas des objets primitifs : String

                En Java, la gestion des objets primitifs (String, Boolean, Integer, Double, ...) est particulière. Ainsi, pour les objets String, Java a une procédure spéciale pour l'instanciation par "", et les instances créées par 2 chaines de caractères identiques (ex : "toto") sont des instances identiques, donc == vaut VRAI. Java gère une sorte de pool d'objets selon leurs contenus.

                Par contre, lors d'une instanciation explicite new String("toto"), l'objet créé est nouveau, spécifique, donc == vaudra FAUX.


                Conclusion

                Toujours bien utiliser equals() et l'implémenter (et le maintenir) pour tous nos objets !
                Voir l'article