Comment gérez-vous planification / délais autour des programmeurs? [fermé]

Question

Est-ce que les programmeurs aiment créer des délais? Im un développeur web et horaires / délais sont un peu partout dans mon domaine. Mais j'ai travaillé avec des ingénieurs logiciels / programmeurs qui détestent les délais, est-il un moyen de contourner cela?

Answer 1

Tout d'abord, vous devez faire la distinction entre les délais et les estimations.

• Les dates limites proviennent de sources externes, par exemple, « Feature X doit être prêt pour le salon ».
• Les estimations proviennent de sources internes, par exemple, "Feature X prendra des semaines pour compléter N".

En général, les programmeurs devraient créer des estimations et ventes / marketing va créer des délais.

Des problèmes se produisent lorsque les deux ne peuvent pas être résolus - si le délai est plus proche que l'estimation

.

Conseils utiles pour dev (fils):

• Que la personne effectuant le travail crée l'estimation.
• Assurez-estimations sont basées sur des tâches minuscules, pas chacun plus d'un jour ou deux.
• Utilisez une boucle de rétroaction pour permettre aux développeurs d'améliorer leurs compétences d'estimation.
• compétences d'estimation précis vous permet de pousser plus fort contre les demandes de délai.

Conseils utiles pour les commerçants / créateurs de délai:

• Ne pas passer outre une estimation avec une date limite.
• Si un conflit avec une estimation date limite, les seules options réelles sont (a) les développeurs font des heures supplémentaires, (b) les exigences relatives à la date limite sont rognées, ou (c) la date limite est manqué.
• Expliquez pourquoi la date limite est importante, et quel est le but de la date limite de fonction est ( « client X signera un contrat à six chiffres »).
• Il faut comprendre que les gens qui se sentent qu'ils ne peuvent pas respecter les délais agressifs ne seront pas motivés.

Answer 2

Les programmeurs HATE délais pour de très bonnes raisons!

Il est presque impossible d'estimer avec précision combien de temps un morceau de code prendra pour concevoir, écrire et déboguer jusqu'à ce que vous l'avez fait.

D'après mon expérience personnelle, j'ai passé plus d'une semaine d'obtenir un script shell « simple » au travail que j'aurais estimé à environ une heure. D'autre part a pris environ une semaine pour écrire un analyseur syntaxique pour les définitions de données COBOL (y compris tous les COMP-3 COMP bizarre ARRIVE SYNC et redéfinissent choses octets mou) que j'avais estimé à environ deux mois.

L'autre gros problème est que face à un délais de programmeurs serrés sauter les meilleures pratiques et commencer le piratage. économisant ainsi environ 50% du temps de codage, mais en ajoutant 300% à l'essai et le temps de débogage.

Answer 3

Traditionnellement, vous ne pouvez régler la qualité, les caractéristiques ou le temps, le dernier étant la date limite. La qualité que vous ne voulez vraiment pas gâcher avec. Donc, tant que le processus que vous utilisez vous permet de calibrer les caractéristiques d'atteindre des délais, je suis ok.

Answer 4

Les développeurs doivent être impliqués dans la création des délais. Si elles sont arbitraires et créé sans l'apport des développeurs alors ils ont le droit de se plaindre. Les projets se légitimement contraintes de temps des affaires, mais les ressources et les caractéristiques doivent être ajustées pour compenser. Ces ajustements ne peuvent pas être sans l'apport des développeurs (sans parler, les gens d'acceptations bancaires QA et opérations).

Answer 5

Les seuls ingénieurs logiciels / développeurs que j'ai rencontrés qui détestent les délais se sentent de cette façon pour une des deux raisons:

1. Ils sont complètement désorganisé, et savent qu'ils ne seront pas répondre à la date limite, et donc ne les aime pas parce que quand ils ratent la date limite il les rend mauvais.
2. Ils ne le font pas ont un problème avec les délais, comme tant que quelqu'un qui comprend la travail impliqué est le réglage de la date limite. Les délais sont pires fait par les gestionnaires qui tentent de vendre un projet et dire « 3 semaines? Non problème! » puis raconter leur équipe de développement qu'ils ont 3 semaines pour produire une version de travail de MS Office et recréez la internet pour petit enfant du chef de la direction.

Answer 6

Je pense que cela dépend de la façon dont les horaires sont créés. Le développeur doit avoir un rôle important à venir avec le calendrier. Sinon, comment saurez-vous si elle est raisonnable ou non?

Si quelqu'un dans la haute direction dicte simplement que « fonction X doit être fait par Y » sans avoir une bonne idée pour combien de temps il pourrait en fait prendre (certaines choses sont beaucoup plus compliquées à mettre en œuvre que ce qu'ils sonnent comme) puis c'est une mauvaise chose. Toutefois, si elles travaillent avec les développeurs pour estimer la quantité d'effort réellement nécessaire et l'équilibre que le reste des besoins de l'entreprise, il fonctionne généralement assez bien.

Answer 7

Eh bien, je suis très heureux avec un délai si ce délai a été déterminé par le processus d'évaluation bien pensé avec la participation des deux gestionnaires et ingénieurs et les exigences pour ce qui est censé être livré sur ledit délai sont bien définis.

Answer 8

Des examens réguliers sont essentiels:

• Liste des principales étapes et réalisations attendues
• Break it up en petits morceaux
• Créer une collection d'estimations plus petites
• les délais raisonnables

Vous devez avoir des délais, mais tout aussi ces délais doivent être réalistes et mesurables. Le déplacement du cahier des charges autour va agacer le développeur - il pourrait être inévitable, mais ne pas avoir peur de faire bouger les choses (après discussion).

Les délais et les estimations de travail ne vont jamais être particulièrement précis, mais si les techniques de gestion de projet de base devrait signifier que les gens connaissent les disparus - et pourquoi cela est arrivé.