Instructions: Plan d'itération
Les itérations sont au coeur du développement logiciel moderne. Ces instructions proposent des stratégies de planification des itérations.
Relations
Eléments connexes
Description principale

Patterns d'itération

Itérations de création

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.

Itérations d'élaboration

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.

Itérations de construction et de transition

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.

Stratégies d'itération

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.

Etendue et superficielle

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

Restreinte et approfondie

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.

Enseignements tirés d'expériences précédentes

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égies hybrides

  • 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. 

Considérations spéciales pour les nouvelles équipes

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.

Retravail prévu

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.

Niveau de planification

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.