BusinessCenter –

Retour d’expérience

3 ans de Gestion de Projet Agile/Scrum

Qui suis-je ?

Raphaël DespinasseScrumMaster / TechLead / Expert Java

Quel est le projet ?

• Un Portail d’intégration• Un site web à l’architecture orientée services, branché sur le SI de

la société, de ses filiales et de ses partenaires• En évolution permanente, soumis à des paliers inter-applicatifs

• Un Portail B to B dédié à tous les professionnels et porteur d’une nouvelle posture stratégique : • Transparence du ROI par la fourniture des audiences des

produits• Autonomie et flexibilité pour la mise à jour des contenus

publicitaires payants ou gratuits (selfcare)• Apport de contenus à valeur ajoutée permettant d’améliorer

l’efficacité et la rentabilité des communications

Organisation du projet• Une équipe métier• 1 Product Owner• 2 Experts métier• 1 Ergonome• 1 WebMaster• 1 Chargé de soutien métier (niveau 2)

• Une équipe projet• 1 responsable MOA• 3 fonctionnels

• 1 responsable MOE• Etudes&Intégration (1 responsable + 3 personnes)• Réalisation (1 responsable + 7 personnes)

Historique du projet

La vision projet sur 4 mois

PlanningGame• Toute l’équipe projet est présente (24 personnes pendant 3h) le premier jour de l’itération• Démonstration par la MOE réa de l’itération précédente (40 min)

• Acception ou refus de la validation Métier/MOA• Périmètre fonctionnel intégralement développé• TU et TNR intégralement développés

• Remarques (toute l’équipe)• Présentation par la MOA des nouvelles US (90 min)

• Questions/Remarques (toute l’équipe)• Acceptation ou refus de chiffrage (MOE réa)

• US compréhensible• Disponibilité des inputs (contrats d’interface, services et environnements d’intégration,

modèles, …)• Rédaction des scénarii des TNR par la MOA

• Chiffrage de la complexité (MOE réa)• Engagement MOE réa (10 min)

• Liste des US embarquées sur l’itération• Nombre de points embarqués sur l’itération

• Rétrospective (40 min)• Note d’itération (pas systématique)• Points positifs sur le projet (Keep)• Points négatifs sur le projet (Drop)• Propositions de nouvelles initiatives (Start)• Questions (Questions)

Engagement MOE• Réalisation des US embarquées sur l’itération

• Développement• Tests Unitaires• Tests de Non-Régression

• Maintenances des Tests• Maintenance des données des bouchons• Maintenance des Tests Unitaires• Maintenance des Tests de Non-Régression

• Livraison sur plateforme d’Intégration Continue (Toutes les nuits)• Injections des données des bouchons• Déploiement sur les plateformes• Vérification du build, du code et des Tests Unitaires• Vérification des Tests de Non-Régression

• Préparation et livraison en Démo (Le dernier jour de l’itération)• Livraison en Recette (Le dernier jour de l’itération)• Livraison pour Bench (Le premier jour de l’itération suivante)

L’itération pour la MOE-Réalisation

• Répartition des US (1 heure)• Répartition collégiale et/ou arbitraire des US• Répartition homogène des US en fonction de leurs nombres de points• Pas de spécialisations dans l’équipe

• Partage des objectifs et des plannings avec l’équipe• Responsabilisation sur la réalisation/maintenance des Tests

• Une US = Dev + TU + TNR• Chaque membre de l’équipe est responsable d’une thématique de TNR

• DailyScrum (max 30 min)• Tous les matins … ou presque …• Possible de faire un tirage au sort pour désigner le responsable du jour

• Correction d’anomalies• Au fil de l’eau en fonction de l’avancé de l’itération• Au fil de l’eau en fonction des anomalies ou incidents de production• Lors des phases de Recette qui ont lieu durant le sprint 1 d’une version

• Les différentes livraisons• Chaque membre de l’équipe prépare sa démonstration avec un fonctionnel• Le responsable est en charge de la date de la fin des commits• Le responsable assure la bonne livraison de la version

Estimations des US• L’estimation Macro (2 heures)

• Très en avance de phase (Au moins 1 mois)• Membres : Les 3 responsables MOE + La responsable (A)MOA + le métier• Présentation fonctionnelle de l’EB• Chiffrage de la complexité à partir d’abaques• Il est possible de faire plusieurs séances d’estimation Macro

• Objectifs de l’estimation Macro• La date de MEP de la version, le nombre de point de complexité totale de la version

et le nombre d’itérations ne dépendent pas de l’estimation Macro. • L’objectif est de déterminer la liste des nouveaux besoins qui seront embarqués

dans la prochaine version à partir des éléments précédents• L’estimation Micro (2 heures)

• En avance de phase (Au moins 15 jours)• Membres : Les 3 responsables MOE + La responsable (A)MOA + Le responsable de

l’US + Le métier• Présentation fonctionnelle de l’US• Il est possible de faire plusieurs séances d’estimation Micro

• Objectifs de l’estimation Micro• L’objectif est de déterminer la liste des US qui seront présentées au prochain

PlanningGame

Les études• Vérification de la faisabilité du Besoin

• Faisabilité technique• Faisabilité fonctionnelle (connaître le SI)• Faisabilité auprès des partenaires du projet (plannings, ressources, …)

• Rédaction des Contrats d’Interfaces• Document technique de référence sur les modalités d’échanges avec nos

partenaires• Suivi des livrables

• Surveillance des plannings des partenaires• Surveillance de la mise à disposition des environnements• Recueil des inputs nécessaires aux développements

• Coordination avec les partenaires• Pour les phases de Recette• Lorsqu’il y a des indisponibités sur les environnements• Lorsqu’il y a des bugs à remonter• Lorsque le livrable n’est pas conforme au CI

Les Benchs• Les scénario de Bench

• Sélection de client en fonction de leurs données• Réalisation de parcours clients sur le Portail• Détermination de l’attendu sur toutes les pages• Détermination des cas d’erreurs• Benchs sur 1 heure et/ou sur une longue durée

• Outillage• Jmeter• Analyse mémoire, processeur, …• Suivi des évolutions (amélioration, régression) entre versions

• Les benchs de performances (A chaque itération)• Injection de clients sur une période• Analyse des temps de réponse des pages• Analyse de la mémoire et la consommation CPU• Nombre de pages en erreur• Analyse des logs

• Les benchs de version déterminent si la version peut partir en production

Les Recettes• Les Recettes au fil de l’eau

• Après chaque fin d’itération• Seulement les nouvelles fonctionnalités• Selon la disponibilité des services/données partenaires, la recette d’une

fonctionnalité peut intervenir plusieurs itérations après réalisation• Les TNR sont là pour limiter le nombre d’erreur

• Les phases de Recette• 1 semaine de Recette intense ou tout le projet est testé• 3 jours de correction par la MOE avec génération d’une version 0 défaut• 2 jours de recette différentielle pour valider la version 0 défaut

Synthèse• SCRUM pour tous

• On peut réussir en SCRUM malgré un ADN projet difficile• Amélioration continue

• Au cours des mois...• ... les risques de dérive sont nombreux• ... les opportunités d’améliorations le sont tout autant !

Questions ?