Comment puis-je planifier le développement de logiciels agiles?

Question

Je suis un pigiste. Chaque fois que je conçois un nouveau site Web ou une application de bureau, j'essaie d'estimer le temps dont j'ai besoin pour développer, déboguer et tester chaque composant. Cependant, quand je commence à l'implémenter, je me rends compte que j'ai besoin de plus de temps à cause de bugs que je ne comprends pas ou d'exceptions auxquelles je n'avais pas pensé. En conséquence, je suis toujours derrière mon emploi du temps. Cela devient pire quand les clients voient une démo ou les composants que j'ai développés et ils réalisent que le projet peut être plus intéressant que ce qu'ils avaient pensé et ils commencent à demander de plus en plus de fonctionnalités. J'apprécierai que vous me disiez comment apprendre à planifier de telle sorte que je puisse réussir à terminer le projet à temps.

Answer 1

Tout d'abord, c'est un problème que tous les développeurs de logiciels ont. Peut-être à part ceux qui font des trucs vraiment ennuyeux, mais ce n'est pas ce que j'appellerais le développement de logiciels.

Le développement de logiciel n'est pas comme repasser des chemises. Si vous en avez terminé une en 5 minutes, vous pouvez être sûr que vous aurez besoin de 20 minutes supplémentaires pour les 4 autres.

Ce type de travail routinier représente peut-être 20% du développement logiciel. Le reste ressemble davantage à un travail scientifique, à savoir comment les choses fonctionnent. Cela implique aussi beaucoup de créativité. Ces choses sont presque impossibles à estimer. Vous pourriez trouver une solution dans les 10 minutes. Vous pouvez également travailler dur pendant une journée ou plus sans aller un peu plus loin. D'autre part, il est compréhensible que votre client (ou votre direction) a besoin de savoir quand le logiciel sera prêt et combien cela va coûter.

Alors, que pouvez-vous faire? Voici quelques recommandations:

• Utilisez votre expérience. Analysez vos projets précédents. Combien avez-vous estimé, combien cela a-t-il vraiment pris? Utilisez l'écart comme facteur de correction. Les simplifications populaires de cette méthode sont "Double it", "Triple it" et ainsi de suite.
• Utilisez une méthodologie agile. Cela signifie que vous devez convaincre votre client de procéder par petites étapes. Il est beaucoup plus facile d'estimer les petites étapes. Après chaque étape, les commentaires du client sont requis. Si des problèmes inattendus surviennent, expliquez-les immédiatement à votre client. Faites-lui comprendre que des efforts supplémentaires sont nécessaires. Agile est probablement la meilleure solution, mais elle nécessite une certaine confiance entre vous et votre client.

Vous avez également mentionné que votre client a besoin de fonctionnalités supplémentaires pendant le développement. C'est compréhensible, personne ne peut penser à tout à l'avance. Mais expliquez à votre client que ces demandes de changement vous causeront du travail supplémentaire pour lequel il doit payer.

Answer 2

Statistiquement, l'estimation initiale est dépassée pour 300% :) Dans votre cas, lorsque le modèle «prix fixe» est utilisé, ajoutez au moins 20% pour couvrir les risques. En outre, si possible, fournissez deux valeurs: "l'implémentation prendra de 40 à 60 heures selon l'API". Encore une fois, comme il s'agit d'un «prix fixe», aucune modification ne peut être ajoutée à la portée initiale, cela doit être précisé au client. Si vous recevez une nouvelle demande de fonctionnalité, estimez-la comme une œuvre distincte (option plus appropriée) ou réestimez la portée initiale (si vous ne pouvez pas l'estimer séparément). Si les exigences sont trop vagues, il est préférable d'utiliser le «temps et le matériel», lorsque vous recevez vos heures de travail réelles, car vous ne serez pas en mesure de donner une estimation précise.