The Lean Startup

dans Lectures

J’ai découvert le Lean Startup grâce à une présentation de Nicolas Deverge lors de l’Agile Tour Bordeaux 2014 qui m’a donné envie d’en savoir un peu plus. En effet, Agilité et Lean sont fortement liées et sont porteuses de nombreuses valeurs communes.

The Lean Startup est mon premier livre abordant le thème du Lean et ses nombreuses déclinaisons. Il décrit la méthode Lean Startup ayant pour objectif de concilier vision créatrice de l’entrepreneur et méthode scientifique afin de faire émerger un produit qui sera en accord avec ce qu’attendent réellement les clients potentiels.

Il a été écrit par Eric Ries, entrepreneur et auteur du blog Startup Lessons Learned. Il est le fondateur de la méthode et à l’origine du mouvement Lean Startup que l’on retrouve sur le blog du même nom.

Le livre est un mélange de théorie, de références à la méthode Lean issue des usines Toyota il y a 50 ans, de retours d’expérience d’entrepreneurs qu’Eric a rencontrés et d’un fil rouge : l’émergence de la méthode à travers la société IMVU dont il est le cofondateur.

Le livre est découpé en trois grandes parties : _vision, steer, accelerate permettant de découvrir la méthode Lean Startup pas à pas.
Continuer

Jeudi dernier avait lieu une nouvelle session du Lava JUG : Organisation, Méthode, Devops, Usines logicielles,… avec Dimitri Baeli.

Dimitri a travaillé pendant 3 ans comme responsable qualité chez ExoPlatform, éditeur open source, avant de prendre la tête de l’équipe R&D de LesFurets.com. Il organise aussi plusieurs événements dans le domaine du développement logiciel comme Lean & Kanban France et l’Agile Tour Rouen.

Le sujet de la conférence de Dimitri était de nous présenter la transformation opérée dans l’équipe R&D de LesFurets.com depuis son arrivée en passant d’un cadre d’éditon logicielle Scrum à un mode de gestion par flux.

Sa présentation était articulée en deux parties: pourquoi ce changement et comment y arriver.

Le but de cette transformation était de réduire le temps entre le développement d’une fonctionnalité et sa mise à disponibilité au client (Time to Market).
Avec la gestion de projet en place à l’arrivée de Dimitri, les fonctionnalités étaient délivrées par sprint d’un mois. Les fonctionnalités développées en début de sprint attendaient donc plusieurs semaines avant d’être déployées en production.
L’équipe a donc commencé à se transformer par petites touches pour tendre vers un modèle de déploiement continu et ainsi livrer une fonctionnalité prête au plus tard une journée après son développement.

Pour arriver à cela, Dimitri et son équipe ont fait pas mal de recherches sur des bonnes pratiques et des méthodes à mettre en place telles que le continuous delivry, kanban, lean, etc.
Ils ont aussi modifié leurs outils et le changement leur ayant apporté le plus de valeur ajoutée fut le passage de Subversion à Git. En effet, plus qu’un changement d’outil de gestion de version, cette transition fut pour eux le début d’un changement de philosophie dans leur processus de développement. La facilité qu’apporte Git dans le maniement des branches leur a permis d’en faire une utilisation massive.
Avec Subversion, tout le monde développait dans Trunk et une branche était créée pour la livraison. Ainsi, les deadlines étaient inévitables afin de synchroniser les développements de chacun, avec comme inconvénient que les fonctionnalités non prêtes devaient être désactivées d’une manière ou d’un autre.
En passant à Git, ils ont renversé la situation en faisant de la branche master la branche de livraison et en créant une branche par fonctionnalité à développer, modèle simplifié inspiré du modèle de branches Git de Vincent Driessen. Ainsi chaque fonctionnalité terminée est fusionnée sur master et prête à être livrée. Un job de compilation, l’octopus, permet de s’assurer que toutes les branches fusionnent bien avant de les basculer vers master.

En conclusion, ce que je retiendrai en premier lieu de cette présentation est le temps et les moyens investis par Dimitri et son équipe dans l’amélioration continue de leurs pratiques, qui a vraiment été la clé de leur réussite et que l’on néglige parfois trop souvent !

Merci au Lava JUG et à Dimitri Baeli pour cette agréable soirée !

Commenter et partager


Jeudi dernier avait lieu une nouvelle session du Lava JUG : On the path to Wisdom avec Clément Escoffier.

Clément a travaillé dans plusieurs sociétés à travers le monde et est actuellement chercheur à l’université de Grenoble. Il s’intéresse à tout ce qui peut améliorer l’efficacité du développement ainsi que sa maintenance. Il participe aussi à des projets Open Source tels que Apache Felix (dont il est membre du Project Management Commitee) et iPOJO ainsi que Wisdom, framework dont il est le principal initiateur.

La présentation se déroula en deux parties.

Tout d’abord Clément retraça son parcours professionnel et les principales raisons qui le conduisirent à initier un projet comme Wisdom. Il nous a ainsi évoqué les difficultés qu’il a rencontrées sur son précédent projet avec son équipe pour trouver la bonne technologie (JavaEE, JavaScript, Play, etc). C’est ainsi que l’idée d’un framework modulaire, dynamique, fun à utiliser et complètement orienté services est né. Il nous a ensuite présenté ce qui se cache derrière Wisdom : Java, services OSGi bien empaquetés, Maven, etc.

Ensuite Clément s’est prêté au jeu du live-coding et le moins que l’on puisse dire c’est que l’effet fut bluffant ! L’une des particularités de Wisdom est l’utilisation de Maven en watch-mode. Ainsi Maven scrute les fichiers en cours de développement et lorsqu’il détecte une ou plusieurs modifications, il recompile, redémarre le serveur et redéploie à la volée ! Le développement s’en trouve grandement facilité et le développeur peut rester concentré sur son code sans perdre une bonne partie de son temps en configuration et redéploiement.
La seconde particularité de Wisdom est son aspect ultra-modulaire : tout est service. Ainsi chaque composant peut-être remplacé ou arrêté à chaud, ce qui rend plutôt bien en live-coding. L’exemple pris fut celui d’un e-commerce de coffee-shop (code source dispo ici), sujet qui se prête assez bien pour mettre en avant la découverte de services à travers les fournisseurs de différents types de café.

Wisdom possède aussi une page d’administration, une page de monitoring, une api native de tests de différents niveaux (unitaires, intégration container, intégration blackbox, etc) et tout ça est à découvrir sur le site du projet et sur le GitHub de Clément.

Merci au Lava JUG et à Clément Escoffier pour cette soirée enrichissante et de grande qualité !

Commenter et partager


Après mon premier Agile Tour Bordeaux le week-end dernier, j’étais cette semaine à l’Agile Tour Clermont-Ferrand, mon troisième déjà. Ce fut pour moi encore l’occasion de passer un moment convivial, riche en échanges et apprentissage. Encore merci à l’A-Cube et aux speakers pour l’organisation de cette journée !

Comme l’an dernier, il était organisé dans l’agréable Centre Diocésain de Clermont-Ferrand avec au programme beaucoup de retours d’expérience de speakers locaux. Retour sur les conférences et ateliers auxquels j’ai participé :

Keynote d’ouverture, par Thierry Fraudet
La métaphore de la construction dans le bâtiment est souvent utilisée pour défendre les idées du cycle en V et sert de vivier à arguments contre l’agilité. C’est ce qui est arrivé à Thierry Fraudet au début de la mise en place de l’agilité à grande échelle chez Michelin et il a alors cherché un contre-pied. Et il a trouvé ! Il nous raconte donc une “jolie histoire”, celle d’une construction de bâtiment agile avant l’heure, celle de l’Empire State Building.

Histoire d’une non transformation agile, par Mathieu Lefevre
Mathieu partage avec nous la mise en place de l’agilité au sein de CGI Grand Est dans une présentation de qualité. Il revient sur le paradoxe auquel on est parfois confronté entre volonté de la direction d’aller vers plus d’agilité et difficultés de mise en place sur le terrain.

Agile Game, Design Challenge, par Nicolas Brie et David Rodde
Mon premier atelier de la journée : le Marshmallow Challenge ! Construire à l’aide de spaghettis, de ficelle, de scotch et de ciseaux le plus haut promontoire afin d’avoir le chamallow le plus haut perché !

Le knowledge management dans l’IT, par Maxime Escourbiac
Depuis plusieurs années, le nombre de données collectées sur Internet par Google, Facebook, Twitter et autres est considérable. Mais que faire de toutes ces données et comment en tirer de l’information intéressante ? Grâce aux techniques du knowledge management, et c’est ce que nous a présenté Maxime.

Example Driven Specifications, par Xavier Renaudin
L’ATDD est une technique permettant de concevoir un logiciel à partir d’exemples. Ici, le principe est dans la même veine. Xavier nous présente un protocole permettant d’aboutir à des spécifications à partir d’exemples. Ce fut un exercice intéressant même si il aurait mérité un peu plus de temps.

Agilité à distance, par Jean-David Olekhnovitch
L’agilité peut-elle rimée avec télétravail ? C’est ce que nous montre Jean-David au travers de son entreprise clermontoise Scopika où tous travaillent en télétravail ainsi que sur des exemples plus connus tels que Wordpress ou Basecamp.
Jean-David nous a aussi présenté avec fun les principes de base pour qu’un télétravail fonctionne bien et comment les principes de l’agilité permettent d’assurer la bonne dose de discipline nécessaire au sein de l’équipe.

J’ai peur de l’Agile, par Ionut Mihalcea
Ionut nous présente un essai personnel sur la transformation de nos peurs (de l’agile ou autre) en actions. Pour cela, il s’appuie sur l’histoire du baleinier Essex qui a inspiré Herman Melville pour Moby Dick.
C’est aussi pour assister à des conférences qui sortent des sentiers battus comme celle-ci que j’aime participer à des événements comme l’Agile Tour.

Enlever les petites roues, par Nicolas Gouy
Et si on mettait de côté nos blocages psychologiques, culturels ou autre pour tenter les choses que l’on n’ose plus faire. Cela nécessite de sortir de notre cadre de référence, d’adopter des points de vue différents, des méthodes originales. C’est ce que nous présente Nicolas dans sa conférence à travers deux exemples : l’apprentissage qu’il a fait du dessin et l’apprentissage du vélo par son fils par la méthode de la draisienne, d’où le titre : enlever les petites roues !
Nicolas sait rendre vivantes ses présentations et celle-ci n’échappe pas à la règle, fun et bonne humeur pour prendre un peu de recul sur nos activités de tous les jours et notre façon d’apprendre.

Keynote de clôture, par Antoine Vernois
Seule conférence technique de la journée, on termine en beauté avec un peu de live coding. Antoine nous rappelle avec le kata du bowling game les différentes techniques de tests unitaires et celle qui est certainement la plus efficace, le Test Driven Development.
Chapeau Antoine pour avoir relever le challenge d’un live coding en toute fin de journée et en pleinière !

En marge des conférences et ateliers, une “coaching clinic” avait été mise en place où toute personne ayant un problème dans l’application de l’agilité sur son projet professionnel se voyait accordé 15 minutes avec un coach pour une séance gratuite !

Pour finir, je rappelle que l’A-Cube organise tout l’année des événements autour de l’agilité : Agile Playground, Agile Book Club et autres joyeusetés.

A l’année prochaine pour un nouvel #atclt !

Commenter et partager

Agile Tour Bordeaux 2014

dans Événements

Le week-end dernier avait lieu l’Agile Tour Bordeaux 2014 et j’étais de la partie ! Retour sur ces deux jours très enrichissants.

L’événement était découpé en deux sessions : le vendredi plutôt axé sur les conférences et le samedi sur les ateliers pratiques. Le tout dans un superbe cadre au sein de l’Epitech.

Le vendredi commençait fort avec la keynote d’ouverture en anglais de Gojko Adzic : How to not just survive but thrive with flexible scope ou comment tirer la pleine puissance d’une équipe agile.
Beaucoup de projets adoptent une méthodologie Scrum mais ne l’exploite pas comme ils devraient, dérivant parfois vers un “Water Scrum Fall”. Un projet fait du Water Scrum Fall lorsqu’il n’utilise pas Scrum pour rendre son périmètre fonctionnel malléable. Une des principales forces de l’agilité est de permettre au “business” de changer d’avis à chaque sprint, de rendre prioritaire des fonctionnalités qui ne l’étaient pas ou au contraire de ne plus faire celles qui n’apparaissent plus utiles et ainsi pouvoir s’adapter à son marché qui peut évoluer très vite !
Or peu de projets exploitent cette force, principalement du fait de la réticence du “business”, de sa “peur” à changer ses plans à la volée. Pourtant la puissance de cette adaptation au changement pourrait être utilisée comme un atout formidable, c’est là toute la force de la présentation de Gojko : comment réaliser un GPS pour nos projets logiciels qui nous guide en temps réel vers notre objectif, nous indiquant non pas une seule route (la traditionnelle roadmap) mais bien tous les virages à prendre l’un après l’autre, nous recalculant l’itinéraire quand on rate un virage au lieu de nous laisser faire fausse route en continuant tout droit et bien plus encore.

La deuxième conférence à laquelle j’ai participé est celle de Nicolas Deverge : Une recette du Maker-Entrepreneur : une grosse louche de Lean Startup avec une pincée de FabLab. J’ai découvert à travers le récit de son expérience le Lean Startup et j’ai été séduit par le concept; celui de se lancer dans l’entreprise d’un petit projet avec un budget limité et le plaisir de faire quelque chose soi-même.
Nicolas nous a présenté un de ses projets, qu’il a débuté en fin d’année dernière, à partir d’un problème simple : la perte des clés de moto de son beau-père. Il a ainsi eu l’idée de confectionner un porte-clé mettant en relation celui qui trouve les clés et celui qui les a perdu. En itérant de MVP en MVP, de réussite en échec, et en semant des clés de test dans les rues de Toulouse (!), Nicolas a ainsi pu mesurer la validité de sa solution.
Il a ensuite pu s’appuyer sur un FabLab, un de ces ateliers associatifs où du matériel industriel est mis à disposition en location afin de faciliter l’accès à ces machines par les petits entrepreneurs, pour aboutir à un premier résultat significatif : les Keys Mag.Net.
Je tiens à remercier Nicolas pour m’avoir fait découvrir cette philosophie de travail.

Le samedi ré-attaquait doucement (après une soirée digne de ce nom…) et c’est Christophe Thibaut qui hérita de la lourde responsabilité de nous réveiller. Ce qu’il fit avec talent dans sa conférence : Vingt fois sur le métier.
Dans cette keynote d’ouverture, Christophe nous fait une synthèse de ce qu’il a pu observer lors de ces vingt dernières années dans le monde du développement logiciel. Une observation qui se rapproche fortement de ce que l’on retrouve dans le mouvement Software Craftsmanship, à savoir que l’Agilité apporte de bonnes choses à nos projets, notamment en terme de communication, de collaboration, d’itération, etc… mais que l’on oublie trop souvent l’une de ses valeurs qui est primordiale : l’excellence opérationnelle ou faire du travail de qualité.
Et pour cela, pas de miracle, l’équipe doit passer par de l’apprentissage, de l’entraînement, de la collaboration et surtout doit prendre le temps de faire les choses qui lui paraissent indispensables à la qualité du code et notamment les tests et ainsi éviter la spirale du “On a pas le temps d’écrire des tests, avec tous ces bugs à corriger !”.

Suite à cet agréable réveil, la matinée se poursuivit avec un Coding Dojo en mode cosy animé par Michael Borde. Je connaissais le Coding Dojo mais je ne l’avais jamais pratiqué sous forme de ping-pong TDD.
Les prérequis sont peu nombreux : 1 vidéo projecteur, 1 ordi portable, 2 claviers, 1 petit jeu sympa à développer et des participants enthousiastes.
Le principe est simple :
- les participants choisissent un kata et un binôme s’installent derrière l’ordinateur
- le premier développeur code un peu de plomberie pour mettre en place le jeu et écrit un premier test qui est rouge si tout va bien
- son partenaire prend sa place derrière le clavier et une autre personne complète le binôme
- le développeur au clavier déroule les deux dernières phases du cycle de TDD : faire passer le test au vert et faire un peu de refactoring, accompagné et aidé par toute l’assemblée bien sûr
- il écrit ensuite un nouveau test qui est rouge et on continue comme ça pendant 2h.
J’ai vraiment passé un bon moment et c’est à refaire au plus vite !

Je n’ai pas le temps de détailler toutes les sessions auxquelles j’ai assistées, ni celles auxquelles je n’ai pas assistées, mais elles furent toutes pour moi des moments d’apprentissage et d’échange précieuses. Je citerais entre autres :
- Refactor legacy, même pas peur ! de Rémy Sanlaville et Johan Martinsson qui m’ont fait découvrir les tests temporaires pour refactoring et des outils comme Approvals
- Software Craftsmanship d’Antoine Vernois que j’avais déjà vu à Clermont-Ferrand en 2013
- Qui veux voyager loin ménage sa monture de Guillaume Vincent qui m’a paru être quelqu’un de très à l’écoute aussi bien de son équipe que de ce qui peut l’aider à avance mieux

Je remercie encore une fois les organisateurs de cet événement, leurs sponsors et les speakers qui on fait de cet événement, un moment riche en partage qui fait du bien au moral.

Commenter et partager

User Stories Applied

dans Lectures

Dans la série des “Signature Book” de chez Addison Wesley,“User Stories Applied” est mon troisième livre approuvé par Kent Beck après “ATDD, by example” et “Test-Driven Development, by example”. Il m’a été prêté par un ami, merci Damien pour le prêt longue durée ;)

Il a été écrit par Mike Cohn qui est l’un des membres foundateurs de Agile Alliance et un développeur reconnu par ses pairs. Il est notamment l’un des spécialistes de Scrum, mettant en place cette méthodologie depuis plus de 20 ans et ayant écrit plusieurs livres sur le déploiement de l’agilité dans les projets informatiques.

Comment recueillir efficacement les besoins utilisateurs ? Comment rester au plus proche de ces besoins sans passer des mois à écrire des documents ? Comment différer le recueil de ces besoins au moment le plus opportun ? Comment estimer le travail à faire pour développer ces besoins ?
C’est pour répondre à toutes ces questions et bien d’autres que Mike Cohn nous présente les Users Stories apparues tout d’abord en eXtreme Programming et ayant évoluées depuis pour s’imposer comme l’une des meilleures méthodes de recueil de besoins dans un projet agile.

J’ai apprécié ce livre, assez facile à lire grâce à un découpage en petits paragraphes. A chaque fin de chapitre, on trouve un résumé (ce qui est une bonne idée si l’on veut reparcourir rapidement le livre plus tard pour se rafraîchir les idées) ainsi que des questions, moyen amusant de savoir ce que l’on a retenu de notre lecture.

Le livre est découpé en cinq parties :
    1. Getting started : présentation générale de ce qu’est une User Story et de comment on travaille avec.
    2. Estimating and Plannig : comment estimer une User Story et comment planifier son développement
    3. Frequently Discussed Topics : bonnes pratiques et questions récurrentes sur les User Stories
   4. An Example : exemple avec mise en situation sur une boutique d’articles de pêche et de plongée souhaitant développer son e-commerce.
    5. Appendices : un premier appendice sur l’eXtreme Programming, méthodologie où sont apparues les User Stories et un deuxième contenant les réponses aux questions de fin de chapitre.
Continuer

The Clean Coder

dans Lectures

Dans “Clean Code”, Robert C. Martin nous décrivait les aspects techniques qui caractérisaient selon lui un bon développeur professionnel : un Software Craftsman. Dans “The Clean Coder”, il reprend le même principe mais en l’appliquant aux aspects humains et relationnels pour nous faire partager son guide de conduite d’un développeur professionnel.

J’ai apprécié ce livre car il pousse le concept de développeur professionnel encore plus loin en donnant quelques bonnes pratiques non pas dans les compétences techniques, mais dans son attitude vis-à-vis des autres membres de son environnement de travail (collègue développeur, manager, client, etc); ce qui est tout aussi important !
Ce livre devrait être étudié dans tous cursus de génie logiciel !

Contrairement à “Clean Code“ où d’autres grands noms du développement logiciel avaient prêté leur plume pour écrire quelques chapitres, “The Clean Coder“ est entièrement écrit par Robert C. Martin et ne reflète que son point de vue personnel, ce qu’il répète plusieurs fois tout au long du livre. Il faut donc appréhender cette lecture comme le résumé de son expérience professionnel et l’enseignement qu’il a su en tirer. Au lecteur de piocher ce qui l’intéresse pour s’approcher d’un idéal, en ayant conscience que tout n’est pas toujours atteignable à 100%.

J’ai personnellement repris beaucoup de ses pratiques (“Savoir dire non” notamment) mais j’en ai aussi laissé de côté car trop éloignées de notre philosophie européenne pour être applicables :) Ce livre m’a fait beaucoup évoluer dans mon attitude professionnel et vis-à-vis de mon travail, je le recommande vivement !
Continuer

J’étais mardi soir au 3ème Agile Playground organisé par l’A-Cube. Le principe est simple : partager les valeurs de l’agilité grâce aux jeux. Les jeux ont une puissance insoupçonnée pour communiquer, échanger et faire partager des points de vue différents. Plusieurs activités peuvent être réalisées au cours d’une session : jouer à un jeu connu, découvrir un nouveau jeu ou bien même créer un jeu !

Nous étions une petite dizaine de participants et nous avons commencé la soirée par jouer. C’était mon premier playground et j’ai donc découvert le delegation poker. Le but du jeu est de faire prendre conscience aux participants du niveau de délégation dont doit faire preuve un manager et quel niveau de responsabilité peut accepter une équipe de travail auto-organisée que l’on retrouve dans beaucoup de méthodes agiles.
Pour cela, chaque joueur dispose de 7 cartes représentant chacune un niveau de délégation, de 1 (chef décidant seul sans consulter l’équipe) à 7 (équipe décidant seule sans présence du manager). L’animateur du jeu énonce un cas (ex: en tant que manager, je décide seul du recrutement d’un nouvel équipier) et chaque participant retourne la carte qui lui semble la plus appropriée.
S’en suit un échange pour connaître les avis de chacun et la raison de leur choix, puis un deuxième tour de jeu (comme au planning poker) pour voir si les avis peuvent converger.
J’ai bien aimé ce jeu qui permet selon les profils des participants (manager, responsable équipe, développeur, etc) de mettre en évidence les différences de jugement et surtout d’échanger autour de ces différences pour que chacun puisse relativiser un peu. Il me semble tout à fait approprié pour désamorcer les tensions qui peuvent apparaître dans un projet.

Après le delegation poker, place à la créativité. Nous avons essayé de créer un jeu en rapport avec des difficultés que l’on peut rencontrer dans notre quotidien professionnel. Un tour de table de chaque participant a permis de lister les idées de chacun et un vote a permis de choisir lequel serait le thème du jeu.
Puis brainstorming autour du thème pour trouver un support (dessin, cartes, organisation des personnes dans l’espace, …) et les règles. Je n’en dirais pas plus, rendez-vous au prochain agile playground en juillet pour découvrir peut-être ce jeu dans sa version finalisée !

J’ai passé une super soirée avec des personnes très sympas. Merci à l’A-Cube pour l’organisation de ces soirées et aux participants pour leur bonne humeur !

Vivement la prochaine !

Commenter et partager


Jeudi dernier avait lieu la 6ème session de l’année du Lava JUG : Développeur front-end en milieu hostile présenté par Julien Muetton. Julien un passioné de développement web qui pratique l’amélioration continue. Il est donc venu nous présenter ses bonnes pratiques, ses outils préférés et sa vision du métier. Il est, entre autres, vice-président de Clermont’ech et président de ClermontJS.

Julien a commencé sa présentation en détaillant ce qu’il appelle un “milieu hostile”. Le développement web a ceci de particulier qu’il possède un vaste environnement hétérogène. Il existe plusieurs navigateurs(IE, Firefox, Chrome, …), une multitudes de “devices”(ordinateurs, tablettes, mobiles) aux tailles d’écran variées, un niveau de sécurité important à injecter dans les applications et une couche réseau à la qualité difficilement prévisible (Fibre, ADSL, 4G, 3G, Edge, …). Julien nous a donné quelques astuces et bonnes pratiques pour appréhender ces contraintes.

Julien a enchaîné avec l’éco-système du développeur web en nous donnant à chaque fois son avis sur la qualité et l’utilisation qu’il fait de chaque outil.

En voici quelques uns :
    - Chaîne de build et “watchers” : Yeoman, Grunt, Broccoli, Gulp, Brunch
    - Package : npm, bowser
    - Versionning : Git
    - Test unitaires
        -Assertions : Chai, should, NodeJS assert
        - Runners : Mocha, Jasmine
        - Mock : Sinon.JS
        - Cross browser runner (test à travers plusieurs navigateurs) : Karma, Yeti
    - Tests fonctionnels
        - CasperJS
        - Selenium et Selenium as service (Sauce Labs, BrowserStack)
        - Régression visuelle : Phantom CSS, Viff
    - Maven, Graddle et surtout l’utilisation de scripts (install, start, stop, tests, release) enchaînés dans un Jenkins.

C’était une bonne présentation ! Moi qui ne suit pas familier avec le développement web, j’ai appris beaucoup de choses et je suis reparti avec pas mal de pistes pour m’y mettre. Le seul point négatif selon moi est l’absence d’une partie démo en live des outils comme l’avait fait Sébastien Douche dans sa présentation; ça passait dans le créneau et ça aurait pu être utile à ceux qui ne les connaissent pas.

Merci Julien !

Prochaine session du Lava JUG, le 19 Juin avec Alexis Moussine-Pouchkine pour une présentation Java dans le Cloud.

Commenter et partager


Kent Beck est un développeur reconnu par ses pairs. Il fait parti des signataires du manifeste Agile et est le fondateur de l’eXtreme Programming qui met en avant des valeurs telles que le courage, le retour sur développement (feedback) et amène de nouvelles méthodes de travail telles que le pair-programming et le développement piloté par les tests (test-driven development).

C’est justement cette dernière technique qui est détaillée dans ce livre. Je l’ai trouvé très bien écrit; il se lit vite du fait de chapitres courts, voire très courts (2 pages pour le chapitre 7), et du style fluide de Kent Beck. L’enchaînement de chapitres courts donnent envie de ne pas s’arrêter, surtout quand ils décrivent une histoire comme c’est le cas pour la première partie qui est un exemple, avec code, du développement d’un système monétaire.
La deuxième partie m’a moins convaincu. Elle est plus difficile à lire et le développement d’un framework de test en Python ne m’a pas emballé.
Enfin la dernière partie est un vrai guide pour mettre en place un développement piloté par les tests. Il fournit beaucoup de trucs et astuces, explique la philosophie qui fait le succès de cette méthode et surtout Kent Beck nous dévoile un peu sa vision du développement logiciel.

Je ne vais pas m’attarder sur les deux premières parties qui sont des déroulements d’exemples concrets mais plutôt reprendre en détail la troisième partie : Patterns for Test-Driven Development.
Continuer
Copyrights © 2016 Pierre PIRONIN. All Rights Reserved.

Pierre PIRONIN

J’ai créé ce blog pour parler de ce qui se passe autour de moi dans le domaine du génie logiciel.
J’exposerai mes devs, mes idées, mes lectures, les faits qui m’intéressent et les événements auxquels je participe.

Bonne lecture !


Artisan développeur


Auvergne, France