Xavier NOPRE

• Dans ce screencast, je montre 2 implémentations possibles pour l'API fluent que j'aimerai avoir sur ma classe. A noter que la première solution a d'autres inconvénients, notamment en usage multi-thread, ou si on veut partager la même instance à plusieurs endroits dans le code (et notamment si on utilise une librairie d'injection de dépendances). 
• A noter également qu'il y a d'autres implémentations possibles que la 2e solution présentée, tout dépend du contexte et des besoins fonctionnels

La théorie

Quelques constats

• Remplacer sa base SQL par une base No-SQL 
• Changer le langage de son backend
• Remplacer son framework de Front par un autre, par exemple Angular par ReactJs
• etc...

Mon approche : réalisme & pragmatisme

1. La brique pourra être facilement remplacée, à moindre cout, et sans trop d'impact sur le reste de l'architecture, du produit, des utilisateurs, et de l'équipe
2. La brique pourra ou pourrait être remplacée, avec un cout non négligeable, et peut-être des impacts sur le reste, donc à gérer
3. La brique ne pourra objectivement pas être remplacée, ou alors avec un cout très important (= ré-écriture d'une partie de l'application), probablement des impacts et risques sur le produit

Backend : niveau 2

Front : niveau 3

Base de donnée : niveau 2

Build du Front : niveau 1

Tests unitaires du Front : niveau 2

Micro-service : niveau 1

Conclusions

• Même s'il est en partie illusoire, gardez en tête le 1er principe qui permet de faire de meilleurs choix
• Repoussez les choix au maximum, attendez d'en avoir l'usage et donc une meilleure visibilité sur les contraintes et vos besoins réels
• Posez-vous la question du "ticket d'entrée" pour tel ou tel choix, quel cout pour l'équipe pour la mise en place et la montée en compétence
• Découpez correctement votre architecture à tous les niveaux : backend / front / micro-services, mais également au sein de votre code pour isoler les codes liés aux frameworks choisis, et ainsi limiter l'impact d'un éventuellement changement
• Pour les choix de niveaux 2 et 3, prenez le temps de bien estimer vos besoins et les réponses à ces besoins par telle ou telle solution, en imaginant ne plus jamais pouvoir en changer

• Le format sur 3 jours, et surtout, la disparition des journées "Université" (mercredi) et "Forum ouvert" (vendredi)
• Les mots de certains sponsors qui, probablement, pour faire différemment et se faire remarquer (?) font, à mon goût, n'importe quoi... :-(
• Et quelques autres bricoles...

• La keynote de Aurélien MORVANT : "Etes vous prêt pour le grand saut ?" avec de bonnes réflexions autour du changement, du droit au changement, des réticences, etc...
• La keynote de Stéphane BIGEARD : "Succès - Echec : Ce que je regarde se développe" qui m'a fortement interpellé par son approche par la valorisation des points forts (en tant que parents, managers, équipiers, ...)
• La "Sensibilisation au Software Craftsmanshift" de Nastasia Saby 
• L'excellent session "Bug Free, By Design" de Johan Martinsson, toujours aussi enrichissant avec une salle plus que pleine !
• Les soirées (propices aux ateliers et jeux) même si j'ai zappé la première 
• Les Shifumis ("Pierre-papier-ciseaux") géants vu d'en haut
• Rater plein de sessions pour discuter avec des copains ou de nouvelles connaissances
• Et plein d'autres choses !...

Historique

L'idée

Le sujet

Objectif(s)

Quelques biais

Déroulement

Itération 1 : les premiers pas

• 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"

Itération 2 : pression

Pause déjeuner : plaisir

Itération 3 : pression toujours...

Itération 4 : on s'éclate !

Itération 5 : encore du plaisir !

Conclusion sur l'atelier

• 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
• ...

• 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... ;-)

Conclusion sur mon Agile Grenoble 2015

Contexte

Les besoins, les contraintes et les concessions

• 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

Solution initiale : des pages statiques

Solution finale : AngularJS

Pas besoin de serveur d'application

    
        
    ...

    
    
    
    

    
    
    
    
    
    
        
    ...

    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    
    
    
    
    

    

        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

Le module 'Proto'

'use strict';

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

'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

        ...

        

    $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'
        })
        ...
});

'use strict';

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

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

Données pour chaque écran

    $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'];

            
                {{mois}}
            
            
                {{annee}}
            

    $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."
            ]
        },{
        ...

    ...
    

    ...
    

    ...

    ...
    

    ...

Introduction

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

Innover ou pas ? 

Une erreur : l'innovation par certains !

Une autre erreur : la validation par tous !

Conclusion

Introduction

• Scrum Master
• Product Owner
• Equipier

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

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

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

• 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 …

Conclusion

C’est quoi ? Quel est l’objectif ?

Mise en œuvre

• 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

Pièges ou erreurs 

Conclusion

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é :

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
• Dans son Quicky de 15', Arnaud Bétrémieux m'a convaincu de l'intérêt de git-deliver que je vais rapidement regarder et probablement adopter !
• 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 ...

Introduction

La Genèse 

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

Rôles 

On voit / On ne voit pas ...

• 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

• 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

Déroulement

Logistique

Démarrage

Redécoupage

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

Multi-tâches (multi-histoires) ?

Itération 1 : Aïe !

Itération 2 : Yeah !

Itération 3 : oups !

Synthèse

Conclusion

Introduction

La session

Objectifs

Public visé

La question du jour 

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 là)
• 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 :

Introduction

Evolution du développeur : chef de projet !?

Je suis développeur et ça me passionne !

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

Je suis manager

Je suis recruteur

Je suis client

Conclusion

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

Salle bien remplie : cool ! (Photo Etienne PERRA)

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

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

"Software Craftsmanship" - Antoine Vernois - @avernois

• 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 ... ;-)

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

Conclusion

"Comment faire avec une énorme base de code sans test ? N'en écrire que pour les bug fixes et nouvelles features ?"

Le mieux ...

Une première approche

Truc : éviter le statique ! 

Ensuite ...

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

Conclusion

Keynote "La horde agile" par Pablo Pernot

"BDD appliqué" par Benoit Gantaume

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

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

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

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

Conclusion