Ajout d'un nouveau développeur juste avant la date limite n'est horrible. Mais qu'est-ce qui n'est pas?
Imaginez qu'un projet est attribué à une équipe, une date limite est estimée à 8 mois. Après 6 mois, cela devient apparent, le projet ne sera certainement pas terminé à l'heure (par exemple, des changements de loi ou un obstacle monumental caché est découvert, le device de plomb se fait frapper par un bus, etc.). Mais le projet est important (par exemple, perdre un client important sur l'échec ou avoir à payer des réparations).
Une solution que nous sommes tous d'accord est horrible est ajouter plus de développeurs , surtout nouveau à la société. Ils auront besoin d'au moins un mois pour se mettre à la hauteur et occuper le reste de l'équipe pendant cette période.
Une solution que nous sommes tous d'accord est génial est la prévention. Mais de telles situations se produisent.
Qu'est-ce qu'une solution raisonnable dans une telle situation pour le gestionnaire de l'équipe, à condition d'avoir beaucoup d'effet de levier pour des personnes supplémentaires, un financement, une négociation client, etc.?
Il est devenu reçu la sagesse qui "ajouter plus de main-d'œuvre à un projet tardif le rendra plus tard". Mais c'est une simplification excessive, le résultat dépend de plusieurs facteurs:
- Dans quelle mesure les développeurs sont-ils disponibles? Il y a une grande différence entre l'ajout de développeurs junior qui a besoin de nombreux conseils et d'ajouter des développeurs expérimentés capables de rechercher et de comprendre des choses à leur place et de se lancer rapidement.
- Dans quelle mesure spécifié et documenté est le projet? Toutes les connaissances n'existent-elles que dans les têtes des développeurs actuels ou de nouveaux développeurs travaillent-ils de la documentation de formulaire?
- Quelle est la complexité et interdépendante du projet? Est-il possible de partitionner dans des tâches de développement plus distinctes?
- Quelle est la qualité du code existant? Est-ce modulaire avec peuplement faible, ou est-ce une grande boule de spaghetti?
Vous obtiendrez des retours diminuant en ajoutant plus de développeurs, mais cela ne signifie pas que vous n'aurez pas nécessairement aucun retour négatif. Il pourrait très bien être un bon investissement si le coût de la livraison est en retard élevé.
Encore, ajouter plus de développeurs n'est pas la seule solution. Les principaux leviers sont:
- Réduire la portée (supprimer les fonctionnalités ou les reporter à une version ultérieure)
- Ajout du temps (c'est-à-dire que la date limite)
- Ajouter des développeurs
- Au fil du temps
Chacun a ses risques. Par exemple, les heures supplémentaires donneront un coup de pouce à court terme, mais auront des rendements décroissants. L'ajout de développeurs est le contraire - ce sera une diminution à court terme de la productivité, mais une prestation à long terme.
La réduction de la portée est absolument l'approche la plus sûre et la moins risquée. Si vous passez à travers les exigences, il peut s'agir de certaines des fonctionnalités ne sont pas aussi critiques que la première pensée. Lors de la négociation avec les clients, il est souvent plus facile de parler de fonctionnalités de reportage plutôt que de les déposer. Puis reconsidérer pour la prochaine version.
Vous voudrez peut-être combiner plusieurs, par exemple. Réduire la portée et reporter la date limite.
Il est important de noter que vous devez examiner la raison du bordereau en premier lieu. Vous mentionnez un développeur principal qui a été touché par un bus. Ceci est un événement imprévisible qui est peu susceptible de se reproduire. Mais dans le monde réel, la raison la plus courante des projets tardifs est:
- Fluage portée
- Spécifications incomplètes/vagues
- Estimations de temps trop émis
- Beaucoup de bugs et de régressions
Si vous souffrez d'une étendue fluage, ajoutez plus de temps ou de plus de développeurs ne vous aiderez pas. Il va probablement augmenter le taux de fluage de la portée. Vous devez donc gérer cela avant toute autre chose.
Les spécifications incomplètes rendent très difficiles à gérer un projet délimité. Certains projets agiles éloignent des spécifications tout à fait, mais notamment ceux-ci n'ont pas de portée fixe ou de délai fixe. Si vous avez une portée et une échéance fixes, vous avez également besoin d'une spécification.
Si le retard est dû au fait que certaines tâches se sont avérées plus prises en charge que prévu, vous devriez vous attendre à ce que les autres tâches encore non finies envahiraient également les estimations.