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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

CREVAISON

Slide 4

Slide 4 text

un problème … plusieurs solutions

Slide 5

Slide 5 text

Des solutions pas   forcément adaptées

Slide 6

Slide 6 text

Ou vraiment   surdimensionnées

Slide 7

Slide 7 text

« To patch or not to patch »

Slide 8

Slide 8 text

http://xkcd.com/1495/

Slide 9

Slide 9 text

http://xkcd.com/844/

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

http://xkcd.com/1425/

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

Profession : pompier du code

Slide 19

Slide 19 text

Pompier : 50% d’entraînement 40% prévention 10% extinction pour un vrai feu : composer le 18 pour du code pourri : [email protected]

Slide 20

Slide 20 text

1. Dette technique ?

Slide 21

Slide 21 text

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 »

Slide 22

Slide 22 text

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 gonﬂe tous les développeurs

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

La dette est inévitable

Slide 25

Slide 25 text

La dette est nécessaire

Slide 26

Slide 26 text

http://www.commitstrip.com/fr/2014/09/08/the-other-inﬁnite-loop-that-all-coders-fear/

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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 ?

Slide 29

Slide 29 text

Conséquences / Symptômes ? (long terme) • Bugs à tout va, perte de qualité ; • Perte de célérité ; • Démissions ; • Difﬁculté de recrutement ; • Tout jeter ? • Fermer la boîte ?

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

2. Prévention

Slide 34

Slide 34 text

Trop de fonctionnalités

Slide 35

Slide 35 text

No content

Slide 36

Slide 36 text

Éviter les effets tunnels !

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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/

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

Le pouvoir du non

Slide 42

Slide 42 text

Le pouvoir du non « pas maintenant »

Slide 43

Slide 43 text

Prise de décisions

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

Réduire le nombre d’intermédiaires  entre le décisionnaire   et les techniciens

Slide 47

Slide 47 text

On ne peut pas se permettre de…

Slide 48

Slide 48 text

Tolérance aux échecs

Slide 49

Slide 49 text

Le mieux est l’ennemi du bien

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

#nobullshit

Slide 52

Slide 52 text

Stimuler les intervenants

Slide 53

Slide 53 text

Culture, empathie !

Slide 54

Slide 54 text

privilégier les valeurs partagées   à l’excellence technique

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

Frustration vs projet qui avance ?

Slide 57

Slide 57 text

Acceptation de l’échec

Slide 58

Slide 58 text

Gestion du code

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

Théorie de la fenêtre brisée

Slide 61

Slide 61 text

Théorie de la Joconde

Slide 62

Slide 62 text

Règle des boyscouts

Slide 63

Slide 63 text

Attention à l'égo

Slide 64

Slide 64 text

Surqualité

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

3. Éteindre l’incendie

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

• Identiﬁer 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.

Slide 73

Slide 73 text

Chaque situation est différente, faites vous conseiller.

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

Le succès    n’est pas toujours ce que l’on voit

Slide 78

Slide 78 text

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