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

Transcript

1. Petit guide de survie dans 

   la complexité d'un projet Web
   

   View Slide

2. View Slide

3. CREVAISON
   

   View Slide

4. un problème
   …
   plusieurs solutions
   

   View Slide

5. Des solutions pas 

   forcément adaptées
   

   View Slide

6. Ou vraiment 

   surdimensionnées
   

   View Slide

7. « To patch or not to patch »
   

   View Slide

8. http://xkcd.com/1495/
   

   View Slide

9. http://xkcd.com/844/
   

   View Slide

10. View Slide

11. http://www.commitstrip.com/fr/
    2015/01/28/looks-can-be-
    deceiving/
    

    View Slide

12. http://xkcd.com/1425/
    

    View Slide

13. View Slide

14. http://www.commitstrip.com/wp-content/uploads/2012/09/Strips-Hackaton-550-final.jpg
    

    View Slide

15. https://www.kickstarter.com/projects/commitstrip/commitstrip-rise-of-the-coders-a-book-about-the-fu
    

    View Slide

16. Bastien Jaillot – @bastnic
    Je suis fainéant pragmatique ಠ_ಠ
    

    View Slide

17. Conseil, réalisation, audit,
    expertise et formation
    ...Poney, Guinness et gif animé.
    

    View Slide

18. Profession : pompier du code
    

    View Slide

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
    

    View Slide

20. 1. Dette technique ?
    

    View Slide

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 »
    

    View Slide

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
    

    View Slide

23. http://slides.com/maximethoonsen/agile-technical-debt-forum-php#/10
    

    View Slide

24. La dette est inévitable
    

    View Slide

25. La dette est nécessaire
    

    View Slide

26. http://www.commitstrip.com/fr/2014/09/08/the-other-infinite-loop-that-all-coders-fear/
    

    View Slide

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.
    

    View Slide

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 ?
    

    View Slide

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 ?
    

    View Slide

30. Impacts ?
    besoin fonctionnel > besoin technique
    … un problème humain plutôt que
    technique
    

    View Slide

31. Impacts ?
    les développeurs peuvent quitter le projet
    critique pour le client à long terme
    

    View Slide

32. la somme des fonctionnalités qui n'auraient
    jamais du voir le jour
    + la sédimentation naturelle du code…
    + les mauvaises volontés.
    

    View Slide

33. 2. Prévention
    

    View Slide

34. Trop de fonctionnalités
    

    View Slide

35. View Slide

36. Éviter les effets tunnels !
    

    View Slide

37. qu’est qu’un
    projet
    « terminé » ?
    http://www.commitstrip.com/fr/2015/03/04/and-its-done/
    

    View Slide

38. Pas comme ça :
    Comme ça !
    Itérations !
    

    View Slide

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/
    

    View Slide

40. Le meilleur code est
    celui qui n’a jamais
    besoin d’être écrit
    

    View Slide

41. Le pouvoir du non
    

    View Slide

42. Le pouvoir du non
    « pas maintenant »
    

    View Slide

43. Prise de décisions
    

    View Slide

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
    

    View Slide

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
    

    View Slide

46. Réduire le nombre d’intermédiaires

    entre le décisionnaire 

    et les techniciens
    

    View Slide

47. On ne peut pas se
    permettre de…
    

    View Slide

48. Tolérance aux échecs
    

    View Slide

49. Le mieux est l’ennemi du bien
    

    View Slide

50. On a vite fait de ne penser qu’à ses intérêts
    

    View Slide

51. #nobullshit
    

    View Slide

52. Stimuler les intervenants
    

    View Slide

53. Culture, empathie !
    

    View Slide

54. privilégier les valeurs partagées 

    à l’excellence technique
    

    View Slide

55. • Formation, conférence
    • veille technique
    • revue de code, mentoring
    • Paternité du code partagée (collective code ownership)
    • responsabiliser sans rendre dépendant
    

    View Slide

56. Frustration
    vs
    projet qui avance ?
    

    View Slide

57. Acceptation de l’échec
    

    View Slide

58. Gestion du code
    

    View Slide

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
    

    View Slide

60. Théorie de la fenêtre brisée
    

    View Slide

61. Théorie de la
    Joconde
    

    View Slide

62. Règle des boyscouts
    

    View Slide

63. Attention à l'égo
    

    View Slide

64. Surqualité
    

    View Slide

65. Caricature : intégration continue, sass,
    npm, webpack… pour une landing page
    

    View Slide

66. sur-coder vous rend indispensable
    (et ce n’est cool pour personne)
    

    View Slide

67. attention au pompier pyromane
    (http://www.geek-directeur-technique.com/2016/08/27/les-pompiers-pyromanes)
    

    View Slide

68. 3. Éteindre l’incendie
    

    View Slide

69. Attention au charme de la
    réécriture de zéro !
    

    View Slide

70. http://www.commitstrip.com/fr/2016/10/31/bohemian-coder/
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

73. Chaque situation
    est différente, faites
    vous conseiller.
    

    View Slide

74. L'ennemi de la dette
    technique, c'est le
    pragmatisme.
    

    View Slide

75. https://fr.wikipedia.org/wiki/Gouvernement_ouvert#/media/File:D%C3%A9mocratie_Ouverte.png
    

    View Slide

76. « La dette technique »
    aux éditions du
    Train de 13h37
    t13h37.fr/boutique
    

    View Slide

77. Le succès

    

    n’est pas toujours ce que l’on voit
    

    View Slide

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
    

    View Slide