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
3. CREVAISON
4. un problème … plusieurs solutions
5. Des solutions pas 
 forcément adaptées
6. Ou vraiment 
 surdimensionnées
7. « To patch or not to patch »
8. http://xkcd.com/1495/
9. http://xkcd.com/844/
11. http://www.commitstrip.com/fr/ 2015/01/28/looks-can-be- deceiving/
12. http://xkcd.com/1425/
14. http://www.commitstrip.com/wp-content/uploads/2012/09/Strips-Hackaton-550-final.jpg
15. https://www.kickstarter.com/projects/commitstrip/commitstrip-rise-of-the-coders-a-book-about-the-fu
16. Bastien Jaillot – @bastnic Je suis fainéant pragmatique ಠ_ಠ
17. Conseil, réalisation, audit, expertise et formation ...Poney, Guinness et gif animé.
18. Profession : pompier du code
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
20. 1. Dette technique ?
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 »
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
23. http://slides.com/maximethoonsen/agile-technical-debt-forum-php#/10
24. La dette est inévitable
25. La dette est nécessaire
26. http://www.commitstrip.com/fr/2014/09/08/the-other-infinite-loop-that-all-coders-fear/
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.
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 ?
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 ?
30. Impacts ? besoin fonctionnel > besoin technique … un problème humain plutôt que technique
31. Impacts ? les développeurs peuvent quitter le projet critique pour le client à long terme
32. la somme des fonctionnalités qui n'auraient jamais du voir le jour + la sédimentation naturelle du code… + les mauvaises volontés.
33. 2. Prévention
34. Trop de fonctionnalités
36. Éviter les effets tunnels !
37. qu’est qu’un projet « terminé » ? http://www.commitstrip.com/fr/2015/03/04/and-its-done/
38. Pas comme ça : Comme ça ! Itérations !
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/
40. Le meilleur code est celui qui n’a jamais besoin d’être écrit
41. Le pouvoir du non
42. Le pouvoir du non « pas maintenant »
43. Prise de décisions
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
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
46. Réduire le nombre d’intermédiaires
 entre le décisionnaire 
 et les techniciens
47. On ne peut pas se permettre de…
48. Tolérance aux échecs
49. Le mieux est l’ennemi du bien
50. On a vite fait de ne penser qu’à ses intérêts
51. #nobullshit
52. Stimuler les intervenants
53. Culture, empathie !
54. privilégier les valeurs partagées 
 à l’excellence technique
55. • Formation, conférence • veille technique • revue de code, mentoring • Paternité du code partagée (collective code ownership) • responsabiliser sans rendre dépendant
56. Frustration vs projet qui avance ?
57. Acceptation de l’échec
58. Gestion du code
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
60. Théorie de la fenêtre brisée
61. Théorie de la Joconde
62. Règle des boyscouts
63. Attention à l'égo
64. Surqualité
65. Caricature : intégration continue, sass, npm, webpack… pour une landing page
66. sur-coder vous rend indispensable (et ce n’est cool pour personne)
67. attention au pompier pyromane (http://www.geek-directeur-technique.com/2016/08/27/les-pompiers-pyromanes)
68. 3. Éteindre l’incendie
69. Attention au charme de la réécriture de zéro !
70. http://www.commitstrip.com/fr/2016/10/31/bohemian-coder/
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
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.
73. Chaque situation est différente, faites vous conseiller.
74. L'ennemi de la dette technique, c'est le pragmatisme.
75. https://fr.wikipedia.org/wiki/Gouvernement_ouvert#/media/File:D%C3%A9mocratie_Ouverte.png
76. « La dette technique » aux éditions du Train de 13h37 t13h37.fr/boutique
77. Le succès
 
 n’est pas toujours ce que l’on voit
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