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

108

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?

débordement831
la source
10
Je remarque que l'un de vos tags est Scrum. Votre équipe est-elle une équipe Scrum? Et si oui, tiennent-ils des rétrospectives?
Daniel
10
Y a-t-il une raison pour laquelle vous utilisez "ils" au lieu de "nous"? Par exemple: "Mon équipe est assez petite et un peu nouvelle (<3 ans). Ils en manquent"?
Thomas Koelle
40
Juste un FYI, si vous avez travaillé pour plusieurs entreprises, vous n'êtes probablement plus un junior.
Kevin
11
Qu'est-ce qui vous fait penser que les choses que vous citez sont "meilleures", et pas seulement la dernière lubie qui fait perdre du temps? Pouvez-vous faire une affaire raisonnable pour chacun?
jamesqf
11
"La direction est ouverte à la mise en œuvre d'améliorations [...]" , ce qui est en grande partie hors de propos, le plus important étant de savoir si le reste de votre équipe est ouvert ou non. S'ils ne le sont pas, la participation de la direction, mais non celle de l'équipe, ouvre la voie à une relation conflictuelle avec le reste de votre équipe.
Mark Rotteveel le

Réponses:

179

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.

jwenting
la source
19
Je suis tout à fait d’accord avec votre observation. La pratique est de loin le meilleur moyen de savoir ce qui fonctionne et, même dans ce cas, il y en a toujours plus et d'autres.
Kain0_0 Le
226
Si un projet est incroyablement complexe et qu'il est difficile de le modifier, il ne s'agit pas d' un «logiciel fantastique».
Steve Chamaillard le
85
Cette réponse donne l’impression que la POO est un corpus de connaissances qui obsède les universitaires, alors que l’industrie "sait mieux". D'après mon expérience, l'inverse est vrai: les universitaires se soucient très peu de la POO, alors que de nombreuses entreprises en sont encore obsédées. Les universitaires ont tendance à s'intéresser à des concepts plus intemporels mais obscurs (dont la valeur met souvent des décennies à être appréciées par l'industrie).
Theodoros Chatzigiannakis Le
13
En outre, attendez-vous à ce que les ingénieurs expérimentés se méfient des modes .
John Wu
67
"C’était un logiciel fantastique. Malheureusement, en production et en maintenance, c’était un cauchemar." La deuxième partie signifie que la première est fausse. Par définition, une bonne conception améliore les logiciels. Si la théorie ne fonctionne pas vraiment, la théorie est tout simplement fausse et la suivre est une idée terrible.
jpmc26
43

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
Kain0_0
la source
Beaucoup d'accord avec là. Une chose qui mérite d'être soulignée est qu'aucune base de code ou procédure n'est parfaite; tout est toujours un compromis. Et bien que vous souhaitiez peut-être tout jeter et recommencer, comme vous le dites, IME, il est généralement préférable d’évoluer lentement, par petites étapes. De cette façon, vous pourrez amener tout le monde avec vous et éviter de perdre les connaissances existantes. L'important est de savoir où vous voulez aller. De cette façon, vous pouvez repérer et saisir les opportunités qui se présentent.
vertiges
@gidds Je pense que c'était ce que je voulais dire, il est préférable de faire de petits changements dont tout le monde est conscient, ou du moins, il est évident que cela a changé et est facile à lire. Bien que je pense qu’il est important d’avoir à l’esprit un objectif à long terme pour vous aider à choisir entre tous les moyens d’améliorer des choses, je ne pense pas qu’il soit toujours possible de le formuler, en particulier pour les développeurs débutants ayant une expérience limitée dans le domaine. travailler à grande échelle avec les gens. Formuler des améliorations au statu quo est beaucoup plus facile. est-ce que cela vous irrite? Oui Qu'est-ce que tu peux faire pour améliorer la situation?
Kain0_0
@gidds en relisant votre commentaire, je conviens qu'aucune procédure ou processus n'est parfait, ni même applicable à une situation donnée, et si le fait de l'avoir manqué peut amener l'équipe à un endroit pire que celui qui n'a jamais essayé. Cela étant dit, même en cas de succès, le résultat final est généralement un compromis entre toutes les exigences concurrentes que le logiciel et son équipe doivent en quelque sorte satisfaire. C'est beaucoup plus difficile si l'entreprise est dans un secteur réglementé. Les gouvernements n'aiment pas ceux qui enfreignent les règles.
Kain0_0 Le
20

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.

Robert Andrzejuk
la source
1
Il me semble que vous êtes allé derrière le dos des gens sans rien justifier d’abord à vos collègues développeurs, mais qu’un gestionnaire l’a forcé. Personne n'aime "ce mec". Donc oui, si vous avez des suggestions d’améliorations, soulevez-les avec vos collègues, mais surtout: soyez en mesure de leur justifier vos suggestions. Pourquoi cela va-t-il améliorer les choses? Comment cela va-t-il sauver du temps et des efforts? Y at-il des inconvénients à la nouvelle façon? Etc. Si vous pouvez prévoir et préparer des réponses aux préoccupations des internautes, ceux-ci seront beaucoup plus susceptibles d'accepter vos suggestions volontiers plutôt que par la force.
Alex
2
Je ne me sentais pas comme si ça "passait derrière le dos des gens". J'ai signalé le problème à mon responsable, il m'a dit de m'en occuper et c'est ce que j'ai fait.
Robert Andrzejuk
17
"obtenir malheureusement un surnom dérivé du système de contrôle de code source." LOL J'espère que vous n'avez pas pris git.
Février
Git n'était pas encore là.
Robert Andrzejuk le
10
@ BЈовић Peut-être qu'ils l'appelaient "subversif" ... :-)
Alexander
14

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.

Telastyn
la source
13

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 ".
Borjab
la source
«Pas pendant les premières semaines» Je pense que surtout pendant les premières semaines, poser simplement des questions peut faire beaucoup de choses. Vous apprendrez non seulement le projet et le déroulement du travail, mais inciterz également vos collègues à comprendre pourquoi X est dans Y et non dans Z, documentation manquante, outils encombrants (pourquoi ai-je besoin de 20 commandes pour intégrer ma modification?), Etc.
Michael
1
J'ai peut-être mal dit: Bien sûr, vous devriez poser des questions sur d'autres moments et spécialement pendant les premiers jours. Mon intention, mais peut-être à mi-chemin, est qu’en tant que junior, vous ne "poussez pas pour les changements" les premiers jours car vous pouvez sembler être un arrogant et vous manquez d’outils pour quelque chose d'aussi difficile que de changer d'organisation
Borjab
9

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

Ewan
la source
6
En tant que jeune employé, j'ai proposé tout cela. Après un certain nombre d'années, avec une certaine assistance (et beaucoup de soutien), je les ai ensuite implémentées avec succès. À la fin, j'étais l'architecte principal. Cela peut fonctionner et cela vaut souvent la peine d'essayer. ;) Cependant, vous devez choisir vos batailles et savoir quand vous faites face à une lutte difficile pour quelque chose qui ne correspond peut-être même pas au profil / à la dynamique de l'organisation. Dans un autre rôle que je suis tenté d'aller sur la même route, et décidé de ne pas même aborder le sujet , car il n'aurait jamais fonctionné et n'a pas été particulièrement important non plus .
Courses de légèreté en orbite le
4
Le test unitaire et l'intégration continue sont un bon choix pour commencer. Ils vous donneront le meilleur retour sur investissement. N'essayez pas Scrum sans les pratiques techniques qui lui permettent de fonctionner. Comment pouvez-vous effectuer des déploiements fréquents si tout le monde est dangereux et nécessite beaucoup de travail de la part des testeurs et des administrateurs système?
Borjab le
Les tests unitaires / tests d'intégration ne sont pas nécessairement quelque chose que l'on peut immédiatement commencer à mettre en œuvre en raison de l'architecture. En outre, ils ont tendance à imposer certains schémas qui peuvent aller à l'encontre de l'ordre des choses existant. Bien qu'ils aient de la valeur, ce n'est pas toujours facile, comme suggéré.
NPSF3000 le
2

Ç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.

ptyx
la source
1

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.

Bernhard Hiller
la source
0

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.

Billal Begueradj
la source
0

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.

mdfst13
la source
+1; une des meilleures réponses avec beaucoup de bonnes idées.
Keith
0

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.

Offirmo
la source
0

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.
Keith
la source