Que faire avec une équipe de développement qui meurt de faim? [fermé]

Cela craint d'être sur le chemin critique en tant que développeur normal, surtout si vous êtes en retard. Lorsque vous êtes le développeur senior, que l'équipe recherche pour le leadership, c'est encore pire.

Lorsque le travail de la majeure partie de l'équipe est au point mort, attendant une pièce critique, que doit faire le reste de l'équipe? Nous avons un accès limité à la pièce critique de sorte que d'autres attendent simplement, peu importe ce que nous faisons. Quand les autres cherchent des conseils sur quoi faire, quelle est la bonne réponse?

Améliorez les tests unitaires, les tests fonctionnels, la documentation, les outils, etc. Il y a une pléthore de choses qui peuvent être faites en temps d'arrêt en attendant que le chemin critique se rattrape.

Bien que j'aime la réponse sur l'amélioration des tests, de la documentation, etc., et c'est une bonne réponse, vous pouvez également la consulter:

• En aidant le composant du chemin critique, cela irait-il plus vite avec la programmation en équipe / entre amis?
• Restructuration du composant critique en plusieurs sous-composants sur lesquels tout le monde peut travailler.
• Dummy sur le composant critique avec quelque chose, peut-être rugueux, qui fait essentiellement le même travail mais peut-être pas assez rapide pour la production.
• Établissez une API pour le composant critique, corrigez cela plus ou moins dans la pierre et aidez à obtenir les fonctionnalités de base de ce composant implémentées (sous réserve de changements dans l'implémentation mais pas d'API).
• Voyez si vous pouvez utiliser des versions précoces et problématiques du composant critique pour travailler sur le reste du système où la fonctionnalité est "assez bonne pour l'instant".

C'est également une bonne idée de commencer la phase des "leçons apprises" maintenant en enregistrant que ces composants critiques doivent être démarrés plus tôt dans le processus de développement, peut-être avant que le reste de l'équipe ne soit réunie.

Vous avez besoin d'un plan de sauvegarde pour votre livrable tardif

Si une pièce critique est déjà en retard, rien ne garantit qu'elle ne glissera pas encore plus. Et alors? Vous attendez juste pour toujours? Ce n'est pas le genre de réponse que vous voulez avoir à dire à la haute direction.

Construisez un simulateur

Une façon de gérer le risque est de commencer à travailler sur un simulateur (harnais, cale, talon, quel que soit le nom que vous voulez lui donner) pour remplacer la pièce critique manquante.

A-t-il une interface définie? Mettre en œuvre.

At-il une documentation détaillée? Imitez-le du mieux que vous le pouvez.

Est-ce juste l'idée de quelqu'un? Voyez si vous pouvez obtenir un prototype.

Puis, quand ils glissent à nouveau l'horaire ....

De cette façon, quand ils glissent à nouveau, vous avez un as dans votre poche arrière pour combler l'écart. Non seulement votre équipe sera débloquée (elle pourra s'intégrer au simulateur), mais vous gagnerez un précieux atout logiciel.

S'ils glissent encore plus de temps, utilisez le temps d'écrire des tests d'intégration automatisés (contre votre simulateur, pour l'instant). De cette façon, lorsqu'ils fournissent la vraie chose, vous pouvez simplement exécuter vos tests et détecter les différences de comportement entre la maquette et le livrable. Cela vous permettra de vous concentrer sur les points que vous devez réviser. En bonus, vous aurez rapidement une idée de combien ils ont coupé les coins au fil de leur temps.

Si le composant critique a une interface connue et s'il n'y a aucun espoir de le faire en peu de temps, pourquoi ne pas construire un double test (par exemple une maquette )?

Cela permettrait à l'équipe de poursuivre le codage, bien que les résultats des tests soient légèrement moins significatifs.

Mis à part l'évident "faites toutes ces choses que vous n'avez pas pu faire jusqu'à présent", il semble que vous et votre équipe n'ayez pas l'esprit tranquille pour faire quoi que ce soit sans rapport avec le projet en retard. Ce qui est compréhensible mais pas utile.

Le vrai problème peut donc être de se détendre à ce sujet. Je ne dis pas indifférent. Soyez conscient de votre responsabilité, de ce que vous pouvez faire pour aider et si cela vous laisse du temps libre, profitez-en. Vous ne pouvez ni ne devez être constamment sur vos gardes. Si vous êtes un leader, je dirais que cela devrait être votre message. Transférer votre nervosité à l'équipe ne rendra pas une équipe plus productive quand cela compte.

Vous ne dites pas quelle méthodologie vous utilisez, ce qui rend difficile de conseiller exactement.

Là où je travaille s'il y a un bloqueur, c'est la main à la pompe qui fait tout ce qu'elle peut pour accélérer le développement.

Demandez-vous s'il pourrait y avoir un problème plus large avec vous en tant que lead prenant trop de place. Oui, les gens se tourneront vers vous pour un leadership technique, mais cela ne signifie pas que certains des membres de votre équipe les plus compétents ne peuvent pas partager la charge de travail s'ils sont encadrés.

Mis à part cela, y a-t-il d'autres travaux non critiques sur lesquels ils peuvent aller de l'avant? De plus, y a-t-il des travaux qu'ils ont achevés qui pourraient être peaufinés (refactorisé, enlevez la dette technique, la documentation, en ajoutant des tests, etc.).

S'il n'y a vraiment rien, donnez-leur quelque chose - parcourez les journaux, les constructions, les documents, les plans de test, les conceptions, les diagrammes, écrivez les ordres du jour, organisez les réunions, organisez des séances de sacs bruns, partagez les connaissances, etc. Il y a toujours quelque chose à faire. Si les gens sont volontiers assis à ne rien faire sur la pièce de l'entreprise, cela devrait être escaladé car ils ne sont clairement pas des joueurs d'équipe.