Guide de survie dans la complexité des projet Web - aka Dette technique

Guide de survie dans la complexité des projet Web - aka Dette technique

Qui n’a jamais participé ou entendu parler d’un projet complètement inmaintenable où il n’est plus possible d’ajouter quoi que ce soit sans avoir peur de tout casser ? Pourquoi votre équipe n’arrive-t-elle pas à implémenter une fonctionnalité qui paraît de l’extérieur toute simple ? Pourquoi votre équipe paraît-elle fatiguée et en a-t-elle marre de votre projet, alors que vous les payez cher pour qu’ils bossent dessus ?

Cette conférence plongera dans la complexité d’un projet Web, complexité technique mais surtout humaine, où les échanges entre humains sont primordiaux et bien plus complexes que la qualité du code produit.

Nous y parlerons de dette technique, d’humains, et surtout d’honnêteté.

Public concerné : Toute personne touchant de près ou de loin à un projet Web. Toutes les personnes présentes donc..

87137598c23e3e90755e5d7476d21405?s=128

Bastien Jaillot

November 24, 2016
Tweet

Transcript

  1. 2.
  2. 10.
  3. 13.
  4. 19.

    Pompier : 50% d’entraînement 40% prévention 10% extinction pour un

    vrai feu : composer le 18 pour du code pourri : coucou@jolicode.com
  5. 21.

    Quand on code au plus vite et de manière non

    optimale, on contracte une dette technique que l'on rembourse tout au long de la vie du projet sous forme de temps de développement de plus en plus long et de bugs de plus en plus fréquents
 
 — Wikipedia, « Dette technique »
  6. 22.

    La dette technique est un emprunt sur la qualité. Elle

    est donc utile car elle permet de faire avancer le projet plus vite à court terme Elle devient problématique quand le coût de développement d'une fonctionnalité devient supérieur à ce qu'elle peut rapporter … et que ça gonfle tous les développeurs
  7. 27.

    Ça vous rappelle quelque chose ? • Vous ne comprenez

    pas pourquoi des règles de gestions validées 10x reviennent sur le tapis ; • Pourquoi c'est impossible de recruter ? et de conserver vos équipes ; • Pourquoi alors qu'avant tout allait vite et bien et tout le monde était content, maintenant tout met des mois ; • On vous a convaincu que PHP c'est pour les losers, donc votre site est en ruby ou en python, et maintenant qu'il faut le maintenir, il n'y a plus personne ? • Pareil pour du magento ; • Vous n'avez jamais fait évoluer votre Drupal 6 et maintenant soit il fonctionne "tomber en marche », soit il ne fonctionne pas et personne ne sait pourquoi dans les deux cas.
  8. 28.

    Conséquences / Symptômes ? (court terme) • Fonctionnel qui peut

    sortir plus vite ? • Fonctionnel qui sort pour moins cher ; • Le sentiment de ne « pas se faire avoir par la technique » : pourquoi payer 20 jours ce que l’on peut avoir en 2 ?
  9. 29.

    Conséquences / Symptômes ? (long terme) • Bugs à tout

    va, perte de qualité ; • Perte de célérité ; • Démissions ; • Difficulté de recrutement ; • Tout jeter ? • Fermer la boîte ?
  10. 32.

    la somme des fonctionnalités qui n'auraient jamais du voir le

    jour + la sédimentation naturelle du code… + les mauvaises volontés.
  11. 35.
  12. 39.

    Comment vendre des prestations agiles à ses clients ? Thibault

    Jouannic – Sud Web 2012 https://www.miximum.fr/blog/comment-vendre-des-prestations-agiles-a-ses-clients/
  13. 44.

    Toute méthode de gestion de projet qui n'est pas basée

    sur un échange permanent entre un client et son prestataire est vouée à l'échec Thibault Jouannic
  14. 45.

    Une relation client sympa qui vire au cauchemar, ça arrive.

    Une relation client de merde qui vire à l’idylle, jamais. Fuyez, dès le début.. Christophe Andrieu – @STPO
  15. 55.

    • Formation, conférence • veille technique • revue de code,

    mentoring • Paternité du code partagée (collective code ownership) • responsabiliser sans rendre dépendant
  16. 59.

    There are only two types of code, code that delivers

    business value, and code that doesn’t. The cleanest code that doesn’t deliver value is still crap — Anthony Ferrara in Beyond Clean Code
  17. 71.

    Tout projet informatique sérieux doit commencer par un dénigrement systématique

    du travail effectué par les développeurs précédents -- Tous les développeurs, un jour, y compris envers soi-même
  18. 72.

    • Identifier les vrais points de blocage fonctionnels (règle des

    80/20 : trouver ce qui apporte 80% de la valeur pour 20% du prix) ; • Construire des ponts ; • Surtout ne pas toucher à ce qui fonctionne ; • Déployer rapidement.
  19. 78.

    Crédits • Rustine • Vélo 1 / Vélo 2 /

    Chris Froome • Cedric Sacilotto – Pompier • ICS Students learn Fire Prevention • Tunnel • Couteau suisse géant • Légo • Sablier • Code Matrix • Tank • Pistolet • Échafaudage • Fenêtre brisée