Un développeur (junior) devrait-il essayer de promouvoir de meilleurs processus et pratiques dans son équipe de développement / informatique?
Je suis un développeur junior qui a la capacité d'aider à façonner les processus de mon équipe si je peux justifier le changement et si cela aide l'équipe à faire son travail. C'est nouveau pour moi, car mes anciennes entreprises avaient plus ou moins des processus définis de manière rigide qui provenaient de la direction.
Mon équipe est assez petite et quelque peu nouvelle (<3 ans). Ils manquent:
- un cadre de développement de logiciel/gestion du travail bien défini (comme Scrum)
- forte propriété du produit
- rôles bien définis (par exemple, le personnel de l'entreprise effectuera des tests manuels)
- réunions régulières de stand-up
- un processus de suivi des problèmes consolidé (nous avons un outil, le processus est toujours en cours d'élaboration)
- une unité, un système, une régression ou une suite ou une liste de tests manuels
- documentation sur la logique et les processus métier
- une base de connaissances pour documenter les conseils internes et clients
Et la liste continue. La direction est ouverte à la mise en œuvre des améliorations tant que la valeur est justifiée et qu'elle aide au travail le plus important (à savoir le développement). L'hypothèse sous-jacente est cependant que vous devez vous approprier 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 sans aucun doute du temps et ne sont clairement pas des travaux de développement.
Cela vaut-il la peine qu'un développeur (junior) essaie de pousser pour ce qui précède au fil du temps? Ou est-il préférable de "rester dans votre file" 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?
De 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 de l'université ont des connaissances théoriques fantastiques - bien meilleures que moi ou de nombreuses autres personnes âgées ayant des décennies à créer des logiciels pour vivre.
MAIS, et c'est un grand MAIS, cette connaissance n'est fondée sur aucun scénario pratique. Dans le monde réel, une grande partie de cette théorie tombe à plat, ou à tout le moins doit être prise avec un grain de sel massif car il s'avère en pratique que cela ne fonctionne pas si bien dans un scénario du monde réel.
Exemple: une application sur laquelle j'ai travaillé il y a longtemps a été conçue par un brillant théoricien OO, conçu pour suivre OO principes et théorie du T, avec beaucoup de motifs appliqués partout.
C'était un morceau fantastique de conception de logiciel.
Malheureusement, cela a entraîné un cauchemar de production et de maintenance. La base de code était si vaste et complexe que les endroits étaient impossibles à changer; Non pas parce qu'il était particulièrement fragile mais parce qu'il était si complexe, personne n'osait y toucher par peur de ce qui allait se passer (l'architecte/designer d'origine était un entrepreneur qui était parti depuis longtemps).
Il a également très mal fonctionné, précisément en raison de la structure multicouche des modèles et des bibliothèques de classes requises par la conception. Par exemple, cliquer sur un bouton sur un écran pour effectuer un seul appel à la base de données entraînerait plusieurs centaines d'instanciations d'objets et d'appels de méthode, le tout au nom de la garantie d'un couplage lâche et d'autres choses du genre.
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 création de logiciels se seraient rendu compte de la monstruosité que la conception entraînerait inévitablement et auraient adopté une approche plus pragmatique, conduisant à un système plus facile à entretenir et mieux performant.
La même chose peut s'appliquer à de nombreuses autres choses que vous rencontrez en tant que nouveau diplômé, ou même nouvel employé dans n'importe quelle entreprise. Ne présumez 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 soit fait de cette façon.
Même maintenant, avec plus de 20 ans d'expérience dans le domaine, je me méfie de critiquer la façon dont les choses sont faites dans les entreprises avec lesquelles je travaille. Je mentionnerai en passant que j'ai remarqué que les choses sont différentes de mon expérience étant la plus optimale, mais pas de manière belliqueuse. Cela conduit souvent à des conversations intéressantes sur la raison pour laquelle ces choses sont telles qu'elles sont. Peut-être que des changements se produiront et peut-être pas, selon que la valeur du changement est inférieure au coût.
N'ayez pas peur de suggérer que les choses peuvent être mieux faites, mais assurez-vous toujours que vous ne vous présentez pas en tant qu'enfant au nez morveux, mais plutôt en tant que collègue qui essaie et veut non seulement apprendre mais aussi aider à améliorer les processus pour l'amélioration de l'entreprise, pas seulement l'exactitude théorique.
Oui mais avec beaucoup de soin !
Permettez-moi de 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 gestion et que votre première réponse est de prendre une douche, alors ce n'est pas habitable. Si votre première réponse est de crier ouais! ... puis de vous plaindre lorsque vous êtes expulsé du bureau, vous devez rendre votre maison plus habitable. C'est un sentiment, et vous le saurez.
Cela étant dit, vous travaillez dans un compliqué symathèse . Tout ce que vous faites est susceptible de mal tourner, et aggravera probablement les choses au moins à court terme, car un simple changement a des répercussions. Donc, tout d'abord devenez humble, je ne veux pas dire devenir un push over ou accepter que les choses doivent être mauvaises, je veux dire accepter le fait que vos bonnes intentions vont se retourner contre vous vicieusement.
Le problème
Avec les meilleures intentions, vous pourriez penser qu'un changement radical doit se produire, et je ne suis pas en désaccord sur le fait que ces situations existent, mais prenez un moment pour y réfléchir. Le système actuel fonctionne, vous et votre équipe produisez du code, peut-être qu'il est lent, peut-être douloureux, mais il fonctionne et vous avez tous de l'expérience sur la façon de le faire. Vous savez à peu près à quoi vous attendre, bref, vous êtes des professionnels expérimentés de ce système.
Après le changement radical, personne, sauf peut-être le réalisateur, ne sait à quoi s'attendre. Bref, tout le monde a été réinitialisé à un niveau 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. Pendant ce temps, les néophytes font des erreurs parce qu'ils ne sont pas pratiqués. Ces erreurs font partie du système, avec lequel vous devez maintenant vivre et ce n'est plus aussi brillant maintenant.
Une voie à suivre
Il y a des moments où la coupe, la gravure et la reconstruction sont de loin les meilleures que vous puissiez faire. C'est particulièrement intéressant si personne n'est pratiqué dans l'ancien système, car la seule chose perdue est la connaissance codifiée. Si ces connaissances sont totalement incompréhensibles, elles sont déjà perdues et recommencer est le seul choix. Inversement, si la méthode de codification, ou la façon dont elle est utilisée, est problématique mais fonctionne, cette connaissance est toujours accessible, et peut-être vaut-elle la peine d'être conservée, peut-être pas - ne prenez pas la décision à la légère.
L'autre choix est de travailler avec le système pour que tout le monde ait un cadre de référence, mais de changer de petites parties du système pour que tout le monde dans l'équipe soit au courant, ou s'ils ne sont pas au courant du changement, il est à la fois facile de 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 fortement de la regarder et d'y réfléchir.
Alors, trouvez une petite chose qui peut être changée qui améliorera votre vie, et j'espère celle de quelques autres. Corrigez ou améliorez la situation. Cela vous donnera de la pratique et de l'expérience sur la mise en pratique des changements. Assurez-vous d'obtenir des commentaires: auriez-vous pu en discuter mieux, était-ce réellement utile, at-il bouleversé 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 produites:
- 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 de système avec succès.
Maintenant, choisissez une autre chose à améliorer, à mesure que votre expérience grandit et que vous éliminez les problèmes de faible accrochage, vous commencerez à affronter les 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éapprises)
- Vous connaissez des moyens immédiats de corriger ou d'améliorer les problèmes que le changement introduira
- les gens autour de vous savent que vous connaissez le système et êtes capable de le changer 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/la malchance de me lancer dans un projet de quelques mois en tant que "Junior".
Comme la première chose que j'ai remarquée, il n'y avait (OMG) aucun dépôt de code! Toutes les fusions de code ont été effectuées manuellement en s'envoyant des fichiers Zip par courrier.
Je suis donc allé voir mon (également nouveau) gestionnaire et j'ai suggéré que nous devrions avoir un référentiel. La réponse était: Ok, organisez-le ....
Ainsi, organiser un référentiel de code, sans aide, était nouveau dans l'entreprise, maintenant c'était une expérience humiliante.
Quand j'ai tout mis en place, (choc) personne ne voulait l'utiliser. J'ai donc essayé de faire avancer les choses et heureusement, mon manager a compris son importance, j'ai donc eu du soutien.
Mais cela a abouti à ce que je n'étais pas bien aimé et malheureusement j'ai obtenu un surnom dérivé du système de contrôle des sources.
Donc, mon point de vue sur ce point est d'abord de sentir les membres de votre équipe, ce qu'ils pensent qu'il est important de configurer ensuite.
Peut-être qu'ils ont aussi une liste comme la vôtre. Peut-être qu'ils ont tout réfléchi et qu'ils voulaient faire cette "chose" sur la liste. Peut-être qu'ils ... (peu importe) ....
Toute l'équipe doit être alignée.
Mais si ce n'est pas le cas, vous pouvez toujours travailler professionnellement. Et trouvez des personnes partageant les mêmes idées et travaillez ensemble comment vous pensez que cela devrait être fait. Si cela donne de bons résultats, plus de personnes travailleront avec vous, ce qui finira par devenir "le" processus.
Tout comme avec le code, la même chose pour les processus de développement: une amélioration continue est nécessaire.
Alors oui, vous devriez toujours essayer d'améliorer, ce qui est possible d'améliorer.
Mais souvenez-vous également que de nombreuses personnes avec lesquelles vous travaillez, pourraient déjà être des professionnels, et elles savent ce qui ne va pas et ce qui est nécessaire.
Cela vaut-il la peine qu'un développeur (junior) essaie de pousser pour ce qui précède 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 le mentionnez, il y a beaucoup de problèmes à résoudre et beaucoup de ces problèmes ne sont pas terriblement précieux. Et à 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 d'améliorer les choses, même si cela signifie choisir qui les choses que vous passez votre temps à essayer d'améliorer.
Parce qu'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, donc si vous voulez vraiment faire la différence, faites-le de la bonne manière:
Pas pendant les premières semaines: Utilisez ce temps pour:
- Créez une bonne première impression. Montrez que vous vous situez dans l'équipe.
- Comprenez la culture et la politique de votre entreprise. Est-il sûr de pousser pour des changements?
- Construisez une bonne relation avec vos collègues
- Découvrez 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é.
Choisissez vos batailles. Obtenez des victoires précoces : Vous pouvez arriver avec de l'énergie pour tout changer, mais ce n'est pas réaliste. Concentrez-vous sur quelques fruits bas 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 affectant 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 également 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 ont, naturellement, peur de pousser fréquemment du code non testé en production. Écrire un test réalisable n'est pas une tâche facile. Le code actuel pourrait être très difficile à tester. De plus, l'équipe ne peut pas utiliser ni pour é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 jugez pas. Ne demandez pas. Demandez-le et écoutez attentivement: C'est un moment où la communication est critique et nous, les programmeurs, ne sommes généralement pas très bons dans les nuances subtiles. Il existe des techniques pour vous aider . Il est facile de continuer à pousser pour notre idée au lieu de se concentrer sur la réponse. Assurez-vous d'abord qu'ils estiment que vous avez obtenu leurs points. Comprenez que les sentiments sont importants. Qu'est-ce que ce changement leur fait ressentir? peur? insuffisance? colère? frustration? espérer? Paresseux? Stupide? (Ne faites jamais que les gens se sentent stupides). Bien sûr, vous auriez posé beaucoup de questions auparavant et cela évitera beaucoup de fausses étapes.
Prenons l'exemple : se plaindre est facile, créer le changement est difficile. Montrez les résultats et les gens vous croiront. S'ils n'utilisent pas de test, vous pouvez écrire vos tests unitaires. Si les gens ne documentent pas, vous pouvez partager certains documents Google avec l'équipe. Comprenez que "Ok, faites-le" est l'un des meilleurs scénarios possibles et que vous devez ensuite livrer. Dans ce cas , vous devez avoir réfléchi 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 budgétaire officielle ou faire croire à vos patrons que vous perdez un temps précieux 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.
Obtenez la 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 du mentorat. Peopleware décrit le "réveil du phénomène géant" avec la base de l'équipe 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 monde est d'accord, le changement est plus facile.
Donnez-lui un peu de temps. Votez ensuite 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, souvenez-vous qu'il existe de nombreuses offres dans le pool d'emplois. Vous voulez apprendre les bonnes pratiques et à long terme, vous serez meilleur dans une paix avec un salaire légèrement inférieur mais en acquérant 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 grand signe. Vous voulez avoir une vision très claire et réaliste de ce que vous avez fait personnellement et de ce que les autres ont fait. 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. Beaucoup de gens n'étaient pas satisfaits et la productivité avait une grande marge d'amélioration. J'ai donc proposé de faire une expérience rapide avec des rétrospectives, nous avons fait X, et Y et en conséquence nous avons eu ce merveilleux résultat mesurable ".
Oui. Mais pas les choses que vous suggérez.
Hors de votre liste, les tests unitaires/d'intégration sont le seul élément sur lequel vous pouvez progresser.
Vous pouvez commencer à les ajouter vous-même avec un investissement en temps minimal et afficher 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. Tout en vous apprenant également à 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 métier qui impliquent toute l'équipe ou même d'autres équipes. Vous pourriez suggérer des améliorations, mais il sera difficile pour un employé débutant de changer et le processus de les changer est généralement non technique et probablement sans rapport avec votre travail normal.
Je suggérerais également des choses comme la mise en place de pipelines CI, les déploiements automatisés, la gestion des versions, les bibliothèques de packages comme bonnes choses à attaquer
Ça dépend de:
- combien vous attendez de meilleures pratiques
- combien d'efforts vous devrez consacrer pour vous y rendre
- quelles sont les chances de succès et les risques - du simple échec de l'adoption aux nouvelles pratiques sont en fait terribles, la qualité du code se dégrade, les personnes clés partent, tout le monde vous déteste et vous devez trouver un autre emploi dans une ville différente où personne ne connaît votre nom
Fondamentalement: il est de votre responsabilité de passer un temps raisonnable à défendre ce que vous pensez être le mieux - mais la décision devrait être une responsabilité d'équipe ou de gestion. Gardez à l'esprit que l'aliénation des personnes en vaut rarement la peine, même si vous vous retrouvez avec de meilleures pratiques.
Ne commencez pas avec 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 référentiel de code source (git, svn, cvs, ...)? Une stratégie de balisage et de branchement? Ce sont des étapes simples qu'un débutant peut faire. Lisez quels problèmes ces étapes (tentent de) résoudre et comment cela aide votre entreprise à réduire les coûts (c'est ce qui intéresse la direction).
La prochaine étape pourrait être des builds automatisés, tous les soirs ou directement après chaque enregistrement, par ex. avec Jenkins. Vous pouvez également exécuter des tests automatiquement. Et ajoutez quelques outils pour mesurer la qualité du code (oh oui: la définition de certaines normes de codage est également une bonne étape).
En ce qui concerne la mêlée, mieux lire sur "Extreme Programming" (XP). Scrum est basé sur de nombreuses idées de XP et ajoute un processus formalisé autour d'eux - les concepts de XP peuvent toujours être utilisés sans ce processus).
Suggérez des choses, fournissez des informations de fond, essayez de convaincre les autres de l'essayer, analysez les résultats, ... mais ne vous attendez pas à beaucoup de coopération de la part des autres: la plupart des gens préfèrent s'en tenir à leurs vieilles mauvaises habitudes. Mais quand vous n'essayez pas, rien ne s'améliorera.
Vous avez dit que l'équipe était assez nouvelle (3 ans), donc si vous ne pouvez pas introduire de bons principes maintenant, ce sera plus difficile à faire 10 ans après. Certaines des choses que vous avez mentionnées, telles que le système de test et de version, sont parmi celles que vous pourriez déjà suggérer, mais ne jetez pas la suggestion comme ça sans mettre l'accent sur leurs avantages évidents et choisir les outils nécessaires à votre pile de développement.
Au début, posez des questions
En lisant votre liste, je suggérerais les questions suivantes (reportez-vous à votre liste pour voir comment elles correspondent):
- Comment puis-je voir quel travail les propriétaires d'entreprise demandent?
- Avez-vous essayé [Scrum]?
- Qui est le propriétaire du produit pour cela?
- Quels rôles y a-t-il?
- 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 puis-je savoir sur quoi travaillent les autres membres de l'équipe?
- 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?
- Lorsque [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 d'autres puissent les réutiliser?
- Avez-vous essayé [JUnit]?
- Où [ceci] est-il documenté?
- Avez-vous essayé [MediaWiki]?
Remplacez les choses entre [crochets] selon le cas pour que les questions aient un sens ou correspondent à vos priorités. Envisagez de reformuler si ma formulation ne correspond pas à votre style.
Vous avez peut-être déjà commencé à le faire. Privilégiez les conversations individuelles aux conversations de groupe. En tête-à-tête, vous pouvez avoir une meilleure lecture de ce que pense l'autre personne. Cette personne est-elle pour ce changement? Encontre? Faiblement? Fou de rage?
Lorsque 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ônent implicitement une position à laquelle elles s'opposent, elles 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. L'argument tend à durcir les positions plus qu'il ne convainc. Notez qui a quelle position et continuez.
Plus tard, prenez des mesures
Recherchez des moyens par lesquels vous et éventuellement d'autres (c'est-à-dire ceux que vous avez notés être d'accord avec vous précédemment) peuvent commencer les changements que vous souhaitez. Tout le monde ne veut pas de stand-up? Pourquoi pas? Peut-être que ceux d'entre vous qui en veulent un peuvent avoir leur propre standup. Pas aussi efficace qu'avec toute l'équipe, mais plus que vous n'en avez maintenant.
Lorsque vous rencontrez un obstacle (et en supposant que vous ne pouvez pas participer à un standup), envoyez un e-mail à l'équipe pour obtenir de l'aide.
Identifiez quels devraient être les rôles, éventuellement avec le soutien d'autres personnes d'accord avec vous. Commencez régulièrement à vous adresser aux gens lorsque le travail implique le rôle que vous (peut-être un groupe que vous) 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 des descriptions de la façon dont ils pensent que leur produit devrait fonctionner maintenant et à l'avenir.
Installez un framework de test (si d'autres le préfèrent, prenez une décision commune sur quel framework) et utilisez-le pour vos projets. Lorsque vous corrigez des bogues, écrivez des tests. Documentez ceci dans le rapport de bogue sur le traqueur de problème (a écrit un test 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, exécutez les tests vous-même et soumettez les problèmes au tracker si nécessaire.
Si vous pouvez obtenir un support de gestion, installez un logiciel wiki ou similaire et commencez à documenter votre contenu. Si les gens vous posent des questions qui montrent qu'ils n'ont pas lu la documentation, dirigez-les vers les pages pertinentes. Encouragez-les à poser plus de questions s'ils ne comprennent pas la documentation. S'ils continuent à poser des questions couvertes dans la documentation, citez la documentation lors de la réponse. Pensez à les encourager à mettre à jour le wiki si vous pensez que le problème est structurel plutôt qu’ils ne lisent pas.
Je suggérerais de ne me concentrer que sur une tâche à la fois. Et certainement seulement pousser un à la fois. Ne poussez pas fort. Voir cet exemple de pousser plus fort que le groupe ne le voulait. Concentrez-vous davantage sur le changement de votre comportement que le leur. Si votre chemin est le bon, 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 faites du Nudge. Une fois que vous avez conduit le cheval à l'eau, laissez le choix de boire ou de boire à l'autre.
Finalement, vous serez senior
Au fil du temps, votre équipe embauchera de nouvelles personnes. Vous cesserez d'être le nouvel embauché 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 progressez également 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 de hâte. Tu as un travail. Vous pouvez attendre un moment pour avoir un meilleur emploi, soit en l'améliorant, soit en en trouvant un meilleur.
Réponse courte: Non, pour toutes les raisons décrites dans les autres réponses. Même lorsque vous êtes un développeur moyen ou senior, il est généralement préférable de cherchez d'abord à comprendre lorsque vous rejoignez une nouvelle équipe.
ne 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 semblent inutiles et inadéquates? Très probablement, vous vous êtes gardé de l'embarras. Si certaines idées sont toujours d'actualité, ce serait le bon moment pour les présenter, si possible en les testant d'abord vous-même.
Réponse tardive et accordez beaucoup de bon contenu dans les autres réponses.
Je pense qu'il faut rappeler qu'un problème clé ici n'est pas les pratiques spécifiques, mais la culture globale de l'équipe.
- Créer un changement culturel est difficile .
- Plus encore si vous voyez comme "junior"
Tout le reste peut suivre s'il existe un moyen d'atteindre 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 rétros régulières. Tout ce dont vous avez besoin, c'est d'une conversation avec l'équipe, puis d'une action.
Vous pouvez facilement commencer à documenter les processus. "Je suis le nouveau mec, ai-je bien compris? Laisse-moi l'écrire." Il est important de suivre ensuite le processus vous-même, ou essayez d'appeler notre où il se casse.
Peut-être que vous commencez par de telles conversations étant ad hoc et que vous suggérez ensuite des rituels réguliers.
Cette approche permet une approche incrémentale, doucement douce. Vous pouvez éviter d'apparaître comme un junior qui sait tout ce qu'il sait et plutôt essayer d'être un facilitateur pour l'équipe qui fait le changement.
Quelques considérations:
- Certaines équipes ont un mauvais processus mais le savent déjà. Ils veulent changer et ont juste besoin de quelque chose pour catalyser cela. D'autres équipes se sont vraiment coincées dans leur chemin et beaucoup plus difficiles à changer.
- Il en va de même pour les particuliers.
- Vous devez être sensible à cela et savoir qui dans l'équipe est ouvert au changement et qui ne l'est pas. Comprendre pourquoi.
- Trouvez des gains faciles.
- Accueillez les changements dans l'équipe: trouvez leurs points de douleur individuels et essayez de les résoudre.