En tant que programmeur, vous souciez-vous de la méthode utilisée par le processus de développement?

Je suis sur le marché du travail et j'ai un ensemble de priorités pour mon prochain emploi, y compris le salaire, le secteur d'activité, etc. Une chose qui n'est cependant nulle part sur ma liste d'exigences est la méthodologie du processus de développement. Je pense que mon travail consiste à créer des logiciels et je vois la structure du processus comme quelque chose que je peux adapter, que ce soit une mêlée, une cascade ou autre.

La méthodologie du processus de développement est-elle une priorité pour vous?

Ce n'est important pour moi que dans la mesure où nous n'obstruons pas le bon sens que nous espérons que la plupart des professionnels auraient.

Lorsque nous parlons de contrôle de version, il y a l'argument selon lequel any version control beats not having anything at allce n'est pas le cas avec les méthodes de développement. Les méthodes signifient des règles, et les règles sont parfois brisées. J'ai travaillé pour des entreprises qui ont fait des choses vraiment loufoques depuis aussi longtemps que tout le monde s'en souvienne, quel que soit le problème que la procédure maladroite qui a réussi à guérir a disparu il y a longtemps.

Je veux ce qui suit hors d'une entreprise:

• Des procédures clairement documentées qui tiennent sur quelques pages. Si je dois lire un mémoire ou (pire) un roman pour me mettre au courant, je serai perdu longtemps.

• Preuve que l'entreprise est ouverte au changement des procédures pour le mieux. Je dois pouvoir aller voir quelqu'un et lui dire: «Je comprends pourquoi tu fais [xyz], mais il y a un outil qui fait la plupart de cela pour toi maintenant. Pouvons-nous l'utiliser?

• Un peu de concurrence peut être bonne et est souvent inévitable. Mais j'éviterai tout magasin où la concurrence est utilisée comme principal moyen de motiver les gens. Si vous avez codifié quelque chose qui envoie le nombre de lignes engagées par jour par le développeur à l'imprimante laser à 17 heures, je ne veux pas travailler pour vous.

• Si vous n'avez pas empêché les builds dans les dépôts bénis de recevoir des modifications qui cassent ladite build, je cours comme un diable. La dernière chose que je veux faire à 17h00 est de retirer les modifications du référentiel maître pour tester ma version locale, seulement pour me retrouver à corriger le point-virgule de quelqu'un d'autre.

• Je préfère sauter dans des méthodes qui ressemblent à une méthode établie qui est tombée de l'arbre agile. Ce n'est pas obligatoire, mais un sentiment de familiarité aide à surmonter la bosse initiale d'essayer d'être productif sans commettre d'erreur de procédure.

Si je vois que je passerai plus de temps à ressentir les procédures qu'à être reconnaissant qu'elles existent, je passerai probablement le boulot.

L'autre retentissant "oh non, plus jamais ça!" est "Nous espérons que vous mettrez également en place les meilleures pratiques pour nous. Nous avons six millions de lignes de code et 21 télétravailleurs, devrions-nous utiliser un SVN ou quelque chose?" .

Quelqu'un pourrait s'amuser à trier ça. Je ne suis pas ce mec :)

En tant que développeur, je tiens à ce que le processus de développement soit sain. Un certain nombre de méthodologies de développement différentes peuvent fournir un processus de développement sain. Inversement, une entreprise cassée peut fournir un processus insensé, peu importe comment on l'appelle.

Par conséquent, je ne me soucie pas particulièrement de leur «méthodologie de développement» officielle. Cependant, je vais toujours poser des questions à ce sujet simplement parce que cela me donne un contexte pour poser des questions de suivi pour comprendre ce qu'ils font vraiment .

Oui, j'ai vu de mauvaises méthodologies que je ne pense pas vouloir répéter. À titre d'exemples, considérez-les: seriez-vous d'accord avec un style de cow-boy pour une équipe d'une douzaine de développeurs où chacun peut utiliser son propre contrôle de code source, ses conventions de codage, etc.? Je sais que non. Que diriez-vous où changer une ligne de code, il y a une douzaine de formulaires à remplir et une vingtaine de signatures pour confirmer le changement de production qui peut prendre des semaines car l'approbation de la direction peut prendre un certain temps? Le "quoi que ce soit" laisse les choses un peu trop ouvertes à mon esprit mais peut-être que je suis un peu cyncial ici.

En tant que développeur, je ne me soucie pas de la méthodologie utilisée, tant qu'elle est appropriée et correctement utilisée.

Ainsi, par exemple, je ne voudrais pas travailler pour une entreprise qui fait du "codage cowboy" , surtout s'ils sont suffisamment ignorants pour penser qu'ils font réellement de l' Agile .

Je préfère les endroits qui ont une méthode de développement que tout le monde peut suivre.

J'ai travaillé dans des emplois très frustrants à cause des choix de processus utilisés pour le développement et les affaires en général. Ces jours-ci, j'ai des exigences minimales pour le processus. Toute entreprise qui ne s'y livre pas est considérée comme mal gérée et ne fonctionnera pas. Je n'ai pas la patience pour l'idiotie que j'avais auparavant, donc je me sauve et je les évite d'aggraver en sautant ces emplois.

Tant que nous avons un semblant d'exigences sensées, un représentant commercial engagé et réactif, et une compréhension que l'équipe de développement a un grand mot à dire dans les délais, alors je suis heureux et je peux m'adapter à tout.