Salut Flavio et merci pour cet exposé.

Maitriser le français, c'est un véritable atout pour le futur. Bravo.

J'ai parcouru ton profil LinkedIn. Tu as fait plein de choses dans le monde startup, coquilles vides en devenir. Ce sont des choses très valorisantes. Il y a une époque où j'avais approché une startup qui .... au final... a été absorbée dans Fedora. Ca donne pas mal de perspectives et... ça met aussi en perspective.

Si j'avais un conseil à donner :

Essayer d'intégrer une vraie chaine CICD, avec :

• Product Owner

• feature teams

• QA

C'est un environnement très très formateur et très loin du "fake it until you make it". Il y a de bonnes opportunités dans les équipes QA pour "pisser du test". Je m'explique :

Lors d'un sprint, dans un environnement TDD (Test Driven Development), les feature teams sont payées pour coder les nouvelles fonctionnalités tandis que les QA sont payés pour réaliser des jeux de tests pérennes.

En TDD, tu te retrouves donc avec le codeur de la Feature Team qui ponds un :

(En python)

def multiply(a, b):

return a * b

Et donc, la QA team doit te pondre une série de tests qui :

• s'assurent que les 2 opérandes sont des nombres entiers naturels, conformément à la user story.

• s'assurent que l'élément neutre de la multiplication fonctionne correctement.

• s'assurent que l'élément absorbant de la multiplication fonctionne correctement.

• s'assurent que l'entrée d'une chaine de caractère dans une des deux opérandes, appelle bien l'exception "titi".

• s'assurent que le non respect des bornes supérieure des opérandes ne provoquent pas un débordement.

• s'assurent que .....

Et donc, s'il fallait encore le démontrer, les TDD produisent 10 fois plus de code de test que de code de fonctionnalité.

Les TDD sont boudées par les "super heros de la feature". Pour parler français : ça les emmer... grave. Donc, il y a de bonnes opportunités pour de jeunes et vaillantes petites mains pour entrer dans les équipes de QA et pondre des tests normatifs.

Tests normatifs ? Quèsaco ?

C'est pondre de la norme opérationnelle pour que la fonctionnalité explicite rencontre également tout ce qui est implicite. Par exemple, un patronyme, en France, est stocké dans un champs de varchar de 25 caractères. Or, un portugais zélé pourrait te sortir du "Pablo dos Santos de Lisbao da Sylva....". Il ne faut pas aller très loin pour faire planter une machine. Un malgache pourrait te sortir un nom à plus de 25 chars.

Quelle règle de gestion mets tu en place dans ce contexte ? Il y a toute une batterie de tests de non régression à mettre en place autour de ces cas.

Sans compter les encodages de caractères spéciaux : le n tilde espagnol.... le eszett allemand, etc....

Bref, je pense qu'il y a beaucoup de collaborations possibles dans ces matières (QA) pour soutenir les feature teams.

Ce n'est évidemment pas la seule piste mais elle rencontre bien une réalité :

• Cette mise en place de tests de non régression est assez indépendante du sprint. On peut quasiment le faire à tout moment dans des projets de renforcement de la non régression.

• On peut intervenir en mode "task force", ce qu'une feature team ne peut absolument pas faire, parce qu'elle construit un produit sur le long terme.

• On peut le faire intensément pendant 1 mois, puis revenir un an après.

Ca colle plutôt bien au timing / aux possibilités d'un étudiant.

Bonjour,

Quel genre de mission cherchez vous ? Plutôt une expérience ou une rémunération (ou les 2) ?

Investir du temps pour accompagner et former une nouvelle recrue sur des sujets techniques souvent complexes, et ce juste pour la durée estivale n'est pas forcément un bon calcul. Et peu de boites font ça.

Les jobs d'été sont plutôt là pour remplacer de la main d’œuvre peu qualifiée.

Si la rémunération n'est pas votre principal objectif, je vous renvoie sur le post d'@hmg dans le fil de discussion suivant : https://www.free-work.com/fr/tech-it/forum/t/intercontrat-mecenat-association-ou-associe-start-up