L'urgent est fait, l' impossible est en cours,
pour un miracle, prévoir un délai

     Souvent on m'a demandé Combien de temps avant que le programme ne soit terminé, telle fonction implémentée, ou tel élément modifié...

Il est d'autant plus délicat de répondre que certaines API/plateformes sont peu documentées. Comment font les développeurs pour obtenir une estimation?

Le programmeur est le pivot entre le demandeur et le programme. Le plus important à gérer entre le demandeur et le programmeur reste la communication, en répondant par exemple Je vous donne une réponse mercredi. Mais souvent ça ne suffit pas.

Concevoir

     La première chose à faire, c'est de concevoir un plan. Son rôle est de mettre à plat les étapes et de les décrire afin de parvenir au résultat demandé. C'est l'étape qui facilite la distribution des rôles dans une équipe.

Pourtant tous les militaires savent qu'aucun plan ne se déroule exactement comme sur le papier. Cependant il permet d'anticiper et/ou d' éviter des problèmes bien plus graves auxquels on n' aurait pas pensé sans plan. Il donne une estimation très large de ce qui attend le/les développeur(s).
En d' autres termes se lancer tête baissée c'est le meilleur moyen de rentrer dans un mur, avec toute la panique que la situation implique. Impensable! On disait que la faculté d' adaptation est une des qualités premières du développeur, mais la capacité d'anticipation est son complément.

Bien définir les besoins du demandeur/des utilisateurs finaux. En effet, tout est axé autour de cet objectif. Quand l'objectif est approximatif c'est l'ensemble en souffrira. A cet effet, définir une série de questions/réponses peut faciliter ce processus.

Le point-clé de la conception consiste à scinder le développement en tâches. Ayant connaissance de ces étapes, leur durée peut être estimée, l'addition de tous ces objectifs donnant l' estimation globale.

Il faut faire ressortir les goulots d'étranglement dont l' achèvement est la condition sine qua non de la poursuite des développements, afin de bien les différencier de ce qui peut être traité en parallèle et qui n'a pas d'incidence sur le cycle de développement.

Ne pas trop s'attarder non plus sur l' étape de la conception, car cette étape est censée faire gagner du temps, pas en perdre. En fait elle est proportionnée à l'envergure du projet.

Le plan est prêt

     Chaque étape précisément décrite dans sa globalité et dans ses détails? Une estimation générale a été calculée?

Multiplier par deux, trois ou dix selon que le développeur est expérimenté dans son environnement, les outils, le langage qu'il utilise, les algorithmes qu'il doit concevoir... En effet l'expérience joue pleinement son rôle lorsqu'on demande à un développeur de refaire quelque chose auquel il a déjà été confronté. Non seulement il est à l' aise dans sa mission, mais il peut évaluer le temps qu'il lui faudra, connait les difficultés auxquelles il sera confronté, et leurs solutions.

Avec ce plan, le sage donnera deux estimations: la pessimiste et l' optimiste. Etant donné que la vitesse de développement dépend de multiples facteurs, et que dans sa globalité c'est le maillon faible qui ralentit l' ensemble, le développeur pourra prévoir et affirmer que si tel objectif est atteint et que les deux étapes suivantes sont également respectées, alors l'ensemble sera prêt en deux mois. Et inversement sinon il faudra compter trois mois.

Il faut raisonner en unités homme/jour. Un programmeur passe rarement la totalité de son temps sur le code. Il le passe aussi en termes de recherches, sinon dans d' autres domaines qui n'ont aucun rapport avec le projet.

Faire les bons choix

     La durée de développement pourrait se résumer ainsi: on peut faire vite et mal, ou le faire bien - option qui prend forcément plus de temps. La solution? Faire vite et bien. Distribuer autant de betas que possible pour s' appuyer sur les échos des utilisateurs, tout en optimisant en parallèle au fur et à mesure que le programme grandit. C'est le compromis gagnant car il faut prendre en compte que la confrontation aux utilisateurs amène des imprévus auxquels personne n' avait pensé. Cette surcharge aurait été atroce dans le cas où les utilisateurs attendent cinq ans un programme, puis sont déçus lorsqu'ils l'obtiennent, s'attendant à mieux, et rajouttent une couche révisionnelle représentant l'équivalent de cinq années de développement. C'est probablement un choc dans une équipe de développeurs.

Certaines fonctions ont déjà été écrites par d' autres. A l' heure de l' Open-Source ce serait dommage de ne pas bénéficier du partage des autres. C'est d'autant plus vrai que le langage est de bas niveau, et une des raisons pour lesquelles les développeurs préférent certains langages de haut niveau -dont la majorité des fonctions/algorithmes sont écrites de manière à assurer les performances.
Par exemple, inutile de ré-écrire des fonctions pour accéder au contenu d'un site web et traiter son contenu: ces fonctions existent dans la majorité des librairies existantes. Et elles sont accessibles depuis nombre de langages de programmation, c'est le rôle des APIs (Application Programming Interface: Interface de Programmation d' Applications).
En revanche, employer une librairie tierce amènera probablement des mises à jour de celles-ci (correction de bugs et failles de sécurité). Heureusement, certains développeurs attachent une grande importance à la rétro-compatibilité. Celà signifie une mise à jour transparente de la librairie pour les développeurs qui les utilisent.

Les imprévus

     Les imprévus concernent tout ce qui n'a pas été pris en compte pendant la conception, et tout ce qui survient pendant.

Le plus gros détracteur en programmation sont les bugs, quelle que soit la consience mise en oeuvre par le développeur. Il faut bien assimiler que le programme n'évolue jamais seul, mais dans le cadre d'un système d' exploitation, en interdépendance avec d' autres programmes, ce qui multiplie les facteurs limitants ...

Souvent, une poignée de bugs sont résolus en quelques minutes, alors que d'autres fois un seul bug peut bloquer l' évolution pendant une semaine. Souvent, le plus difficile consiste à trouver son origine d'ou l'émergence d'une génération de bug hunters implacables.

Une chose à laquelle on ne pense pas spontanément: la rédaction des manuels utilisateur/développeur/maintenance, la distribution vers d'autres plateformes... Mieux vaut y penser avant. Seule une vision globale amène le recul nécessaire, la prise en compte de tous les paramètres.

Justesse de l'estimation

Le développement prend toujours plus que le temps estimé

     Toute estimation est forcément trop longue par rapport à ce qu' attend le demandeur. Généralement il a besoin d'un programme, et il en a besoin tout de suite.

Lui donner une estimation, puis finalement terminer l' applicatif APRES la date estimée a des effets dévastateurs. A contrario, finir avant la date d' estimation constitue le schéma idéal: le demandeur est heureux de cette bonne surprise; le développeur dispose de plus de temps; et tous deux peuvent utiliser ce laps inattendu pour peaufiner ensemble les détails. Le demandeur sera plus probablement enclin à accorder une récompense. Ou amoindrir l'estimation pour le prochain pogramme, attention.

Ne jamais succomber à la tentation de réduire votre estimation sous la pression de personnes qui n'ont jamais rien programmé de valable (ceux que je nomme Les catapultés par DRH). Quelles que soient leurs qualités de meneur d'hommes, ils ne doivent pas en oublier les réalités du terrain pour autant, en exigeant d'aller plus vite que la musique. Quand la partition est écrite l'ensemble des musiciens n'a d'autre choix que de s'y tenir.

Votre estimation se base sur une démonstration. Appuyez-vous dessus pour argumenter les hypothèses. En insistant qu'il y a plus de chance que le programme soit prêt avant plutôt qu'après.

Ce serait une erreur que de mal réagir face à ce type de pression. Au contraire il faut rebondir en indiquant que vous faites ce qu'il faut pour tendre vers cet objectif Diminuer le temps de développement revient à diminuer les spécificités du programme, ou alors à augmenter la productivité en renforçant l'équipe: augmenter le potentiel humain.

Ne pas confondre précision et justesse. Dire Ca me prendra 8 jours, 6 heures, 25 minutes et 18 secondes est trés précis, mais moins juste que de dire 8 jours. Plus la durée est longue, moins la précision sera grande.

Il est très important de ne jamais sous-estimer ou sur-estimer les prédictions car la hiérarchie ou les utilisateurs en viendront à la conclusion de ne pas croire en vos estimations.


C'est pourquoi certains développeurs prétendent qu'il ne faut jamais donner aucune estimation!
En d' autres termes -inavoués- ce sera fait quand ce sera prêt, et ça prendra le temps qu'il faudra, point. Est-ce que le directeur des ventes peut estimer son chiffre d' affaires des 6 mois à venir, et s'y tenir? Même en météorologie, certaines estimation se révèlent infructueuses.

L'estimation est une perte de temps, mais elle n' empêche pas la planification, qui elle aussi, se verra assignée un certain laps de temps à respecter.

Au contraire, privilégiez au cours du développement les bilans successifs qui permettent de faire le point en informant des avancées et des problèmes rencontrés.
Favorisez aussi la communication qui se base sur du concret en permettant de tester des bétas le plus souvent possible. C'est le meilleur moyen de démontrer la progression -et de juger sa vraie vitesse de développement. Traitez avec soin chaque distribution temporaire en la numérotant, en y joignant sa source et tous les documents associés et dépendances, la liste des bugs connus et de de ce qui reste à faire (par ordre de priorité), ... Bref s' approcher du résultat final sans vraiment le faire.

C'est un test en conditions réelles, dont l'importance est vitale dans la progression du programme. Il confirme le dogme qui pousse à compiler souvent, en fait, le plus souvent possible, pour identifier rapidement tout bug qui survient entre deux versions. Méthode implacable pour isoler les sources d' erreurs qui sont comme on le sait, un trou noir qui engouffre le temps.

Il serait regrettable de mentir en donnant une estimation qui se révèlera de facto erronée. Car méme vous, vous ne savez pas combien de temps, et savez que méme l'estimation la plus précise qui soit, n'est jamais fiable à 100%.

On vous demande quand même une estimation?
Ce sera fait lorsque vous serez satisfait du résultat.