Pourquoi ne pouvons-nous rien faire?

Je travaille dans une petite équipe, dans une entreprise de taille moyenne, dont la plupart n'est pas impliquée dans le développement de logiciels. Je suis le développeur le plus récent et le moins expérimenté et je n'avais aucune formation professionnelle ou académique dans le domaine des logiciels avant de commencer, mais je suis assez satisfait du respect de mes contributions et je suis reconnaissant d'avoir été pris au sérieux à un stade aussi précoce de ma carrière.

Pourtant, je pense que je devrais faire plus avec cette généreuse quantité de temps d'antenne. En équipe, nous semblons avoir du mal à faire avancer les choses. J'aimerais pouvoir suggérer quelque chose pour améliorer la situation, et je pense que je serais écouté si c'était une bonne idée, mais je ne sais pas trop quoi suggérer.

Les choses que je peux identifier comme étant des problèmes comprennent:

• La spécification des tâches à accomplir est rare. C'est en partie parce que la gestion est un goulot d'étranglement et que nous n'avons ni l'argent ni les gens pour nous engager à élaborer des exigences détaillées autant que nous le souhaiterions. C'est aussi en partie parce que le logiciel que nous développons est d'investigation et que la méthode précise n'est pas claire tant qu'elle n'est pas démontrée et utilisée pour déterminer son efficacité.
• Le développeur principal aime beaucoup ce qu'il appelle le `` prototypage '' au point qu'il a récemment commencé à insister pour que tout soit `` prototypé '', ce qui, pour nous, ressemble à de l'écriture de mauvais code et à le donner aux modélistes pour jouer avec. On ne sait pas exactement ce qu'il attend de cet exercice dans de nombreux cas. L'implémentation «réelle» souffre alors du fait qu'il insiste sur le fait que les bonnes pratiques prennent trop de temps à partir du prototypage. Je n'ai même pas commencé à pouvoir démêler cette logique tordue et je ne suis pas sûr de vouloir essayer.
• Les modélisateurs sont censés nous dire tout sur la méthodologie souhaitée avec des détails précis, et il est acquis une confiance absolue que ce qu'ils sortent est théoriquement impeccable. Ce n'est presque jamais vrai, mais aucune mesure n'est prise pour rectifier cette situation. Personne du côté de la modélisation ne soulève de préoccupations structurées susceptibles d’être suivies d’effet, ni ne cherche à obtenir des conseils sur l’application des meilleures pratiques. Rien n'est fait non plus de leur passivité.
• J'ai déjà essayé de pousser TDD dans l'équipe, mais j'ai trouvé cela difficile car c'est nouveau pour moi et même si ceux qui surveillent mon travail étaient prêts à le tolérer, aucun autre enthousiasme n'a été manifesté par quelqu'un d'autre. Je ne peux pas justifier le temps que je passe à me vautrer et à ne pas finir les fonctionnalités, donc l'idée a - pour le moment - été abandonnée. Je crains que cela ne soit pas repris, car personne n'aime qu'on lui dise comment faire son travail.
• Nous avons maintenant un serveur d'intégration continue, mais il n'est principalement utilisé que pour exécuter des tests de régression sur plusieurs heures. On a laissé entendre qu'il devrait également exécuter des tests unitaires et d'intégration complets, mais pour le moment personne ne les écrit.
• Chaque fois que je soulève le problème de la qualité avec le développeur principal, j'obtiens une réponse à l'effet de `` La fonctionnalité de test A est simple, la fonctionnalité B est beaucoup plus importante pour l'utilisateur mais trop difficile à tester, donc nous ne devrions pas tester la fonctionnalité UNE'. Encore une fois, je n'ai fait aucun progrès pour essayer de démêler cette logique.

....phew. Quand je le formule comme ça, ça a l'air bien pire que je ne le pensais. Je suppose que, en fin de compte, c'est un appel à l'aide.

Permettez-moi de jouer l'avocat du diable un instant:

La spécification des tâches à accomplir est rare ... Le Lead Dev aime beaucoup ce qu'il appelle le «prototypage»

Le développeur principal aime le prototypage car les spécifications sont rares. C'est probablement une bonne chose; c'est ainsi que fonctionnent les boutiques itératives.

Les modélisateurs sont censés nous dire tout sur la méthodologie souhaitée en détail

Cela ne fonctionnera pas dans une boutique itérative. La nature même du développement itératif est que les exigences sont souvent incomplètes. Les itérations sont ce qui est nécessaire pour étoffer les exigences.

J'ai déjà essayé de pousser TDD dans l'équipe, mais j'ai eu du mal car c'est nouveau pour moi

Cela ne fonctionnera pas non plus; vous devez comprendre la technologie avant de pouvoir l'évangéliser. De plus, dans un magasin itératif avec peu d'exigences, le TDD peut être trop lourd. Il vaut mieux encourager une couverture adéquate des tests unitaires.

Nous avons maintenant un serveur d'intégration continue, mais il n'est principalement utilisé que pour exécuter des tests de régression sur plusieurs heures.

Cela peut être approprié dans un petit magasin itératif.

Chaque fois que je soulève le problème de la qualité avec le développeur principal, j'obtiens une réponse à l'effet de `` La fonctionnalité de test A est simple, la fonctionnalité B est beaucoup plus importante pour l'utilisateur mais trop difficile à tester, donc nous ne devrions pas tester la fonctionnalité UNE'

Il semble que votre boutique ait des contraintes de temps assez serrées; que cela vous plaise ou non, vous êtes lié par ces contraintes.

Il semble également que vous veniez d'une partie de l'industrie du logiciel qui valorise de faire les choses "dans le bon sens" plutôt que de mettre les choses sur le marché en premier. Il n'y a rien de mal à cela (c'est admirable, en fait), sauf que le premier à commercialiser un logiciel buggé est souvent le gagnant. Ce n'est pas juste, mais c'est comme ça.

Je vais me concentrer sur le prototypage ici

le problème majeur avec les prototypes est qu'ils sont censés être une preuve de concept

Cependant, si vous ne pouvez pas continuer à construire sur le prototype et que vous devez reconstruire le produit final à partir de zéro, vous pourriez aussi bien ne pas avoir construit le prototype et vous avez perdu votre temps à le construire.

mon conseil à votre équipe est d'obtenir une certaine qualité et flexibilité dans ces prototypes. Je sais qu'il n'est pas possible de créer des choses parfaites du premier coup, mais essayez de rester extensible pour les besoins futurs

Ce sont de bonnes réponses. Je peux seulement ajouter que "essayer de communiquer" est au mieux une proposition incertaine. Les changements dans le fonctionnement d'une organisation ne se produisent pas rapidement. Quand cela se produit, c'est souvent comme une marée, où l'élan se construit d'en bas et d'en haut. Vous serez donc plus heureux si vous gardez vos attentes basses et attendez votre chance de dire comment les choses seront faites ou attendez avec impatience de travailler avec une autre organisation.

Avez-vous identifié quelqu'un dans l'entreprise qui "comprend" si c'est le cas, accrochez-vous à ce type et apprenez autant que possible de lui. Sinon, attendez votre temps, commencez à apprendre et à grandir par vous-même (rejoignez un projet Open Source ou lancez votre propre projet) et cherchez un endroit qui peut favoriser votre croissance.

La pire chose qui puisse arriver est que vous restiez sur place et que vous appreniez à faire les choses de la mauvaise façon. Oui, il devrait y avoir un certain pragmatisme, mais une équipe vraiment qualifiée peut faire les choses de la bonne façon et toujours à l'heure avec un produit de qualité. Il semble que votre équipe actuelle n'ait pas ce qu'il faut et vous devriez commencer à en chercher une nouvelle.