Open Agile

Suite à mon précédent billet sur la planification en méthode Agile dans lequel j’avais abordé le principe du planning de release et d’itération, je vous propose de continuer sur la planification est de développer le planning de release. Dans un prochain billet, je détaillerais la réalisation du planning d’itérations.

Au point de départ, nous avons un client qui nous a contactés pour développer une application. Ce projet est constitué d’un ensemble de besoins à la fois fonctionnel et technique (backlog).

La première action à réaliser dans le cadre de ce projet est de définir le planning de release. L’objectif est d’avoir une vision globale du projet en terme de planning, d’activité et de coût.  Comment réaliser un planning de release ? Le schéma suivant nous donne une première approche, que nous allons détailler par la suite.

Un projet est soumis à plusieurs conditions, qui sont régies par le classique triangle : ressources (coût, budget), calendrier, périmètre (fonctionnalités, caractéristiques). Ce sont ses éléments qui vont nous permettre de constituer notre planning de release. Prenons un simple exemple, un client souhaite X fonctionnalités avec un cout de X euros. Après une première estimation des besoins du client, nous devons lui indiquer que par rapport aux coûts nous ne pourrons pas respecter le périmètre. Nous devons appliquer des priorités sur les fonctionnalités avec notre client pour choisir ce qui peut-être fait avec son budget.

L’exercice est de définir un planning de release selon les conditions inhérentes au triangle du projet.  Nous pourrons réaliser un premier planning qui sera adapté et modifié selon les contraintes de ce triangle et ceci en relation avec notre client.

Remarque : Comme je l’ai déjà indiqué dans mes précédents billets, je n’utilise pas la notion de « vélocité » et de « user story » dans mes projets.  Ces deux éléments sont trop vagues pour réaliser un projet en mode forfait, ce qui représente 100% de notre activité de développement.

Les activités à réaliser pour créer notre planning de release sont les suivantes :

• Identifier les cas d’utilisation
• Sélectionner la longueur d’une itération
• Estimer la charge par cas d’utilisation
• Appliquer les priorités sur les cas d’utilisation
• Sélectionner les cas d’utilisation et les date de release

Identifier les cas d’utilisation

L’identification des différents cas d’utilisation est réalisée à partir d’un cahier des charges fourni par le client, d’une liste de fonctionnalités attendues dans le programme, etc.

La première démarche est de compartimenter en cas d’utilisation ou story (pour les non-techniques) les besoins fonctionnels et un cas d’utilisation transverse pour les éléments technique. Cette activité est réalisée par le product ower et le client. Ce sont les acteurs qui ont la vue fonctionnelle du projet.  La partie technique sera abordée lors de la constitution du planning des itérations par l’équipe du projet. Il est important de créer un cas d’utilisation tranverses qui prend en compte les besoins du client, car il peut impacter de manière importante sur le budget et le calendrier de projet.

Pour permettre une évaluation budgétaire réaliste du projet (et surtout éviter de s’en rendre compte au milieu ou à la fin du projet), nous essayons d’obtenir une bonne granularité de nos cas d’utilisation. C’est à dire une cinématique nominale pour chaque d’utilisation. Ce qui pourra se traduire sous la forme suivante :

Contexte :

Un utilisateur souhaite se connecter à l’application. Cet utilisateur possède un compte dans le référentiel de données.

Acteurs :

• Collaborateur : utilisateur référencé dans le référentiel de données
• Administrateur : Collaborateur ayant des droits d’administration.

Description du use case :

Ce mode d’authentification permet à un collaborateur de se connecter à l’application. Celui-ci accède à une page d’authentification où il saisit son couple identifiant/mot de passe. Le système vérifie les paramètres d’authentification auprès du référentiel de données.

Pré-requis :

L’utilisateur est enregistré dans lle référentiel de données.

Descriptif du cas d’utilisation

1. Le collaborateur ouvre son navigateur et accède à l’application
2. Le système demande son couple identifiant/mot de passe à l’utilisateur
3. L’utilisateur saisit son couple identifiant/mot de passe et valide
4. Le système vérifie les informations en relation avec le référentiel de données. En cas d’échec, on retourne à l’étape 2
5. Dans le cas d’une première authentification, le système initialise et crée un compte utilisateur dans le référentiel de données. L’application redirige l’utilisateur vers la page principale de l’application.

Post-conditions :

Un compte utilisateur a été créé (en cas de première authentification) dans le système. L’utilisateur est sur la page principale de l’application et peut commencer à l’utiliser.

A la fin de cette phase, nous avons identifier les différents cas d’utilisation. Nous passer à la phase suivante.

Sélectionner la longueur d’une itération

Comme je l’ai expliqué précédemment dans mon billet sur « le planning en méthode Agile », la longueur d’une itération est subjective, la majorité des projets agile utilise une longueur de 30 jours (quatre semaines). Cette période ne doit pas être considéré comme acquise, car elle peut à la finalité, nous poser des problèmes dans notre projet. Je conseille  de prendre le temps de bien choisir sa longueur lors de la conception du planning de release.

Certains éléments du projet doivent nous aider à définir la période d’une itération. Le premier point qui peut nous aider concerne la longueur du projet dans sa globalité, si nous travaillons sur un petit projet avec de nombreux cas d’utilisation ou story, il est plus intéressant de faire des itérations courtes pour que l’équipe en charge de l’intégration puisse les valider rapidement. Inversement, tous les projets n’ont pas la chance d’avoir une équipe d’intégration attitrée, le planning peut aussi dépendre de leur disponibilité.
Pour choisir la longueur d’une itération,  Je vous propose une petite liste de facteurs qui peuvent vous aider à la définir :

• La taille du projet
• Le nombre de cas d’utilisation
• Les priorités du client en terme de calendrier
• La flexibilité au changement
• L’implication du client dans cette méthode de projet
• La présence d’une équipe d’intégration spécifiquement sur ce projet
• La politique de l’entreprise sur le projet
• Le taux d’incertitude sur la mise en oeuvre de certaines fonctionnalités

Ce qu’il faut retenir :  Il faut choisir une longueur et la conserver tous au long du projet. Cette longueur correspond au rythme du projet et de l’équipe. L’équipe prend son tempo sur ce rythme et le conserve, un changement de longueur engendrerait une coupure dans ce rythme et perturberaient rapidement les équipes et le rendement du projet.

Estimer la charge par cas d’utilisation

Un planning de release est un planning avec une vision très macro à la différence d’un planning des itérations. Néanmoins, il ne faut pas penser que le travail de calcul des charges doit se faire à la légère. Dans mon précédent billet sur le planning poker, je vous avais présenté une méthode pour calculer les charges par cas d’utilisation. L’activité de planification est réalisée de la même manière pour calculer les charges par cas d’utilisation.

Le calcul de charge ne porte pas exclusivement sur le développement, mais aussi sur la partie spécification (conception) et intégration. Dans notre méthode de travail, nous calculons les charges en idéal days et non en vélocité. La vélocité est considérée comme trop floue par nos clients et les équipes.

Chaque cas fonctionnel est présenté à l’équipe projet par le product ower (par celui qui à la vision la plus fonctionnelle du projet), une première planification est réalisée par la méthode du planning poker.

Les charges pourront être réajustées après la réalisation du planning des itérations (identification des taches par cas d’utilisation). À la fin de ce travail, nous obtenons notre tableau des charges par cas d’utilisation :

Cas d’utilisation	Charge
CU 100	13
CU 101	21
CU 102	8
CU 103	8
CU 104	5

Appliquer les priorités sur les cas d’utilisation

Un des points les plus importants du planning de release est d’appliquer une priorité sur chaque cas d’utilisation. En effet, cela permet de sélectionner les cas d’utilisation qui devront être développés en premier. Cette priorité est appliquée par le client et le responsable du projet, néanmoins, il est important de prendre en compte l’avis des développeur qui peuvent apporter une vision différente concernant la chronologie de réalisation des cas d’utilisation, ainsi que le risque afférent à chaque cas d’utilisation. .

À la fin de ce travail, nous obtenons notre tableau des priorités par cas d’utilisation :

Cas d’utilisation	Priorité	Charge
CU 100	1	13
CU 101	3	21
CU 102	2	8
CU 103	5	8
CU 104	4	5

Sélectionner les cas d’utilisation et les dates de release

Après toute cette activité que l’on peut quantifier au maximum sur 2 jours (selon la taille du projet et l’expérience des acteurs), nous avons les éléments suivants :

• La longueur d’une itération,
• Une liste des cas d’utilisation, avec leurs priorités et les charges.

Nous sommes fin prêts pour réaliser notre planning de release. Ce travail est maintenant assez simple, nous allons  associer les cas d’utilisation et les itérations. Pour ce faire, nous prenons les cas d’utilisation prioritaires, nous prenons leurs charges, nous les positionnons dans les itérations.

Nous avons sélectionné pour ce projet une longueur d’itération de 30 jours. Nous allons créer le planning suivant :

Itérations	Cas d’utilisation	Priorité	Charge
Itération 1	CU 100	1	13
Itération 2	CU 101	3	21
Itération 1	CU 102	2	8
Itération 2	CU 103	5	8
Itérations 1	CU 104	4	5

Nous avons dans notre exemple 2 itérations, nous pouvons proposer le planning de release suivant :

• La première livraison au bout de 30 jours comportant 3 cas d’utilisation
• Une deuxième livraison au bout de 60 jours avec l’ensemble du projet.

Il faudra prévoir d’autres livraisons après les retours du client à propos de la première livraison et ensuite lors de la deuxième livraison.