Comment gérer les mentalités ad hoc?

J'ai rejoint une équipe de développement de six personnes il y a deux mois. Les gens sont gentils, tout va bien. Mais j'observe de plus en plus un état d'esprit ad hoc. Les trucs sont rapidement corrigés, au prix d'une utilisation future, il y a peu de tests et deux personnes ont admis avec plaisir qu'ils aiment porter les connaissances dans leur tête plutôt que de les écrire.

Comment y faire face? Je voudrais donner l'exemple, mais le temps est limité - j'aime architecturer et réellement mettre en œuvre les choses. Mais je crains que l'état d'esprit ad-hoc ne m'infecte et plutôt que de viser la clarté et la simplicité dans la conception et le code - ce qui n'est pas simple à établir - je suis entraîné dans le vide d'une spirale sans fin de hacks sur hacks - qui non L'étranger peut se dissocier - juste pour le respect du calendrier et de la gestion.

— Rotian
source

Je suggère un coup de pied tombant pour provoquer un manque de capacité à conserver des souvenirs. La documentation est essentielle pour tout système à longue durée de vie ... même si elle n'est pas formelle.

— Rig

Bienvenue dans le développement de logiciels!

— yannis

@YannisRizos, non non non! ;)

— Rotian

@Rotian Ceci est presque une lecture obligatoire: joelonsoftware.com/articles/fog0000000332.html . Un peu dépassé, mais toujours une excellente ressource, et vaut probablement une réponse en soi.

— K.Steff

Plus largement, je recommande "Clean Oncle Bob" / "Clean Code /" et / The Clean Coder /. Je ne suis pas d'accord avec tout ce qu'il dit dans ces livres, mais c'est une très bonne matière à réflexion. Ils m'ont certainement beaucoup ouvert les yeux!

— Michael Scott Shappe

Réponses:

Vous connaissez déjà une partie de la réponse: vous devez donner l'exemple. Vous devez également vous familiariser avec le fait que votre "leadership" pourrait être ignoré, que vos collègues continueront à faire les choses comme ils l'ont toujours fait - soit parce que cela rend le patron heureux, soit parce qu'ils apprécient eux-mêmes l'opportunité par rapport à maintenabilité à long terme.

En fin de compte, vous devez laisser vos résultats parler d'eux-mêmes. Vous avez manqué un délai de trois jours, mais vous avez épargné à l'équipe AQ au moins autant de jours de test prévus parce que vous avez piloté votre développement et que cela fonctionne en grande partie comme prévu? C'est une victoire.

En fin de compte, cependant, si vous n'avez pas au moins un certain degré d'adhésion de la direction pour ce type de compromis, vous êtes simplement dans le mauvais environnement et vous devez en trouver un de plus propice aux bonnes pratiques. Les mauvaises pratiques créent des habitudes, donc le plus tôt vous pouvez soit trouver un moyen de vous tenir debout, soit passer à un environnement de travail avec de meilleures pratiques, mieux c'est.

— Michael Scott Shappe
source

J'apprécie votre réponse. Je suppose que vous connaissez très bien mon environnement - j'essaierai de travailler plus dur - et si je ne reçois pas de rôle - je chercherai autre chose.

— Rotian

+1. Soyez le changement que vous souhaitez voir dans votre équipe. Fixez la norme.

— Scott C Wilson

+1 pour laisser les résultats parler d'eux-mêmes. Cela, combiné avec l'exemple, est le meilleur moyen d'affecter un changement positif. Les gens veulent naturellement faire du bon travail (la plupart, de toute façon), et s'ils voient quelqu'un obtenir des résultats meilleurs que les leurs, ils sont susceptibles de demander le secret. Et ils sont beaucoup plus susceptibles d'écouter lorsqu'ils demandent de leur propre gré que s'ils sont informés, non sollicités.

— Erik Dietrich

@Rotian Pas votre environnement spécifique, bien sûr, mais oui, j'y suis allé, et je l'ai fait. Le pire, à l'époque, je ne comprenais même pas à quel point c'était grave. Je savais seulement que quelque chose n'allait pas subtilement à un niveau profond, et j'ai finalement décidé que c'était suffisant pour sortir. Ce n'est qu'au cours des dernières années que j'ai pu signaler des pratiques spécifiques qu'ils auraient dû (ou ne devraient pas) faire.

— Michael Scott Shappe

Rien?

Je veux dire, les contraintes de temps d'affaires existent. Le vôtre pourrait être un scénario où le temps de mise sur le marché est plus précieux que la facilité d'utilisation future.

Si vous êtes un programmeur de base, établir des normes et vous préoccuper de l'architecture du produit n'est pas vraiment votre travail (en particulier 2 mois). Vous devez vous efforcer d'améliorer le produit comme vous le pouvez (y compris le changement de culture), mais pas au détriment de l'aliénation de votre équipe et / ou de votre patron. Être le nouveau gars qui pense qu'il sait mieux est un moyen rapide et facile de le faire.

Je demanderais pourquoi vous faites toutes ces corrections rapides de piratage? Est-ce dû à des correctifs rapides précédents? Il est alors assez facile de souligner que si les choses étaient bien faites en premier lieu ...

En fin de compte, les mauvaises pratiques de programmation entraînent une douleur concrète. Si les gens pensent que non, il vous suffit d'attendre.

— Telastyn
source

Pour autant que je comprends, le problème n'est pas que ces personnes apportent des correctifs ad hoc en raison de contraintes de temps. Le problème est qu'ils ne voient pas cela comme une dette technique qui devrait être remboursée à l'avenir. C'est comme sauter: vous pouvez vous débrouiller sans le soutien de la Terre pendant un certain temps, mais vous feriez mieux d'être prêt à atterrir.

— 9000

@ 9000: le PO dit que c'est pour des raisons de calendrier et de gestion, donc je suppose (en espérant) que c'est surtout une contrainte de temps. Il n'est pas rare de sous-estimer le travail réel impliqué dans le développement de logiciels.

— Telastyn

Je conviens que les mauvaises pratiques conduisent à une douleur concrète; mais la douleur concrète ne conduit pas toujours aux changements que vous attendez de voir dans un monde rationnel. Par expérience, je peux vous dire qu'il existe des managers qui n'apprendront pas de cette douleur et ne viendront pas encourager les bonnes pratiques. Ils continueront de s'embrouiller, car autrement, il faudrait tenir tête à LEURS patrons pour plaider pour passer du temps à le faire "correctement", ce qu'ils ne sont pas toujours prêts à faire.

— Michael Scott Shappe

@UncleMikey: Bien sûr. Mais si vos gestionnaires sont trop inefficaces pour planifier les choses de manière appropriée, vous ne pouvez pas faire grand-chose.

— Telastyn

@ 9000 et Telastyn - oui, c'est les deux je pense - une certaine ignorance sur le fait qu'une chose comme la dette technique existe vraiment combinée avec un environnement qui encourage les solutions de contournement pour diverses raisons différentes (que ce soit le temps, l'habitude, etc.).

— Rotian