Guillaume Saint-etienne

Information & Communications Technology

TDD TDD & BDD ATDD Domain Driven Design Clean Code Clean Architecture Hexagonal Architecture Lean Software Development Agile software development 🙋 Soft skills for developers

Toulouse, Occitanie, France

Guillaume Saint-etienne

Software & Team Architect

https://twitter.com/guillaume_agile

Je suis artisan développeur depuis 30 ans déjà, j'ai été aussi architecte logiciel, chef de projet, responsable d'équipe , j'ai travaillé pour diverses ESN et éditeurs logiciels, dont Varian Medical Systems pendant 10 ans.

Guillaume Saint-etienne

Dévelopeur Senior, Artisan Logiciel, Architecte, Lead Equipe

https://twitter.com/guillaume_agile

Je suis artisan développeur depuis 30 ans déjà, j'ai été aussi architecte logiciel, chef de projet, responsable d'équipe , j'ai travaillé pour diverses ESN et éditeurs logiciels, dont Varian Medical Systems pendant 10 ans.

Current sessions

L'invasion des mutants dans votre code (oui mais pour votre bien)

Tester c'est être agile, car c'est être confiant dans le produit qu'on livre. Vous faites probablement du TDD, ou au moins vous essayez d'écrire des tests. Vous vous vantez même d'avoir une bonne couverture. Mais résisterez vous à l'invasion des mutants?
Cette pratique de test peut faire peur, et pourtant... Quelle puissance! Quelle exigence!
Ce n'est pas (que) un outil de test, c'est (aussi) le gardien de la qualité de votre code. Et il ne tergiversera pas!
Etes vous prêts?


Le long voyage sur Mars de 3 explorateurs du code


Deux développeurs et un coach agile embarquent à bord d'un rover pour un long voyage sur Mars.
Un kata d'apprentissage pas uniquement technique revu et revisité pour mener l'exploration à son terme. Mais que veut dire "mener à son terme" pour ce groupe ?
Notre attention initiale était de développer complètement ce kata en poussant son développement vers une architecture de type hexagonale nous permettant ainsi de couvrir une large plage de problématiques.
C'était une idée un peu folle, car contraire au principe des coding dojo "traditionnel" où un groupe se retrouve le temps d'une séance en ayant aucun enjeux sur le point d'arrivée.
Ici nous inversons la proposition, tenons sur la durée et poussons un kata sur plusieurs séances de coding dojo !
Cela nous a conduit sur des chemins inattendus et riches nous avons tant appris que nous vous proposons de vous relater cette aventure.


Cuisines et Dépendances

Un travail d'équipe dans le monde numérique est fait de relations complexes. Humaines et techniques. Des liens se tissent et très vite les problèmes apparaissent. De mon expérience de software craftsman j'ai poussé la réflexion bien plus loin sur nos dépendances dans le travail et ce que nous pouvons en faire.


Agilité pour l’échafaud

Cela aurait pu être le titre d'un film. Cela avait commencé sous un autre titre: "Agilité à l'échelle". Mais bien vite, le principe de réalité est venu frapper à la porte. Comment tout ces beaux frameworks si bien pensés peuvent ils échouer? Retours du terrain, panorama des recettes bien concoctées qui finissent par un plat cramé.
Et un bouquet final avec des idées pour rattraper la sauce.
A vos marmites!


10 years challenge: même code, même team, même produit

Pour la grande majorité des développeurs (ceux ci étant en majorité employés dans des ESN) les projets s’enchaînent et ne se ressemblent pas. Sans compter les effets du turn-over sur la qualité de ce qui est produit.

J'ai connu cela durant mes 15 premières années de carrière.

Et tout d'un coup, l'âge de raison sûrement, je fût pris il y a 10 ans dans une aventure au long terme. Déboussolant ou rassurant? Peut être les deux. Mais cela ne s'est pas fait par hasard.

Laissez moi vous raconter ce qui m'a permis de rester contre tout attente avec la même équipe et le même code durant toutes ces années.

Venez découvrir les raisons d'une telle longévité, avec comme défi permanent de produire du code pensé pour durer. Et c'est du .Net !


La fracture Agile avec les développeurs

"Agile is almost over" a encore dit récemment Brian Marick. Il y en a pour qui c'est depuis longtemps le cas, ce sont les développeurs; tendons le micro pour comprendre la grogne et ne pas tomber *encore* dans la taylorisation ou la fuite facile de l'Agile vers le Non-IT