Publié par
Il y a 2 mois · 12 minutes · Agile, Craft

Codeurs en seine 2016, dans l’oeil du craftsman et de l’agiliste

Codeurs en seine est une conférence (gratuite) ayant lieu tous les ans en novembre, à l’université de Rouen. Cette année, la conférence fêtait ses 10 ans !

 

Retours des amphis pour une agiliste du craft

Tout au long de la journée du jeudi, 4 amphis étaient proposés en parallèle, soit au final pas loin de 20 talks différents tout au long de la journée ! C’est pourquoi j’ai décidé d’orienter ma journée autour d’un angle : l’agile et le craftsmanship.

Qui a volé l’orange?

Par Frédéric Leguédois (1h)

Comment la recherche du blâme conduit à la perte d’innovation dans l’entreprise.

L’un des points les plus difficiles à interpréter du Manifeste Agile est certainement : « La collaboration avec les clients plus que la négociation contractuelle ». Les interprétations de ce point sont en effet assez variables :

  • certains agilistes le traduisent par « être souple par rapport aux contrats légaux signés avec le client »,
  • d’autres y voient plutôt une redite du point du manifeste « Les individus et leurs interactions plus que les processus et les outils ».

Alors que le message original est plutôt de « ne pas chercher à punir ceux qui se trompent, chercher plutôt des solutions. »

Le problème est que face à une erreur, lorsque l’on cherche un coupable : nous cherchons alors à appliquer une sanction (réelle ou symbolique), plutôt qu’à trouver une solution.

Cela aboutit à des effets délétères : les accusés accusent d’autres personnes à leur tour, créant des conflits et des tensions qui tendent à faire oublier le problème original. Cela entraîne une ambiance de culpabilisation, qui amène à la dissimulation et au mensonge. Ce climat général aboutira à une perte de confiance au sein de l’équipe d’une part, puis entre l’équipe et le manageur d’autre part, qui mettra en place des reportings, coûteux en énergie et en temps.

Un autre effet de bord de la recherche des coupables, c’est que, à terme, cela revient à féliciter les personnes qui ne se trompent jamais. Soit celles qui, bien souvent, sont les personnes qui ne prennent pas d’initiative, ou alors qui tendent à fuir leurs responsabilités.

Comment éviter la recherche de coupables, au détriment de la recherche de solutions ?

  • Exprimer clairement qu’on est dans la recherche de solutions, pas de coupables.
  • Le management et la hiérarchie doivent jouer le jeu (ne pas chercher de coupable non plus)
  • …mais le manager doit donner l’exemple : à savoir admettre quand il se trompe lui-même.
  • L’important étant de ne jamais accuser les autres, même sur les points importants, mais de toujours être transparent sur ses propres erreurs.
  • La prise d’initiative doit être autonome : les développeurs doivent avoir suffisamment de marge de manœuvre pour tenter des choses sans en avoir à demander l’autorisation à leur manageur.
  • Face a une erreur, même importante, insistez sur la recherche d’une solution, et s’y tenir, ne partez pas sur la recherche d’un coupable.

Ces préconisations permettent au final de favoriser l’initiative. Il est important de favoriser toutes les prises d’initiative, même si toutes n’aboutissent pas et certaines échouent, afin de pouvoir conserver ce climat d’initiative.

Lao-Tseu, Software-Craftsman

par Gautier Mechling (1h) (slides)

Cette présentation se base sur comment la pensée de Lao Tseu, sage Chinois du milieu du VIe siècle, illustre les préconisations des mouvements craftsmanship et agiliste, notamment dans son livre Tao Tö King, « livre de la voie et de la vertu ».

Gautier Mechling fait ainsi le lien entre la parole de Lao et des sujets plus modernes tels que le mentoring, la gestion du code légacy, les principes SOLID, les pratiques agiles, la gestion de la dette technique, le crash monitoring et la conteneurisation.

 

Petit guide de survie dans la complexité d’un projet Web

par Bastien Jaillot

Comment éviter les crises au quotidien au sein de votre équipe grâce à l’agilité.

Dans la pratique, la mise en place des bonnes pratiques et préconisations n’est pas toujours aisée au sein de la vie d’une équipe.

A commencer par la dette technique. En théorie, tout le monde est d’accord sur la définition : un emprunt fait à la qualité du code. Mais à la différence d’un emprunt fait à une banque, il est ici largement aisé de dépasser son seuil de paiement, au risque de rendre l’application in-maintenable.

En fait, la dette technique, c’est plus une accumulation de code sédimentaire, « auquel personne ne touche », de fonctionnalités qui n’auraient jamais du apparaître et d’économies à court terme.

Mais comment prédire cette apparition ? Par la prévention : évitez (ou dé-priorisez) les fonctionnalités inutiles : elles n’aboutiront qu’à salir le code, démotiver l’équipe et engendrer une surcharge de travail et un effet tunnel. Il faut être capable de dire non à son client (ou la version polie « pas maintenant »).

Concernant la prise de décision au sein d’une équipe, il est conseillé d’avoir le moins d’intervenants possible entre l’équipe décisionnelle et les techniciens.

Fonctionner en itération permet également d’avoir une meilleure tolérance aux échecs.

Un petit pas pour le développeur, un grand pas pour la qualité

par Christophe Hermann (15 min)

Comment faire de la qualité rapide et productive ?

L’un des problèmes de nos jours, est que l’on a tendance à tout vouloir : du code de qualité, rapide, et pour pas cher.

Or, dans la pratique, il faut choisir:

 

 

Bien souvent, la priorité sera mise sur de faibles coûts. Et ensuite sur la rapidité. Pourtant, au fond, les manageurs souhaitent également du code de qualité. Ils veulent juste que cette qualité soit rapide et pas chère.

Voici une liste exhaustive des solutions:

  • une couverture de tests efficaces permet une qualité pour pas cher : en effet une erreur coûtera toujours moins si elle est détectée par les tests que par la recette, une régression coûtera toujours moins si elle est détectée par les tests que sur la prod.
  • Industrialisez les tâches qui peuvent l’être afin d’augmenter la qualité et éviter les erreurs humaines (tests, processus de build, de release)
    • …Mais ne tombez pas dans le piège de la sur-industrialisation (typiquement, si votre automatisme est peu-utilisé ou doit être mis à jour à chaque utilisation)
    • Utilisez des checklists afin de documenter tous les processus qui ne peuvent être industrialisés.
  • Ecrivez un squelette « propre » d’application, que vous réutiliserez à chaque nouvelle création
    • … avec en place un environnement de tests, des metrics, un README sur les éventuelles opérations à faire pour intégrer le projet dans le process (par exemple, ajouter le projet dans l’outil d’intégration continue)
    • …avec les dépendances et technologies préconisées ( par exemple, tous vos projets utiliseront spring-boot 1.2.3 et hibernate 3.4.5)
    • avec des exemples de configuration
    • Pensez à mettre à jour ce squelette régulièrement.
  • Rédiger des conventions de nommage, de structure, d’architecture, de syntaxe, etc.
    • … et faites-les accepter par toute votre équipe

Enfin, souvenez-vous que votre prochain projet ne doit pas être parfait, il doit juste être mieux que le précédent.

15 ans de qualité Web : stop ou encore ?

par Élie Sloïm, (30 min)(15 ans de qualité Web : stop ou encore ?)

Comment en est-on venu, dans l’univers flamboyant du développement logiciel, à parler de qualité ?

Au début des années 2000, personne ne faisait de la qualité dans le domaine de l’informatique. Les opportunités de croissance semblaient infinies, le but était de faire du chiffre. Puis la bulle a explosé. Le marché est devenu plus restreint, les clients plus difficiles à séduire, à maintenir. Et seules les entreprises centrées sur la qualité sont parvenues à perdurer.

C’est pour cela qu’Elie Sloïm nous présente OPQUAST, un ensemble de checklist universel des bonnes pratiques de développement et organisme de certification qualité.

Conduire un Retour d’EXpérience projet

par  Delphine Malassingne (1h)

Méthodologie du REX : retour d’expérience d’un retour d’expérience

Un REX (Retour d’EXpérience) est un processus de réflexion mis en oeuvre pour tirer des enseignements et des axes d’améliorations d’un projet (en cours ou terminé).

Idéalement il est effectué par

  • quelqu’un d’externe au projet,
  • neutre et bienveillant,
  • à l’aise dans l’animation,
  • transverse,
  • toujours la même personne, afin de pouvoir comparer les différents REX entre eux, et vérifier que les enseignement et axes d’améliorations ont bien été suivis.

Un REX suit plusieurs étapes :

  • Idéalement, il doit être prévu dès l’avant vente du projet, afin de faciliter la collecte d’informations
  • Chaque participant au projet remplit un questionnaire (anonyme, mais qui permet d’indiquer sa place dans l’équipe). Y compris les manageurs, commerciaux, personnes restées seulement une semaine. Le but n’est pas tant de faire une moyenne exacte que d’avoir tous les points de vue.
  • Une fois les questionnaires remplis et analysés, faire une réunion avec les différents intervenants pour discuter des différents points mis en évidence par le questionnaire et élaborer un plan d’action
  • Lors de ce point, il est important que les questions soient posées et que les opinions sur le sujet soient brassées, mais surtout que les différentes interventions soient notées par écrit.
  • Ensuite un compte-rendu et un plan sont réalisés, mais le compte-rendu ne sera publié que lorsque plusieurs REX auront été effectués, afin de pouvoir les mettre en perspective et voire les évolutions. En revanche, le plan d’action est publié et applicable de-suite.

Le but des REX n’est pas d’avoir une évaluation finale à un projet unique, mais plutôt de mettre en place une amélioration globale continue.

Dev vs Wild

par  Yoann Ono Dit Biot (slides)

Quelles sont les conséquences de vos failles de sécurité sur votre application en général, et sur vous en particulier ?

 

Il est difficile de l’admettre, mais la sécurité informatique ne semble pas être la priorité de tous les devs. Nous entendons souvent :

  • « Personne ne m’attaque »
    • alors que la majorité des attaques sont automatiques et non ciblées.
    • alors qu’il faut en moyenne 200 jours pour identifier une faille ou ne serais-ce que de détecter une potentielle attaque passée.
  • « Moi, je n’ai rien à cacher »
      • alors que l’objectif de la majorité des attaques n’est pas vos données, mais vos ressources serveurs.
      • … avec un risque de dénis de service
      • … voire de crypto lock : quelqu’un prend en otage votre serveur et vous le rend contre une rançon
  • Mais au final, qu’est-ce que la sécurité en informatique?
  • Elle passe par 3 points:
    • Confidentialité
    • Intégrité
    • Disponibilité

Le but de la sécurité informatique est de garantir ces 3 points, de protéger l’utilisateur, le SI, et enfin de proposer des solutions en cas de problèmes

Ce n’est pas:

  • uniquement un problème de sysadmin : la meilleure sécurité du monde ne pourra pas rattraper l’incompétence d’un développeur
  • magique : ce n’est pas une silver bullet, il faut comprendre précisément les failles et les processus de sécurité
  • rétroactif : une fois que le mal est fait, il est difficilement rattrapable
  • sûr à 100%

Comment la mettre en place:

  • Définissez un niveau de risque minimal
  • Formez et communiquez avec les équipes de développement
  • Définissez les rôles au sein des équipes : qui vérifie le code, qui teste, qui vérifie si une attaque a eu lieu
  • Analysez les risques
    • anticipez les impacts
    • Méthode e-BIOS
    • Méthode MEHARI (Méthode harmonisée d’analyse des risques)
  • Définissez la surface d’attaque (les accès depuis l’extérieur par là où l’attaque va s’effectuer)
  • Renseignez-vous régulièrement sur les recommendations OWASP
  • Mettez en place des tests de sécurité automatisés.
  • Faites appel à des audits de sécurité, voir à un Bug Bounty

En bref, tous les ingrédients pour une conférence bien remplie.
Beaucoup de craft, d’agilité ! mais ça serait oublier les autres slots, tels que

Les Pipelines Jenkins dans la vraie vieDeep Learning et Intelligence Artificielle : mythes et réalitésvue.js, j’avais pas vu !Criteo, Why What Who How ?Concevoir une expérience Mobile plus accessibleDéplacer une Application Monolithique vers une Architecture Microservices,  Angular2 et les standards du web,  etc.

Vivement l’année prochaine !

BONUS : la key-note Codeurs du monde

par Agnes Crepet et Cyril Lacote(1h) (retranscription) (Codeurs du Monde)

Du bonheur d’être développeur dans les différents pays du globe

Ce duo revient sur leurs expériences professionnelles dans différents pays, et sur les conditions de vie des développeurs, partout dans le monde :

Ils ont ainsi organisé des meetups au Togo, où les conférences étaient rares et certains spectateurs, très motivés, dépensaient une journée de salaire et faisaient des heures de transport pour venir les voir.

Ils ont également été en Malaisie, où l’accent est mis sur l’enseignement et la formation. Puis ils sont allés enseigner à Jakarta (Indonésie), à des étudiants très pro-actif-e (50 % de filles !) et engagé(e)s, prêt(e)s à créer leur startup à peine sortie de l’école (voire avant pour certain(e)s).

Ils ont ensuite mis en place un pod-cast à San Francisco, où il existe un gap entre la vision très idéalisée du métier de développeur dans la Silicon Valley, et la réalité (les salaires ne suffisent pas à payer les loyers, tensions avec les populations locales).

Ils ont ensuite travaillé à Stockholm, où l’accent est mis sur la balance entre la vie professionnelle et la vie personnelle.

Enfin ils sont devenus indépendants, puis ont créé leur propre société à St-Etienne : Ninja Squad 

Enfin Agnes et Cyril tirent cette conclusion sur l’épanouissement: ce qui rend les développeurs heureux, c’est principalement pouvoir choisir son destin. Et donc, être maître de son cadre de travail.

 

Une réflexion au sujet de « Codeurs en seine 2016, dans l’oeil du craftsman et de l’agiliste »

  1. Publié par Francis, Il y a 3 jours

    Merci, pour tous ce contenu avec les liens associés.
    Beaucoup de chose intéressantes.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *