Dans la phase de création, les risques principaux sont souvent des risques métier ou techniques. En début de création,
le risque métier prépondérant est généralement de garantir le financement du projet. De ce fait, le résultat de la
phase de création est généralement un prototype de concept. Le prototype de concept propose une démonstration d'une
fonctionnalité clé ou d'une technologie essentielle.
La première itération d'un nouveau produit est généralement la plus difficile. Une première itération ne se limite pas
à la production d'un logiciel mais est également responsable de la mise en place du processus, de la formation de
l'équipe, de la compréhension d'un nouveau domaine, de la familiarisation avec de nouveaux outils, etc. Soyez modérés
dans vos attentes relatives au développement de l'architecture ou au degré de fonctionnalité utilisable que vous pouvez
atteindre. Si vos attentes sont trop élevées, vous risquez de retarder la fin de la première itération, de réduire le
nombre total d'itérations et donc de ne pas tirer partie des avantages d'une approche itérative. Les premières
itérations doivent se concentrer sur la création d'une architecture appropriée. Vous devez donc impliquer les
architectes logiciel dans le processus de planification des premières itérations.
Dans la phase d'élaboration, les itérations visent à définir une architecture stable, à concevoir et implémenter le
comportement principal du système et à étudier les problèmes techniques d'architecture via une série de prototypes
d'architecture. Les scénarios "architecturalement significatifs " sont des sous-flux qui permettent d'obtenir
l'architecture du système en définissant différentes méthodes.
Vers la fin de la phase d'élaboration et lors de la construction et de la transition, les demandes de changement
(également appelés ordres de modification logicielle ou SCO) commencent à diriger le processus d'itération. Les
demandes de changement proviennent :
-
de demandes d'amélioration
-
de demandes de modification dont la portée va au-delà de la classe ou du package spécifique
-
de modifications de la portée et des objectifs de l'itération
-
de changements des exigences (proposition de modification des exigences ou application d'un changement accepté des
exigences de référence).
Ces demandes de changement sont à rapprocher du plan de projet existant, des plans d'itération et de la liste de
risques existantes. Les demandes de changement peuvent entraîner une réévaluation de la priorité des exigences ou des
risques. Vous devez cependant soigneusement gérer les demandes de changement afin de ne pas perdre le contrôle du
projet.
Les phases de construction et de transition visent à développer l'architecture et à implémenter les exigences
restantes.
Contrairement au modèle de développement en cascade dans lequel le système est considéré dans sa globalité, nous ne
considérons qu'une partie de la fonctionnalité du système à chaque itération. Lors de chaque itération, un
sous-ensemble du système global est analysé, conçu et implémenté. Le choix du sous-ensemble et du niveau de détail est
critique pour réduire les risques des itérations suivantes. Il existe deux stratégies de base : étendue/superficielle
et restreinte/approfondie.
Dans une stratégie étendue et superficielle, l'intégralité du domaine est analysé mais seuls les éléments superficiels
sont pris en compte. Tous les cas d'utilisation sont définis et sont, pour la plupart, très détaillés, afin d'avoir une
vision claire du problème envisagé. L'architecture est également largement définie, ainsi que les services et
mécanismes clés fournis par les composants architecturaux. Les interfaces des sous-systèmes sont définies mais leurs
caractéristiques internes ne sont détaillées que lorsque des risques ou incertitudes significatifs doivent être gérés.
L'implémentation est très limitée jusqu'à la phase de construction (phase lors de laquelle la plus grande partie de
l'itération se déroule).
La stratégie étendue et superficielle est recommandée dans les cas suivants :
-
L'équipe est inexpérimentée, dans le domaine ou la technologie (y compris la méthodologie ou le processus).
-
Une architecture solide est nécessaire pour des capacités futures et l'architecture n'a pas de version antérieure.
Cette stratégie a cependant des inconvénients :
-
L'équipe peut rester bloquée dans une paralysie analytique (sentiment illogique selon lequel si la
conception n'est pas parfaite aucune implémentation n'est possible).
-
Des résultats précoces sont souvent nécessaires pour générer la confiance et la crédibilité. Plus le projet tarde à
produire un résultat exécutable, plus l'équipe manquera de confiance quand à sa capacité à en obtenir.
-
Les caractéristiques techniques et les défis de l'architecture ne sont pas suffisamment visibles pour que les
véritables risques techniques soient apparents
Dans la stratégie restreinte et approfondie, un segment du problème est analysé en détail. Les cas d'utilisation
associés à ce segment restreint sont définis et détaillés de façon approfondie, de manière à obtenir une vision claire
du problème envisagé. L'architecture requise pour le comportement souhaité est définie et le système conçu et
implémenté. Les itérations suivantes se concentrent sur l'analyse, la conception et l'implémentation de segments
verticaux supplémentaires.
La stratégie restreinte et approfondie est recommandée dans les cas suivants :
-
Des résultats précoces doivent être démontrés pour prévenir un risque majeur, obtenir un soutien ou prouver la
viabilité du projet.
-
Les exigences évoluent sans cesse et il est donc difficile de définir complètement les exigences avant de commencer
les efforts de conception détaillée et d'implémentation.
-
L'échéance est obligatoire et commencer le développement tôt est un élément important pour réussir une
livraison.
-
Il possible de réutiliser de nombreux éléments, ce qui permet davantage de livraisons incrémentielles.
Cette stratégie a cependant des inconvénients :
-
Cette stratégie a tendance à développer, pour chaque itération, un logiciel intégré verticalement mais incompatible
horizontalement. Ce problème est parfois appelé syndrome tuyaux de poêle et gêne l'intégration du système.
-
Cette stratégie n'est pas appropriée au développement de systèmes dans un domaine totalement nouveau ou basés sur
une architecture sans version antérieure, car la plus grande partie d'un système doit être échantillonnée pour
obtenir une architecture stable.
D'une façon générale, les premières itérations sont plus souvent étendues et superficielles alors que les itérations
suivantes (lorsqu'une architecture stable a été développée) suivent plus facilement une stratégie restreinte et
approfondie.
La première itération est généralement la plus difficile car il est nécessaire que l'intégralité de l'environnement de
développement et la plus grande partie de l'équipe de projet soient en place. Les problèmes de mise en place d'équipe
et d'intégration des outils rendent la première itération encore plus complexe. Si l'équipe se concentre sur les
problèmes d'architecture elle évitera de se disperser et de s'enliser dans les détails trop tôt.
-
Stratégie restreinte et approfondie utilisée en phase de création
L'étude d'une nouvelle technologie est essentielle à la viabilité du projet. De nombreux projets
e-business nécessitent l'étude plus approfondie des nouvelles technologies. Le prototype de concept est
toujours considéré comme temporaire et n'étudie que la viabilité du concept du projet.
-
Stratégie étendue et superficielle utilisée en phase de création
Cette stratégie permet d'obtenir une meilleure vision de la portée du système et d'échantillonner l'ampleur de
la fonctionnalité du système pour vérifier que l'architecture est capable de fournir les capacités souhaitées.
-
Stratégie étendue et superficielle utilisée en phase d'élaboration
Cette approche permet de développer une architecture stable qui répond à des risques techniques spécifiques
avec de façon restreinte et approfondie. Dans la phase de construction, lorsqu'une architecture stable est
établie, la stratégie redevient restreinte et approfondie lorsqu'une fonctionnalité est développée et livrée
dans une série d'incréments intégrés.
-
Stratégie restreinte et approfondie utilisée en phase de construction
Les itérations de construction sont toujours retreintes et approfondies, avec des équipes travaillant en
parallèle pour développer et fournir la fonctionnalité requise.
Les nouvelles équipes sont généralement excessivement optimistes quand à leurs capacités. Pour parer cela et éviter
d'éventuels problèmes de moral lorsque les résultats ne sont pas à la hauteur des attentes optimistes, soyez modeste en
fixant les objectifs de fonctionnalité à atteindre lors de la première itération. Essayez d'acquérir de l'expérience
tout en créant une impression de réalisation et de dynamique de projet.
Si l'équipe ne connaît pas les méthodes et/ou l'environnement de développement, réduisez la fonctionnalité au minimum
pour la première itération. Concentrez-vous sur l'intégration et l'adaptation de l'environnement et familiarisez-vous
avec les outils, puis attaquez-vous au contenu dans la fonctionnalité dans les itérations suivantes.
Retravailler peut-être positif, dans une certaine mesure. L'un des avantages principaux du développement itératif est
justement de permettre des erreurs et des essais, mais suffisamment tôt pour que des actions correctives puissent être
prises. Cependant, les équipes techniques ont souvent tendance à vouloir être trop perfectionnistes entre une itération
et la suivante.
A la fin de chaque itération, lors de l'évaluation de celle-ci, l'équipe doit également décider quelles parties de la
version actuelle doivent être retravaillées. Prévoyez, pour les différentes phases, les pourcentages de retravail
suivants (par rapport au système global) :
-
Création, 40%-100% - développement de prototypes exploratoires jetables
-
Elaboration, 25%-60% lors des premières itérations ; moins de 25% lors des itérations suivantes ou dans le cas d'un
cycle d'évolution.
-
Construction, après la référence d'architecture, 10% ou moins par itération et 25% au total.
-
Transition, moins de 5%.
Le retravail est inévitable. Si aucun retravail ne semble nécessaire, méfiez-vous. Cela peut être dû à :
-
un calendrier trop serré
-
un manque d'évaluation ou de test réel
-
un manque de motivation ou de concentration
-
une perception négative du retravail (gaspillage de ressources, aveu d'incompétence ou d'échec).
Si un retravail trop important est nécessaire, méfiez-vous également. Cela peut être dû à un trop grand perfectionnisme
ou un niveau de modification des exigences inacceptable. Une étude de rentabilité doit être effectuée pour évaluer la
nécessité d'une partie du retravail.
Notez que le travail planifié mais non effectué (en raison de l'approche jalonnée de la gestion d'itérations) de
l'itération précédente n'est pas inclus dans la catégorie "retravail". Le responsable de projet doit inclure ce
travail dans le groupe de fonctionnalités à partir desquelles le contenu de l'itération suivante doit être défini. Bien
sûr, ce travail devrait normalement avoir une priorité élevée. Le responsable de projet doit également rechercher et
soigneusement étudier les raisons pour lesquelles l'itération précédente n'a pas atteint les objectifs prévus. Par
exemple, si nous ne recommandons pas l'ajout arbitraire de personnel dans un effort désespéré pour tenir un délai, il
est préférable que le projet ne soit pas constamment en manque d'effectif si vous définissez des plans ambitieux
pour chaque itération. Cela a souvent pour conséquences une équipe démoralisée et un client non satisfait. Vous devez
trouver le juste équilibre, et les modèles d'estimation, COCOMO II par exemple, (voir [BOE00]) peuvent vous y aider. Pour chaque itération, un projet génère un historique
des accomplissements (productivité et qualité). Pour un responsable de projet, un indicateur important à prendre en
compte lors de la planification de l'itération suivante est ce que l'itération précédente a accompli.
Lorsque la première ébauche du plan d'itération est terminée, le chef d'équipe, en collaboration éventuelle avec le
responsable de projet, peut détailler celle-ci en en plan de travail au niveau de la tâche. Le modèle Microsoft Project
inclus (au niveau de la tâche) peut illustrer cela. Remarquez cependant que ces plans de travail sont basés sur le plan
d'itération et qu'il ne s'agit pas de produits indépendants, créés séparément. Il est important, pour que le
responsable garde le contrôle du projet, que les plans de travail soient compatibles avec le plan d'itération du
responsable de projet.
|