Un développeur (junior) doit-il chercher à améliorer ses processus et ses pratiques au sein de son équipe de développement / informatique?

Je suis un développeur junior qui a la capacité de contribuer à façonner les processus de mon équipe si je peux justifier le changement et si cela aide l'équipe à accomplir son travail. Ceci est nouveau pour moi car mes entreprises passées avaient plus ou moins des processus définis de manière rigide par la direction.

Mon équipe est assez petite et un peu nouvelle (<3 ans). Ils manquent:

• un cadre de développement logiciel / gestion du travail bien défini (comme Scrum)
• forte propriété du produit
• des rôles bien définis (par exemple, le personnel de l'entreprise fera des tests manuels)
• réunions régulières
• un processus de suivi des problèmes consolidé (nous avons un outil, le processus est en cours de développement)
• une suite ou une liste de tests d'unité, de système, de régression ou manuelle
• documentation sur la logique métier et les processus
• une base de connaissances pour documenter les astuces internes et celles destinées aux clients

Et la liste continue. La direction est ouverte à la mise en œuvre d'améliorations pour autant que la valeur soit justifiée et que le travail le plus important (à savoir le développement) soit accompli. L’hypothèse sous-jacente est cependant que vous devez prendre en charge la mise en œuvre, car personne ne le fera pour vous. Et il va sans dire que certains des projets ci-dessus ne sont pas triviaux, prennent certainement beaucoup de temps et ne constituent clairement pas un travail de développement.

Les développeurs (débutants) ont-ils intérêt à essayer de faire avancer les choses ci-dessus au fil du temps? Ou est-il préférable de "rester dans votre voie" et de vous concentrer sur le développement, et de laisser l'essentiel de la définition du processus et de l'optimisation à la direction?

Bonnes réponses jusqu'à présent, mais elles ne couvrent pas toutes les bases.

D'après mon expérience, de nombreuses personnes fraîchement sorties du collège possèdent des connaissances théoriques fantastiques - bien meilleures que celles de moi ou de nombreuses autres personnes âgées possédant des décennies de développement de logiciels pour gagner leur vie.

MAIS, et c'est un gros MAIS, cette connaissance n'est fondée sur aucun scénario pratique. Dans le monde réel, une grande partie de cette théorie échoue ou, à tout le moins, doit être assimilée à un énorme grain de sel, comme on a pu le constater en pratique dans un scénario réel.

Exemple: une application sur laquelle j'ai travaillé il y a longtemps a été conçue par un brillant théoricien de OO, conçue pour suivre les principes et la théorie de OO au T, avec de nombreux motifs appliqués partout.

C'était un morceau fantastique de conception de logiciel.

Malheureusement, cela a entraîné un cauchemar pour la production et la maintenance. La base de code était si grande et complexe que les lieux étaient impossibles à changer; Pas parce que c'était particulièrement fragile, mais parce que c'était si complexe, personne n'a osé le toucher par crainte de ce qui allait arriver (l'architecte / designer d'origine était un entrepreneur qui était parti depuis longtemps).

Les performances étaient également très médiocres, précisément à cause de la structure multicouche des motifs et des bibliothèques de classes nécessaires à la conception. Par exemple, un clic sur un bouton sur un écran pour effectuer un appel unique à la base de données entraînerait plusieurs centaines d'instanciations d'objets et d'appels de méthodes, le tout pour garantir un couplage lâche et ainsi de suite.

Cet architecte avait été professeur d'université avec plusieurs livres sur le sujet à son nom. Il n'avait jamais travaillé un jour en tant que programmeur sur un projet commercial.

Les personnes ayant une expérience pratique de la construction de logiciels auraient compris quelle monstruosité créerait inévitablement et adopteraient une approche plus pragmatique, conduisant à un système plus facile à entretenir et plus performant.

La même chose peut s’appliquer à beaucoup d’autres choses que vous rencontrez en tant que nouveau diplômé, voire même en tant que nouvel employé dans une entreprise. Ne supposez pas que, parce que votre base théorique vous dit que quelque chose ne va pas ou n'est pas optimal, il n'y a pas de très bonne raison pour que cela se fasse de cette façon.

Même maintenant, avec plus de 20 ans d’expérience dans le domaine, j’ai peur de critiquer la façon dont les choses se passent dans les entreprises avec lesquelles je vais travailler. Je mentionnerai en passant que j’ai remarqué que les choses sont différentes de celles de mon expérience, mais que ce n’est pas de manière belliqueuse. Cela conduit souvent à des discussions intéressantes sur les raisons pour lesquelles ces choses sont comme elles sont. Peut-être que des changements vont se produire et peut-être pas, selon que la valeur de changer des choses est inférieure au coût.

N'ayez pas peur de suggérer que les choses pourraient être mieux faites, mais assurez-vous toujours de ne pas apparaître comme un gamin sachant tout, mais plutôt comme un collègue qui essaie et veut non seulement apprendre, mais aussi aider à améliorer les processus d'amélioration de l'entreprise, pas seulement la correction théorique.

Oui mais avec beaucoup de soin!

Laissez-moi clarifier cela.

Vous devez vous efforcer d'améliorer l'habitabilité du logiciel. Si vous regardez le code / l'équipe / l'entreprise / le projet / la direction et que votre première réponse est de prendre une douche, elle n'est pas habitable. Si votre première réponse est de crier ouais! ... et de vous plaindre lorsque vous êtes expulsé du bureau, vous devez alors rendre votre maison plus habitable. C'est un sentiment et vous le saurez.

Cela étant dit, vous travaillez dans une symathèse complexe . Tout ce que vous ferez risque de mal tourner et d’empirer les choses, du moins à court terme, car un simple changement a des répercussions. Alors tout d’abord, devenez humble, je ne veux pas dire que je deviens une impulsion ou que j’accepte le fait que les choses doivent être mauvaises, je veux dire qu’il faut accepter le fait que vos bonnes intentions vont vous tourmenter vicieusement.

Le problème

Avec les meilleures intentions du monde, vous pourriez penser qu’il faut opérer un changement en profondeur. Je ne nie pas le fait que ces situations existent, mais prenez le temps de réfléchir. Le système actuel fonctionne, votre équipe et vous-même produisez du code, peut-être lentement, douloureusement, mais cela fonctionne et vous avez tous l'expérience de la façon de le faire. Vous savez à peu près à quoi s'attendre, bref vous êtes des professionnels exercés dans ce système.

Après le changement radical, personne, à l'exception peut-être de l'implémenteur, ne sait à quoi s'attendre. En bref, tout le monde a été réinitialisé à un niveau de néophyte dans cette partie du système. Ce n'est pas bon. Les néophytes doivent apprendre les nouvelles règles, ce qui prend du temps. À cette époque, les néophytes font des erreurs car elles ne sont pas pratiquées. Ces erreurs font maintenant partie du système, avec lequel vous devez maintenant vivre, et il n’en est plus aussi brillant aujourd'hui.

Une voie à suivre

Il y a des moments où réduire, graver et reconstruire est de loin le meilleur que vous puissiez faire. C'est particulièrement intéressant si personne n'est pratiqué dans l'ancien système, car la seule chose qui est perdue est la connaissance codifiée. Si cette connaissance est totalement incompréhensible, elle est déjà perdue et le seul choix est de recommencer. Inversement, si la méthode de codification, ou la façon dont elle est utilisée, est problématique mais fonctionne, ces connaissances sont toujours accessibles et peuvent être conservées, peut-être pas. Ne prenez pas la décision à la légère.

L’autre option est de travailler avec le système de manière à ce que tout le monde ait un cadre de référence, mais de modifier de petites parties du système afin que tous les membres de l’équipe soient au courant, ou s’ils ne sont pas conscients du changement, il est facile de le faire. remarquer et facile à apprendre. C'est la base des pratiques appelées Kaizen . Une formule plus orientée développeur est présentée dans la présentation Shaving the Golden Yak, je recommande vivement de la regarder et d’y réfléchir.

Trouvez donc une petite chose qui peut être changée pour améliorer votre vie et, espérons-le, celle de quelques autres. Réparer ou améliorer la situation. Cela vous donnera de la pratique et de l'expérience pour mettre en pratique les changements. Assurez-vous de recevoir un retour d'information: auriez-vous pu en discuter davantage, était-il utile, at-il perturbé une autre partie du système? Développez votre sens de ce qui peut être fait et comment le faire.

Maintenant trois choses se sont passées:

• vous avez amélioré le système,
• vous avez acquis de l'expérience sur la façon de changer le système
• l'équipe vous a vu changer avec succès le système.

Choisissez maintenant une autre chose à améliorer, à mesure que votre expérience grandit et que vous éliminez les problèmes faciles, vous allez commencer à faire face aux problèmes les plus difficiles du système, mais au moins maintenant, lorsque vous dites que nous devons changer X:

• Vous savez comment le changement affectera le système
• Vous savez quels problèmes cela va générer (quelles règles doivent être réapprenées)
• Vous connaissez des solutions immédiates pour résoudre ou améliorer les problèmes que le changement introduira
• les personnes autour de vous savent que vous connaissez le système et que vous pouvez le modifier avec succès

Oui, vous pouvez. MAIS...

Tu dois être prudent.

Au début de ma carrière (il y a très longtemps), j'ai eu la chance d'entrer dans un projet vieux de quelques mois en tant que "Junior".

Comme première chose que j'ai remarquée, il n'y avait pas de référentiel de code (OMG)! Toutes les fusions de code ont été effectuées manuellement en envoyant des fichiers zip les uns aux autres par courrier.

Je suis donc allé voir mon (également nouveau) responsable et lui ai suggéré de créer un référentiel. La réponse était: ok, organisez-le

Ainsi, organiser un référentiel de code, sans aide, était une nouveauté dans l'entreprise, c'était maintenant une expérience humiliante.

Quand j'ai tout organisé, (choc), personne ne voulait l'utiliser. J'ai donc essayé de faire avancer les choses et heureusement, mon responsable a compris son importance et j'ai donc eu du soutien.

Mais cela a eu pour résultat que je n’étais pas très aimé et que j’ai malheureusement reçu un surnom dérivé du système de contrôle de code source.

Donc, voici ce que je pense, c’est d’abord de sentir les membres de votre équipe, ce qu’ils pensent qu’il est important de mettre en place ensuite.

Peut-être qu'ils ont aussi une liste comme la tienne. Peut-être qu'ils ont tout traversé et qu'ils voulaient faire cette "chose" sur la liste. Peut-être qu'ils .... (peu importe) ....

Toute l'équipe doit être alignée.

Mais s'ils ne le sont pas, vous pouvez toujours travailler de manière professionnelle. Et trouvez des personnes partageant les mêmes idées et travaillez ensemble à la manière dont vous pensez que cela devrait être fait. Si cela donne de bons résultats, davantage de personnes travailleront avec vous et deviendront éventuellement "le" processus.

Comme pour le code, il en va de même pour les processus de développement: une amélioration continue est nécessaire.

Donc, oui, vous devriez toujours essayer d’améliorer ce qu’il est possible d’améliorer.

Mais souvenez-vous aussi que de nombreuses personnes avec lesquelles vous travaillez peuvent déjà être des professionnels et savent ce qui ne va pas et ce qui est nécessaire.

Les développeurs (débutants) ont-ils intérêt à essayer de faire avancer les choses ci-dessus au fil du temps?

Oui, cela vaut toujours la peine d'essayer d'améliorer les choses. Vous savez mieux quels problèmes vous rencontrez après tout.

Mais comme vous l'avez dit, il y a beaucoup de problèmes à résoudre et beaucoup d'entre eux ne sont pas très utiles. Et dans de nombreux endroits, il y aura des obstacles insurmontables à votre réussite ou à d’autres personnes bien mieux placées pour les défendre. Donc , vous devriez toujours essayer de faire les choses mieux, même si cela signifie la cueillette qui choses que vous passez votre temps à essayer de faire mieux.

En fin de compte, si vous ne faites pas partie de la solution, vous faites partie du problème.

Oui. Mais le changement organisationnel est difficile, même pour une personne âgée. Si vous voulez vraiment changer les choses, faites-le de la bonne façon:

• Pas pendant les premières semaines: utilisez ce temps pour:

  • Créez une bonne première impression. Montrez que vous faites partie de l'équipe.
  • Comprenez bien la culture et la politique de votre entreprise. Est-il prudent de pousser pour des changements?
  • Construisez de bonnes relations avec vos collègues
  • En savoir plus sur le processus, les règles et les besoins de votre équipe
  • Apprenez votre travail et faites-le du mieux que vous pouvez. Vous serez sûrement assez occupé.

• Choisis tes combats. Obtenez quelques victoires au début : Vous pouvez arriver avec de l'énergie pour tout changer, mais c'est irréaliste. Concentrez-vous sur les fruits les plus faciles et montrez que vos idées fonctionnent. Vous voulez qu'ils soient réceptifs à des améliorations plus complexes. Et rappelez-vous que les choses sont plus faciles dans les livres.

• Considérez l'implication des autres : je fais des refactors qui affectent beaucoup de fichiers. Même s'ils améliorent le code, je dois être très prudent pour éviter de transformer les fusions en une douleur dans le cul. Essayez aussi de comprendre les raisons pour lesquelles ils continuent à travailler comme ça. Peut-être qu'ils ne peuvent pas utiliser Scrum car ils manquent de tests et craignent, bien entendu, de mettre fréquemment en production un code non testé. Écrire un test réaliste n'est pas une tâche facile. Le code actuel pourrait être très difficile à tester. En outre, l’équipe ne peut pas non plus écrire des tests ou du code testable. La base de code actuelle peut être particulièrement difficile à tester et doit être refactorisée. Cela peut prendre des années pour changer ce problème, mais au moins, vous pouvez vous concentrer sur la cause première.

• Ne juge pas. Ne demande pas. Demandez-le et écoutez attentivement: C’est un moment où la communication est essentielle et où nous, les programmeurs, n’avons généralement pas une très bonne idée des nuances subtiles. Il existe des techniques pour aider . Il est facile de continuer à défendre notre idée au lieu de nous concentrer sur la réponse. Assurez-vous d'abord qu'ils sentent que vous avez obtenu leurs points. Comprenez que les sentiments sont importants. Qu'est-ce que ce changement leur fait ressentir? peur? l'insuffisance? colère? frustration? espérer? Paresseux? Stupide? (Ne faites jamais que les gens se sentent stupides). Bien sûr, vous auriez déjà posé beaucoup de questions et cela évitera de nombreuses fausses étapes.

• Diriger par l'exemple : se plaindre est facile, créer le changement est difficile. Afficher les résultats et les gens vont vous croire. S'ils n'utilisent pas de test, vous pouvez écrire vos tests unitaires. Si les personnes ne documentent pas, vous pouvez partager des documents Google avec l'équipe. Comprenez que "Ok, fais-le" est l’un des meilleurs scénarios possibles et qu’il faut ensuite tenir ses promesses. Dans ce cas, vous devez avoir pensé aux ressources dont vous aurez besoin . Exemple: donnez-moi une petite instance Amazon et deux heures des administrateurs pour un serveur Jenkins

• Restez petit et simple (et pas cher): vous ne voulez pas attendre une approbation officielle du budget, ni laisser vos chefs penser que vous perdez un temps précieux de la part de programmeurs coûteux. Ce serait formidable d'avoir ce logiciel de révision de code ou d'évaluer plusieurs outils open source, mais nous n'utiliserons que le repo pour le moment.

• Obtenir une masse critique: Rassemblez le groupe de personnes axé sur l'amélioration de la qualité. Vous pouvez même les accompagner à des conférences et demander de l'aide ou un mentorat. Peopleware décrit le "réveil du géant" avec la base de l’équipe qui se rebelle littéralement contre certaines pratiques stupides qui ralentissent la productivité. Cela aurait été très dangereux individuellement et je ne l'aurais pas recommandé. Mais si tout le groupe est d’accord, le changement est plus facile.

• Donnez du temps. Ensuite, votez avec vos pieds: vous voudrez peut-être l’essayer pendant quelques mois, jusqu’à deux ans. Mais certaines entreprises n'ont pas de solutions faciles. Certaines équipes ne veulent pas changer et n'ont pas d'incitations. Et certaines bases de code sont de l'horreur pure. Si vous sentez que c'est vous contre le monde, rappelez-vous qu'il existe de nombreuses offres d'emploi. Vous voulez apprendre les bonnes pratiques et, à long terme, vous serez meilleur avec un régime de salaire légèrement moins élevé mais avec une expérience qui vous rendra plus précieux.

Bonus: Si vous réussissez, écrivez-le pour votre CV / Entretiens. En tant que junior, vous avez généralement très peu à dire et créer un changement pour le mieux est toujours un bon signe. Vous voulez avoir une vision très claire et réaliste de ce que vous avez fait personnellement et du travail des autres. Imaginez la question d’entrevue suivante.

• Parlez-moi d'un moment où vous avez fait une différence dans l'équipe.
• Eh bien, j'étais dans un endroit où ils avaient des pratiques très anciennes. Cela a déplu à beaucoup de gens et la productivité avait une grande marge d'amélioration. J’ai donc proposé de faire une expérience rapide avec les rétrospectives, nous avons fait X, et Y et, par conséquent, nous avons obtenu ce merveilleux résultat mesurable ".

Oui. Mais pas les choses que vous suggérez.

Les tests unitaires / d'intégration sont les seuls éléments sur lesquels vous pouvez progresser.

Vous pouvez commencer à les ajouter vous-même avec un investissement de temps minimal et une valeur instantanée. C'est un problème technique avec des avantages largement acceptés et n'affectera pas les autres pratiques de travail. En plus de mieux connaître la base de code même si les résultats ne sont pas acceptés. Une vente facile.

Les autres sont généralement des processus d’entreprise impliquant l’ensemble de l’équipe, voire d’autres équipes. Vous pouvez suggérer des améliorations, mais il sera difficile pour un employé débutant de changer et le processus de modification n’est généralement pas technique et probablement sans rapport avec votre travail normal.

Je suggérerais également des choses telles que la configuration de pipelines de CI, les déploiements automatisés, la gestion des versions, les bibliothèques de packaging, en tant que bon moyen d’attaquer

Ça dépend de:

• combien vous attendez-vous de meilleures pratiques
• combien d'effort vous devrez dépenser pour y arriver
• Quelles sont les chances de succès et les risques - de la simple adoption à l'échec aux nouvelles pratiques sont en fait terribles, la qualité du code se dégrade, des personnes clés quittent les lieux, tout le monde vous déteste et vous devez trouver un autre emploi dans une autre ville où personne ne connaît votre nom

Fondamentalement, vous avez la responsabilité de consacrer un temps raisonnable à la défense de ce que vous pensez être le meilleur - mais la décision doit être prise par une équipe ou une responsabilité de la direction. Gardez à l'esprit qu'aliéner les gens en vaut rarement la peine, même si vous vous retrouvez avec de meilleures pratiques.

Ne commencez pas par les choses les plus compliquées comme Scrum. Commencez par les étapes les plus simples possibles.

Vous n'avez pas mentionné la gestion du code source. Avez-vous un dépôt de code source (git, svn, cvs, ...)? Une stratégie de marquage et de branchement? Ce sont des étapes simples qu'un débutant peut faire. Lisez quels problèmes (tentez de) résoudre ces étapes et comment cela aide votre entreprise à réduire les coûts (c'est ce qui intéresse la direction).

La prochaine étape pourrait être la construction automatisée, la nuit ou directement après chaque enregistrement, par exemple avec Jenkins. Vous pouvez également exécuter des tests automatiquement. Et ajoutez quelques outils pour mesurer la qualité du code (ah oui: définir certaines normes de codage est également une bonne étape).

Pour ce qui est de la mêlée, lisez plutôt la section "Programmation extrême" (XP). Scrum est basé sur de nombreuses idées de XP et ajoute un processus formalisé autour de celles-ci - les concepts de XP peuvent toujours être utilisés sans ce processus.

Suggérez des choses, fournissez des informations en arrière-plan, essayez de convaincre les autres de l'essayer, analysez les résultats,… mais ne vous attendez pas à beaucoup de coopération des autres: la plupart des gens préfèrent s'en tenir à leurs vieilles mauvaises habitudes. Mais si vous n'essayez pas cela, rien ne va s'améliorer.

Vous avez dit que l'équipe est assez nouvelle (3 ans), donc si vous ne pouvez pas introduire de bons principes maintenant, il sera plus difficile de le faire 10 ans plus tard. Certaines des choses que vous avez mentionnées, telles que les tests et le système de version, sont parmi celles que vous pourriez déjà suggérer, mais ne faites pas cette suggestion sans insister sur leurs avantages évidents et sur le choix des outils requis par votre pile de développement.

Au début, posez des questions

En lisant votre liste, je vous suggérerais les questions suivantes (reportez-vous à votre liste pour voir comment elles s’adaptent):

• Comment puis-je voir le travail demandé par les propriétaires d'entreprise?
• Avez-vous essayé [Scrum]?
• Qui est le propriétaire du produit pour cela?
• Quels sont les rôles?
• Que fait ce rôle?
• Quel rôle est responsable de [cette activité]?
• Avez-vous essayé un standup quotidien?
• Comment puis-je communiquer mes obstacles au reste de l'équipe?
• Comment savoir sur quels autres membres de l'équipe travaillent?
• Devrions-nous mettre [ceci] dans l'outil de suivi des problèmes?
• Comment devrions-nous écrire [ceci] dans l'outil de suivi des problèmes?
• Quand [ceci] se produit, devrions-nous le mettre dans l'outil de suivi des problèmes comme [cela]?
• Comment testons-nous?
• Comment enregistrons-nous nos tests pour que les autres puissent les réutiliser?
• Avez-vous essayé [JUnit]?
• Où est-ce documenté?
• Avez-vous essayé [MediaWiki]?

Remettez les éléments entre [crochets] comme il convient pour que les questions aient un sens ou correspondent à vos priorités. Pensez à reformuler si mon libellé ne correspond pas à votre style.

Vous avez peut-être déjà commencé à le faire. Privilégiez les conversations en tête-à-tête plutôt que les conversations de groupe. Parce que face à face, vous pouvez avoir une meilleure lecture de ce que pense l'autre personne. Est-ce que cette personne est pour ce changement? Encontre? Faiblement? Rabidement?

Quand vous êtes nouveau, poser des questions est pratiquement gratuit. Les gens devraient s'attendre à ce que vous posiez des questions. Même si vos questions préconisent implicitement une position à laquelle ils s'opposent, ils ne devraient pas se mettre en colère. Ils devraient expliquer pourquoi ils s’opposent à cette position. Je recommande de ne pas discuter avec eux. Se disputer tend à durcir les positions plus qu’il ne convainc. Notez qui a quelle position et passez à autre chose.

Plus tard, prendre des mesures

Cherchez des moyens par lesquels vous et éventuellement d’autres (par exemple, ceux que vous avez notifiés comme étant d’accord avec vous précédemment) pouvez commencer les changements souhaités. Tout le monde ne veut pas un stand-up? Pourquoi pas? Ceux d'entre vous qui en veulent peuvent peut-être avoir leur propre stand-up. Pas aussi efficace qu'avec toute l'équipe, mais plus que ce que vous avez maintenant.

Lorsque vous rencontrez un problème (et en supposant que vous ne pouvez pas partager un stand-up), envoyez un courrier électronique à l'équipe pour obtenir de l'aide.

Identifiez quels devraient être les rôles, éventuellement avec le soutien d'autres personnes qui sont d'accord avec vous. Commencez systématiquement à vous adresser aux gens lorsque le travail implique le rôle que vous (probablement un groupe) pensez qu'ils devraient avoir. S'ils repoussent, demandez-leur d'identifier qui devrait assumer ce rôle.

Demandez aux propriétaires de produits (que vous avez identifiés) de rédiger une description de la manière dont ils pensent que leur produit devrait fonctionner maintenant et à l'avenir.

Installez un cadre de test (si d’autres le souhaitent, prenez une décision commune sur le cadre) et utilisez-le pour vos projets. Lorsque vous corrigez des bogues, écrivez des tests. Documentez-le dans le rapport de bogue sur l'outil de suivi du problème (écrit un bogue démontrant le bogue, stocké à [emplacement]). Encouragez les autres à exécuter les tests lorsqu'ils apportent des modifications. Si ce n'est pas le cas, lancez les tests vous-même et soumettez les problèmes au suivi si nécessaire.

Si vous pouvez obtenir un support de gestion, installez le logiciel wiki ou similaire et commencez à documenter vos données. Si des personnes vous posent des questions montrant qu'elles n'ont pas lu la documentation, dirigez-les vers les pages correspondantes. Encouragez-les à poser plus de questions s'ils ne comprennent pas la documentation. S'ils continuent à poser des questions abordées dans la documentation, citez-le lors de la réponse. Envisagez de les encourager à mettre à jour le wiki si vous pensez que le problème est structurel plutôt que de ne pas les lire.

Je suggérerais de ne se concentrer que sur une tâche à la fois. Et ne faites que pousser un à la fois. Ne poussez pas fort. Voir cet exemple de pousser plus fort que ce que le groupe voulait. Concentrez-vous davantage sur le changement de comportement que le leur. Si votre façon de faire est la bonne, cela devrait être évident pour les personnes qui vous observent. L'action a plus de poids que les mots. Essayez de ne pas vous répéter avec la même personne lorsque vous vous déplacez. Une fois que vous avez conduit le cheval à l’eau, laissez le choix entre boire ou boire à l’autre.

Finalement, vous serez senior

Au fil du temps, votre équipe embauchera de nouvelles personnes. Vous cesserez d'être le nouvel employé et pourrez défendre vos positions auprès de nouvelles personnes. Travaillez avec eux pour apporter des modifications. Et vous constaterez peut-être que vous faites également des progrès avec vos coéquipiers existants. Ou si cela ne fonctionne pas, cherchez un nouvel emploi où ils ont de meilleures pratiques. Il n'y a pas vraiment pressé. Tu as un travail. Vous pouvez attendre un moment pour avoir un meilleur travail, soit en l’améliorant, soit en le trouvant.

Réponse courte : Non, pour toutes les raisons exposées dans les autres réponses. Même en tant que développeur moyen ou senior, il est généralement préférable de chercher d'abord à comprendre en rejoignant une nouvelle équipe.

Une solution proposée :

1) chaque fois que vous voyez quelque chose qui devrait être amélioré, prenez-en note! (dans un cahier, dans une note numérique ...)

2) Après 6 mois, revenez à vos notes et vérifiez-les. Combien d'idées se sentent maintenant inutiles et inadéquates? Très probablement, vous vous êtes épargné une certaine gêne. Si certaines idées tiennent encore, ce serait le bon moment pour les présenter, si possible en les testant d’abord.

Réponse tardive et convenez de beaucoup de bon contenu dans les autres réponses.

Je pense qu’il faut souligner que la question clé n’est pas les pratiques spécifiques, mais la culture générale de l’équipe.

• Créer un changement culturel est difficile .
• Plus encore si vous êtes vu comme "junior"

Tout le reste peut suivre s'il existe un moyen de parvenir à une amélioration continue .

Mon approche pour y parvenir est la suivante:

• Processus et procédures documentés
• Rétrospectives avec l'équipe dont les actions sont des modifications de la documentation du processus.

Je suppose que si vous n'avez pas de sprints, vous n'avez pas encore de retros régulières. Tout ce dont vous avez besoin, c’est d’une conversation avec l’équipe, puis de l’action.

Vous pouvez facilement commencer à documenter les processus. "Je suis le nouveau, ai-je bien compris? Laisse-moi l'écrire." Il est donc important de suivre le processus vous-même ou d’appeler notre processus là où il se brise.

Vous pouvez peut-être commencer avec de telles conversations ad hoc et ensuite suggérer des rituels réguliers.

Cette approche permet une approche progressive et douce. Vous pouvez éviter de paraître en tant que junior qui savent tout et d'essayer plutôt de jouer le rôle de facilitateur pour l'équipe qui apporte des changements.

Quelques considérations:

• Certaines équipes ont un processus médiocre mais le savent déjà. Ils veulent changer et ont juste besoin de quelque chose pour catalyser cela. D'autres équipes sont restées coincées dans leurs habitudes et beaucoup plus difficiles à changer.
• Même chose pour les individus.
• Vous devez être sensible à cela et déterminer qui dans l'équipe est ouvert au changement et qui ne l'est pas. Comprendre pourquoi.
• Trouvez des victoires faciles.
• Faites en sorte que les changements soient les bienvenus au sein de l’équipe: trouvez leurs points de douleur individuels et essayez de les résoudre.