Le planning des itérations
2009
Dernier billet d’une série de trois articles sur la panification Agile, nous avons abordé dans un précédent billet le principe de la planification Agile et détaillé dans un deuxième, une méthode de créer son planning de release. Ce dernier billet propose d’expliciter la démarche pour mettre en oeuvre le planning des itérations.
Pour rappel, le planning de relesase est une vue de haut niveau du planning du projet, le planning des itérations est une vue granulaire de ce même projet. Il a pour objectif de dénombrer l’ensemble des taches par cas d’utilisation.
La création du planning des itérations est une démarche plus simple en terme de phase par rapport au planning de release. L’équipe projet va dans un premier temps identifier l’ensemble des tâches par cas d’utilisation, estimer les taches et éventuellement mettre à jour le planning de release.
Identifier les tâches des cas d’utilisation
Avant de commencer cette activité, il est important de prendre conscience qu’il n’est pas nécessaire d’identifier l’ensemble des tâches pour l’ensemble des cas d’utilisation lors de cette première planification. Imaginons un projet avec 20 cas d’utilisation, en moyenne un cas d’utilisation regroupe 10 taches, nous devrions identifier plus de 200 taches ! Travail laborieux qui pourrait être remis en doute avec l’avancée du projet. Il est nécessaire de garder en tête les bases des méthodes agiles, dont « juste à temps« . Il n’est logique de se lancer dans une activité d’identification de l’ensemble des tâches avant d’avoir commencé le projet. Celui-ci pourrait voir évoluer son périmètre après les premières livraisons ou selon certaines contraintes non identifiées à ses débuts.
À partir de desiderata, nous allons essentiellement travailler sur la première itération et identifier les relations entre la première et la deuxième itération. Chaque cas d’utilisation de la première itération sera étudié pour en extraire les taches nécessaires à la conception, le développement et l’intégration.
À la fin de cette première étape, nous avons identifié les tâches nécessaires pour la première itération et éventuellement une première liste des tâches les plus importantes de la deuxième itération.
Nous obtenons un premier tableau qui peut être représenté de la manière suivante :
| Itération | Cas d’utilisation | Taches | Type |
|---|---|---|---|
| 1 | UC 103 – Demande d’inscription | Spécification de ce cas d’utilisation | Conception |
| CRUD des données dans le référentiel | Réalisation | ||
| Création d’un formulaire de demande | Réalisation | ||
| Créer le MCD dans le référentiel de données | Réalisation | ||
| Validation des données du formulaire | Réalisation | ||
| Affichage du formulaire | Réalisation | ||
| Test du cas d’utilisation | Intégration | ||
| 1 | UC 101 – Authentification | Spécification de ce cas d’utilisation | Conception |
| Formulaire d’authentification | Réalisation | ||
| Appel référentiel de données | Réalisation | ||
| Vérification des données d’authentification | Réalisation | ||
| Vérification du rôle de l’utilisateur | Réalisation | ||
| Affichage interface selon type de rôle | Réalisation | ||
| Test de ce cas d’utilisation | Intégration |
Comme vous avez pu le constater, nous avons choisi d’identifier les taches avec des identifiants complémentaires : conception, réalisation et intégration (CRI). Cela nous permet d’évaluer la charge d’activité par acteur.
Calculer les charges par taches
Nous avons à présent une liste de tâches pour mettre en oeuvre nos cas d’utilisation, la deuxième phase consiste à calculer le cout de chaque tache. Les charges sont calculées en heures à la différence des cas d’utilisation qui sont calculés en ideal days. L’idéal est de réussir à avoir des taches d’une durée d’une journée pour faciliter le suivi et l’affectation des charges. Pour l’équipe un jour = taches.
À la suite de cette deuxième activité, nous mettons à jour notre tableau qui peut être représenté de la manière suivante :
| Itération | Cas d’utilisation | Taches | Type | Charges |
|---|---|---|---|---|
| 1 | UC 103 – Demande d’inscription | Spécification de ce cas d’utilisation | Conception | 2 |
| CRUD des données dans le référentiel | Réalisation | 2 | ||
| Création d’un formulaire de demande | Réalisation | 1 | ||
| Créer le MCD dans le référentiel de données | Réalisation | 2 | ||
| Validation des données du formulaire | Réalisation | 3 | ||
| Affichage du formulaire | Réalisation | 1 | ||
| Test du cas d’utilisation | Intégration | 1 | ||
| 1 | UC 101 – Authentification | Spécification de ce cas d’utilisation | Conception | 1 |
| Formulaire d’authentification | Réalisation | 0,5 | ||
| Appel référentiel de données | Réalisation | 0,5 | ||
| Vérification des données d’authentification | Réalisation | 1 | ||
| Vérification du rôle de l’utilisateur | Réalisation | 0,5 | ||
| Affichage interface selon type de rôle | Réalisation | 2 | ||
| Test de ce cas d’utilisation | Intégration | 1 |
Mise à jour du planning de release
Nous avons terminé notre travail sur le planning des itérations. Il nous faut réaliser un dernier travail qui consiste à vérifier s’il existe des éventuelles différences de charge entre les cas d’utilisation du planning de release et ceux du planning des itérations.
Le planning des itérations implique de rentrer dans le détail lors de la phase d’identification des taches, ce travail peut nous permettre de découvrir des éléments que nous avions oubliés lors de la planification des cas d’utilisation. D’ou l’importance de bien identifier les cas d’utilisation (cf. planning de release) lors de la phase de planification des release.
commentaire