Offre de développement projet « Agile »
Nous vous proposons de développer et piloter votre projet avec la démarche SCRUM.
Dans ce cadre, Oxiane
- Constitue l’équipe projet et met à disposition les moyens matériels nécessaires à sa réalisation,
- Est garant de la gestion de projet Scrum à travers son Scrum Master,
- Vous accompagne durant les phases clés : définition du Backlog Produit, priorisation des items, planification de sprint, rétrospective,
- Maintient les indicateurs projet et vous donne la visibilité sur l’avancement prévisionnel,
- S’engage pour chaque itération sur les items à réaliser, selon vos priorités et la vélocité réelle de l’équipe,
- Livre selon des délais fixes une application testée et utilisable
Il convient de donner quelques éléments de présentation de Scrum. Il s’agit d’un survol et de la présentation des concepts clés.
Introduction
L’approche empirique
Pour la plupart des projets de développement de logiciel, nombre de décideurs s’appuient encore sur les croyances suivantes :
- Au début du projet, on peut prévoir exactement les fonctionnalités qui seront réalisées à une date fixée
- On peut prédire le déroulement du projet, définir dans quel ordre les travaux vont se dérouler et calculer le coût global du projet
La réalité du terrain montre que c’est le plus souvent une utopie : le besoin évolue, les changements sont inévitables et les plans deviennent très vite obsolètes.
Scrum repose sur une approche empirique : Plutôt que de définir strictement un plan détaillé de tout le projet, l’équipe définit des objectifs pour le court terme. Des points de validation entre client et équipe de développement sont appliqués régulièrement et permettent de mettre en évidence objectivement l’état d’avancement du projet.
Connaissant empiriquement cet état, on peut alors projeter une date de fin réaliste et -au besoin- adapter les objectifs.
Valeurs
L'équipe
- Priorité des personnes et des interactions sur les procédures et les outils.
- L’accent est mis sur la constitution des équipes, qui doivent être composées de personnes avec une forte capacité à travailler en équipe et à communiquer. Ce sont avant tout les interactions, les initiatives et la communication interpersonnelles qui feront le succès d’un projet.
- Les outils appropriés ne sont pas rejetés, bien au contraire. Ce sont les outils surdimensionnés, qui, au même titre que des procédures lourdes, sont à proscrire.
L'application
- Priorité d’applications opérationnelles sur une documentation exhaustive : Il est vital que l'application fonctionne.
- Ecrire et maintenir de la documentation est très consommateur de ressources. Un document qui n’est pas mis à jour régulièrement devient rapidement inutile. Il est donc important de rester succinct, de savoir se débarrasser de documents qui ne sont plus utiles à l’avancement du projet.
La collaboration
- Priorité de la collaboration avec le client sur la négociation de contrat
- L’application de méthodes agiles s’appuie sur une relation de confiance forte entre le client et l’équipe chargée de la réalisation. Le client doit travailler en étroite collaboration avec l’équipe de réalisation pour lui fournir des retours constants, des indicateurs de satisfaction, faire les demandes de modification au plus tôt.
L'acceptation du changement
- Priorité de l’acceptation du changement sur la planification. Ce principe n’exclut pas la planification, bien au contraire. Simplement, plutôt qu’une planification rigide, le planning est revu tout au long du projet en fonction des changements (évolutions de la demande du client, des contraintes techniques) qui peuvent intervenir.
- Les premières itérations vont souvent provoquer des demandes d'évolution.
Le "Cadre" Scrum
Scrum est un processus agile qui se concentre sur la gestion de projet. Il s'agit d'un cadre organisationnel et non de procédés imposés ! Les pratiques et outils que nous mettons en oeuvre autour de Scrum sont issus de notre expérience ; ils ne sons pas figés. Au cours d'un projet, nous serons probablement amenés avec vous à modifier ou abandonner ou ajouter des pratiques afin d'améliorer le fonctionnement du projet.
Organisation
Scrum définit un cadre organisationnel léger.
Trois rôles clés :
- Le directeur produit
- Le scrumaster
- L’équipe
Le Directeur Produit
- Définit les fonctionnalités du produit
- Choisit la date et le contenu de la release
- Définit les priorités dans le Backlog Produit en fonction de la valeur « métier »
- Ajuste les fonctionnalités et les priorités à chaque sprint si nécessaire
- Accepte ou rejette les résultats
Le Scrum Master
- Représente le management du projet
- Est responsable de faire appliquer par l’équipe les valeurs et les pratiques de Scrum
- Protège l'équipe des interférences extérieures
- Aide à résoudre les problèmes
- S'assure que l'équipe est complètement fonctionnelle et productive
- Facilite une coopération poussée entre tous les rôles et fonctions
L'équipe
- S'auto-organise
- Pas de rôles affectés : tous les membres de l'équipe peuvent être au fil du temps concepteur, développeur, testeur, etc.
- S'engage sur une itération, auprès du Directeur Produit, sur les Items qu'elle va réaliser
- Met en place ses propres pratiques agile de développement (intégration continue, tests, pair programming par exemple)
Cycle de vie
Le métier définit les exigences et priorités. Les exigences sont définies comme des éléments d’une liste appelée « Backlog du Produit »
L'équipe s'organise elle-même pour déterminer la meilleure façon de produire les exigences les plus prioritaires.
A la fin d’un sprint, une version de l’application même fonctionnellement incomplète est livrée et pleinement utilisable.
Les paramètres fixes et ne devant pas être modifiés durant un sprint :
- La durée du sprint
- Le nombre de membres de l’équipe
- Sauf cas de force majeure, la composition de l’équipe
Les paramètres sur lesquels il est possible d’influer : Le contenu fonctionnel de l’application à la fin du sprint (le nombre d’item du backlog produit réalisés)
Gestion de projet avec Scrum
Introduction
Une méthodologie « Agile » comme SCRUM ne veut pas dire pas de gestion de projet, bien au contraire !
La gestion de projet qu’elle soit « agile » ou « traditionnelle » tend à répondre à deux questions essentielles :
- Quand-est-ce qu’on finit le projet ? (ie : à quelle date est-ce que l’application est terminée, en production et utilisable ?)
- Combien est-ce que cela va coûter ?
Pour répondre à ces deux questions,
(1) La méthode traditionnelle
- Fixe un ensemble de fonctionnalités à réaliser
- Essaye d’estimer de façon prédictive la charge et le délai pour réaliser ce périmètre
- Adapte le plan, revoit régulièrement la charge prévue et le délai en fonction des problèmes rencontrés, de l'affinage du besoin, de la découverte de besoins implicites à réaliser, voir des changements du périmètre initial
Conséquence : pour plus de la moitié des projets informatiques, coût et délai estimé initialement sont doublés à minima !
(2)Scrum
- Fixe les temps de développement (par des itérations à durée fixe)
- Mesure les fonctionnalités réalisées sur un temps fixe
- Projete (en se basant sur ce qui a déjà été fait, c’est à dire de façon empirique) à quel moment se terminera le projet
- (et/ou) adapte le nombre de fonctionnalités prévues pour rester dans un délai global fixé
Ici, par définition, le périmètre n’est pas figé, les besoins et priorités évolueront au cours du temps, en grande partie parce que le client pense, découvre et construit l’application en même temps qu’elle se réalise !
A la fin, l’application réalisée peut être plus ou moins éloignée du périmètre initialement prévu mais délai et coût ont été maîtrisés.
Points
Le principe de planification empirique de Scrum repose sur une estimation des items du Backlog Produit par l’équipe en « points ».
Un item du Backlog Produit doit être facilement « estimable » par l’équipe à partir d’une description orale de quelques minutes. Sinon, probablement, il faut décomposer l’item en question.
L’idée est similaire aux points de fonction, points de use case des méthodes traditionnelles :
- Associer une valeur de points relative entre éléments comparables
- Se doter d’éléments de mesure formels et simples, basé sur un mélange de la complexité et du temps de travail estimés
- Obtenir des indicateurs de suivi
- Disposer au fil du temps d’une expérience d’estimation sur une base comparable
Il n’y a pas de recherche d’unité particulière ...
... mais un item estimé à 10 devrait prendre 2 fois plus de temps à réaliser qu’un item estimé à 5
Vélocité
La vélocité est la quantité de travail qu’une équipe est capable de réaliser en une itération.
Avec une estimation relative en points, la vélocité de l’équipe, c’est le nombre de points réalisés sur une itération, c’est à dire la somme des valeurs initialement estimées en points pour les réalisations acquises (terminées / livrées en fin d’itération).
Notons qu’un item terminé à 90% mais non livré dans l’itération vaut zéro.
Si l’on sait –par exemple– que l’équipe a une vélocité de 14 et que l’on connaît l’ensemble des points du backlog, on peut
- extrapoler combien d’itérations il reste à faire pour terminer le projet (on peut préciser : au pire, en moyenne, au mieux)
- ou bien revoir les priorités afin de rester dans une enveloppe prévue
On obtient alors un « burndown chart » du projet qui indique la tendance de progression.
exemple :
Moments clés de SCRUM
Il existe des moments importants dans la conduite d’un projet SCRUM.
La planification du sprint
Ici, l’équipe va, avec le directeur produit, déterminer le but du sprint et les items du Backlog Produit à réaliser durant le sprint.
Il s’agit d’un moment clé car l’équipe va s’engager à réaliser les items auprès du directeur produit.
Le directeur produit ne peut pas agir sur les points estimés ni sur la vélocité réelle de l’équipe !
Mais il peut changer ses priorités ou découper un item en deux items de priorités différentes !
Le Scrum quotidien
Il s’agit d’une réunion journalière, en général en début de journée, de 15 à 20 minutes, réalisée debout (« standing meeting »).
Tout le monde peut être présent mais seuls les membres de l’équipe s’expriment. Ils répondent individuellement à trois questions :
- Qu’ai-je fait depuis hier ?
- Que vais-je faire aujourd’hui ?
- Quels sont les obstacles que j’ai rencontré ou à venir ?
L’objectif est la communication et l’engagement.
La revue de sprint
L'équipe présente ce qu'elle a fait pendant le sprint. Cela se fait avec une démo des nouvelles fonctionnalités ou de l'architecture, directement sur l’application livrée et qui restera disponible pour les futurs utilisateurs.
Toute l'équipe participe. On invite du monde et surtout des utilisateurs.
La rétrospective de sprint
L’objectif est de réfléchir régulièrement à ce qui marche et ce qui ne marche pas du point de vue organisationnel.
Ce type de réunion dure en général de 30 minutes à 2 heures et elle a lieu à la fin de chaque sprint.
Il ne s’agit pas de faire une analyse des bugs de l’application ! Mais du fonctionnement du Scrum.
Chacun discute de ce qu’il aimerait :
- Commencer à faire
- Arrêter de faire
- Continuer à faire
Vocabulaire
- Sprint : Itération
- Backlog de produit (Product Backlog) : Référentiel de toutes les exigences (requirements)
- Backlog de sprint (Sprint Backlog) : Plan de l’itération
- Directeur Produit (Product Owner) : Représentant des clients et utilisateurs dans l’équipe Scrum
- ScrumMaster : Animateur de l’équipe Scrum (rôle de chef de projet adapté à Scrum)
- Intervenant (Stakeholder) : Personne intéressée par le projet mais en dehors de l’équipe Scrum
- Mêlée quotidienne (Scrum Daily Meeting) : Réunion d’équipe limitée à un quart d’heure
- Produit partiel potentiellement utilisable (potentially shippable product increment) : exécutable avec des fonctionnalités utilisables obtenu à la fin d’un sprint
- Revue de sprint (sprint review meeting) : revue d’itération
- Rétrospective : revue sur l’utilisation de Scrum pendant le sprint
- Burndown chart (Beurdone) : diagramme montrant la tendance de la progression pour un sprint ou pour un produit
