DevFest 2019 !

Le DevFest s’impose petit à petit comme la conférence technique majeure des Hauts-de-France. Organisé par le Google Developer Group (GDG) Lille, c’est une journée où se succèdent des talks sur différents thèmes : cloud, développement mobile, web, …

De notre côté, c’était une participation un peu plus active que d’habitude, car Salto Consulting était sponsor bronze de l’événement. Il s’agit d’une aide financière en échange d’une visiblité du logo de l’entreprise sur les visuels, de la com’ sur les réseaux sociaux et la possibilité de fournir un goodie dans le sac offert à chaque participant. Chose faite :

Lunettes Salto Consulting

Le Kinepolis de Lomme était le décor pour cette année. On peut y voir sans doute le signe que l’événement prend de l’ampleur et que le nombre de participants est en constante augmentation. En tout cas, il est vraiment très appréciable de suivre des sessions confortablement installé dans un fauteuil de cinéma. Et on peut imaginer la joie ressentie par le speaker lorsqu’on voit ses slides projetés sur un magnifique écran géant ! Jugez un peu :

Slides sur écran de cinéma

A 9h15 commence la keynote d’ouverture. Pierre Ziemniak nous raconte l’historique des séries françaises depuis la création de la télévision. On y découvre quelques pépites oubliées, notamment un extrait de la série « Commando Spatial », datant de 1967 et faisant référence à Star Trek. C’était une keynote sympa pour lancer la journée.

Voici le résumé de quelques conférences auxquelles nous avons pu assister.

 Des microservices aux migroservices

Beaucoup de monde dans la salle pour cette session par François Teychené. Quoi ? Un talk sur les microservices en 2019 ?
François revient dans un premier temps sur les inconvénients liés aux monolithes : livraisons lentes, scalabilité difficile, complexité d’évolution.
Les gains attendus des microservices : évoluer plus vite, faciliter la scalabilité. MAIS la complexité est toujours là notamment à cause des interactions entre les services sur le réseau… non en fait, c’est encore plus complexe qu’avant !

François nous donne alors la définition du migroservice : c’est quand on essaie de faire une architecture microservice sans avoir prévu l’outillage nécessaire. Additionné à la démarche DevOps, le nombre d’outils qui peuvent entrer en jeu est impressionnant : Traefik, Consul, Vault, Kubernetes, Kafka, RabbitMQ, AWS, GCP, Docker…

On revient sur la notion de bounded context et le fait qu’il faut définir correctement les limites des microservices ! Le découpage des services doit être métier et non technique, et surtout il doit suivre les cas d’utilisation (ventes, catalogue…) plutôt que les entités (client, produit). Tiens tiens, on a déjà évoqué ces sujets ici-même à propos de l’architecture modulaire 😉

Enfin François insiste sur l’importance d’automatiser toutes les tâches afférentes aux microservices (déploiement…). En bref une bonne conférence qui fait écho aux problématiques d’architecture distribuée que nous rencontrons tous les jours.

 Kubernetes – Pimp my laptop

Sébastien Nahelou est aux commandes pour ce talk visant à améliorer la productivité à propos de l’utilisation de Kubernetes. Ce n’était clairement pas un sujet pour débutants : nous avons parcouru beaucoup de choses en 45 minutes. Pour commencer, voici en vrac les outils évoqués :

  • kubectl-aliases : série d’alias pour la ligne de commande
  • kube-PS1 pour bash et zsh : permet d’afficher le cluster et namespace courants dans le terminal
  • kubectx et kubens pour switcher rapidement de cluster et de namespace
  • k9s : interface dans le terminal pour manager les clusters Kubernetes
  • tubekit facilite certaines tâches courantes, comme récupérer le nom d’un pod sans devoir « copier-coller »
  • kube-score analyse le yaml et donne des indications de bonnes pratiques
  • kubesec effectue des vérifications de sécurité des ressources d’un cluster kubernetes
  • kubetail aggrège et affiche les logs de plusieurs pods simultanément
  • helm-unittest : sorte de tests unitaires sur les charts Helm
  • kubectl explain (commande standard) permet de récupérer la documentation et le format du yaml dans le terminal

Au niveau des bonnes pratiques quand on écrit la configuration Kubernetes, Sébastien nous encourage à utliser les options kubectl –dry-run -o yaml : en effet cela permet de récupérer un ficher yaml propre sans devoir l’écrire à la main… beaucoup sont allergiques à ce format et c’est vraiment une astuce à suivre !

Sébastien nous fait ensuite une démo en mettant en application les astuces données.
On découvre alors l’outil Telepresence. Celui-ci permet de substituer un service déployé sur un cluster distant par un service local… en d’autres termes, le poste de développeur peut prendre la place d’un élément du cluster déployé afin de faciliter le développement et le débug. ça a l’air hyper utile et aurait mérité davantage de temps.

Enfin (!) Squash permet de débugger dans son IDE une application déployée sur Kubernetes. Ici aussi l’outil fait forte impression.

Vous l’aurez compris avec ce résumé, c’était un talk très rapide avec énormément de tips & tricks concrets autour de Kubernetes. Il fallait suivre mais c’était très enrichissant.

Cela montre également que l’écosystème autour de Kubernetes n’est pas très mature. On a besoin de beaucoup d’outils pour pouvoir travailler efficacement.

 Doom, gloom or loom

Rémi Forax était là pour nous parler du projet Loom ! Intéressant d’écouter un contributeur à différents projets autour du JDK (et accessoirement Java champion). On commence par les différences entre du code impératif et réactif avec des exemples en Spring. Le souci du code réactif étant la difficulté à débugger le code, les traces étant illisibles.

Le projet Loom introduit l’objet Continuation qui permet des arrêts / redémarrages dans du code impératif. Plusieurs Continuation peuvent tourner au sein d’un même thread mais pas en parallèle.

Rémi nous montre l’utilisation du mot clé async en Kotlin et ses limites, notamment par le fait qu’on doit déclarer explicitement les fonctions qui peuvent être bloquées avec le mot clé suspend. Et cela a tendance à créer deux mondes distincts. Rémi fait le parallèle avec les exceptions en Java, où les exceptions de type checked sont délaissées car contraignantes.

Autre objet introduit par loom : Fiber. C’est un objet similaire au Thread. La différence majeure est que quand il est suspendu, l’état du fiber est enregistré dans la JVM, et peut être repris plus tard. Par rapport aux threads traditionnels, on réserve beaucoup moins de mémoire car seules les choses utilisées sont stockées dans le heap quand l’exécution est suspendue.

Le projet Loom n est pas encore finalisé et il sera officiellement dans Java en… on ne sait pas !

Un talk très sympa, bien touffu pour ne pas s’endormir après la pause déjeuner 🙂

Il faut sauver le soldat Jenkins

Nicolas De Loof nous parle de Jenkins X. Ce n’est pas « juste » un jenkins sur kubernetes. Ce n’est pas non plus un jenkins amélioré ou visant à remplacer l’original.

Jenkins X is not...

Jenkins X est un outil opinionated ce qui signifie qu’il fait des choses automatiquement quand on fait les choses « comme tout le monde ».

Explication du Terme GitOps : Git est la seule source de vérité, que ce soit pour le code, l’infrastructure ou le déploiement. On va par exemple avoir un repository pour versionner les templates de déploiements Helm pour Kubernetes, les push sur ce repository sont analysés par un pipeline jenkins X et sont exécutés.

Nicolas nous fait ensuite une petite démo. Jenkins X s’installe sur un cluster Kubernetes. Pour sa démo il utilise l’outil en ligne de commande jx.

jx create quickstart : initialise un projet « hello-world » dans le langage/framework de notre choix. Jenkins X utilise ensuite le mécanisme de buildpack : par rapport à notre stack technique, l’ensemble des fichiers nécessaires à un déploiement par Docker sur Kubernetes sont initialisés (Dockerfile, templates helm…)
Quand on soumet une Pull Request sur GitHub, l’outil déploie automatiquement la version correspondante de l’application.

Contrairement à un Jenkins traditionnel, Jenkins X est plutôt fait pour être administré par la ligne de commande. On comprend avec la démo que Jenkins X est en effet très orienté : il permet d’aller très vite dans un cadre précis, mais on se pose la question de son utilisation si on veut déployer d’une façon spécifique.

A voir, je pense qu’il faut vraiment l’essayer pour se faire une idée. Il peut sans doute faire gagner beaucoup de temps à condition de ne pas faire des choses exotiques.

 Micronaut, le framework JVM ultra-light du futur

Olivier Revial nous présente ce framework que l’on a déjà évoqué sur notre blog.
Micronaut a pour but de prendre le « bon » des frameworks existants, tels que Spring, tout en s’afranchissant des contraintes de lourdeur.

Olivier nous affiche une démo de la création d’une application Micronaut avec la ligne de commande. Avec une configuration très légère on peut facilement interagir avec une base MongoDb en mode réactif, exposer un endpoint HTTP. Les métriques sont exposées simplement via la configuration.

Enfin on évoque GraalVM pour compiler des images en mode natif. La compilation est beaucoup plus longue, plusieurs minutes, mais l’application démarre en 30ms!

Olivier conclut sur le faut que Micronaut est un framework jeune, mais dont l’adoption est croissante. La faible consommation mémoire peut aider à aller vers le serverless.

De notre côté, on aime beaucoup ce framework. Mais entre les améliorations constantes apportées à Spring notamment sur les performances, et Quarkus qui est supporté par RedHat et va plus loin dans sur le concept « Java natif », il a du travail pour conserver une place de choix dans cet écosystème.

 De Java à un exécutable natif : GraalVM et Quarkus changent la donne

Emmanuel Bernard et Guillaume Smet sont sur scène pour nous parler du gros buzz du moment dans le monde Java : Quarkus. La philosophie de Quarkus est de cibler les applications cloud native, déployées sur le cloud.

On rentre tout de suite dans le vif du sujet avec une application web. Emmanuel lance l’application en mode dev qui permet de rafraîchir le code à chaud, sans devoir redémarrer. Ce mode apporte une vraie plus-value car c’est super rapide, on ne se rend pas compte du rechargement en arrière-plan.

On voit ensuite le système d’extensions qui permet d’ajouter des composants à notre application (connexion à la base, parser JSON…) via la ligne de commande.

Sur les développements d’API HTTP, l’interface swagger-ui est activée par défaut en mode développement avec l’extension OpenAPI, très pratique pour tester rapidement son API HTTP.

Au niveau de la Developer Experience, on est assez proche d’un Spring Boot mais plus conforme aux standards JEE (par exemple, notons l’utilisation de Jax-RS pour définir les routes HTTP plutôt que des annotations spécifiques).

Emmanuel fait un apparté sur Java et les containers : Java date des années 1990 où les programmes étaient généralement lancés sur un seul serveur, dans un seul process. Avec l’explosion du cloud, les ressources consommées par les applications deviennent critiques.
Attention à la confusion souvent faite : en Java, la RAM consommée n’est pas du tout équivalente à la taille max du heap (la fameuse option -Xmx). En réalité le resident set size (RSS) est très élevé sur les applications JEE/Spring y compris quand le heap est petit.

RSS size in Java

Du coup, l’accent est mis sur la consommation mémoire et le temps de démarrage de Quarkus en mode « natif », avec GraalVM. Les chiffres donnés sont plutôt impressionnants !

Guillaume évoque alors plus en détail GraalVM et son fonctionnement. La compilation en mode « natif » élimine les classes non utilisées. Comme on utilise très peu du code embarqué par les librairies, cela permet d’économiser énormément de mémoire.

La démo est assez impressionnante. Nous sommes de notre côté déjà convaincus que Quarkus est un outil incroyable et tout développeur Java devrait s’y intéresser.

Comment la GCP m’a permis de sauver ma prod chez Mamie

Sylvain Nieuwlandt commence par nous démontrer comment basculer son infrastructure vers GCP pour… gagner de l’argent.

Ensuite on voit comment débugger en live une application déployée sur GCP grâce à Stackdriver. Avec quelques modifications dans les fichiers de propriétés, et avec les fichiers de code déployés sur GCP, il est possible par exemple d’injecter du log à chaud en production.

Suit ensuite une démo de l’application modbile « Cloud console ». C’est une application Android/iOS qui permet de se connecter à la plateforme GCP. Bien sûr on n’a pas accès à tous les services comme sur l’interface web, mais un shell est disponible. Ici Sylvain nous montre comment redéployer des machines virtuelles en production depuis son téléphone.

Cette conférence était assez fun et enrichissante sur certaines possibilités de Stackdriver notamment.

 En conclusion

Le DevFest devient un événement incontournable et ce n’est pas par hasard. L’organisation est très bien huilée, et malgré le nombre grandissant de participants cela reste d’une grande fluidité. Voici une photo de l’espace principal au cours de la journée pour rendre compte de la foule (photo de Damien Cavaillès) :

du monde au devfest...

Du côté des conférences, c’est très varié et de qualité. Le fun est également présent avec la keynote de clôture à la sauce Burger Quizz.
Un grand bravo aux organisateurs pour leur travail !

On reviendra avec plaisir en 2020 !

Rencontrez-nous : les événements IT de l’été 2016 à Lille

Venez nous rencontrer durant cet été 2016, nous serons présents sur différents événements IT :

1er Juin: Tour de France Digitale @Euratechnologies

2 Juin: Atlassian Tour @Euratechnologies

3 Juin: Euratech Days @BlancheMaille

5&6 Juillet: Summer Days @Euratechnologies

Et d’autres événements à venir…

Lille_Euratechnologies_small

France Digitale

Le Tour de France digitale, c’est le rendez-vous des futures startups de la frenchtech ! Les meilleures startups ont besoin des meilleurs développeurs, nous venons à leur rencontre ce 1er juin à Euratechnologies ! Inscrivez-vous, c’est gratuit : https://www.eventbrite.fr/e/billets-tour-de-france-digitale-a-lille-1-juin-23985354842

 

Atlassian Tour

Jeudi 2 Juin se tiendra le rendez-vous français des débutants, experts, et tous ceux qui souhaitent découvrir JIRA et ses outils (Confluence, Bitbucket…) Nous mettons régulièrement en place JIRA pour nos clients PME et grands groupes, nous serons donc présents pour discuter de vos questions et vos projets autour des produits Atlassian.

 

Euratech Days

Les EuratechDays auront lieu à BlancheMaille (Roubaix) vendredi 3 Juinhttp://www.eventbrite.fr/e/billets-euratechdays-blanchemaille-25168155631

Découvrez l’histoire et l’écosystèmes de BlancheMaille et de ses startups !

 

Euratech Days Summer

Les 5&6 Juillet à Euratechnologies : plus d’informations à venir !

 

 

Retour sur la soirée GitHub au ChtiJUG du 9 décembre 2015

Ce Mercredi 9 décembre à l’Université Lille 1 à Villeneuve d’Ascq se tenait un Ch’ti JUG qui avait pour thème : Comment GitHub build GitHub.GitHub

Alain Helaili (@AlainHelaili) travaille chez GitHub et nous a présenté l’entreprise et montré en partie quelle était leur façon de travailler et les outils qu’ils utilisent.

Il a commencé par nous apprendre l’histoire originale de l’entreprise : des associés en Californie qui voulaient développer une super idée. Pour améliorer leurs conditions de travail, il ont créé une application autour du gestionnaire de source git. Puis ils l’ont partagé, jusqu’au jour où une entreprise a voulu l’utiliser. Il a donc fallu créer la société : GitHub, pour pouvoir vendre et trouver un prix. A ce moment là, DropBox proposait du stockage pour 7$/mois… le prix était trouvé.

Le contexte aussi est intéressant : les associés, même à coté, discutent par chat. Et le leitmotiv est que tout doit avoir une URL pour exister. Ainsi le travail est plus facilement collaboratif et asynchrone : pratique quand on travail sur plusieurs « time zone », surtout quand on sait que l’entreprise de près de 500 salariés est répartie un peu partout dans le monde ! Par ailleurs, l’une des valeurs fondamentales de GitHub est que tout soit le plus simple possible, quitte à omettre des fonctionnalités ou les retravailler jusqu’à ce que l’utilisation en devienne une évidence.

Alain nous a ensuite montré comment fonctionnait l’organisation du développement dans la société. Notamment via l’utilisation des issues et pull request. Ce qui transparaît le plus était pour moi :

  • L’absence d’e-mail au profit de création d’issue ou pull request afin de rendre visible les décisions et qu’elles soient de fait toujours documentées.
  • L’outillage devops notamment avec hubot le robot avec qui on discute par chat et qui se charge de déployer en production, faire des opérations de maintenance etc.
  • Le workflow de développement qui contient les phases classique de TU, TI, TNR etc et qui se termine par un test… en production, plutôt que d’imaginer des scénarios de montées en charge qui resteront toujours éloignés de la réalité. La phase finale consiste à déployer en production pendant un laps de temps défini, d’en mesurer les impacts puis de retirer la fonctionnalité le temps de valider qu’il n’y ait pas eu de mauvais impact. Et ce n’est qu’une fois cette validation en production faite que le développement est mis sur la branche principale : master. Ainsi la branche master ne correspond pas forcément à ce qu’il y a actuellement en production, mais elle est le socle de base, fiable pour la production.

Enfin l’application GitHub nous a été aussi présenté comme hautement personnalisable via les hooks et les nombreuses apis disponibles. On a notamment cité :

  • Review Ninja : la gestion des pull request par SAP
  • Gitcolony : également sur les pull request avec notamment la possibilité de les gérer cross-repos
  • Zenhub : qui permet de visualiser les évolutions en cours sous la forme d’un kanban
  • et plus globalement tous les addons disponibles avec GitHub

N’hésitez pas à consulter leur blog http://githubengineering.com pour en découvrir plus encore.

Le seul point négatif à mon sens de cette conférence était la salle dont l’écran était un peu petit et le micro qui coupait de temps en temps. Par contre on peut souligner le super accueil des étudiants de Lille 1 !

Merci à Alain, à l’équipe du Ch’ti JUG (enfin surtout Cyril cette fois-ci ;)) et aux étudiants de Lille 1 !

Matthieu Fernandes

Global day of code retreat

Ce samedi 14 novembre, à l’initiative de Jérémie et de l’association Nord Agile, se déroulait dans nos locaux l’édition Lilloise du Global day of code retreat.

Le GDCR est une journée mondiale durant laquelle des développeurs se réunissent pour améliorer ensemble leurs skills.
Cette année, plus de 140 événements ont été organisés à travers le monde : http://globalday.coderetreat.org/timeline-2015.html

Pourquoi un Code Retreat ?

Beaucoup de développeurs, pendant leurs études ou durant leur vie professionnelle, apprennent des langages de programmation / frameworks / outils.
Mais il n’y a pas ou peu de choses pour apprendre pas à bien coder. Combien de personnes ont déjà suivi une formation « Améliorer la qualité / maintenabilité de son code » ? Pourtant cela coûte cher ! (1)

Le principe du code retreat, c’est justement d’essayer de lever la tête, sortir de son quotidien pour travailler ça.

Comment ça fonctionne ?

Tout au long de la journée, des binômes travaillent par sessions de 45 minutes sur l’implémentation d’un jeu : Le Jeu de la vie.
A l’issue de la session, on efface le code et une rétrospective est menée pour partager les expériences et trouvailles de chacun.
Puis changement de binôme et on recommence avec des contraintes différentes : interdiction de parler, mode ping-pong, pas le droit d’utiliser de « IF », …

Quels enseignements ?

Certains seront sceptiques quant à l’apport réel d’une telle journée et pourtant… sortir de sa zone de confort, ça incite sacrément à la remise en question et à l’ouverture d’esprit !

Code Retreat en action !

Code Retreat en action !

Cette journée, c’est comme vivre plein de petites revues de code en accéléré, avec une mise en pratique immédiate.
Changer de binôme tout le temps permet aussi de découvrir d’autres langages de développement, IDE, méthodes de travail.

Pour aller plus loin : software craftmanship

KPI : 100% de gens satisfaits !

(1) http://www.nist.gov/director/planning/upload/report02-3.pdf – The Economic Impacts of Inadequate Infrastructure for Software Testing

Agile Tour Lille 2015 (Partie 2/2)

Retour sur la 1ère partie…

Suite de l’article : Agile Tour Lille 2015, partie 2

Pour rappel, voici les conférences que j’ai suivies cette année :

  1. Des lean startups dans l’administration !? – par Pierre Pezziardi
  2. Si le TDD est mort, alors pratiquons une autopsie – Par Bruno Boucard et Thomas Pierrain
  3. Construire plus vite en apprenant plus vite – Retour d’expérience du Monde.fr – Par Ismaël Héry
  4. Ratez vos revues de code en 5 leçons ! – Par Michel Domenjoud
  5. L’estimation, un formidable outil de discussion, même pour les projets #NoEstimates – Par Sébastien Delest
  6. Le Kanban expliqué par Bison futé – Par Cyrille Deruel
  7. Alliés contre les défauts – pourquoi et comment nous relisons ensemble le code que nous produisons – Par Julien Jakubowski et Antoine Blancke
  8. Intégration continue, DevOps et après ? – Par Laurent Tardif

5. L’estimation, un formidable outil de discussion, même pour les projets #NoEstimates – Par Sébastien Delest

Sebastien Delest est venu nous présenter le mouvement #NoEstimates. Aujourd’hui, nous avons besoin d’estimer pour décider et gérer un projet, une équipe. La difficulté est qu’estimer l’imprévu peut s’avérer.. complexe. On utilise généralement le coté reproductible des choses pour avoir une idée du temps nécessaire. Seulement on ne fait pas tout le temps la même chose, qui plus est dans le même contexte. Par ailleurs on a souvent tendance à être trop optimiste.

Sébastien nous propose donc d’éviter l’estimation, ou au moins de minimiser son importance. Pour cela il nous propose quelques alternatives :

  • On ne peut se fier à une estimation pour des décisions importantes. Il vaut mieux prendre des décisions mineures et pouvoir changer d’orientation, s’adapter.
  • Il faut garder le point de vue sur la vision, l’objectif est d’utiliser le maximum de feedbacks sur des cycles courts pour prioriser les besoins.
  • Engager moins d’argent et donc moins de temps, en faisant un point d’avancement chaque semaine, par exemple, pour savoir si on continue ou si on prend la bonne direction.

Toutefois, l’estimation a également des vertus : elle permet par exemple via le planning poker de discuter du besoin et de partager la vision de celui-ci. Et donc de mieux le comprendre et soulever les premières inconnues. Il en est de même pour la rédaction des User Stories et des Scénarios BDD qui permettent de décomposer le besoin et encore une fois d’avoir une meilleure vision des détails. Sur ces points, l’orateur insiste sur l’intérêt d’avoir des interlocuteurs variés afin d’augmenter les points de vue et d’enrichir les échanges.

On peut également se poser la question de la valeur ajoutée d’une demande. Générerait-elle plus de chiffre ? Est-ce nécessaire pour améliorer la maintenabilité et donc mieux supporter les évolutions à venir ou simplement la qualité du support ? Pour cela, on peut utiliser une Story-map qui permet de prioriser les fonctionnalités par valeur ajoutée et/ou effort nécessaire.

Comme toujours il n’y a pas de solution miracle, mais des bonnes pratiques peuvent limiter les impacts. Ainsi si un client change d’avis et souhaite revenir en arrière, faire des cycles courts et avoir un retour au plus vite permet de réduire les pertes. De même, dans le cas d’engagement au forfait, il vaut mieux privilégier la confiance et s’engager sur l’effort plutôt que sur le contenu.

Dans tous les cas, le travail d’estimation doit être pris comme une opportunité d’échanges sur le besoin et les priorités plutôt que comme une simple opération comptable.

6. Le Kanban expliqué par Bison futé – Par Cyrille Deruel

Voilà une présentation très dynamique et diablement pertinente ! Cyrille est Delivery Manager chez Octo, il ne travaille aucunement pour bison futé, en revanche il a eu une soudaine conviction un jour de bouchons sur la route des vacances. Il a remarqué de nombreuse similitudes entre la gestion du trafic routier et celle ses projets informatiques. Voilà l’origine de sa présentation.

Cyrille nous propose donc d’améliorer les 5 pratiques de notre kanban en appliquant les solutions correspondantes à ce que fait Bison Futé pour mieux gérer le trafic routier.

1. Visualiser le flux de travail

Pour éviter la frustration des clients engendrée par le manque de vision des délais, on peut indiquer sur le kanban une estimation du temps restant avant la mise en production d’une fonctionnalité, comme le fait Bison Futé avec ses panneaux à affichage variable estimant le temps restant pour atteindre une destination. Ce n’est pas un engagement, on ne peut prévoir l’imprévu. Par contre on peut supposer au vu du rythme actuel que si la fonctionnalité est en phase de test par exemple, il lui reste X jours pour arriver en production.

De même on peut préciser le nombre de personnes travaillant actuellement sur tel ou tel pan applicatif. Ainsi on a conscience qu’un sujet dans un domaine avancera plus ou moins vite en fonction de l’énergie actuellement allouée sur ce domaine.

2. Limiter le WIP (Work In Progress)

C’est un classique, le multi-tâches c’est le mal, et accumuler un ensemble de tâches en cours est le meilleur moyen de se noyer. C’est là qu’intervient le WIP. Pour respecter ce nombre de tâches pouvant être traitées en parallèle, on bloque ce nombre. Comme un feu rouge devant une autoroute, vous êtes ainsi certain que la route sera fluide et optimale. De manière plus radicale, on peut imaginer une circulation alternée. Si les Product Owners ne sont pas en mesure de prioriser les tâches, on peut les choisir aléatoirement. C’est à éviter autant que possible, mais ça débloque le problème. Un concept intéressant est également celui de la fourrière. Si chaque jour une tâche n’avance par car un élément externe est bloquant, on peut mettre cette tâche en fourrière, ne plus s’en préoccuper et ainsi libérer l’équipe d’un point sur lequel elle ne peut rien faire.

3. (Mesurer et) gérer le flux

Concernant le trafic routier, il y a plusieurs options : on peut réserver une voie au taxi pour qu’il puisse aller plus vite en cas de bouchon, ponctuellement utiliser une voie d’arrêt d’urgence pour augmenter le flux ou encore limiter la vitesse globale pour augmenter la vitesse de croisière. (Réduire la vitesse de 10km/h sur le périphérique parisien à augmenté de 18% la vitesse moyenne !)

Pour notre kanban, comme pour le reste d’ailleurs, le meilleur moyen de décider est d’abord de mesurer. Il faut régulièrement s’adapter et expérimenter. Tester une nouvelle manière de gérer, et si au bout d’un mois le résultat n’est pas concluant, on refait comme avant. Par ailleurs, en période de congés, quand une partie de l’équipe est absente, on absorbe forcément moins d’activité que si tout le monde était présent.

4. Rendre explicites les règles des processus

Il est essentiel de définir les règles à suivre, de réaliser des checklists pour vérifier que l’on s’y tienne et de les adapter au fil du temps et notamment de l’expérience. Ainsi en cas de problème, on peut en identifier les causes et faire évoluer le process pour ne plus reproduire l’erreur. La checklist permet d’éviter les habitudes qui trop vite nous font oublier certains points et donc reproduire des erreurs.

Ici aussi en mesurant la « quantité de problèmes »qu’on a sur les différents sujets, on est plus à même d’identifier et corriger le problème en amont.

5. S’améliorer collaborativement

Il faut dés le début avoir conscience et prendre en compte les contraintes externes. Un éco-pont a permis d’éviter des accidents avec des sangliers sur la route. Vérifier que le ciblage de nos utilisateurs est compatible avec le règlement de la CNIL évite de s’en rendre compte une fois en production. Il faut aussi, comme le télépéage, automatiser tout ce qui peut l’être, comme le déploiement sur un environnement de tests, par exemple.

Cyrille ajoute à cela l’importance d’avoir une bonne salle de pause et des événements en dehors du travail. Cela améliore la qualité des échanges et simplifie la communication.

Il faut aussi prendre conscience que le changement peut prendre du temps : 40 ans après le lancement de la ceinture de sécurité, 21% des tués dans les accidents de la route ne la portaient pas…

Je vous invite à parcourir les slides qui sont assez évocateurs :

 

 

7. Alliés contre les défauts – pourquoi et comment nous relisons ensemble le code que nous produisons ? – Par Julien Jakubowski et Antoine Blancke

Voila une nouvelle présentation sur la revue de code, plutôt orientée sur le retour d’expérience des équipes au Web Center d’Axa.

Julien et Antoine commencent par nous expliquer qu’au début, la revue de code était plutôt faite par un expert dans l’équipe et parfois en pair-programming. Cependant le résultat était peu concluant car le retour d’expérience était peu diffusé et l’expert avait trop de code à relire. Ils ont donc opté pour une revue de code faite par l’ensemble de l’équipe. De premier abord, cela semble particulièrement coûteux, à raison de 3 réunion d’une heure par semaine pour tout le monde d’un coup. Dans les faits, le coût est de 5% du budget de développement du projet.

Il y a deux choses qui permettent d’accepter ce coût :

  • La première est d’optimiser au maximum l’efficacité de la revue de code. Pour cela, il ont établi des rôles qu’il est impératif de respecter : un time-keeper, un modérateur, un scribe, 3 lecteurs et bien sur l’auteur initial du code qui explique ce qu’il a produit. Chaque rôle permet d’équilibrer la réunion et de s’assurer de son efficacité.
  • La deuxième chose est de relativiser ce coût par rapport au autre coût d’un projet. Des statistiques donnent un R.O.I de 4 pour 1 (4h de debug pour 1h de revue) avec un budget dédié à la correction de bugs au départ de 43% du budget du projet. Pour finalement descendre à 5% du budget lorsque la revue de code est utilisée.

D’autres avantages de la revue de code sont aussi la communication autour du code, la mise en place d’une propriété collective du code qui devient donc plus facile à maintenir, et enfin la facilité d’apprentissage pour les nouveaux arrivants qui intègrent plus facilement les standards et la compréhension du projet.

S’il est difficile au début de faire des revues de code, par peur de montrer son code ou de faire des remarques peu pertinentes, ou simplement par la pression du projet. Avec du travail, notamment sur la communication : ne pas critiquer le code mais faire référence au standard, reformuler ses phrases pour ne pas accuser (tu …) mais plutôt partir d’une hypothèse (je pense que …). Et le respect des rôles (time-keeper, modérateur), la pratique de la revue de code s’avère très efficace et améliore notablement la communication, même avant les revues !

En conclusion, s’ils ne devaient garder qu’une chose sur leurs gestions de projet, ils garderaient la revue de code !

Les slides de la présentation sont disponibles ici :

 

8. Intégration continue, DevOps et après ? – Par Laurent Tardif

« Prédire » l’avenir est difficile : En 1994 par exemple, le rapport Thery ne croyait pas en l’avenir d’internet… Toutefois Laurent commence par présenter un chiffre intéressant : d’après une étude Gartner, en 2016 Devops va passer d’un marché de niche à une réelle stratégie pour 25% des entreprises. Le ton est donné.

Ensuite, il réalise un rapide état des lieux de ce qui existe : l’émergence des principes sur l’agilité, les outils d’intégration continue qui permettent déjà de rapprocher le développement des tests. Tout cela permet d’améliorer la qualité du code, sa robustesse et son processus de livraison.

Ensuite nous voyons une définition de ce qu’est DevOps – la fusion du dev, des tests, et des ops :

  • D’un point de vue technique, c’est principalement de l’automatisation, des processus de tests, de la livraison, etc.
  • D’un point de vue du business, c’est une approche qui croit en l’expérimentation, à l’échec rapide, au produit viable minimal et une décision prise sur des chiffres.

Puis on passe en revue rapidement pléthore de domaines couverts par devops ainsi que les principaux outils associés :

On constate à nouveau qu’il est très important de mesurer, via du monitoring, la gestion du feedback utilisateur. C’est là clé pour prendre les bonnes décisions.

Puis Laurent fait un rapide bilan de ce que l’on a aujourd’hui : un forte tendance vers les produits Open Source, les clouds privés et/ou publics, les technologies autour des containers (Docker) et micro-services, et enfin le machine learning, aujourd’hui avec Mahout et Spark et demain certainement avec Flint.

On apprend que les solutions de cloud privé sont en recul, notamment du fait de leur coût et leur complexité, au contraire de l’IoT et la sécurité qui sont en forte croissance. Un nouveau courant cherche à décentraliser les puissances de calcul pour les apporter jusque dans les téléphones mobiles (via des containers). Cela permettrait d’amoindrir les coûts et d’améliorer le service, par exemple en cas de coupure réseau.

Enfin comme piste de réflexion pour le buffet de clôture, Laurent imagine qu’après l’association des Devs et des Ops, la prochaine génération associera les Devs et le Marketing.

Les slides de la présentation sont disponibles ici :

Tout cela n’aurait pas eu lieu sans l’association Nord Agile et de leurs sponsors, un grand merci à eux !

Et bien sûr merci à Salto Consulting de m’avoir permis de participer à cette journée !

Par Matthieu Fernandes

Agile Tour Lille 2015 (Partie 1/2)

Ce 15 octobre 2015 avait lieu la 8ème édition de l’Agile Tour Lille. C’était une excellente journée riche en retours d’expériences, approches différentes et comme toujours lors de ce type d’événement, en rencontres enrichissantes.

Cette année, l’Agile Tour Lille comptait 400 inscrits et 120 personnes en liste d’attente ! Et effectivement, on se sentait parfois un peu à l’étroit dans les salles jusqu’à suivre une conférence assis par terre 😉 Concernant l’accueil j’ai adoré l’idée du badge de la conférence qui contient un plan des lieux et le planning de la journée : c’était juste parfait.

La journée a commencé sur les chapeaux de roues, avec 30 secondes et un slide par speaker pour présenter leur conférence. Et le choix ne fut pas simple !

Pour ma part j’ai suivi les conférences suivantes :

  1. Des lean startups dans l’administration !? – par Pierre Pezziardi
  2. Si le TDD est mort, alors pratiquons une autopsie – Par Bruno Boucard et Thomas Pierrain
  3. Construire plus vite en apprenant plus vite – Retour d’expérience du Monde.fr – Par Ismaël Héry
  4. Ratez vos revues de code en 5 leçons ! – Par Michel Domenjoud
  5. L’estimation, un formidable outil de discussion, même pour les projets #NoEstimate – Par Sébastien Delest
  6. Le Kanban expliqué par Bison futé – Par Cyrille Deruel
  7. Alliés contre les défauts – pourquoi et comment nous relisons ensemble le code que nous produisons – Par Julien Jakubowski et Antoine Blancke
  8. Intégration continue, DevOps et après ? – Par Laurent Tardif

Je vous propose d’en extraire ici quelques idées.

1. Des lean startups dans l’administration !? – par Pierre Pezziardi

Pierre nous parle de son expérience et de ce qu’il réalise en lean management pour le Secrétariat Général à la Modernisation de l’Action Publique.

Il évoque les difficultés de travailler avec les systèmes environnant particulièrement lourds et complexes de l’administration. Il nous révèle une technique redoutable pour estimer la charge d’un projet : systématiquement, c’est 6 mois pour 4 personnes, avec un objectif précis en tête (exemple : un taxi en un clic !)

Pierre évoque aussi la difficulté d’être innovant dans une organisation fortement ancrée dans des procédures dont la relative efficacité est éprouvée depuis des années. Être disruptif avec les procédures habituelles, c’est comme proposer une interface web pour remplir un formulaire Cerfa, ça fonctionne, mais l’efficacité n’est pas là.

Il indique également qu’une petite équipe de 50 personnes ne peut pas bouleverser une structure de 4000 personnes du jour au lendemain. Il faut gagner la confiance, convaincre et propager une nouvelle culture de travail.

Pour être plus efficace, il propose de s’isoler au maximum des processus existants, quitte à garder des tâches manuelles. En effet, si une nouvelle fonctionnalité est utilisée une centaine de fois par jour et demande une action manuelle du côté administratif, au moins dans un premier temps, ça peut être acceptable et permet d’avoir la fonctionnalité en production très tôt.

Pour ouvrir l’Agile Tour, cette conférence était a point nommé, un véritable retour d’expérience sur l’efficacité de l’agilité là ou l’on ne l’attendait pas : dans l’administration. Et Pierre est toujours très pertinent avec des propos souvent si évidents qu’on aurait trop tendance à les oublier. Par exemple, le chef : c’est l’usager !

2. Si le TDD est mort, alors pratiquons une autopsie – Par Bruno Boucard et Thomas Pierrain

Bruno et Thomas tiennent à souligner le fait que le TDD ne se résume pas au classic Red-Green-Refactor. Ce n’est que la partie visible de l’iceberg.

Tout d’abord un petit rappel de RGR :

  • Red : on écrit le test sur un code mort => il est en échec : rouge
  • Green : on implémente le minimum pour que le test passe : vert
  • Refactor : on améliore

… puis on recommence.

Voilà pour la partie visible, d’ailleurs je me permets toute de suite une petite note personnelle :

Toute personne qui s’est déjà essayé au TDD vous le dira : au début commencer par écrire un test, c’est compliqué car ce n’est pas dans nos habitudes. Quand on a une idée que l’on veut implémenter, on le fait et on a une idée relativement précise de ce que l’on doit faire. Dans notre métier les choses se présentent un petit peu différemment : il s’agit d’implémenter ce que quelqu’un d’autre a en tête ! Et parfois même plusieurs personnes… Finalement, se poser la question de savoir ce qui m’est demandé, avant même de savoir comment y répondre parait beaucoup plus légitime. Voilà ce qu’apporte le TDD dans un premier temps : s’assurer que nous répondons à la bonne question ! A condition bien sûr, de trouver la question…

Mais revenons donc à la conférence. Thomas et Bruno font remarquer que voir sa liste de test validée fait partie des satisfactions de la journée. Le fait d’écrire un premier test devient quelque chose de simple et un vrai coup d’épaule pour démarrer. Une lutte efficace contre la procrastination. Ils insistent également sur la nécessité de s’entraîner en rappelant la théorie des 10000 heures de Anders Ericsson. Il évoque par exemple les codes kata, et les coderetreats. D’ailleurs à ce sujet le prochain Global Day of Code Retreat (CRTGD) à lieu chez Salto le 14 novembre!

Enfin quelques idées sont soulevées :

  • Commencer par les tests c’est difficile, il n’y a pas de design émergeant. En effet commencer par les tests impose de s’imprégner de son sujet, d’en discuter avec les différents interlocuteurs pour bien décomposer les choses. La technique du « should » est mise en avant, il s’agit de parler de comportement, pas d’une API.
  • Il ne suffit pas d’écrire beaucoup de tests. Au contraire, trop de tests rendent la maintenance difficile. Il ne s’agit pas de tester des méthodes, mais des « gestes métier ». Il faut donc rester haut niveau. C’est la couverture de test qui importe, pas la quantité.
  • TDD est-il vraiment efficace ? Oui ! par essence même, on ne test que ce qui est demandé et on écrit alors le minimum de code qui répond au besoin. Pas de sur-conception ou d’hypothèse hors spécification. On rappelle ici les bases : YAGNI (you ain’t gonna need it) et KISS (keep it simple stupid).

Une méthode intéressante est celle de la double boucle qui consiste à faire une première boucle avec un test d’acceptance contenant lui-même plusieurs boucles de tests unitaires.

Les auteurs rappellent également la nécessité pour le développeur de connaître des design patterns et d’avoir des notions d’architecture.

En résumé, si vous ne faites pas encore du TDD, il est temps ! Et si vous avez abandonné : parfait, il est temps se s’y remettre sérieusement !

3. Construire plus vite en apprenant plus vite – Retour d’expérience du Monde.fr – Par Ismaël Héry

Ismaël Héry nous fait part de son expérience au Monde.fr. Il nous rappelle le petit miracle que représente la publication d’un journal tous les matins, et le bouleversement actuel entre la presse écrite qui décroit indéniablement et la presse numérique qui monte mais avec des profits inférieurs. Dans ce contexte compliqué, il faut avancer et s’améliorer pour rester dans la course. La spécificité des médias est aussi l’approche du délai. Lorsqu’il y a une élection présidentielle ou tout autre événement, si une application dédiée est prévue il faut qu’elle soit livré à l’heure, pas au jour ou à la semaine… Dans un tel contexte on peut comprendre que les éventuelles pénalité de retards soient infinies !

Avec de telles contraintes, il faut savoir être rapide et prendre de l’avance. Cela implique de travailler sur des technologies nouvelles, non éprouvées et pose donc certaines questions :

  • Quel temps est nécessaire à l’apprentissage ?
  • Les tests sont ils automatisables ?
  • Comment se comporte cette technologie en cas de montée en charge ?

Pour pouvoir répondre à ces questions il n’y a qu’une option, il faut mesurer et avoir un retour au plus tôt. Cela implique :

  • Expérimenter : le meilleur moyen de savoir si une solution peut répondre au besoin reste tout simplement de l’essayer.
  • Mesurer : mettre en place au plus tôt un monitoring de la solution, intégrer des bêta testeurs et en prendre soin. Ce sont eux qui vous diront si la solution est pertinente. Il faut savoir trouver des personnes bienveillantes qui seront indulgentes et d’autres plus « pointilleuses » qui vous feront beaucoup de retour.
  • Mettre en production ! : c’est ce qui apporte le plus de retour. Techniquement, au plus tôt on met en production, au plus tôt on aborde les différentes difficultés liées aux technologies choisies. De même, cela permet d’obtenir plus vite des retours utilisateurs et de décider si on doit continuer ou pas sur cette voie.

Ismaël insiste sur l’importance des avis utilisateurs. Jusqu’à mettre en place des « fakes » qui ne feraient que récupérer l’avis des utilisateurs. Il explique également qu’il faut prendre une bonne dose d’empathie. Souvent ce que l’on pense compliqué pour l’utilisateur passera sans soucis alors qu’une fonctionnalité qui semblait anodine peut paraître laborieuse par l’utilisateur final.

En conclusion, pour apprendre vite, il faut tester au plus vite en production tous en mesurant : monitoring, analytics, retours d’utilisateurs. La vie d’un projet est faite d’un graphe de micro-décisions qui se dessine dans le temps. Le conseil d’Ismaël pour faire ces choix : « En cas de doute, choisissons le chemin de l’apprentissage maximum ». Il faut créer dans l’équipe « un sain sentiment d’urgence et d’engagement » qui force à garder un rythme soutenu et soutenable plutôt que de compter sur le coup de fouet donné à l’approche de la date de livraison. Urgence qui conduit trop facilement à des échecs.

Une citation d’Ismaël est particulièrement explicite : « Si vous sortez et que vous n’avez pas de bug, c’est que vous êtes sorti trop tard. »

4. Ratez vos revues de code en 5 leçons ! – Par Michel Domenjoud

Michel Domenjoud disposait de 20 minutes pour nous faire part de son expérience sur les revues de code. Tout d’abord, il souligne qu’une équipe utilisant la revue de code sera plus confiante sur la fiabilité de l’application en production, contrairement à une équipe qui n’applique pas de revue de code et qui craindra de modifier certains pans complexes d’une application. Personnellement je tiens le même discours au sujet des tests unitaires.

Puis Michel nous rappelle quelques chiffres sur la revue de code :

  • 65% des bugs sont ainsi détecté au plus tôt
  • un ROI de 4/1 à savoir 4 heures de debug pour une heure de revue de code

Voici quelques conseils :

  • Il faut choisir le format de revue de code approprié à l’équipe et à la situation et l’appliquer à un rythme soutenable. Relire 2000 lignes de code la veille d’une mise en production, ce n’est pas soutenable. Par contre faire en pair-programming un algorithme complexe qui demande autant de ligne de code me parait plus sûr.
  • L’auteur du code doit lui-même appliquer les modifications décidées en code-review. Ça implique de progresser et d’éviter le dictât d’un développeur qui diffuserait la bonne parole…
  • Il faut échanger sur les pratiques, mettre en place des standards commun. Chaque équipe possède ses exigences et affinités, elle doit définir ce qui lui convient.
  • Egoless programming : le code se partage, il évolue avec toute l’équipe et n’est donc pas la propriété d’une personne.
  • Ce n’est pas le moment de « troller », en pause café en revanche…
  • Prendre une décision collective implique que chacun fasse des compromis. Ainsi tout le monde progressera.

Enfin Michel nous invite à utiliser les différents formats de revue de code (pair-programming, revue par un pair, revue collective). Chacune a ses avantages, et toutes sont complémentaires.

Vous trouverez les slides de sa présentation sur :
http://fr.slideshare.net/mdomenjoud/agile-tour-lille-2015-ratez-vos-revues-de-code

Et pour aller plus loin ses articles sur le blog d’Octo : http://blog.octo.com/author/mdo/

Fin de la partie 1 (à suivre…)

Par Matthieu Fernandes

 

Global Day Of Code Retreat @ Salto – 14 Novembre 2015

Code Retreat

Code Retreat

Le Global Day of Code Retreat, c’est une journée durant laquelle des développeurs se retrouvent aux 4 coins du monde pour coder ensemble et améliorer leurs pratiques de développement. Toutes les technologies sont concernées.

Salto Consulting est heureux d’accueillir dans ses locaux l’édition 2015 de l’étape Lilloise, qui aura lieu le 14 Novembre prochain.

Participation gratuite : http://www.eventbrite.fr/e/billets-global-day-of-coderetreat-2015-19135942118

Rendez-vous à partir de 9h00 dans nos locaux au 23 rue du Chemin de Fer, 59800 Roubaix.

Munissez-vous de votre PC et votre IDE préféré. Un plateau repas est prévu le midi.

Contactez-nous pour + d’informations.

La nouvelle offre JIRA dans le détail

Jira-agile-logo DEVIENT

Jira-Software-logo

Comme énoncé dans l’article « La nouvelle offre JIRA » de notre Salto Consulting, Atlassian propose à partir du 12 Octobre une restructuration de son offre.

Elle se décompose en 3 applications dont les fonctionnalités sont listées dans le tableau qui suit :

Jira-functions

 

Quelles sont les nouveautés qu’apporte JIRA Software ?

Au niveau du produit :
Pour l’utilisation en « Cloud », vous en avez certainement déjà constaté certaines.

  • Un enrichissement des templates

jira-project-template

  • de nouveaux workflow pré-configurés

jira-business-workflow

  • Une vision « Version » (Release) plus intégrée à partir des tableaux SCRUM

jira-release-view

  • Une navigation plus fluide (Le menu à gauche devient le point central de la navigation)

jira-left-menu

  • Des écrans « Demande » qui vont à l’essentiel

jira-open-issue

Au niveau de l’administration :

  • Une simplification dans la navigation

jira-admin-page

  • Une gestion des droits d’accès des utilisateurs (groupes) par application

jira-user-access

 

Du côté pricing :
Atlassian nous promet une baisse du coût d’abonnement ou d’acquisition des licences ainsi qu’un mixage d’utilisation des produits (limitation de certains utilisateurs au core permettant d’économiser une utilisation Jira Software).

La road Map :
On y est :

jira-road-map

Les événements IT dans la région en Septembre / Octobre

Les équipes de Salto seront présentes sur 3 événements de la région ces prochaines semaines, l’occasion de vous présenter ces rendez-vous :

– Ch’ti Jug AngularJS2 – 29 Septembre 2015 – 18h30 @Tourcoing – La Plaine Images

AngularJS2

Découvrez les nouveautés et percez les secrets de AngularJS2, la nouvelle version du framework Javascript Open-source de Google.

 

 

– Rencontres IG2Iennes – 1er Octobre 2015 – 09h00 @Lens – Ecole IG2I

ig2i

Chaque année, c’est l’événement de la branche informatique et industrielle de Centrale Lille : IG2I. Ouvert à tous, vous pouvez y rencontrez élèves, enseignants et entreprises partenaires.

 

 

– Agile Tour Lille – 15 Octobre 2015 – 09h @ Lille – Euratechnologies

Agile Tour Lille

14.000 participants dans 80 villes, voici l’objectif à battre pour cette version 2015 de l’Agile Tour ! Ouvert à tous ceux intéressés de près ou de loin par l’agilité : Scrum Masters, Product Owners, développeurs, DSI, Chefs de projet… rendez-vous à l’étape Lilloise !

Agenda events, venez nous rencontrer ! Agile Tour, Graphday, Rencontres IG2Iennes…

L’agenda est chargé ces prochaines semaines, AngularJS 2, Bases Graphes, Agilité… il y en a pour tous les goûts !

GraphDay Neo4J @Paris – 29 Septembre : Venez à la découverte des bases de données orientées graphes.

Chti Jug AngularJS 2 @Lille – 29 Septembre : Nouveautés du framework AngularJS 2.

Rencontres IG2Iennes @Lens – 1er Octobre : La journée de rencontre entre les étudiants d’IG2I et les entreprises de la région.

Agile Tour Lille @Lille – 15 Octobre : Le rendez-vous annuel de l’agilité dans le Nord !