AILES : Le cycle itératif

C'est quoi, le problème du Waterfall ?
Aujourd'hui encore, les projets sont dirigés au moins en apparence sous forme de waterfall, c'est à dire un cycle unique en V (Analyse - spécifications & modélisation - conception, codage, tests-unitaires et l'intégration, livraison et recette).
On retrouve ce cycle en V décrit avec humour ici)
    Vu de "l'extérieur", le client voit donc 5 grandes phases. Certes, en interne, il peut en être autrement, mais si ce n'était pas le cas, voilà ce que cela signifierait :
- pas de retour entre les phases : une fois le l'analyse est faite, c'est terminé, tout le monde travaille sur la conception. Une fois que la conception est faite, c'est terminé... etc.,
- des dates fixes pour chaque phase, qui servent de références pour juger de l'état d'avancement des développeurs,
- pas de critère de complétion pour l'analyse et la conception : ces phases se finissent... quand le calendrier l'indique. Et, du coup, la plupart du temps, ces phases se terminent dans les temps! Mais elles ne sont pas réellement "finies".

Grandes caractéristiques de l'itératif
- Intégration continue : on ne rassemble pas les morceaux juste avant la recette finale. On le fait tout au long du projet,
- versions exécutables intermédiaires fréquentes : le client doit souvent avoir l'occasion de voir l'avancement du projet pour mieux "corriger le tir",
- gestion des risques : le projet doit s'attaquer aux parties impliquant les plus gros risques (techno mal maîtrisée, produits peu connus,...).
Conséquences :
- développement continu : les versions intermédiaires (qui sont, rappelons-le, de véritables exécutables remplissant n% des fonctionnalités attendues, en commençant par les plus "risquées") forcent le projet à remplir toutes les fonctionnalités exigées par le client.
Il n'y a donc pas de phénomène du type : "90% du projet fait, 90% restent à faire" (cf. loi n°7).
- intégration progressive des évolutions : les besoins du client changent ou, pour le moins, s'affinent au fil du projet. Le cycle itératif permet de détecter ces changements au plus tôt et des les intégrer soit directement, soit via des avenants.

Vous en prendrez bien une tranche ?
Tout l'enjeu du cycle itératif est de bien réaliser que, dans un projet, il n'y a que 2 dates connues :
- le T0 (prononcez « t zéro », date de début du projet, et encore, il est courant que l'on se fasse avoir sur cette date, cf. 10/).
- la date de livraison (donc, de "fin" du projet).
    Entre ces 2 dates, il s'agit de diviser le projet en tranche (itérations) qui ne sont pas des milestones (comme celle du cycle en V du Waterfall : analyse, conception, codage, ...), donc qui n'ont pas de date fixe qui leur serait attachée !
Cela ne signifie pas pour autant qu'on ne pourrait manager son projet en en mesurant l'état d'avancement.
    Une itération a pour caractéristique d'être :
- un cas d'utilisation (ou une partie). Il ne s'agit pas de sous-système technique mais bien de quelque chose auquel le client peut donner un sens,
- une fonctionnalité. Cela permet, plus tard dans le projet, lorsque l'on décide d'éliminer telle ou telle partie pour rester dans les délais, d'éliminer des itérations et non de nombreuses parties d'une ou plusieurs itérations,
- un exécutable : une itération doit pouvoir être évaluée par le client, avec des critères d'appréciations,
- court : une itération se compte en jours, une à deux semaines maxi, pas en mois.
- un mini-cycle en V : non seulement en sortie on a un exécutable, mais on a aussi des documents d'analyse et de conception qui viennent compléter ceux des itérations précédentes.
- indépendante des itérations à venir : il s'agit d'avoir bien pensé son découpage de façon à ce que chaque itération utilise les fonctionnalités des itérations précédentes et le moins possible celle des itérations suivantes.
La notion de couplage prend, ici encore, tout son sens (comme pour le problème des dépendances entre packages).

C'est la première qui compte...
    La première itération est celle à choisir avec le plus de soin. Elle doit à la fois être celle comportant les difficultés techniques les plus importantes et être "visuelle", et ce pour 2 raisons :
- savoir le plus tôt possible si l'on peut réussir le projet ou non (donc s'attaquer aux difficultés en premier),
- calibrer les délais le plus "large" possible, en multipliant la durée de la première itération (qui, en générale, est longue) par le nombre d'itérations prévues.
Certes :
- les fonctionnalités les plus complexes ne sont pas toujours abordables en premier car elles peuvent dépendre d'autres, plus simples. Il faudra néanmoins les aborder le plus tôt possible,
- les itérations peuvent se "paralléliser", mais les 2 premières doivent, de préférence, se faire séquentiellement.

Planifier ? Estimation continuelle
    L'avantage du Watefall et de ses 5 milestones, avec ses dates fixes, c'est qu'un manager peut à tout moment "voir dans le temps" où il en est.
    Les itérations, auxquelles - initialement - aucune date n'est attachée, n'empêchent pas ce type d'évaluation. Simplement, celle-ci se raffine dans le temps.
    Lorsque la première itération se termine, on a :
- un exécutable représentant n% des fonctionnalités du projet et dont on sait qu'il marche (!),
- l'analyse et la conception pour cette partie du projet,
- la durée nécessaire pour réaliser cette itération.
    On peut alors faire une première - grossière - estimation de la durée du projet en multipliant celle de la première itération par le nombre d'itération.
    On n'en tirera pas de conclusion définitive d'autant que la deuxième itération est souvent un peu plus longue que la premières, les développeurs se rendant compte d'un certains nombre d'erreurs dans la première (justement!).
    L'enseignement tiré de ces premières itérations permet ensuite d'affiner les suivantes, qui, pour le coup, seront plus courtes, moins complexes, mieux maîtrisées et s'appuieront sur des fonctionnalités déjà évaluées par le client.

Manager un projet
    Bon... sérieusement, tout cela est bien joli, mais peut-on réellement manager un projet avec un tel système ?
    Il faut bien savoir qu'un projet est fait de trois dimensions :
- l'équipe (de développeurs),
- le sujet (ensemble des fonctionnalités que doit remplir le programme),
- les délais (à respecter... en théorie).
[Colin LORRAIN nous rappelle une 4ème dimension importante : le client. Laurent Bossavit, Coach XP nous en confirme l'importance pour un projet de qualité]
    Lorsqu'une des itérations dépasse la date estimée (même si initialement aucune date ne lui était attachée, l'enjeu des premières itérations reste d'estimer la durée des suivantes), le chef de projet a 3 possibilités :
- augmenter l'équipe (appeler des renforts, des experts, ...),
- "changer le sujet" (enfin... diminuer le nombre de fonctionnalités finalement implémentées!),
- modifier la date estimée (pour la faire coller avec la réalité!).
    Encore une fois, les premières itérations sont cruciales, car elles vont vous permettre tôt dans le projet de voir si l'une des trois dimensions a besoin d'être revue.
    Vous aurez ainsi le temps de former de nouvelles recrues ou de négocier avec le client des fonctionnalités plus "réalisables" ou encore des délais plus "réalistes".
    Si aucune de ces trois dimensions n'est "flexible", si toutes les trois sont fixées dès le début du projet... celui-ci n'est pas gérable autrement que par les prières!
Il faudra alors imposer ses ultimatums, dicter ses exigences, forcer ses résultats auprès de développeurs qui en seront vite démotivés (comme pour l'exemple du Waterfall)
    En revanche, si l'approche itérative ne résout pas tout, elle permet aux managers, sur la base d'exécutables concrets et d'évaluations régulières par le client... de manager!

exemple de schéma récapitulatif :