Nous avons défini l'itération comme un mini-projet complet, impliquant toutes les disciplines et ayant généralement
pour résultat un système exécutable incomplet, appelé une édition. Bien que le cycle (éditer, compiler, tester et
déboguer) ressemble à une itération, ce n'est pas le sens que nous lui donnons ici. Les constructions quotidiennes ou
hebdomadaires qui intègrent et testent de façon incrémentale de nouveaux éléments du système, peuvent également
s'apparenter à des itérations. Toutefois, une construction ne représente qu'une partie d'une itération au sens où nous
l'entendons ici.
Une itération commence par une planification et une définition des exigences, et s'achève par la création d'une
édition, interne ou externe.
La durée d'une itération dépend principalement de la taille de l'organisation de développement.
Par exemple :
-
Cinq personnes peuvent effectuer la planification le lundi matin, déjeuner ensemble tous les jours pour évaluer
l'avancement, réattribuer les tâches, commencer à générer une construction le jeudi et terminer l'itération le
vendredi soir.
-
Mais ce processus serait difficilement réalisable avec une équipe de 20 personnes. En effet, il faudra compter
davantage de temps pour répartir le travail, assurer la synchronisation entre les sous-groupes, intégrer, etc. Dans
ce cas, une itération prendra plutôt trois ou quatre semaines.
-
Avec 40 personnes, il faudra déjà compter une semaine pour que "l'influx nerveux aille du cerveau jusqu'aux
extrémités". En effet, si vous avez des niveaux de management intermédiaires, la définition des objectifs visés
nécessitera une documentation plus formelle. Il est probable alors qu'une itération dure en moyenne trois mois.
D'autres facteurs entrent en jeu : le degré de familiarité de l'organisation avec l'approche itérative, la stabilité et
la maturité de l'organisation, le niveau d'automatisation pour la gestion du code (par exemple, gestion des changements
distribuée), la distribution des informations (par exemple, site Web interne), l'automatisation du test, etc.
Vous devez également savoir qu'une itération implique inévitablement la mobilisation de ressources pour la
planification, l'analyse des résultats, la synchronisation, etc.
Ainsi, si les nombreux avantages de l'approche itérative vous poussent à multiplier les itérations, les limites
humaines de votre organisation vous freineront bien vite dans vos ardeurs.
Quelques données empiriques :
Lignes de code source (SLOC)
|
Nombre de développeurs
|
Durée d'une itération
|
10 000
|
5
|
1 semaine
|
50 000
|
15
|
1 mois
|
500 000
|
45
|
6 mois
|
1 000 000
|
100
|
1 an
|
-
Pour les itérations de plus de 6 mois, il est préférable d'ajouter des jalons intermédiaires afin d'assurer
le suivi du projet. Vous pouvez également essayer de limiter la portée de l'itération afin de réduire sa durée et
de garantir la clarté des objectifs.
-
Les itérations de plus de 12 mois génèrent des risques supplémentaires, car elles excèdent le cycle de
financement annuel. Un projet qui n'a produit aucun résultat tangible sur les 12 derniers mois risque de perdre son
financement.
-
Les itérations de moins d'un mois doivent avoir une portée clairement définie. Généralement, les itérations
courtes conviennent davantage à la phase Construction, pour laquelle les nouvelles fonctionnalités à ajouter sont
peu nombreuses. Dans le cadre d'une itération courte, les activités formelles d'analyse et de conception sont
limitées voire inexistantes. Il s'agit souvent d'améliorer une fonctionnalité déjà mise en place.
-
Toutes les itérations ne doivent pas nécessairement être de la même durée : leur durée peut varier en
fonction des objectifs. Généralement, les itérations d'élaboration sont plus longues que les itérations de
construction. En revanche, au sein d'une même phase, les différentes itérations sont souvent de même longueur :
cela facilite la planification.
Après avoir évalué le nombre total d'itérations dans votre plan général, vous devez définir le contenu de chacune de
ces itérations. Il peut être utile de trouver un nom ou un titre pour qualifier le produit obtenu à la fin de chaque
itération, afin que l'objectif soit plus clair.
Exemples d'itérations pour un commutateur téléphonique privé
-
Itération 1 : appels locaux.
-
Itération 2 : ajouter les appels extérieurs et la gestion des abonnés.
-
Itération 3 : ajouter la messagerie vocale et les conférences téléphoniques.
Un projet simple peut comporter une seule itération par phase :
-
Une itération pour la phase de création, dont le produit serait par exemple un prototype justifiant le concept ou
une maquette de l'interface utilisateur. Il est également possible de n'avoir aucune itération pour cette phase,
par exemple dans le cas d'un cycle d'évolution.
-
Une itération pour la phase d'élaboration, afin de produire un prototype architectural.
-
Une itération pour la phase de construction, pour générer le produit (par exemple, une édition "bêta").
-
Une itération pour la phase de transition, pour achever le produit (édition complète).
Pour un projet de plus grande envergure, le cycle de développement initial peut se présenter de la manière suivante :
-
Une itération pour la phase de création, dont le produit pourrait être un prototype.
-
Deux itérations pour la phase d'élaboration : une pour le prototype architectural, l'autre pour la référence
architecturale.
-
Deux itérations pour la phase de construction pour exposer un système partiel, puis l'améliorer.
-
Une itération pour la phase de transition, pour transformer les capacités opérationnelles initiales en une édition
complète.
Pour un projet encore plus vaste, comportant de nombreux impondérables, on aurait certainement :
-
une itération supplémentaire pour la phase de création, afin de passer davantage de temps sur le prototype.
-
une itération supplémentaire pour la phase d'élaboration, afin d'explorer différentes technologies.
-
une itération supplémentaire pour la phase de construction, en raison de l'envergure du produit.
-
une itération supplémentaire pour la phase de transition, afin d'avoir un retour sur l'aspect opérationnel.
Un cycle de développement peut donc comporter :
-
Au minimum : 3 itérations [0,1,1,1]
-
Généralement : 6 itérations [1, 2, 2, 1]
-
En cas de projet plus vaste : 9 itérations [1, 3, 3, 2]
-
Au maximum : 10 itérations [2, 3, 3, 2]
Ainsi, vous pouvez considérer que vous aurez entre trois et dix itérations. Toutefois, les extrémités de cette
fourchette représentent des cas exceptionnels et il faut savoir que la plupart des projets de développement se
déroulent en six à huit itérations.
De nombreuses variations sont possibles en fonction des risques, de la taille et de la complexité :
-
Si le produit concerne un domaine entièrement nouveau, vous devrez peut-être rajouter quelques itérations
dans la phase de création afin de consolider les concepts, présenter des maquettes à des représentants des clients
ou des utilisateurs ou élaborer une réponse solide à une demande de proposition.
-
Si une nouvelle architecture doit être développée, ou si des activités poussées de modélisation de cas
d'utilisation doivent être exécutées, ou encore si vous constatez que les risques semblent importants, vous devez
prévoir deux ou trois itérations pour la phase d'élaboration.
-
Si le produit est important et complexe et développé sur une longue période de temps, vous devez prévoir au
moins trois itérations pour la phase de construction.
-
Enfin, vous devez prévoir plusieurs itérations dans la phase de transition si vous devez livrer le produit avec des
fonctionnalités minimales afin de réduire le délai de commercialisation, ou si vous pensez que vous devrez apporter
un certain nombre de changements mineurs à la base utilisateur après un certain temps d'utilisation.
La séquence de revues par défaut pour un projet à cycle de vie en cascade comporte une seule revue majeure à
l'achèvement des produits importants, par exemple :
-
Revue des exigences du système (SRR), à l'issue de la spécification du système ;
-
Revue de spécification logicielle (SSR), à l'issue de la spécification des exigences logicielles ;
-
Revue de conception préliminaire (PDR), suite à la rédaction des sections concernant la conception
architecturale dans la description de la conception logicielle ;
-
Revue critique de la conception (CDR), suite à la rédaction des sections concernant la conception détaillée
dans la description de la conception logicielle.
Dans le Rational Unified Process (RUP), des portions des produits équivalents sont révisées au fur et à mesure de leur
avancement au sein de chaque itération, mais les principaux jalons (et par conséquent les principales revues)
correspondent à l'achèvement de chaque phase : création, élaboration, construction et transition. Un responsable de
projet qui souhaite adopter le RUP doit résoudre ce conflit apparent, pour des raisons d'obligations contractuelles.
Idéalement, le responsable de projet doit convaincre le client qu'une approche basée sur des phases et des itérations
offre une meilleure visibilité sur l'avancement du projet et réduit les risques, ce qui rend inutiles la revue des
exigences du système (SRR), la revue de spécification logicielle (SSR), etc. Toutefois, cela n'est pas toujours
possible et dans ce cas, le responsable de projet devra planifier ces revues aux moments appropriés. Dans le RUP, il
est possible d'identifier les moments auxquels ces produits importants (ou plus exactement, leurs équivalents dans le
RUP) sont globalement terminés, bien que cela ne corresponde pas toujours exactement à la fin d'une phase ou d'une
itération.
Cette correspondance est définie ici en supposant que les efforts consacrés aux exigences, à la conception, etc. seront
à peu de chose près identiques dans le RUP et dans le cycle de vie en cascade idéal, mais que ces efforts seront
répartis différemment. Le résultat obtenu est le suivant :
-
La revue des exigences du système (SSR, correspondant globalement au document Vision) peut être planifiée à la fin de la phase de création ;
-
La revue de spécification logicielle (SSR, correspondant globalement à la Spécification des exigences logicielles) peut être planifiée
environ après qu'un tiers de la phase d'élaboration a été effectué ;
-
La revue de conception préliminaire (PDR, correspondant globalement au Document d'architecture logicielle) peut être planifiée à la fin
de la phase d'élaboration ;
-
La revue critique de la conception (CDR, correspondant globalement au Modèle de conception) peut être planifiée environ après qu'un
tiers de la phase de construction a été effectué.
Toutefois, pour une plus grande efficacité, le responsable de projet doit essayer, en accord avec le client, de
combiner ces revues avec les revues RUP prévues. Cela est possible pour la revue de spécification logicielle (SRR) et
la revue de conception préliminaire (PDR), qui peuvent être regroupées respectivement avec la revue du Jalon des objectifs de cycle de vie et la revue Architecture de cycle de vie.
Tout comme le processus logiciel, l'organisation du projet est également influencée par les caractéristiques du projet.
La structure par défaut présentée ici (voir la figure ci-dessous) doit être adaptée pour refléter les effets des
facteurs suivants :
-
Le contexte métier
-
L'ampleur de l'effort de développement logiciel
-
Le degré de nouveauté
-
Le type d'application
-
Le processus de développement actuel
-
Les facteurs liés à l'organisation
-
La complexité technique et de gestion
Il s'agit de facteurs clés pour l'analyse de la manière dont l'organisation doit adopter un nouveau processus de
développement. Nous examinerons ici leur impact sur le choix de la structure du projet. La figure ci-dessous présente
une organisation de projet par défaut, montrant comment les responsabilités sont affectées à la structure de l'équipe.
Figure illustrant l'organisation de projet par défaut. Notez qu'aucune considération d'ancienneté ni de hiérarchie
n'intervient dans l'ordre des rôles.
Cette figure constitue un point de départ pour indiquer comment les rôles et les responsabilités au niveau du projet
doivent être mappés avec la structure des équipes. Cette figure montre également que les rôles (dans les cadres jaunes)
ne correspondent pas à des personnes, mais à des "casquettes" qu'une personne (ou une équipe) peut porter dans le cadre
du projet. C'est la raison pour laquelle certains rôles (comme celui de responsable de projet) apparaissent plusieurs
fois. Cela signifie qu'à un moment donné, le comportement de responsable de projet tel qu'il a été défini dans le RUP
peut apparaître dans plusieurs équipes. Par exemple, pour un projet d'une certaine envergure, la préparation d'un
rapport d'état basé sur une structure de répartition du travail peut être confiée à une personne de l'équipe
Administration. Toutefois, il s'agit d'une responsabilité que le RUP affecte au rôle appelé Responsable de
projet.
En revanche, pour un projet plus petit, il est probable que la personne nommée responsable de projet effectuera
toutes les tâches affectées au rôle appelé responsable de projet, auquel cas l'équipe Administration coïncide
avec l'équipe Gestion logicielle. Le choix de la structure des équipes dépend de la nature et de l'ampleur du projet,
mais doit également respecter quelques règles de bon sens :
-
Les petites équipes sont généralement plus productives ; toutefois, dans le cas d'un gros projet, il faut également
tenir compte des interactions entre les équipes.
-
Il convient d'éviter les hiérarchies trop complexes.
-
Un manager ou un responsable d'équipe doit contrôler entre 5 et 9 personnes.
-
La structure des équipes de développement logiciel doit
être élaborée en fonction de l'architecture logicielle : une bonne architecture, avec une cohésion élevée et un
faible couplage entre les sous-systèmes, permet aux équipes de travailler plus efficacement en parallèle.
-
A l'exception du test d'unité, il est préférable que le test soit pris en charge par une équipe autre que l'équipe
de développement. Toutefois, pour un tout petit projet, cela peut ne pas être judicieux d'un point de vue
économique.
-
La structure doit donner à chaque équipe et à chaque personne des responsabilités clairement définies. Cela est
particulièrement important si la hiérarchie comporte plus de trois niveaux. En effet, les managers et les
responsables d'équipe qui se situent au milieu de telles structures doivent comprendre ce que l'on attend d'eux en
termes de tâches techniques et d'encadrement.
-
La structure doit être adaptée aux capacités, à l'expérience et aux motivations de l'équipe : par exemple, si une
même équipe est censée assurer l'analyse, la conception et l'implémentation sans aucune aide extérieure, ses
membres devront présenter toutes les compétences nécessaires. Un analyste confirmé ne fait pas forcément un bon
implémenteur.
-
La structure des équipes ne doit pas être rigide. Certaines personnes peuvent passer d'une équipe à une autre en
cours de projet, et les responsabilités des équipes peuvent évoluer de phase en phase.
Le raisonnement qui a conduit à l'élaboration de l'organisation par défaut est expliqué en détail dans [ROY98]. Notamment, l'attribution des responsabilités de déploiement à l'équipe
chargée de l'évaluation du logiciel suppose que, parmi toutes les équipes du projet de développement, cette équipe est
celle qui est capable de mieux appréhender le logiciel tel que l'utilisateur le percevra.
Au cours du déroulement du projet, l'organisation est amenée à évoluer pour s'adapter à la structure de répartition du
travail indiquée dans le planning de projet. Cela est illustré dans la figure ci-dessous, tirée de [ROY98].
Cette évolution montre que chaque phase s'intéresse plus particulièrement à un ensemble de tâches différent :
-
L'équipe de création : une organisation qui se concentre sur la planification, avec l'aide des autres équipes pour
s'assurer que les plans représentent bien tous les points de vue ;
-
L'équipe d'élaboration : une organisation qui se concentre sur l'architecture, dont le coeur est constitué de
l'équipe d'architecture logicielle, assistée des équipes de développement logiciel et d'évaluation du logiciel afin
d'obtenir une référence d'architecture stable ;
-
L'équipe de construction : une organisation équilibrée, dont la plupart des tâches incombe aux équipes de
développement logiciel et d'évaluation du logiciel ;
-
L'équipe de transition : une organisation centrée sur le client, dont les tâches de déploiement sont étroitement
liées aux retours des utilisateurs.
Le passage de certains intervenants d'une équipe à une autre au fil de l'évolution du projet garantit la pérennité des
connaissances et des compétences. Par exemple, une fois l'élaboration terminée, certains membres de l'équipe
d'architecture peuvent rejoindre les équipes de développement, éventuellement en tant que responsables d'équipe, ou
afin de veiller à ce que la 'vision' architecturale soit respectée au cours du développement. Ensuite, vers la fin de
la phase de construction, l'équipe d'évaluation entre en scène, et une partie de l'équipe de développement passe dans
l'équipe d'évaluation. A ce stade, il est important de ne pas perdre de vue l'intégrité architecturale dans le feu du
développement, et que l'influence de l'équipe d'architecture ne décline pas au fur et à mesure que le projet évolue. Le
passage de certains membres de l'équipe d'architecture dans l'équipe d'évaluation peut permettre de répondre à cette
exigence.
|