Le développeur : pisseur de code ou ingénieur ? avec Benoit Gantaume - Scrum Life 30
Вставка
- Опубліковано 2 жов 2024
- 🎁 Le guide du Scrum Master compétent 👉 sl.run/CWh8RN
Parlons des développeurs ! Vous connaissez les pisseurs de code ? Pour ce Scrum Life spécial, j'ai invité Benoit Gantaume pour échanger autour de cette expression malheureuse, et l'opposer à l'ingénieur.
💜️ La communauté Scrum Life 👉 sl.run/alZqRs
----------
LIENS EN RAPPORT AVEC CETTE VIDÉO
- Artisan Développeur : bit.ly/2FtWjLL
- L'article que je cite : jp-lambert.me/...
Découvrez toute la communauté Scrum Life ! 👉 sl.run/A39tkG
En tant que testeuse cet échange est un bonbon pour mes oreilles
Mes 2 influenceurs pro préférés dans une vidéo !!! Au top !!
De base on fait du TDD + clean code. Quand parfois je (moi ou les équipes) m'écarte de cette pratique, j'exposer clairement les conséquences business d'une telle approche au PO. Si le PO a bien compris les conséquences, mais que ça ne lui fait pas peur alors go!
Il y a 25 ans, j'ai commencé une carrière d'ingénieur développeur qui a doucement glissé vers un poste de pisseur et ensuite secrétaire codeur. Pas le choix sur les technos, l'architecture, la qualité, les logiciels et même quelque fois sur le nommage des fonctions. Si vous bosser chez le plus grand fabricant d'avion Français, les pilotes vous expliquerons même la façon de coder ;-)
Au top JP comme toujours ! Bon là je ne suis pas très objectif forcement...
Mais la question que tu poses est un vrai sujet !
Je suis heureux d'avoir contribué à la réflexion.
Merci pour ton invitation.
Merci d'avoir partagé ta prise de recul Benoît, j'ai beaucoup apprécié le passage où tu exprimes le fait que cette démarche intervient dans la complexité d'un écosystème projet, avec ses contraintes (souvent) concurrentes (et parfois contradictoires). Faire comprendre à l'ensemble des parties prenantes - notamment les décideurs - quels sont les enjeux liés à la qualité du code est un aspect crucial, et un vrai levier qui permet de faire passer d'un ressenti de "boîte noire" du développement (où l'on "impose" au métier une "lenteur" au niveau du développement, préjudiciable au business) au sentiment d'un "investissement", rentable dès un avenir proche.
j'ai bien aimé cette vidéo. On a un point de vu assez différent des autres scrum life. un peu plus pragmatique, un peu plus permissif. En écoutant entre les lignes, j'entend du non respect du DOD, du code pas forcément de qualité(mais avec un dette contrôlée).
Ça déculpabilise un peu :)
Les vidéos du scrum life nous montrent le chemin qui restent à parcourir, et c'est souvent vertigineux. Mets le doigt sur des mauvaises pratiques (et ça fait mal, aie !) - mais c'est aussi ce que j'aime, c'est mon coté SM :-) -
Là on souffle un peu :-) et on se dit qu'on est pas les seuls à faire avec ce que l'on a.
C'était aussi le premier Scrum Life avec invité me semble-t-il 🙂
@@ScrumLife oui sans doute :D
je fais tous les épisodes dans l'ordre ! me spoilé pas hein !!!
Oh ! c'est comme dans les séries TV : un crossover ! :)
Merci à vous deux pour le partage de vos idées !
Intéressant, vous parlez de culture d'entreprise, comment changer celle-ci ? (peut-être un futur sujet pour une video)
Si tu veux rester dans ta boite, il y a la technique du colibri. Quelques outils sont également utiles : J'aime beaucou le livre 'Fearless Change'. Par contre ça va être long...
Le code informatique et les datas font partis du patrimoine de l’entreprise, il est absolument vital de l’entretenir et d’éviter les malfaçons comme pour les locaux de l’entreprise. Le problème dans beaucoup de société c’est la vision comptable du développeur perçu comme une charge le plus souvent et non pas comme une immobilisation.
Heureusement certaines entreprises l'ont compris...
Super, comme dab !
Et très intéressant de faire des collab comme ça.
PS : Guillaume elle est passé ou la 2eme broche de lunettes? :D
Très intéressant. Bravo! Pour moi, il faut que les forces de l'entreprise (les décideurs) ait la conscience que la qualité du code fait partie de la valeur du produit. Si d'une part la majeur partie des devs sont incompétents au point de faire le sourd quand tu évoques ces bonnes approches et que d'autre part les décideurs n'ont aucune idées de quoi servent les tests alors là tu es mal barré. Je pense que cette épisode mérite un max de partage....
On n'explique malheureusement pas à un Dev comment faire son travail. On doit lui montrer l'exemple. C'est uniquement comme ça que j'ai obtenu quelques bons résultats.
Je suis d'accord : c'est le binomage est le moyen le plus efficace de transmettre le TDD et les bonnes pratiques.
je le pense aussi. ça peut constituer une très bonne approche pour aider à la montée en compétence de toute l'équipe
Ce n'est pas encore le cas en France, mais il y a des pays où existe un "ordre des ingénieurs", comme pour les médecins, avocats... Etre inscrire à un "ordre" implique qu'un ingénieur (informatique) se doit de respecter une éthique et un code de déontologie et c'est là, selon moi, que se fait la distinction entre le "développeur" et le "développeur professionnel"
Un tel ordre ne rendrait-il pas le métier stagnant ?
J’en discutais il y a quelque jour à propos d’un « ordre des métiers agiles » et au final, je me rend compte que ça peut devenir néfaste. Je prépare un article là-dessus, par exemple : est-ce qu’un « développeur professionnel » de l’ordre osera tester un comportement qui n’est pas valider par l’ordre ? Et dans ce cas-là, qu’est-ce qui le différencierait du développeur « non professionnel » qui n’est pas dans l’ordre ?
Et s’il faut réunir une commission de x personnes pour « valider » une nouvelle façon de coder ... je ne suis pas sûr qu’on y gagne.
Bonjour Constantin,
Je suis à 100 % Ok avec toi sur la création d'un "Ordre des métiers Agile".
Il y aurait un risque trop fort de standardisation / normalisation qui, je pense, nuirait à "l'adaptation" du mindset Agile !
En revanche, un "ordre des ingénieurs" pourrait être ok s'il fallait, comme Olivier le propose, adhérer à un code déontologique. Cela permettrait de mettre en garde les "petits nouveaux" (j'ai bientôt 47 ans !) sur leur DEVOIR de réflexion et de prise de recul par rapport à un projet.
@+ et au plaisir de te lire.
Colaps
colaps oui à conditions que ce soit assez ouvert pour ne pas pénaliser l’arrivée du changement
+1 ... Toujours en phase avec toi Contantin :)