Comment évaluer le temps de développement d'un projet informatique ?
Une des causes est la difficulté de trouver une méthode pour évaluer a priori le temps nécessaire pour mener à bien chaque tâches qui constituent le projet. Précisons que, d'après moi, deux réalités limitent de manière incontournable la possibilité de chiffrer correctement un projet :
1. La méconnaissance des technologies utilisées. Si on ne connaît pas les contraintes des outils de développement, les limites et les difficultés d'une technologie que l'on compte employer dans un projet, voire pire, que l'on n'ait la moindre idée au départ des technologies que l'on va mettre en oeuvre, impossible d'évaluer correctement le temps de réalisation. On devrait toujours se ménager un temps raisonnablement court pour lever ces incertitudes techniques avant toute planifications.
2. Dans une démarche de développement itératif, qui devrait être la démarche la plus courante de développement, on est limité dans sa vision à quelques itérations, au delà, c'est le brouillard. En effet, le but de ces itérations est de découvrir les besoins réels des utilisateurs, besoins qui sont difficilement formalisables au démarrage du projet. Cela peut conduire à des réorientations majeures. La planification d'un développement itératif est, elle aussi itérative. Pour contourner la difficulté, on peut au départ se fixer un temps maximal de développement. La consommation de ce temps fait aussi partie des éléments à prendre en compte pour décider de l'orientation des itérations prochaines.
Ceci étant dit, comment évaluer lorsque l'on sait ce que l'on doit faire pour la prochaine itération et que l'on a raisonnablement levé les incertitudes technologiques ?
Le cas idéal est celui où on a déjà réalisé un projet similaire. Il suffit alors d'adapter à la marge les temps constatés lors du premier projet.
Si l'on n'est pas dans ce cas, que faire ?
Lorsque j'ai commencé à faire de l'informatique de manière professionnelle, disons au début des années 1990, étaient en vogue des méthode de quantification. Par exemple : compter de nombre d'écrans applicatifx, en faisant le distingo selon la complexités des écrans. Plus élaborée était la méthode dite des points de fonctions qui consiste à quantifier les services fonctionnels rendus à l'utilisateur par l'application. Ces méthodes ne prenaient pas suffisamment en compte deux points pourtant essentiels du développement informatique :
- Elle ne s'intéressaient qu'à l'extérieur de l'applicatif en négligeant les efforts de construction de l'architecture logicielle sous-jacente
- Elles négligeaient le fait que certains services fonctionnels conduisent dans la pratique à des saut technologiques mal évalués par ces méthodes.
De fait, ces méthodes étaient vraiment adaptées à des environnements très stables techniquement et fonctionnellement, environnements de type progiciel.
J'ai pour ma part, modestement, une méthode qui peut faire rire par sa simplicité. Elle consiste à décomposer les tâches d'un projet en sous-tâches, puis ces sous-tâches et sous-sous-tâches, etc... On s'arrête lorsqu'on atteint des tâches "atomiques", c'est à dire des tâches où l'on peut comprendre dans le détails comment elles vont être réalisées concrètement. On affecte à ces tâches 5 jours. Hé bien, malgré l'aspect bricolage de la méthode, je trouve qu'elle permet une précision assez étonnante.
Dans la pratique, certaines de ces tâches atomiques prennent plus de 5 jours, d'autres moins, mais 5 jours semble être une moyenne correcte pour une tâche que l'on ne détaille pas, mais que l'on peut concevoir clairement.
Si l'on n'est pas dans ce cas, que faire ?
Lorsque j'ai commencé à faire de l'informatique de manière professionnelle, disons au début des années 1990, étaient en vogue des méthode de quantification. Par exemple : compter de nombre d'écrans applicatifx, en faisant le distingo selon la complexités des écrans. Plus élaborée était la méthode dite des points de fonctions qui consiste à quantifier les services fonctionnels rendus à l'utilisateur par l'application. Ces méthodes ne prenaient pas suffisamment en compte deux points pourtant essentiels du développement informatique :
- Elle ne s'intéressaient qu'à l'extérieur de l'applicatif en négligeant les efforts de construction de l'architecture logicielle sous-jacente
- Elles négligeaient le fait que certains services fonctionnels conduisent dans la pratique à des saut technologiques mal évalués par ces méthodes.
De fait, ces méthodes étaient vraiment adaptées à des environnements très stables techniquement et fonctionnellement, environnements de type progiciel.
J'ai pour ma part, modestement, une méthode qui peut faire rire par sa simplicité. Elle consiste à décomposer les tâches d'un projet en sous-tâches, puis ces sous-tâches et sous-sous-tâches, etc... On s'arrête lorsqu'on atteint des tâches "atomiques", c'est à dire des tâches où l'on peut comprendre dans le détails comment elles vont être réalisées concrètement. On affecte à ces tâches 5 jours. Hé bien, malgré l'aspect bricolage de la méthode, je trouve qu'elle permet une précision assez étonnante.
Dans la pratique, certaines de ces tâches atomiques prennent plus de 5 jours, d'autres moins, mais 5 jours semble être une moyenne correcte pour une tâche que l'on ne détaille pas, mais que l'on peut concevoir clairement.
Rétroliens
Pas de rétroliens
Commentaires
Afficher les commentaires en Vue non groupée | Vue groupée