La responsabilité sans autorité n'a pas de sens - une solution technique?

Question

Mon père dit toujours "La responsabilité sans autorité n'a pas de sens".

Cependant, je trouve qu'en tant que développeurs, nous sommes toujours bloqués dans des situations où nous sommes:

• Veiller à ce que le logiciel soit "sans bug", mais n’a pas le pouvoir de mettre en œuvre un système de suivi des bogues
• Responsable du respect des délais impartis aux projets, mais ne peut pas influencer les exigences, la qualité ou les ressources de l'équipe (les trois éléments de la gestion de projet)
• etc.

Bien sûr, il y a beaucoup de choses que vous pourriez dire pour contourner cela: trouver un nouvel emploi, vous battre avec un patron, etc.

.

Mais qu’en est-il d’une solution technique à ce problème? Autrement dit, quels types de code pouvez-vous effectuer vous-même sans avoir à convaincre une équipe de corriger certains de ces problèmes - ou quel type d'outils pouvez-vous utiliser pour démontrer pourquoi des bugs non suivis vous nuisent? , les délais ne sont pas respectés à cause de problèmes de qualité, et comment utiliser ces outils pour gagner plus d'autorité sans avoir à être le patron?

*** Un exemple - le patron vient vous voir et dit "Pourquoi y a-t-il tant de bugs !!?!?" - la plupart d’entre nous diraient "Nous n’avons pas un bon système pour les suivre!", mais c’est généralement considéré comme une excuse, selon mon expérience. Et si vous pouviez indiquer un rapport (les gestionnaires adorent les rapports) et dire "Vous voyez, c’est la raison pour laquelle"?

Answer 1

Tout ce que vous pouvez faire est de votre mieux, ne vous sentez pas comme si la clé du succès d'un logiciel repose uniquement entre vos mains, en tant que membre d'une équipe, et ne doit pas être responsable de tout.

Évidemment, vous êtes dans un environnement qui affecte négativement votre logiciel, mais ne peut pas changer tout son comportement. Je vous recommande donc de commencer par le vôtre, de commencer à travailler en équipe avec vos propres bogues, délais, exigences, qualité et ressources. ne vous embêtez pas pour le reste du bazar, mais essayez d’être le meilleur dans votre travail.

Travaillez comme une équipe autonome, montrant à votre patron vos plans et vos rapports de progression, demandant plus de ressources lorsque vous en avez besoin et montrant comment ses plans sont affectés lorsqu'il les donne ou non.

Vous trouverez davantage de conseils à ce sujet dans les PSP et TSP articles de Wikipédia

Après avoir montré un bon travail à votre patron et respecté vos propres délais, il vous fera sûrement davantage confiance et laissera certaines de vos idées à l’ensemble de l’équipe.

Answer 2

Vous n'avez pas besoin d'un système de suivi des bogues, vous avez besoin de tests automatisés: tests unitaires ou autres. Vous pouvez configurer des tests automatisés avec un Makefile. Vous pouvez toujours trouver des chemins bloqués par la direction, mais cela ne signifie pas pour autant que vous ne pouvez pas faire quoi que ce soit dans les limites de votre travail. Bien entendu, la réponse pourrait être "trouver un autre emploi". Si vous ne pouvez pas trouver un autre emploi maintenant, acquérez quelques compétences pour pouvoir le faire.

Answer 3

La réponse est simple: vous pouvez commencer à utiliser les outils vous-même.

Améliorez votre travail propre . Si les gens veulent que vous corrigiez le code, dites-leur de déposer un bogue. Montre-leur comment. Assurez-vous qu'ils peuvent le faire sans rien installer. Ils veulent une mise à jour de statut? Dites-leur de vérifier le bogue. Ils demandent un changement de code que vous avez fait? montrez-leur comment faire une requête de l'historique du contrôle de source. ou montrez-les simplement sur votre boîte. Commencez à leur montrer ce que fonctionne .

Et lorsque vous avez besoin des mêmes résultats, demandez-leur de faire les démarches nécessaires. Lorsque vous ne trouvez pas les modifications dans votre contrôle de code source, demandez-leur de commencer à différencier manuellement leurs révisions des bandes de sauvegarde. Ne faites pas leur travail, ni celui du contrôle de source et du suivi des bogues, pour eux.

Et surtout, lorsque vous appliquez cette pression des pairs, soyez gentil à ce sujet . Les mouches et le miel et tout.

S'ils ne l'obtiennent pas, vous pouvez continuer à être le seul développeur professionnel. dans votre entreprise ou votre groupe. Ou du moins, cela aidera à compléter votre curriculum vitae: "avez de l'expérience dans la configuration de logiciels CVS et FogBugs pour améliorer la qualité des produits", entre autres.

Answer 4

En ce qui concerne les outils spécifiques permettant de montrer que des bogues non suivis nuisent à la capacité de l’équipe de produire du code qualité, vous avez un catch-22 ici, car vous avez besoin de quelque chose pour suivre les bogues avant de pouvoir montrer leur effet. Vous ne pouvez pas mesurer ce que vous ne pouvez pas suivre. Alors que faire?

À titre d’exemple analogue, un membre de notre équipe qui a récemment rejoint notre équipe a estimé que la façon dont nous examinions les codes par courrier électronique était ridicule. Il a donc trouvé un outil open source, l'a installé sur sa boîte, a invité quelques membres de notre équipe à l'esprit ouvert à l'essayer pendant un moment, puis l'a présenté à notre chef d'équipe. En quelques semaines, il a eu l’occasion de le présenter à toutes nos équipes. Le nouveau gars influençait toute la société. J'ai entendu beaucoup d'histoires sur l'adoption de cet outil de type guérilla.

L'astuce consiste à identifier les personnes habilitées à prendre la décision, à déterminer ce qu'elles valent et à rassembler suffisamment de preuves pour démontrer que ce que vous souhaitez mettre en œuvre leur apportera ce qu'elles valent.

Pour en savoir plus sur la manière de diriger depuis le milieu ou le bas d'une organisation, consultez le Leader des 360 degrés de John Maxwell.

Answer 5

Si vous souhaitez un rapport sur la qualité et son impact sur la productivité, voici le meilleur: http://itprojectguide.blogspot.com/2008/ 11 / caper-jones-2008-software-quality.html Caper Jones a quelques livres et est toujours présente lors de conférences. En dehors d'un bon IDE, un groupe de développeurs / informatique a besoin d'un contrôle de code source (VSS, SubVersion, etc.) et d'un suivi des problèmes

Answer 6

Si l'on demande à un comptable de créer un ensemble de comptes sans utiliser une double entrée et sans solde, personne ne s'attendrait à ce que le comptable le fasse.

Cependant, la comptabilité en double est en usage standard depuis le 13ème siècle environ.

Il faudra beaucoup de temps avant que notre profession adopte des pratiques standard tellement enracinées que personne ne travaillera sans elles.

Désolé, je pense que nous devrons faire face à ce type de problème pendant plusieurs années à venir.

Answer 7

Désolé de ne pas avoir répondu directement à votre question, mais ...

Je suis convaincu que l'échec dont vous parlez est un échec de la communication et il nous incombe, en tant que professionnels, de développer nos compétences en communication au point où nous sommes suffisamment respectés et dignes de confiance pour tirer parti de l'autorité dont nous avons besoin pour améliorer notre fonctionnement. environnements et processus que vous suggérez.

En bref, je ne pense pas qu'il existe une solution technique capable de résoudre tous les problèmes créés par une mauvaise communication sur le lieu de travail.

La technologie a plutôt causé l'attrition de la communication directe en face à face.

Désolé, je suis de nouveau sur une tangente - n'hésitez pas à mettre au point.

Answer 8

Ne coder que vous ne pouvez garder que vos propres fichiers source, bien commentés, gardez un nombre de bogues faible avec des tests. Mais vous allez avoir besoin d’outils externes pour suivre les progrès et les bugs (bugzilla, yoxel, trac, outils de diagramme de Gantt, Mylyn pour Eclipse, un blog, peu importe). Dans ces cas, les personnes, la discipline, les bonnes habitudes et le leadership constituent la force la plus écrasante. Aucun logiciel ni aucune offre individuelle ne peut gagner seul.