La question de budgets et des délais
Rappel : Budget à la régie
Rappel : Budget au forfait
Les hommes.jours sont évalués a priori en fonction d'un spectre fonctionnel donné et payés quelque soit la consommation réelle (en théorie, car en pratique le projet dérive, les besoins évoluent et les forfaits sont renégociés, mais souvent dans la douleur).
Fondamental : Hyperstatisme et degrés de liberté
Les méthodes traditionnelles ont tendance à l'hyperstatisme, rien ne peut être bougé, car tout est fixé : délais, coûts, fonctions.
Dans une méthode agile, en revanche, l'on va maintenir un ou plusieurs degrés de liberté :
Le budget est fixé, voire les délais, mais pas le champ fonctionnel.
Le budget est fixé avec plus ou moins 30%, les délais sont fixés (livraison obligatoire), une partie du champ fonctionnel est optionnelle.
La date de livraison est fixée sans marge de manœuvre et l'on joue sur le spectre fonctionnel pour ajuster, voire sur le budget (accroissement des ressources en parallèle).
...
Intermédiaire forfait/régie
Les méthodes agiles s'accommodent bien :
de budgets à la régie, dans le cadre d'une enveloppe générale plus ou moins stricte correspondant à une évaluation a priori de la MOE[2] en accord avec les moyens de la MOA[3].
de budgets au forfait, à condition qu'ils soient négociables dans une certaine mesure (et dans les deux sens), et qu'ils ne soient pas (trop) liés contractuellement à un spectre fonctionnel (trop) précis.
Finalement, les deux approches convergent vers un entre-deux...[2]
Exemple :
L'enveloppe initiale fixée a priori est de 100k€, le délai de 6 mois, l'équipe de 4 personnes, pour 200 h.j de travail.
À la fin de la première itération, il apparaît qu'une fonction F1 est beaucoup plus complexe que prévue, elle est simplifiée en F1' et un complément de 20 h.j est estimé, un supplément budgétaire de 10k€ est alloué.
À la seconde itération, la fonction F1' est terminée, finalement sans surcoût, grâce à une nouvelle technologie identifiée ayant permis de gagner du temps.
Les 10k€ supplémentaires sont maintenus, mais alloués à une nouvelle fonction F2 non prévue initialement, que le client a identifié entre temps dans un produit concurrent.
...
To be continued...
Projets agiles = risque de dérive ?
Au contraire car on inverse le raisonnement habituel : On ajuste le contenu aux moyens plutôt que le contraire.
Si on souhaite faire quelque chose d'imprévu, ou que l'on rencontre un problème, on va modifier le contenu de ce que l'on souhaitait faire globalement pour absorber le coût de la modification.
Alors que dans un projet traditionnel, on est soumis à la contrainte globale qui empêche les ajustements locaux sans négociation (avenant, etc.).
Fondamental :
L'objectif des méthodes agiles est de payer plus de réalisation et moins de régulation.
Exemple : Contre-exemple (officieux !)
Les prestataires de services ont coutume d'appliquer un facteur d'ajustement une fois les jours de développement évalués pour payer les coûts de régulation d'une part et tenter de palier par avance aux incertitudes d'autre part.
Ce facteur est en général bien supérieur à 2... Donc pour une journée productive en terme de réalisation, plusieurs sont passées à en parler ou à se protéger de ses éventuelles conséquences néfastes !