SCRUM Mthode AGILE de gestion de projet Sminaire

SCRUM Méthode AGILE de gestion de projet Séminaire conçu par (www. delf. fr) V 18 -00 1

Sommaire q Contexte Agile et Scrum q Revue et rétrospective q Démarche q Planification d’une journée q Les acteurs q Les tests d’acceptation q Le backlog q L’ingénierie de logiciel q Planification de release q La mise en œuvre q Planification d’un sprint § Ce support de cours, propriété de la société ne peut être reproduit qu’avec son autorisation

Sommaire q Contexte Agile et Scrum q Revue et rétrospective q Démarche q Planification d’une journée q Les acteurs q Les tests d’acceptation q Le backlog q L’ingénierie de logiciel q Planification de release q La mise en œuvre q Planification d’un sprint § Ce support de cours, propriété de la société ne peut être reproduit qu’avec son autorisation

Agile et gestion de projet Un cadre d’application pour la gestion de projet qui n’est pas universel Ø Générique Ø à spécialiser Objectif Moyen Délai

Méthode Agile L’alliance Agile www. agilealliance. org Pourquoi § Faciliter l’expression des besoins § Aider à l’acceptation du changement Comment § § Organiser l’expression des besoins Mieux intégrer le client Démarche itérative Raccourcir les cycles de développement

Principes de base Issues du manifeste pour le développement logiciel agile www. agilemanifesto. org

Diffusion § 10 th Annual State of Agile Development Survey, 2016 § Plus de 20 000 participants

Origine et définition de Scrum n Années 90 : Jeff Sutherland et Ken Schwaber les grands principes n 1996 : Un premier article naissance n 2016 : dernière version du guide Scrum n Définition n Une méthode agile pour améliorer la productivité des équipes n Une équipe soudée (la mêlée) qui cherche a atteindre son but en avançant individuellement (sprint)

Les valeurs de Scrum n Courage et droit à l’erreur n Focalisation sur un objectif partagé n Engagement n Respect envers les autres et envers Scrum n Ouverture pour s’améliorer

La partie générique de Scrum Les rôles § Product Owner § Scrum Master § Dev’ Team (Equipe de développement) Les artefacts § Product Backlog § Sprint Backlog § Increment Le cérémonial § Sprint Planning (Planification du sprint) § Daily Scrum Meeting § Sprint Review (Revue de sprint) § Sprint Retrospective

Démarche SCRUM Product Backlog Sprint Backlog Increment

Démarche SCRUM Revue Rétrospective Planification 2

Sommaire q Contexte Agile et Scrum q Revue et rétrospective q Démarche q Planification d’une journée q Les acteurs q Les tests d’acceptation q Le backlog q L’ingénierie de logiciel q Planification de release q La mise en œuvre q Planification d’un sprint § Ce support de cours, propriété de la société ne peut être reproduit qu’avec son autorisation

Démarche itérative Planification des releases (roadmap) Release 1 Release 2 …. Planification des sprints …. Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Planification journalière Tâche 1 Tâche 2 Tâche 3 ……………… Tâche n ….

Démarche itérative et incrémentale Planification des releases (roadmap) Release 1 Release 2 Des fonctionnalités nouvelles pour les utilisateurs ….

Démarche itérative et incrémentale Planification des sprints …. Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Des fonctionnalités nouvelles pour le Product Owner ou les utilisateurs

Démarche itérative et incrémentale Des itérations identiques Sprint 1 • Comprendre le besoin • Concevoir la solution • Réaliser l’applicatif • Tester • Accepter Sprint 2 • Comprendre le besoin • Concevoir la solution • Réaliser l’applicatif • Tester • Accepter Sprint n • Comprendre le besoin • Concevoir la solution • Réaliser l’applicatif • Tester • Accepter Cf. capitalisation : rétrospective de sprint

Démarche itérative et incrémentale Des tâches terminées pour l’équipe de développement Planification journalière Tâche 1 Tâche 2 Tâche 3 ……………… Tâche n Des itérations identiques • Étude technique, Écriture des tests unitaires • Programmation • Exécution des tests unitaires • Intégration … ….

Démarche itérative et incrémentale Les atouts de la démarche § Feedback pour le client § Information sur l’avancement du projet § Organisation de l’expression du besoin § les revues de sprint § Feedback pour l’équipe § Cristallisation de l’avancement § Retour d’expérience en environnement réel § les rétrospectives de sprint

Sommaire q Contexte Agile et Scrum q Revue et rétrospective q Démarche q Planification d’une journée q Les acteurs q Les tests d’acceptation q Le backlog q L’ingénierie de logiciel q Planification d’une release q La mise en œuvre q Planification d’un sprint § Ce support de cours, propriété de la société ne peut être reproduit qu’avec son autorisation

Les acteurs Le Product Owner § § Représente le client et les utilisateurs Définit les besoins Fixe les priorités Valide les solutions Le Scrum Master § § Garant de la méthode Protège l’équipe développement L’équipe de développement § Multi compétences § Auto gestion L’équipe Scrum § Les autres parties prenantes

L’équipe, le Product Owner Responsabilités § Fournir une vision partagée du produit § Définir le contenu du produit § Planifier le développement du produit Compétences nécessaires § Connaître le domaine étudié § Avoir une vue globale puis une vue détaillée § Assimiler le changement, savoir négocier § Connaître le rôle de PO et les fondamentaux de Scrum

L’équipe, le Product Owner Participation Une participation continue Participation au cérémonial Scrum Exemple de charge : § Réunion de planification de sprint : max 8 H § Scrums quotidiens (au moins 2 / semaine): max 15 mn § Revue de sprint : max 4 H § Rétrospective de sprint : max 3 H Implication au jour le jour § Mettre à jour le backlog de produit § Répondre aux questions sur le produit § Définir et passer les tests d’acceptation 5 à 10% de son temps

L’équipe, Le Scrum Master Responsabilité § § Veiller et aider à la mise en place de Scrum Inciter à la capitalisation Gérer (identifier et éliminer) les obstacles qui pourraient freiner Assistance au Product Owner Compétences souhaitées § Connaître Scrum § Apte à communiquer facilement § Apte à guider une équipe § Apte au rôle de médiateur § Inclinaison à la transparence Le Scrum Master peut être • Un membre de l’équipe dev. • Un spécialiste Scrum Exemple de charge : • au début de 20% • par la suite de 10 à 15% Variable en fonction du contexte

L’équipe, l’équipe de développement (dév. ) Multi compétente § § § Analyse le besoin Conçoit la solution Réalise l’application Conçoit, réalise et passe les tests unitaires Intègre Autogestion § Le Scrum Master n’est pas un chef de projet informatique § Le Product Owner n’est pas un chef de projet utilisateur Des développeurs confirmés (certains) Atelier : en fin de stage

Sommaire q Contexte Agile et Scrum q Revue et rétrospective q Démarche q Planification d’une journée q Les acteurs q Les tests d’acceptation q Le Product Backlog q L’ingénierie de logiciel q Planification de release q La mise en œuvre q Planification d’un sprint § Ce support de cours, propriété de la société ne peut être reproduit qu’avec son autorisation

Le backlog Backlog sprint 2 Sprint 1 Sprint 2 Backlog sprint 3 Sprint 3 Backlog sprint n Sprint n Incrément 1 Incrément 2 Incrément 3 Incrément n Produit complet Backlog produit Backlog sprint 1

Backlog du produit le référentiel des exigences § Chaque exigence est décrite par une story § Les stories sont rangées par priorité § Le backlog produit est défini en amont du projet Scrum § Les fonctions essentielles sont identifiées (Features, macro stories) § Le backlog est actualisé tout au long du projet § La description des fonctions est affinée au fil du projet § Features, macro stories, stories

La vie du backlog produit Besoins à définir Besoins connus Diagnostic existant Expression des besoins Choix de reconfiguration Backlog produit / version initiale Sprint …

Story: élément du backlog produit Story : un élément fonctionnel qui apporte une valeur Une exigence qualité STORY ___________ Nom Identifiant Rôle Consulter les commandes Taille : 2 Priorité : 1 Description Type - Consulter les commandes Choisir un produit Enregistrer une facture ……… État Taille Priorité

Story: élément du backlog produit STORY ___________ Nom Préciser le rôle de l’utilisateur Aider à la compréhension de la story Exemple : le client, le responsable des stock, … Identifiant Rôle Description Type État Taille Priorité Une description détaillée du rôle (Persona : personne qui représente un groupe) Description du rôle Fréquence d’utilisation du produit Nombre de personnes ayant ce rôle Ses critères de satisfaction dans l’utilisation du produit

Story: élément du backlog produit STORY ___________ Nom Identifiant Rôle Description Type État Taille Priorité Description libre quelques lignes Ou Description structurée 1 - rôle / but / justification 2 - une liste d’actions élémentaires 3 - diagramme de séquence (uml) 4 - cas d’utilisation (uml) ……….

Story: élément du backlog produit Description structurée STORY ___________ Nom Identifiant Rôle 1 - rôle / but / justification Rôle de l’utilisateur (en tant que) But Justification (je veux) (afin de) Description Type État Taille Priorité En tant que client, je veux m’inscrire à une session de formation afin d’obtenir une nouvelle compétence En tant que client je veux acheter un billet de train afin de me rendre d’une ville à une autre

Story: élément du backlog produit Description structurée STORY ___________ Nom Identifiant Rôle Description Type État Taille Priorité une liste d’actions élémentaires -Flot principal -Saisir le produit retenu -Afficher le prix -Saisir le nombre d’unités -Calculer et afficher le prix total -…………. - Flot alternatif 1 : code produit inconnu Afficher message anomalie Demander un nouveau code …………. Héritage des use case d’uml

Story: élément du backlog produit STORY ___________ Nom Identifiant Rôle Description Type État Taille Priorité User Story : vue utilisateur Technical Story : vue développeur

Story: élément du backlog produit STORY ___________ créée Par n’importe qui acceptée Par le Product Owner estimée L’équipe dev. (poker) planifiée sprint ou release En cours De développement Nom Identifiant Rôle Description Type État Cycle de vie D’une story Taille Priorité finie

Story: élément du backlog produit STORY ___________ Petites tailles § Les stories prioritaires § Prêtes à développer § Seront associées à des séries de tests Nom Identifiant tailles moyennes et grandes § Pourront être décomposées Rôle Description Type État Taille Priorité 1, 2, 3, ……. Évaluer la taille : cf. le planning poker

Story: élément du backlog produit STORY ___________ Gérer la base client Nom Identifiant décomposition Rôle Description Type État Taille Priorité Relancer un client Valider un client Saisir un nouveau client

Story: élément du backlog produit Les stories d’un backlog sont classées par priorité STORY ___________ Nom Identifiant Rôle Description Type Priorité 1, 2, 3, ……. Les critères pour fixer les priorités - la réduction des risques - la diminution de l’incertitude sur des besoins - l’augmentation de la qualité - les dépendances entre stories État Taille Priorité Évaluer la priorité : cf. le priority poker

Story et autres Feature (macro story, backlog produit) Décomposée en Détaillée avec STORY (backlog produit) Réalisée par Tâche (voir backlog sprint) Story-test (voir test d’acceptation)

Feature FEATURE _____________ Nom • Aide à la définition du périmètre projet Description • Aide à l’initialisation du backlog produit Valeur ajoutée • Un backlog produit : de 5 à 20 features Les stories (à terme) Taille

Story: identification des fonctions Les fonctions § Décrire le comportement de l’application informatique nécessaire à la réalisation des processus en précisant les fonctions à remplir Architecture des systèmes d’information § 3 vues Architecture métier représentation des processus et mise en évidence de leur contribution aux objectifs de l’entreprise (PO) Architecture fonctionnelle représentation des fonctions et des informations du système d’information (PO et équipe dev. ) Architecture applicative représentation des composants informatiques et leurs échanges (équipe dev. ) Features ……stories ……. stories détaillées … tâches

Story: identification des fonctions FORMATION Une approche par les données 1 * SESSION * 1 PROF 1 * INSCRIPTION § Gestion formation § Saisir une nouvelle formation § Modifier une formation § Supprimer une formation § Consulter les sessions d’une formation § Gestion session § Saisir une nouvelle formation § Modifier une formation § Supprimer une formation § ……… § Gestion prof § ……. . § Gestion inscription § …. .

Story: identification des fonctions Gestion stock: Domaine r maj stock acture f Produits: Domaine infos produit Un flux un fonction potentielle : Client info s com man de man d e infos commande Distribution: : aff Domaine ect e er nd Domaine a ch m au om c ffe s i n o t f ur o n inf e s i l chtour sc o f au né in ffe es Personnel: ur Domaine com Clients: Domaine Facturation: Domaine

Story: identification des fonctions Le modèle de KANO proportionnelle Attente de base ‘heureuse surprise

Story: identification des exigences qualités Un logiciel peut être considéré sous deux angles § Les fonctions qu'il réalise § L'utilisation du logiciel : les facteurs qualité Fonctionnel Pertinence Adéquation Généralité Utilisation Maniabilité Fiabilité Efficience Confidentialité Couplabilité Maintenance Maintenabilité Portabilité Économique Efficacité J. Mc. Call, Factors in software quality, 1978

Grooming: L’entretien du Product Backlog Constat : Un "document" par nature évolutif. Le Product Owner et l’équipe vont régulièrement toiletter le Product Backlog § identifier des User storiesy utilisateur qui n'auraient plus de sens § créer de nouvelles stories si des besoins nouveaux ont été signalés § réévaluer la priorité des stories entre elles § attribuer des estimations à des stories qui n'en ont pas encore § Découper, détailler les story de l’itération à venir.

Modèles et techniques complémentaires Diagramme de classe § Pour décrire les grands blocs informationnels et les contrôles associés § Dictionnaire de données § Pour décrire les contrôles Diagramme de flux § Pour décrire le périmètre du projet (échanges avec les domaines connexes) Diagramme de séquence § Pour décrire les fonctions § …. 1 3 2

Sommaire q Contexte Agile et Scrum q Revue et rétrospective q Démarche q Planification d’une journée q Les acteurs q Les tests d’acceptation q Le backlog q L’ingénierie de logiciel q Planification de release q La mise en œuvre q Planification d’un sprint § Ce support de cours, propriété de la société ne peut être reproduit qu’avec son autorisation

Planification des releases : la roadmap Release : un ensemble de sprints pour planifier à moyen terme Quand ? Avant la planification de la première release Release backlog 1 Quel est le contenu des releases ? Product backlog Product Owner Release backlog 2 Release backlog 3 Scrum Master

Planification des releases : la roadmap Planification des releases Release 1 Release 2 …. Planification des sprints …. Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5

Planification d’une release Release 1 …. Quand ? § Avant le premier sprint § À chaque fin de sprint Qu’est ce qui sera livré ? Engagement de l’équipe Scrum Master Product Owner L’équipe dev.

Planification d’une release : La taille des story Évaluer la taille des stories de la release : le planning poker 1 2 0 0 2 Petites stories S 3 5 8 13 0 0 0 13 Moyennes stories M 21 34 55 ? 0 0 0 ? Grandes stories L La suite de Fibonacci

Planification d’une release : La taille des story Évaluer la taille des stories de la release : le planning poker § Le Product Owner présente la story § L’équipe dev. pose des questions § Chaque participant abat une carte § Discussion Petites stories Moyennes Grandes stories § 2ème tour ou moyenne ou consensus

Planification d’une release : La taille Ranger des stories par niveau d’estimation 1 Story 2 3 Story 5 8 Story Post 'It 13 Story Story

Planification d’une release : La taille Un exemple d’approche 1 2 3 5 8 Story Story Choisir une story « moyenne » … Story Story Beaucoup plus facile référence plus difficile Beaucoup plus difficile

Planification d’une release : Durée § Fixer la taille de la release Product Owner Exemple L’équipe dev. Scrum Master 10 semaines Release 1 Sprint 1 2 semaines Sprint 2 2 semaines Sprint 3 2 semaines Sprint 4 2 semaines Sprint 5 2 semaines

Planification d’une release : Priorité et valeur Les exigences sont priorisées en tenant compte de la valeur client • du retour sur investissement • du niveau de risque correspondant • de sa nécessité

Planification d’une release : Vélocité «. . . En délivrant des fonctionnalités à chaque fin d’itération vous allez très rapidement pouvoir évaluer objectivement votre niveau de productivité et affiner itération après itération la charge et la date de fin prévue. » Freddy Mallet § Capacité § Projection de la vélocité connue sur les futures releases § Vélocité § la partie du backlog (stories terminées) réalisée par l’équipe de développement pendant la release

Release 1 Planification d’une release : Vélocité § Définir la capacité de l’équipe de dév. pour la première release. Exemple § Estimer la charge en jour / homme § Capacité de l’équipe développement : § § § Sprint de 10 jours ouvrables Equipe de 6 développeurs Capacité « brute » : 60 jours par sprint Il y a 3 débutants Capacité corrigée : 55 jours par sprint Release de 3 sprint Capacité estimé 55 * 3 = 175 ….

Planification d’une release : Le plan de release § Construire le plan de release § Le contenu de la release en terme de sprint § Le contenu des sprints en terme de story Sprint 1 Sprint 2 story Planifié story 5 10 story Planifié Sprint 3 2 Planifié 5 story 5 Planifié 3 story Planifié 5 Capacité de l’équipe dev. : 15 points / sprint

Planification d’une release : Le plan de release Planification des releases Release 1 …. Planification des sprints …. Sprint 1 Sprint backlog Sprint 2 Sprint backlog Sprint 3 Sprint backlog

Planification d’une release : le suivi Le suivi d’une release : Le release burndown chart § ce graphisme représente le nombre de points restant à faire dans la release 3 4 4 5

Sommaire q Contexte Agile et Scrum q Revue et rétrospective q Démarche q Planification d’une journée q Les acteurs q Les tests d’acceptation q Le backlog q L’ingénierie de logiciel q Planification de release q La mise en œuvre q Planification d’un sprint § Ce support de cours, propriété de la société ne peut être reproduit qu’avec son autorisation

Démarche SCRUM Revue Rétrospective Planification

Planification d’un sprint Sprint 1 Quand et combien de temps …. § Au démarrage de chaque sprint § 8 H max. pour un sprint d’ 1 mois Product Owner Qu’est ce qui sera livré ? § Le PO définit l’objectif § L’équipe et le PO choisissent les stories L’équipe dev. § L’équipe Définit et estime les tâches Comment va –t-on réaliser l’objectif ? Scrum Master § Kanban ? Sprint backlog

Définition des tâches Une tâche § Une description § Un résultat (cf. signification de fini) § Une estimation en heures § Origine § Déduites des stories § Indépendantes des stories Exemples § Lire les documents x, y § Préparer la base de test § Développer l’interface U. § Exécuter les tests § Préparer la salle de revue § ………

Sprint backlog À faire Story 1 Story 2 Story 3 En cours Fini tâche Une description tâche Une estimation (en heures) tâche tâche

Stabilité pendant un sprint Le Scrum Master § protège l’équipe de développement durant le sprint § Demande au client à différer la prise en compte du changement jusqu’au prochain SPRINT § Il gère les obstacles . . . Le Client Ø peut annuler un sprint Sprint 6

Planification d’un sprint Le suivi, les burndown charts Le sprint burndown chart § Ce graphisme représente le nombre d’heures restantes à faire dans le sprint 7 6

Sommaire q Contexte Agile et Scrum q Revue et rétrospective q Démarche q Planification d’une journée q Les acteurs q Les tests d’acceptation q Le backlog q L’ingénierie de logiciel q Planification de release q La mise en œuvre q Planification d’un sprint § Ce support de cours, propriété de la société ne peut être reproduit qu’avec son autorisation

Démarche SCRUM Revue Rétrospective Planification

Revue d’un sprint Revue du sprint Sprint Backlog Sprint Produit partiel potentiellemt livrable L’équipe dev. présente les nouvelles fonctionnalités Tous les acteurs concernés sont présents Modifications du backlog produit Product Owner L’équipe dev. Scrum Master invités

Revue d’un sprint résultats § Préparer la démonstration § Rappeler les objectifs du sprint § Effectuer la démonstration § Calculer la vélocité Backlog produit actualisé Plan de release màj § Ajuster le plan de release Burdown chart màj

Revue d’un sprint À essayer § Dérouler un scénario À éviter § Modifier au dernier moment § Inviter largement mais expliquer que c’est un produit partiel § parler processus § Parler des stories § Parler « technique » § Solliciter le feedback § Ne pas finir les stories § En faire la réunion essentielle sur le produit 4 h pour un sprint d’un mois

Démarche SCRUM Revue Rétrospective Planification

Rétrospective d’un sprint Rétrospective du sprint Backlog sprint Produit partiel Sprint L’équipe dev. fait en interne le bilan des conditions de réalisation du sprint Lister ce qui marche et ce qui ne marche pas Entre 15 et 30 minutes Product Owner L’équipe dev. Scrum Master

Rétrospective d’un sprint Une réunion pour mettre en pratique une amélioration continue § Collecter les informations sur le sprint passé § Identifier les idées d’amélioration § Sélectionner et classer les idées d’amélioration résultat § Adapter Scrum pour le prochain sprint Une liste d’actions

Rétrospective d’un sprint À éviter À essayer § Parler de ce qui va bien § Régler ses comptes § Vouloir tout améliorer d’un coup § Se concentrer sur une seule amélioration § Ne pas faire aboutir les actions décidées § Mener des rétrospectives plus poussées en fin de release § Arrêter de faire les rétrospectives § Utiliser un facilitateur externe 3 h pour un sprint d’un mois

Sommaire q Contexte Agile et Scrum q Revue et rétrospective q Démarche q Planification d’une journée q Les acteurs q Les tests d’acceptation q Le backlog q L’ingénierie de logiciel q Planification de release q La mise en œuvre q Planification d’un sprint § Ce support de cours, propriété de la société ne peut être reproduit qu’avec son autorisation

Démarche SCRUM Revue Rétrospective Planification

Planification d’une journée : Mêlée quotidienne N’attendons pas trop tard pour réagir ! § Réunion journalière § 15 minutes § Poussée collective 5

Planification d’une journée : Mêlée quotidienne Réunion journalière pour : § Éliminer les obstacles nuisant à la progression de l’équipe § Garder l’équipe concentrée sur l’objectif du sprint § Évaluer l’avancement du travail pour le sprint en cours § Communiquer objectivement sur l’avancement

Planification d’une journée : Mêlée quotidienne 3 questions pour chaque membre de l’équipe : 1. Qu’ai-je fait hier pour atteindre l’Objectif du Sprint ? 2. Que vais-je faire aujourd’hui pour atteindre l’Objectif du Sprint ? 3. Est-ce que je vois un obstacle qui m’empêche ou empêche l’Équipe de Développement d’atteindre l’Objectif du Sprint ?

Planification d’une journée : Mêlée quotidienne Les acteurs § Seuls les membres de l’équipe dev. ont la parole § Le Scrum Master (anime) § Le Product Owner § les autres parties prenantes (communication)

Planification d’une journée : Mêlée quotidienne Résultats § Le plan de sprint est actualisé § Le burndown chart de sprint est actualisé § La liste des obstacles est actualisée

Sommaire q Contexte Agile et Scrum q Revue et rétrospective q Démarche q Planification d’une journée q Les acteurs q Les tests d’acceptation q Le backlog q L’ingénierie de logiciel q Planification d’une release q La mise en œuvre q Planification d’un sprint § Ce support de cours, propriété de la société ne peut être reproduit qu’avec son autorisation

Les tests d’acceptation Le test intégré à chaque sprint Une description complémentaire : les spécifications par l’exemple Les étapes § § Définir les conditions de satisfaction Écrire les story tests Développer la story Passer les story tests Pilotage par les tests d’acceptation Product Owner

Les tests d’acceptation éventuellement Quand passer les tests ? Planification des releases Release 1 Release 2 …. Planification des sprints …. Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5

Les tests d’acceptation : les story tests story État avant l’exécution (étant donné) Événement (quand) État après l’exécution (alors) storytest storytest Story test Exemple d’écriture des tests q Étant donné le client connecté et les produits disponibles affichés. q Quand le client choisi le produit qu’il veut acheter. q Alors la commande est enregistrée, un ordre d’expédition est émis et les stocks sont mis à jour

Les tests d’acceptation : les story tests storytest storytest Story test A voir une démarche pour identifier les tests des stories « de gestion » 1. Des tests pour vérifier l’interface U. 2. Des tests pour déclencher les anomalies (contrôles) 3. Des tests courants (créer, consulter, supprimer, …. ) Construire une base de test Base de test

Les tests d’acceptation : les story tests storytest storytest Story test Avoir une démarche pour identifier les tests des stories « exigences qualités » • Associer à chaque facteur ou critère qualité exigé : • Une métrique • Une valeur

Les tests d’acceptation : résultat des tests Modification du backlog § de nouvelles stories § des stories mise à jours

Sommaire q Contexte Agile et Scrum q Revue et rétrospective q Démarche q Planification d’une journée q Les acteurs q Les tests d’acceptation q Le backlog q L’ingénierie de logiciel q Planification de release q La mise en œuvre q Planification d’un sprint § Ce support de cours, propriété de la société ne peut être reproduit qu’avec son autorisation

L’ingénierie de logiciel § Développement piloté par les tests § Conception simple § Remaniement § Programmation en binôme Développé par Xp et adopté par Scrum Master L’équipe dev.

L’ingénierie de logiciel Le développement piloté par les tests Écriture des tests Programmation Exécution des tests automatisation Les tests unitaires avec un environnement comme x. Unit

L’ingénierie de logiciel La conception simple § Eviter d’imaginer dès le départ la totalité des classes et héritages nécessaires dans le futur système Le remaniement § Améliorer la conception du code sans modifier son comportement externe

L’ingénierie de logiciel La programmation en binôme § Pilote et copilote § Responsabilité collective du code § Avantages § La recomposition régulière des binômes favorise la circulation de la connaissance à l’intérieur du projet § Amélioration de la qualité du code (clarté, conception) § Inconvénients § Augmente la charge et le coût § Difficulté de mesurer la rentabilité

Sommaire q Contexte Agile et Scrum q Revue et rétrospective q Démarche q Planification d’une journée q Les acteurs q Les tests d’acceptation q Le backlog q L’ingénierie de logiciel q Planification de release q La mise en œuvre q Planification d’un sprint § Ce support de cours, propriété de la société ne peut être reproduit qu’avec son autorisation

La mise en œuvre : choisir sa documentation Diagramme de classe Schéma BD Diagramme De séquence Description des stories Plan qualité Code tests unitaires Et tests d’intégration Tests d’acceptation Doc. utilisateur Doc. exploitation Procès verbaux

La mise en œuvre : estimer les charges § À la construction du backlog § Pour proposer un calendrier § Pour évaluer le budget § Pour découper en release § Pour le développement § Pour planifier les release § Pour planifier les sprints Les points fonctionnels DELPHI Le planning poker

La mise en œuvre : choisir un outil Version. One, Time Performance, Ice. Scrum, The Scrum, Open. ERP, Green. Hopper, Microsoft Scrum, JIRA, . . .

La mise en œuvre : compléter le cadre Scrum est plus un cadre méthodologique qu’un processus projet complet Scrum n'existe que dans son intégralité et fonctionne bien en tant que conteneur pour d'autres techniques, méthodologies et pratiques. (dixit Ken Schwaber).

La mise en œuvre : sortir du cadre Méthodes estimation de charges Projet de grande taille Techniques de modélisation Projet stratégique fort Techniques de reporting Projet international Techniques de planification ……. ………. Organisation existante Taille de l’équipe Responsable qualité Contrainte qualité interne Architectes des systèmes … Responsable des achats ………. PROCESSUS PROJET spécialisé

La mise en œuvre : préciser rôles et responsabilités 7

La mise en œuvre : sous traiter Constat § En Agile, le périmètre par principe n’est pas fixe § Dans la sous-traitance, l’enveloppe budgétaire doit être fixe

La mise en œuvre : sous traiter Proposition § Définir le contenu initial des itérations § Engager le fournisseur sa vélocité par itération § Clause de changement gratuit § Clause de clôture avant la dernière itération Conseils § Bien définir les rôles § Binôme client/fournisseur pour estimer la charge du changement

La mise en œuvre : transition vers Scrum Les étapes de la transition Évaluer le contexte Préparer l’application de Scrum Conduire un projet pilote Déployer la méthode Faire un bilan 8

Conclusion : Scrum une réponse adaptée § Le SI : un outil pour mettre en œuvre la stratégie de l’entreprise § Une obligation de forte réactivité, des délais courts et maîtrisés § Parmi les solutions § § L’urbanisation du système d’information Des projets courts Des démarches de projets adaptées Le client impliqué

Conclusion : Scrum pour s’améliorer The 2015 CHAOS Report All size projects 70 60 50 40 30 20 10 0 Successful Challenged Agile Waterfall Failed

Conclusion : Scrum pour s’améliorer Largesize projects Small size projetcs 70 60 50 40 30 20 10 0 50 40 30 20 Successful Challenged Agile 10 Failed 0 Waterfall Successful Medium size projetcs Challenged Agile Failed Waterfall 80 60 40 20 0 Successful Challenged Agile Waterfall Failed The 2015 CHAOS Report

Conclusion : critères d’éligibilité Favorisant § § § Besoin rapide de mise à disposition du produit Imprévisibilité des besoins du client Nécessité de changements fréquents Besoin de visibilité du client sur l’avancement des développeurs Présence de l’utilisateur assurant un feedback immédiat Défavorisant § § Indisponibilité du client ou de l’utilisateur Dispersion géographique des ressources humaines Inertie des acteurs du projet ou refus des changements Gouvernance complexe de la DSI

Pour clore notre stage Des questions ? § Pensez à (remplir et) remettre votre fiche d’appréciation. § Je suis disponible pour vos questions et demandes. § Merci pour votre présence et votre écoute. § Cette formation a été conçue par les ingénieurs de la société § § § tél : 01 53 63 37 87 mail : delf@delf. fr site : www. delf. fr § Ce support de cours, propriété de la société ne peut être reproduit qu’avec son autorisation

Bibliographie § Agile, SCRUM, XP, … § Scrum, Management de projet Agile de Kenneth S. Rubin aux éditions Perason, 2013 Un ouvrage qui présente un état de l’art complet § Scrum, de Claude Aubry aux éditions Dunod, 2013 Un excellent ouvrage pour la mise en pratique § PMI-ACP Exam prep de Mike Griffiths aux éditions Premier Edition, 2012 Ouvrage de préparation à la certification agile du Project Management Institute (PMI) § Scrum en action de Guillaume Bodet aux éditions Pearson, 2012 Le partage d’une expérience agile § Extreme Programming Explained, de K. Beck aux éditions Addison Wesley, 2000. L’ouvrage fondateur de la méthode XP § Extreme Programming Installed, de R. Jeffries, A. Anderson, C. Hendrickson aux éditions Addison Wesley, 2001. Un ouvrage amusant sur la mise en pratique d’XP dans le cadre d’un projet.

Bibliographie § Gestion d’équipe § Coacher une équipe agile de Véronique Messager aux éditions Eyrolles, 2012 Un ouvrage complet sur le coaching agile § Coaching agile de Fabrice Aimetti et Isabel Monville aux éditions Ayeba, 2014 § Les projets SI § J. Hugues, B. Leblanc, C. Morley, RAD une méthode pour développer plus vite , Dunod 1997 § C. Morley, J. Hugues, B. Leblanc, UML 2 pour l’analyse dun système d’information , Dunod, 3ème édition 2009 § C. Morley, Management d’un projet système d’information , Dunod, 6 ème édition 2010 § C. Morley, J. Hugues, B. Leblanc, O. Hugues, Processus métiers et S. I. , Dunod, 2ème édition 2008

Annexe Site Web § Sites WEB § scrum. org § scrumalliance. org § frenchsug. org

Vos cartes 1 2 3 5 8 ? 118