Informatique

Bonjour à tous, j'ai besoin d'aide sur un point et je ne sais pas comment le résoudre.

J'ai obtenu mon diplôme dans une école assez médiocre en Belgique (3 ans d'études après le lycée). C'est le genre d'école "dernière chance". Pour vous donner une idée, dès la première année, j'ai vu un gars à côté de moi qui n'arrivait même pas à allumer l'ordinateur...

Bref, ça m'a poussé à apprendre beaucoup de choses par moi-même, avec des vidéos YouTube, des cours Udemy et ce genre de trucs. Aujourd'hui, j'ai 2 ans d'expérience en tant que développeur fullstack (Spring Boot/Java + Vue.JS).

La première année, j'ai passé pas mal de temps sur le banc de touche parce que j'étais junior et qu'il y avait un manque de projets et de budget.

Maintenant, je travaille avec une équipe qui ne tient pas de réunions, ne travaille pas en Agile, et ne fait rien dans ce style (pas d'analyste dans l'équipe). Ce n'est pas forcément un énorme problème vu qu'on gère principalement des projets de petite à moyenne taille.

Mon problème est le suivant : je n'arrive pas à être efficace quand il s'agit de commencer un projet de zéro. Je ne sais pas comment aborder la préparation du projet, comment anticiper, comment faire le travail d'un analyste en gros. Et je me retrouve toujours face aux mêmes difficultés en boucle :

- J'ai du mal à démarrer la prochaine fonctionnalité une fois que j'en ai terminé une.
- J'ai du mal à savoir par quoi commencer, dans quel ordre, etc...
- Je suis extrêmement lent lors du développement

Et d'autres problèmes liés à l'efficacité. J'aime la manière chaotique dont l'équipe travaille parce que ça m'a permis de faire de gros progrès en peu de temps. Mais au final, je reste ce dev lent de l'équipe qui ne livre pas à temps.

Alors, où est-ce que je peux apprendre ce qui me manque ? Des conseils de quelqu'un qui a vécu une expérience similaire ou qui sait simplement comment résoudre ce problème ?

Évidemment, c'est grandement une question d'expérience, je devrais coder plus et c'est ce que je fais. Mais j'ai l'impression de passer à côté de quelque chose que j'aurais dû apprendre à l'école ou autre...

Si ton équipe n'a aucune structure alors ce n'est pas une équipe, j'imagine que vous devez bosser sur des projets à part chacun dans votre coin ?

Tu as un exemple un peu plus concret de moment où tu bloques ?

Renseigne-toi sur les architectures, la scalabilité et les deisgn patterns, ça te donnera un début.

Ensuite, découpe tes fonctionnalités en petits bouts. La plupart des petits bouts auront des pré-requis. Ceux qui n'en ont pas sont les premières tâches à effectuer. Tu déroules ensuite au fur et à mesure.
Ca demande de l'organisation consciente et explicite au début, mais ça devient instinctif au fur et à mesure de l'expérience.

Le 10 octobre 2024 à 15:07:26 :
Si ton équipe n'a aucune structure alors ce n'est pas une équipe, j'imagine que vous devez bosser sur des projets à part chacun dans votre coin ?

Tu as un exemple un peu plus concret de moment où tu bloques ?

Si je dois spécifier des moments de bloquage. C'est toujours entre les implémentations d'une features. Exemple concret:
Récemment, j'ai du faire un programme de récupération de fichier en cas de plantage d'un serveur. Donc le programme est sensé récupérer des fichiers depuis un serveur et les stocké sur un répertoire/serveur de stockage de secours. Bah je me prends d'énorme blocage à chaque fois que je dois implémenter un des services. Genre celui qui va faire les transfert de fichier via FTPS, j'ai galérer à trouver une solution parce que je mets un temps fou à savoir ce que je dois faire. C'est difficile à exprimé. Mais genre je suis devant ma classe, et je passes des heures (on & off) à me demander "mais par quoi je dois commencer" ou bien "Quels structure de données va recevoir et renvoyer ce server"...
Ce genre de trucs qui me font regarder mon écran pendant trop longtemps sans écrire une ligne de code

Le 10 octobre 2024 à 16:28:11 :
Renseigne-toi sur les architectures, la scalabilité et les deisgn patterns, ça te donnera un début.

Ensuite, découpe tes fonctionnalités en petits bouts. La plupart des petits bouts auront des pré-requis. Ceux qui n'en ont pas sont les premières tâches à effectuer. Tu déroules ensuite au fur et à mesure.
Ca demande de l'organisation consciente et explicite au début, mais ça devient instinctif au fur et à mesure de l'expérience.

Bah justement, j'ai acheté ce cours hier après avoir fait ce topic, j'ai terminé deux chapitres, je pense que ça fait parti des informations/théories dont j'ai besoin
Tu connaitrais pas une ressource similaire qui va plus en profondeur ou alors avec des use case concrets/proche d'exemple de programme crées en entreprise ?

https://www.udemy.com/course/the-complete-guide-to-becoming-a-software-architect/

Le 10 octobre 2024 à 11:51:59 :
Maintenant, je travaille avec une équipe qui ne tient pas de réunions, ne travaille pas en Agile, et ne fait rien dans ce style (pas d'analyste dans l'équipe).

Mais du quoi c'est quoi comme organisation ? Comment on te communique les tâches sur lesquelles tu dois taffer ?

Mon problème est le suivant : je n'arrive pas à être efficace quand il s'agit de commencer un projet de zéro. Je ne sais pas comment aborder la préparation du projet, comment anticiper, comment faire le travail d'un analyste en gros.

T'es sûr que c'est pas plutôt lié à un prob organisationnel et un manque de définition du besoin ?

Dans ma boîte j'ai un prob équivalent mais ce qui me bloque c'est pas des problématiques techniques, c'est vraiment cet espèce de flou constant où on va demander à des devs de commencer à coder un truc sans besoin ou specs clairement définies.

Genre on s’attend à ce que tu devines ce qui est attendu, et si au final ça convient pas bah pas grave tu recommences à 0.

Dans toutes les boites où j'ai taffé c'était comme ça Ils te vendent ça comme de "l'agilité" mais perso je vois plutôt ça comme un prob d'organisation

Le 13 octobre 2024 à 12:05:10 :

Le 10 octobre 2024 à 11:51:59 :
Maintenant, je travaille avec une équipe qui ne tient pas de réunions, ne travaille pas en Agile, et ne fait rien dans ce style (pas d'analyste dans l'équipe).

Mais du quoi c'est quoi comme organisation ? Comment on te communique les tâches sur lesquelles tu dois taffer ?

Mon problème est le suivant : je n'arrive pas à être efficace quand il s'agit de commencer un projet de zéro. Je ne sais pas comment aborder la préparation du projet, comment anticiper, comment faire le travail d'un analyste en gros.

T'es sûr que c'est pas plutôt lié à un prob organisationnel et un manque de définition du besoin ?

Dans ma boîte j'ai un prob équivalent mais ce qui me bloque c'est pas des problématiques techniques, c'est vraiment cet espèce de flou constant où on va demander à des devs de commencer à coder un truc sans besoin ou specs clairement définies.

Genre on s’attend à ce que tu devines ce qui est attendu, et si au final ça convient pas bah pas grave tu recommences à 0.

Dans toutes les boites où j'ai taffé c'était comme ça Ils te vendent ça comme de "l'agilité" mais perso je vois plutôt ça comme un prob d'organisation

Le 13 octobre 2024 à 12:05:10 :

Le 10 octobre 2024 à 11:51:59 :
Maintenant, je travaille avec une équipe qui ne tient pas de réunions, ne travaille pas en Agile, et ne fait rien dans ce style (pas d'analyste dans l'équipe).

Mais du quoi c'est quoi comme organisation ? Comment on te communique les tâches sur lesquelles tu dois taffer ?

Mon problème est le suivant : je n'arrive pas à être efficace quand il s'agit de commencer un projet de zéro. Je ne sais pas comment aborder la préparation du projet, comment anticiper, comment faire le travail d'un analyste en gros.

T'es sûr que c'est pas plutôt lié à un prob organisationnel et un manque de définition du besoin ?

Dans ma boîte j'ai un prob équivalent mais ce qui me bloque c'est pas des problématiques techniques, c'est vraiment cet espèce de flou constant où on va demander à des devs de commencer à coder un truc sans besoin ou specs clairement définies.

Genre on s’attend à ce que tu devines ce qui est attendu, et si au final ça convient pas bah pas grave tu recommences à 0.

Dans toutes les boites où j'ai taffé c'était comme ça Ils te vendent ça comme de "l'agilité" mais perso je vois plutôt ça comme un prob d'organisation

Bah c'est exactement ça, je m'en suis un peu rendu compte hier. Je suis sensé capter les besoins fonctionnels à partir d'une discussion orale.
Après, j'y vois pas forcément du mauvais car ça m'a poussé dans mes retranchements. Mais j'avoue que ça m'a posé tellement de problèmes aussi.
Par contre, l'informations existe bien ailleurs donc c'étais aussi à moi d'aller la cherchée. Et là j'ai merdé

Mais oui, hier je relisais la code base et je me rendais compte que certaines tables de ma BDD, bah j'avais aucune idée de leur définition/rôle et pareils pour certaines de leur propriétés

Si c'est ça le souci, c'est en même temps plus simple et plus compliqué.
Là, faut exiger (de manière frontale ou sournoise) des besoins fonctionnels clairs avec toutes les informations :
- quels sont les entrants ?
- à quel serveur se connecter ?
- quels sont les sortants ?
- quels sont les flux mis en cause ?
- quels sont les fonctionnalités/écrans impacté(e)s ?
- etc

En prime, s'il y a des tables et/ou champs de la BDD qui sont inconnus, cela prouve un sérieux manque de documentation et il serait peut-être temps de l'indiquer et de le résoudre.

Quel que soit la méthode Agile utilisée, si le ticket n'a pas les infos suffisantes pour commencer le dév', on le refuse jusqu'à ce que le métier/product owner fasse correctement son taff (quitte à l'aider un peu pour lui indiquer ce qui est acceptable).

Nous les développeurs ne sommes pas des magiciens mais malheureusement nous avons sans cesse un travail de pédagogie et d'accompagnement à réaliser avec nos interlocuteurs afin que ceux-ci nous fournissent assez d'informations pour que nous puissions faire correctement notre travail et répondre aux problématiques et besoins qu'ils expriment (mal la plupart du temps, malheureusement).

Si je dois spécifier des moments de bloquage. C'est toujours entre les implémentations d'une features. Exemple concret:
Récemment, j'ai du faire un programme de récupération de fichier en cas de plantage d'un serveur. Donc le programme est sensé récupérer des fichiers depuis un serveur et les stocké sur un répertoire/serveur de stockage de secours. Bah je me prends d'énorme blocage à chaque fois que je dois implémenter un des services. Genre celui qui va faire les transfert de fichier via FTPS, j'ai galérer à trouver une solution parce que je mets un temps fou à savoir ce que je dois faire. C'est difficile à exprimé. Mais genre je suis devant ma classe, et je passes des heures (on & off) à me demander "mais par quoi je dois commencer" ou bien "Quels structure de données va recevoir et renvoyer ce server"...
Ce genre de trucs qui me font regarder mon écran pendant trop longtemps sans écrire une ligne de code

Je pense que le manque d'équipe structuré te porte préjudice dans ce cas, parce que les périmètres du problème n'ont pas été posé, généralement c'est là qu'on définit les structures de données requises.

Comme dit plus haut tu dois avoir tout les besoins et spécificités possibles AVANT de commencer à travailler, tu dois avoir une idée claire de l'environnement dans lequel ta solution sera déployée et ce que ta solution doit faire.
Une fois que tu sais tout ça tu peux justement commencer a implémenter ta solution comme Bunyan l'a évoqué.

Point important, tout développement doit être documenté textuellement (mail, ticket jira...), pas seulement pour s'en souvenir mais aussi pour avoir une trace, ça peut être très utile en cas de problème surtout dans les grandes entreprises.

Je te conseilles de garder une trace de toute discussion professionnelle importante, imaginons que tu as une réunion où tu préviens d'un problème X a régler le plus vite possible avant d'avoir un problème mais qu'on ne te laisse pas le régler, si tu poses un compte rendu de réunion par mail ou autre, en mentionnant bien le pb et les risques on ne pourra pas revenir vers toi en t'accusant d'être le responsable et de n'avoir prévenu personne.

Parce qu'une discussion orale est impossible a prouver.

Si t'es de Belgique et que tu veux bossé avec une très bonne structure va postuler a la Smals, je suis freelance depuis 2 ans là.

J'ai jamais vu autant de structure que là.

Pour chaque projet on a :

Plusieurs analystes
1 architecte
des devs ( front et back )

ET avant de commencer un projet si t'as pas une équipe avec ça, le PL ne commence pas le projet. fin bref très bien structuré.

Apres, être dev c'est pas simplement convertir des envies de qlq en ligne de code

Essaie surtout de découpé les besoin, le plus compliqué ( fin pour moi ) au début c'était de lire un besoin d'une fonctionnalité et me dire ok il faut TOUT ça et le truc c'est que si tu penses directement a la finalité tu vas galerer et perdre trop de temps.

découpe par petit morceau, essaie de tout split en plusieurs micro fonctionalité