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


10

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?


10
Vous n'avez aucune dette technique à rembourser? Y a-t-il des fonctionnalités prévues pour l'avenir sur lesquelles vous pourriez augmenter? De nouvelles technologies ou paradigmes que vous aimeriez essayer dans le cadre des fonctionnalités existantes?
jonrsharpe

27
@StudentT qui est incroyablement myope, étant donné la difficulté probable à remonter l'équipe une fois le bloqueur résolu.
jonrsharpe

8
@StudentT plutôt le leader devrait être congédié pour ne pas planifier pour l'avenir, ne pas prévoir que des choses comme cela puissent se produire.
jwenting

13
Devs affamés? Un mot: pizza.
Mason Wheeler

3
Si OP n'a aucune dette technique à rembourser et aucun test unitaire / fonctionnel ou script de déploiement à écrire / améliorer, il se plaint définitivement de Deaven (Dev Heaven) et je suis soudain très triste: <
xDaizu

Réponses:


29

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.


2
Cette. Le développeur moyen (moi compris) se plaint constamment d'un manque de temps pour affiner les choses. Tenez-les dessus.
Traubenfuchs

4
J'aime ce général "fais tout ce que tu n'as pas encore fait". J'ajouterais des révisions de code et une refactorisation à cela. Faites-en un logiciel vraiment soigné qui fonctionne comme une machine bien huilée et c'est un plaisir à voir. C'est satisfaisant pour les développeurs.
Peter - Rétablir Monica

des choses qui n'étaient pas assez importantes à faire auparavant ne valent probablement pas la peine d'être faites maintenant. c'est juste 'faire du travail'
Ewan

16

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.


2
J'aime l'alternative "il y a toujours quelque chose à améliorer". S'ils sont assez bons, il est préférable de se concentrer sur le problème actuel et de trouver une solution de contournement appropriée.
Walfrat

15

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.


Le simulateur n'a pas besoin d'être complet ou fantastique, juste assez pour vous permettre de progresser.
Thorbjørn Ravn Andersen

1
Je pense que c'est un conseil très solide et pas immédiatement évident. Surtout la perspective au-delà du codage, à savoir les tests. La maquette est à double valeur.
Peter - Réintègre Monica

4

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.


2

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.


0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.