Méthodologie Agile et Hybride

Responsable du cours: Dr. Marwa Ben Jabra

Niveau: 4éme Informatique

M1 Data Science

Année universitaire : 2022-2023

 Plan du cour
I. Définition D’un Projet II. Méthode AGILE

III. Scrum IV. Méthode Hybride

 Objectifs du cours
• Comprendre les éléments nécessaire d’un projet et les difficultés de
mangement du projet

• Comprendre le concept du méthode Agile

• Etudier les fondamentaux de la gestion des projets

• Comprendre la méthode hybride

CHAPITRE I

Définition d’un projet

 Qu’est ce qu’un projet?

1: Activité unique et temporaire : un début et une fin. On parle de triangle qualité coût et délai

2: Par étapes , qui se prépare. Se pense avant de s’exécuter et se déroule par étapes ou
phases=‘jalons’

3: Un résultat: Le livrable. Le projet sert à répondre à des besoins bien définis et le juger de sa
réussite:
Le livrable mesure la réussite du projet.
Une autre caractéristique du projet est le fait qu’il mobilise des personnes de compétences
diverses
 Définition dans ISO 21500

• Un projet est un processus unique qui consiste en un ensemble d’activités

coordonnées et maîtrisées comportant des dates de début et de fin
entrepris dans le but d’atteindre un objectif conforme à des exigences
telles que des contraintes de délai, de coût et de ressources
 Pourquoi des projets ?

𝐶𝑟é𝑎𝑡𝑖𝑜𝑛 𝑑𝑒 𝑣𝑎𝑙𝑒𝑢𝑟
Productivité = Coût
• Création de valeur : quantité de valeur que l’on arrive à créer = innover, choses améliorées ou
choses dont on est les seuls à détenir le savoir faire

• Coût: Ressources consommées pour créer la valeur.

Plusieurs solutions existent afin d’augmenter la productivité.

- Par la baisse des coûts : Mais cela ne représente pas la solution idéale notamment à cause de
la concurrence et de la mondialisation.

- Par l’augmentation de la création de valeur: à l’aide de l’innovation et de l’amélioration

continue des choses
 Pourquoi des projets ?

• Ce projet permet d’aller au-delà de la seule réduction des coûts, en favorisant

l’innovation et donc la création de valeur.

Autrement dit, l’innovation amène à la maximisation de la création de la valeur.

L’essence d’un projet est l’innovation

Derrière l’innovation: productivité + et survie de l’entreprise.

Manager un projet
 Modèle Waterfall

Le modèle de développement logiciel le plus couramment utilisé avec cette caractéristique est le
modèle Waterfall.

Cependant, dans la plupart des cas, de nouvelles fonctionnalités sont ajoutées et les exigences
antérieures peuvent également changer.

Le modèle Waterfall n'est pas structuré pour s'adapter à ces changements continus d'exigences.

En outre, l'utilisateur n'aura pas de clarté sur la fonctionnalité du produit tant que le produit ne
sera pas disponible dans son intégralité.
Modèle Waterfall
 Modèle incrémental itératif

Dans le modèle incrémental itératif, le développement commence avec un nombre limité

d'exigences finalisées et hiérarchisées.

Le livrable est un incrément de travail du produit.

Un ensemble d'activités allant des exigences au développement de code est appelé une itération.

Sur la base de la fonctionnalité de l'incrément et de tout ou partie des exigences nouvelles,

modifiées et en attente, le lot d'exigences suivant est attribué à l'itération suivante.

Le résultat de l'itération suivante est un incrément de travail amélioré du produit.

Ceci est répété jusqu'à ce que le produit accomplisse les fonctionnalités requises.
Modèle incrémental itératif
 Modèle incrémental itératif

L'utilisateur n'est généralement pas impliqué dans le travail de développement et cela peut
entraîner des lacunes de communication entraînant des fonctionnalités incorrectes.

L'implication est positive pour l'équipe de développement, mais elle est exigeante sur le temps de
l'équipe et peut ajouter des retards.

En outre, tout changement d'exigence informel au cours d'une itération peut prêter à confusion
et peut également créer des dérives de portée.

Avec cette prémisse, le développement Agile est né.

CHAPITRE II

Méthode AGILE
 Définition

• Une méthode agile est une approche itérative et collaborative, capable de prendre en compte
les besoins initiaux du client et ceux liés aux évolutions.

• Le terme «agile» fait référence à la capacité

• Utilisées d’abord dans le cadre du développement logiciel et désignant de nouvelles pratiques

de gestion de projet, les méthodes agiles trouvent leur émergence dans les années 2000.
S’imposant comme un modèle plus souple et plus flexible, elles prennent le contre-pied des
gestions de projets dites prédictives en proposant le développement d’un produit par le biais
d’itérations.
 Origine des Méthodes AGILES

Vu le taux élevé d’échec des projets dans les années 1990, 17 experts en développement logiciel
se réunissent aux Etats-Unis en 2001 afin de mettre en commun une nouvelle méthode de
gestion des projets.

Le «Manifeste Agile» naît de cette rencontre et détermine les valeurs et les principes
fondamentaux de la méthode Agile.

Une plus grande implication du client et une meilleure réactivité des équipes face à ses
demandes sont au cœur de la méthode Agile. Ce manifeste prône les 4 valeurs fondamentales de
la méthodologie :
 Manifeste des Méthodes AGILES

Au cœur du Manifeste, les quatre valeurs fondamentales concernent l’équipe, le produit applicatif,
la collaboration, et l’acceptation au changement.

Sur l’équipe: «Les individus et leurs interactions plus que les processus et les outils»

Sur le produit applicatif: «Un logiciel qui fonctionne plus qu’une documentation exhaustive»

Sur la collaboration: «La collaboration avec les clients plus que la négociation contractuelle»

Sur l’acceptation du changement: «L’adaptation au changement plus que le suivi d’un plan»

Ces quatre valeurs fondamentales sont complétées par douze principes, qui déclinent leurs
implications concrètes dans les méthodes de travail et les attitudes à privilégier dans le cadre du
développement d’un logiciel.
 Manifeste des Méthodes AGILES

On peut citer notamment le principe de simplicité: «La simplicité, c’est-à-dire l’art de minimiser la
quantité de travail inutile, est essentielle», et le principe itératif: «Livrez fréquemment un logiciel
opérationnel avec des cycles de quelques semaines à quelques mois, et une préférence pour les
plus courts».

D’un point de vue organisationnel, le Manifeste promeut l’auto-organisation des équipes, la

confiance et le soutien dans l’atteinte des objectifs, ainsi que le dialogue direct en face-à-face.
 Manifeste des Méthodes AGILES

Les 12 principes de la méthode Agile:

1: Satisfaire le client en priorité

2: Accueillir favorablement les demandes de changement

3: Livrer le plus souvent possible des versions opérationnelles de l’application

4: Assurer une coopération permanente entre le client et l’équipe projet

5: Construire des projets autour de personnes motivées

6: Privilégier la conversation en face à face

 Manifeste des Méthodes AGILES

7: Mesurer l’avancement du projet en matière de fonctionnalité de l’application

8: Faire avancer le projet à un rythme soutenable et constant

9: Porter une attention continue à l’excellence technique et à la conception

10: Faire simple

11: Responsabiliser les équipes

12: Ajuster à intervalles réguliers son comportement et ses processus pour être plus efficace
 Exemple Concret

Par exemple, vous prévoyez de vous rendre à Matmata depuis Sousse en passant par les petites
routes de campagne. Avant de partir, vous planifiez chaque détail de votre trajet en précisant le nom
de chaque ville et village traversés, l'heure précise de passage, chaque rue empruntée, la quantité
d'essence consommée, les kilomètres parcourus, etc. Le problème, c'est que les imprévus ne
manqueront pas sur le chemin: embouteillages, travaux et déviations, voire panne de votre véhicule.
Votre planification devient très vite obsolète et vous venez de perdre un temps précieux à organiser
avec précision un itinéraire que vous ne pouvez pas forcément suivre.

Avec la méthodologie Agile, plutôt que de planifier l'intégralité de votre itinéraire, vous vous fixez
un premier objectif à court terme, une grande ville, et vous prenez immédiatement la route. Une
fois l'objectif atteint, vous prenez le temps d'analyser la situation actuelle (état de la circulation et
de la voiture) et vous adaptez la suite de votre itinéraire en fonction de ces informations. Vous
continuez ainsi de suite jusqu'à atteindre votre destination finale.
 Une Approche itérative

La méthode Agile se caractérise en premier lieu par le fait de découper le projet en plusieurs étapes
de quelques semaines, nommées itérations. Durant une itération, une version intermédiaire du
produit attendu est développée, puis validée. Les fonctionnalités sont intégrées au fur et à mesure du
projet en suivant un mode incrémental. Le produit se construit donc au fil des itérations de manière
progressive. Le client, ou utilisateur final, voit ainsi régulièrement avancer le développement du
projet, en obtenant à chaque itération une nouvelle version opérationnelle et testable du produit
cible. Il peut ainsi valider le fait que ce qu’il a sous les yeux et voit fonctionner correspond bien à ses
besoins, ou au contraire demander des modifications, et établir ou revoir ses priorités pour les
prochaines étapes du projet en partant d’un résultat tangible plutôt que d’un idéal abstrait.

Chaque itération est un mini-projet en soi, avec toutes les activités nécessaires à la livraison d’un
produit minimum fonctionnel: analyse, conception, codage, test, documentation. Il est recommandé
que chaque itération correspondante à une plage temporelle identique
 Un Esprit collaboratif

• La méthode agile met délibérément l’accent sur la notion d’équipe.

• La réussite d’un projet complexe est en effet conditionnée à la compétence, à la motivation, et à la

bonne organisation d’une équipe.

• La méthode agile privilégie des interactions nombreuses et de qualité entre les acteurs du projet,
qu’ils soient membres à plein temps de l’équipe projet ou seulement interlocuteurs occasionnels.

• Chacun est appelé à partager l’information, donner son point de vue en respectant celui des autres,
et aller spontanément vers l’entraide.

• L’objectif est de passer d’une logique de contrôle et de concurrence, bien souvent la norme dans les
grandes organisations, à une logique de confiance et de coopération.
 Un Esprit collaboratif

•l’équipe projet agile doit autant que possible s’auto-organiser, sans passer par le pouvoir
décisionnaire d’un chef. Cette ambition qui paraît utopique s’affirme en fait via des dispositions
concrètes et des règles strictes

•La méthode agile n’a pas recours à des «chefs» de projets, mais plutôt à des leaders facilitateurs, qui
sont au service de l’équipe, et doivent créer les conditions optimales pour atteindre collectivement
les objectifs.

•Le manager n’est pas là pour commander, mais pour protéger et soutenir son équipe.

•Il est aussi recommandé de regrouper physiquement les membres du projet, dans un espace
propice à faciliter les échanges.

•La réunion d’équipe, cadre traditionnel où se manifestent la hiérarchie et les rapports de force, est
remplacée des rituels animés de telle sorte que chacun puisse s’exprimer et que la prise de décision
s’oriente vers le consensus.
 Moins de lourdeur, plus de valeur
• Le projet agile nécessite des outils légers ≠ produire des spécifications techniques, de la
documentation, des tableaux de bords ou des rapports

• La méthode préconise de livrer des versions intermédiaires et montrer des produits ou sous-parties
du produits qui fonctionnent

• La priorité à la création de valeur pour l’usager final ≠ de décrire et de commenter

• Une démarche empirique: si un processus ou un outil fait gagner du temps et rend l’équipe plus
efficace , on l’adopte

• La méthode agile s’attache à très peu d’éléments obligatoires au départ ≠ les méthodes classiques
prévoient de nombreux éléments à respecter tout au long du projet

• Le client ou l’usager décide de ce qui est conforme ou non à son attente et ses priorités pour les
prochaines itérations

• L’ensemble de travail s’oriente naturellement vers sa satisfaction.

 L’acceptation du changement

Tout projet comporte des éléments imprévisibles (technologie, la gestion du projet, contexte
économique ou règlementaire, facteurs humains)

• Le changement est le bienvenu

• le changement ne doit pas être considéré comme un problème

• L’équipe projet s’assure d’être toujours au plus prés des besoins de l’usager en maximisant la
valeur que l’on va lui apporter.
 Méthodologie de développement de
système dynamique (DSDM)

C'est un cadre agile pour les projets logiciels. Il a été utilisé pour affiner les approches
traditionnelles.

La version la plus récente de DSDM s'appelle DSDM Atern.

Le nom Atern est l'abréviation de Arctic Tern - un oiseau marin qui peut parcourir de grandes
distances et qui représente de nombreuses caractéristiques de la méthode qui sont des
méthodes naturelles de travail telles que la hiérarchisation et la collaboration.
 Scrum

C'est le framework agile le plus populaire, qui se concentre particulièrement sur la façon de gérer
les tâches dans un environnement de développement en équipe.

Scrum utilise un modèle de développement itératif et incrémental, avec une durée d'itérations
plus courte.

Scrum est relativement simple à mettre en œuvre et se concentre sur des livraisons rapides et
fréquentes.
 Programmation extrême (XP)
C'est un type de développement logiciel agile.

Il préconise des versions fréquentes dans des cycles de développement courts, ce qui vise à
améliorer la productivité et à introduire des points de contrôle où les nouvelles exigences des
clients peuvent être adoptées.

La méthodologie tire son nom de l'idée que les éléments bénéfiques des pratiques traditionnelles
de génie logiciel sont poussés à des niveaux extrêmes.

(La programmation extrême est une discipline de développement de logiciels qui organise les
gens pour produire des logiciels de meilleure qualité de manière plus productive.)

XP aborde les phases d'analyse, de développement et de test avec de nouvelles approches qui
font une différence substantielle dans la qualité du produit final.
 Développement piloté par les tests (TDD)

C'est un processus de développement logiciel qui repose sur la répétition d'un cycle de
développement très court:

- D'abord le développeur écrit un cas de test automatisé qui définit une amélioration souhaitée
ou une nouvelle fonction

- Puis il produit le moins de code pour réussir ce test,

- Enfin, apporte le nouveau code à des normes acceptables.

 Lean

Il s'agit d'une pratique de production qui considère la dépense de ressources pour tout objectif
autre que la création de valeur pour le client final comme un gaspillage, et donc un objectif
d'élimination.

En travaillant du point de vue du client qui consomme un produit ou un service, le terme valeur
est défini comme toute action ou processus pour lequel un client serait prêt à payer.

Lean est centré sur la préservation de la valeur avec moins de travail.

 Kanban

C'est un système pour améliorer et maintenir un haut niveau de production.

Kanban est une méthode par laquelle Just-In-Time (JIT), la stratégie employée par les
organisations pour contrôler les dépenses d'inventaire, est réalisé.

Kanban est devenu un outil efficace pour soutenir le fonctionnement d'un système de production
dans son ensemble, et il s'est avéré être un excellent moyen de promouvoir l'amélioration.
 Conclusion
Au cours des 10 dernières années, il y a un volume sans cesse croissant d'histoires de réussite, où
les entreprises ont considérablement amélioré le succès et les performances de leurs équipes de
développement informatique et des projets avec des pratiques agiles. Cela a conduit à une large
adoption de l'agilité dans divers secteurs, notamment les médias et la technologie, les grandes
entreprises et même le gouvernement.

Agile Framework aide les équipes à bénéficier de:

•Délai de livraison / commercialisation plus rapide

•Réduire l'incertitude et les risques

•Augmentez le retour sur investissement (ROI) en vous concentrant sur la valeur client

Parmi ces différentes méthodologies agiles, Scrum s'est avérée extrêmement réussie dans le
monde au cours des 20 dernières années.
CHAPITRE III

SCRUM
 Scrum - Cadre

Scrum est un cadre pour le développement et le maintien de produits

complexes.

Ken Schwaber et Jeff Sutherland ont développé Scrum.

Ensemble, ils soutiennent les règles Scrum.

 Scrum – Cadre
Définition de Scrum

Scrum est un cadre dans lequel les gens peuvent résoudre des problèmes adaptatifs complexes,
tout en fournissant de manière productive et créative des produits de la plus haute valeur
possible.

Scrum est un cadre de processus qui a été utilisé pour gérer le développement de produits
complexes depuis le début des années 1990.

Scrum n'est pas un processus ou une technique de construction de produits; c'est plutôt un cadre
dans lequel vous pouvez employer divers processus et techniques.

Scrum met clairement en évidence l'efficacité relative de vos pratiques de gestion et de

développement de produits afin que vous puissiez vous améliorer
 Scrum – Cadre
Définition de Scrum

Le framework Scrum se compose des équipes Scrum et de leurs rôles, événements, artefacts et
règles associés. Chaque composant dans le cadre sert un objectif spécifique et est essentiel au
succès et à l'utilisation de Scrum.

Les règles de Scrum lient les événements, les rôles et les artefacts, régissant les relations et
l'interaction entre eux. Les règles de Scrum sont décrites tout au long de ce cour .

Note- Dans toute l'industrie, il y a des idées fausses selon lesquelles Scrum signifie pas de
documentation, l'équipe Scrum se compose uniquement de développeurs, etc. Ce n'est pas
entièrement le cas; nous donnerons des éclaircissements à ce sujet dans les sections suivantes.
 Scrum – Cadre
Cadre de processus Scrum

Dans Scrum, les

événements prescrits
sont utilisés pour créer
de la régularité..

Tous les événements

sont des événements
temporisés, de sorte que
chaque événement a une
durée maximale.
 Scrum – Cadre
Sprint

Le cœur de Scrum est un Sprint, une boîte de temps de deux semaines ou d'un mois au cours de
laquelle un incrément de produit potentiellement libérable est créé.

Un nouveau Sprint commence immédiatement après la fin du Sprint précédent.

Les sprints comprennent la planification du sprint, les daily Scrums meetings, le travail de
développement, la revue du sprint et la rétrospective du sprint.
 Scrum – Cadre
Sprint

• Dans la planification de Sprint, le travail à effectuer dans le Sprint est planifié en collaboration
par l'équipe Scrum.

• Le Daily Scrum Meeting est un événement de 15 minutes dans une boîte de temps permettant à
l'équipe Scrum de synchroniser les activités et de créer un plan pour cette journée.

• Une revue de sprint est organisée à la fin du sprint pour inspecter l'incrément et apporter des
modifications au backlog produit, si nécessaire.

• La rétrospective de sprint a lieu après la revue de sprint et avant la prochaine planification de

sprint. Lors de cette réunion, l'équipe Scrum doit s'auto-inspecter et créer un plan d'améliorations
à appliquer au cours du sprint suivant.
 Scrum – Rôles

L'équipe Scrum se compose de trois rôles, à savoir

 Scrum – Rôles
ScrumMaster
Le ScrumMaster (parfois écrit comme Scrum Master, bien que le terme officiel n'ait pas
d'espace après «Scrum») est le gardien du processus de mêlée.

Il / elle est responsable de-

• Faire fonctionner le processus sans heurts

• Eliminer les obstacles qui ont un impact sur la productivité

• Organiser et animer les réunions critiques

 Scrum – Rôles
Product Owner

Le Product Owner est responsable de maximiser la valeur du produit et le travail de l'équipe.

La manière de procéder peut varier considérablement selon les organisations, les équipes Scrum et
les individus.

Le Product Owner est la seule personne responsable de la gestion du Product Backlog.

 Scrum – Rôles
Product Owner

La gestion du backlog produit comprend:

• Exprimer clairement les éléments du Backlog produit.

• Commander les articles du Backlog Produit pour atteindre au mieux les objectifs et les missions.

• Optimiser la valeur du travail effectué par l'équipe.

• S'assurer que le Backlog produit est visible, transparent et clair pour tous, et montre sur quoi
l'équipe travaillera plus loin.

• S'assurer que l'équipe comprend les éléments du Backlog produit au niveau requis.
 Scrum – Rôles
Propriétaire du produit

Le Product Owner peut effectuer le travail ci-dessus ou demander à l'équipe de le faire.

Cependant, le Product Owner reste responsable de ces tâches.

Le Product Owner est une personne, pas un comité. Le Product Owner peut représenter les désirs
d'un comité dans le Product Backlog, mais ceux qui souhaitent modifier la priorité d'un élément
du Product Backlog doivent s'adresser au Product Owner.

Pour que le Product Owner réussisse, toute l'organisation doit respecter ses décisions. Les
décisions du Product Owner sont visibles dans le contenu et la commande du Product Backlog.

Personne n'est autorisé à dire à l'équipe de travailler à partir d'un ensemble d'exigences différent,
et l'équipe n'est pas autorisée à agir sur ce que quelqu'un d'autre dit. Ceci est assuré par
ScrumMaster.
 Scrum – Rôles
L’équipe
• L'équipe est auto-organisée et interfonctionnelle.

➢ Cela signifie que l'équipe comprend des analystes, des concepteurs, des développeurs, des
testeurs, etc., selon le cas et le cas échéant pour le projet.

• Certaines personnes dans l'industrie appellent cette équipe une équipe de développement.
Cependant, une telle référence mène à la controverse selon laquelle l'équipe ne peut avoir que
des développeurs et aucun autre rôle.

➢ Il est évident que ce n’est qu’une idée fausse. Pour développer un produit logiciel, nous avons
besoin de tous les rôles et c'est l'essence même de Scrum - l'équipe fonctionnera en
collaboration.
➢ Les équipes interfonctionnelles possèdent toutes les compétences nécessaires pour accomplir
le travail sans dépendre d'autres personnes ne faisant pas partie de l'équipe, ce qui permet
d'économiser du temps et des efforts. Le modèle d'équipe dans Scrum est conçu pour
optimiser la flexibilité, la créativité et la productivité.
 Scrum – Rôles
L’équipe

• La taille optimale de l'équipe est suffisamment petite pour rester agile et suffisamment grande
pour effectuer un travail important dans un sprint.
• La taille de l'équipe doit être comprise entre cinq et neuf personnes, si possible. Moins de cinq
membres de l'équipe réduisent l'interaction et se traduisent par de plus petits gains de
productivité. Avoir plus de neuf membres demande trop de coordination.

• L'équipe Scrum travaille en étroite collaboration, au quotidien, pour assurer la fluidité des
informations et la résolution rapide des problèmes.
• L'équipe Scrum délivre le produit de manière itérative et incrémentielle, maximisant les
opportunités de feedback.
• Les livraisons incrémentielles d'un produit complet garantissent qu'une version potentiellement
utile du produit opérationnel est toujours disponible.
 Scrum – Scrum Master
Services ScrumMaster au Product Owner
ScrumMaster est une personne responsable formée, qui rend les services décrits ci-dessous –

Le ScrumMaster sert le Product Owner de plusieurs manières, notamment:

• Trouver des techniques pour une gestion efficace du Backlog Produit.

• Aider l'équipe Scrum à comprendre le besoin d'éléments de Backlog produit clairs et concis.

• Comprendre la planification des produits dans un environnement empirique.

• S'assurer que le Product Owner sait comment organiser le Product Backlog pour maximiser la
valeur.

• Comprendre et pratiquer l'agilité.

• Faciliter les événements Scrum au besoin.

 Scrum – Scrum Master
Services ScrumMaster à l'équipe Scrum

Le ScrumMaster sert l'équipe Scrum de plusieurs manières, notamment:

• Coaching de l'équipe Scrum dans l'auto-organisation et la transversalité.

• Aider l'équipe Scrum à créer des produits de grande valeur.

• Supprimer les obstacles à la progression de l'équipe Scrum.

• Faciliter les événements Scrum à la demande ou au besoin.

• Coaching de l'équipe Scrum dans des environnements organisationnels dans lesquels Scrum
n'est pas encore pleinement adopté et compris.
 Scrum – Scrum Master
Services ScrumMaster à l’organisation

Le ScrumMaster sert l'organisation de plusieurs manières, notamment:

• Diriger et encadrer l'organisation dans son adoption de Scrum.

• Planification des implémentations de Scrum au sein de l'organisation.

• Aider les employés et les parties prenantes à comprendre et à mettre en œuvre Scrum et le
développement de produits empiriques.

• Provoquer un changement qui augmente la productivité de l'équipe Scrum.

• Travailler avec d'autres ScrumMasters pour augmenter l'efficacité de l'application de Scrum dans
l'organisation.
 Scrum – Scrum Master
Conclusion

Scrum est un cadre de processus qui définit certaines règles, événements et rôles pour apporter
de la régularité.

Cependant, il peut être adapté à n'importe quelle organisation, en fonction des besoins, à
condition que les règles de base de Scrum ne soient pas violées.
 Scrum – Événements

▪ Scrum Process Framework peut être visualisé au moyen d'une séquence d'événements et des
artefacts correspondants.

▪ Les événements Scrum sont des événements temporisés. Cela signifie que, dans un projet,
chaque événement Scrum a une durée maximale prédéfinie.

▪ Ces événements permettent une transparence sur l'avancement du projet à tous ceux qui sont
impliqués dans le projet.
 Scrum – Événements

▪ Les événements vitaux de Scrum sont-

✓ Le Sprint

✓ Planification de sprint

✓ Réunions Scrum quotidiennes

✓ La revue de sprint

✓ La rétrospective Sprint
 Scrum – Événements
Démarche itérative du Scrum
 Scrum – Événements
Itérations Release

Chaque fin de release apporte de nouvelles fonctionnalités pour les utilisateurs

 Scrum – Événements
Itérations Sprint

Chaque fin de sprint apporte de nouvelles fonctionnalités pour les Product Owner
 Scrum – Événements
Itérations Stories

Chaque fin de Story est une nouvelle liste de tâches terminées pour la team
Scrum – Événements
Planning
Scrum – Événements
Le process Scrum
 Scrum – Événements
Le Sprint

• Lors d'un Sprint, un incrément de produit fonctionnel est développé.

• Il est généralement d'une durée de deux semaines ou d'un mois, et cette durée reste constante
pour tous les sprints du projet.

• Nous ne pouvons pas avoir des durées variables pour les différents sprints d'un projet.

• Un nouveau Sprint commence immédiatement après la fin du Sprint précédent.

 Scrum – Événements
Le Sprint

• Le Sprint Goal est un objectif fixé pour le Sprint.

• Il fournit des conseils à l'équipe sur les raisons pour lesquelles elle construit l'incrément.

• Il est créé lors de la réunion de planification de sprint.

• La portée du sprint est clarifiée et renégociée entre le Product Owner et l'équipe au fur et à
mesure que les exigences sont apprises.

• Ainsi, chaque Sprint lui est associé, une définition de ce qui doit être construit, une conception
et le plan flexible qui guidera sa construction, le travail de développement et l'incrément de
produit résultant.
 Scrum – Événements
Le Sprint

• Un sprint doit être annulé si l'objectif de sprint devient obsolète.

• Cela peut se produire si l'organisation change de direction ou si les conditions du marché ou de

la technologie changent. Un sprint ne peut être annulé que par le produit Owner, bien que
d'autres aient une influence sur le même.

• En raison de la nature de courte durée des sprints, l'annulation pendant un sprint a rarement
du sens. Comme les annulations de sprint consomment des ressources, pour se réorganiser
dans un autre Sprint, elles sont très rares.

• Si un Sprint est annulé et qu'une partie du travail produit pendant le sprint est potentiellement
libérable, le Product Owner l'accepte généralement.

• Tous les éléments incomplets du Backlog Sprint sont replacés dans le Backlog Produit.
 Scrum – Événements
Planification de Sprint

• Le travail à effectuer dans le sprint est planifié lors de la réunion de planification du sprint.

• La réunion de planification de sprint dure au maximum quatre heures pour les sprints de deux
semaines et huit heures pour les sprints d'un mois.

• Il est de la responsabilité du Scrum Master de s'assurer que la réunion a lieu et que tous les
participants requis sont présents et comprennent le but de la réunion programmée.

• Le Scrum Master anime la réunion pour surveiller le maintien de la discussion et la clôture à

temps.
 Scrum – Événements
Planification de Sprint

La planification de sprint se concentre sur les deux questions suivantes –

• Qu'est-ce qui doit et peut être livré dans l'incrément de sprint?

• Comment le travail nécessaire à l'exécution du Sprint sera-t-il réalisé?

Les contributions à cette réunion sont –

• Le backlog produit
• Le dernier incrément de produit
• Capacité projetée de l'équipe pendant le sprint
• Performances passées de l'équipe
 Scrum – Événements
Planification de Sprint

• L'équipe Scrum discute des fonctionnalités qui peuvent être développées pendant le Sprint.

• Le Product Owner fournit des clarifications sur les éléments du Product Backlog.

• L'équipe sélectionne les éléments du Product Backlog pour le Sprint, car ils sont les meilleurs
pour évaluer ce qu'ils peuvent accomplir dans le Sprint.

• L'équipe comprend des analystes, des concepteurs, des développeurs et des testeurs.

• Le travail est effectué de manière collaborative, minimisant ainsi les retouches.

 Scrum – Événements
Planification de Sprint

• L'équipe Scrum propose ensuite un objectif de sprint.

• Le Sprint Goal est un objectif qui fournit des conseils à l'équipe sur les raisons pour lesquelles
elle construit l'incrément de produit.

• L'équipe décide ensuite de la manière dont elle intégrera la fonctionnalité sélectionnée dans
un incrément de produit fonctionnel pendant le sprint.

• Les éléments du Backlog produit sélectionnés pour ce Sprint ainsi que le plan pour les livrer
sont appelés le Sprint Backlog.
 Scrum – Événements
Planification de Sprint
• Le travail pendant un sprint est estimé lors de la planification du sprint et peut être de taille et
/ ou d'effort variables.

• À la fin de la réunion de planification de sprint, le travail est divisé en tâches d'une durée d'un
jour ou moins.

• Cela permet de faciliter la répartition du travail et le suivi de l'achèvement.

• Si l'équipe se rend compte qu'elle a trop ou pas assez de travail, elle peut renégocier les
éléments du Backlog produit sélectionnés avec le Product Owner.

• L'équipe peut également inviter d'autres personnes (ne faisant pas partie de l'équipe Scrum) à
assister à la réunion de planification de sprint pour obtenir des conseils techniques ou de
domaine ou une aide à l'estimation.
 Scrum – Événements
Daily Scrum Meeting
• La Daily Scrum Meeting est une réunion de 15 minutes pour l'équipe, menée quotidiennement
pour comprendre rapidement le travail depuis la dernière Daily Scrum Meeting et créer un plan
pour les prochaines 24 heures. Cette réunion est également appelée Daily Stand up Meeting.

• Le Daily Scrum Meeting se tient à la même heure et au même endroit chaque jour pour réduire la
complexité.

Au cours de la réunion, chaque membre de l'équipe explique –

• Qu'a-t-il fait hier pour aider l'équipe à atteindre l'objectif de sprint?

• Que fera-t-il aujourd'hui pour aider l'équipe à atteindre l'objectif de sprint?
• Y a-t-il des obstacles qui l'empêchent, lui ou l'équipe, d'atteindre l'objectif de sprint?

Daily Scrum est considéré à tort comme un événement de suivi de statut, bien qu'en fait, il s'agisse
d'un événement de planification.
 Scrum – Événements
Daily Scrum Meeting

• La contribution à la réunion doit être la façon dont l'équipe fait pour atteindre l'objectif de
sprint, et le résultat doit être un plan nouveau ou révisé qui optimise les efforts de l'équipe
pour atteindre l'objectif de sprint.

• Bien que le Scrum Master coordonne la réunion Scrum quotidienne et s'assure que les objectifs
de la réunion sont atteints, la réunion est sous la responsabilité de l'équipe.

• Si nécessaire, l'équipe peut se réunir immédiatement après la réunion de réunion quotidienne,

pour des discussions détaillées ou pour planifier à nouveau le reste du travail du sprint.
 Scrum – Événements
Daily Scrum Meeting
Voici les avantages des réunions Scrum quotidiennes –

• Améliorez la communication au sein de l'équipe.

• Identifiez les obstacles, le cas échéant, afin de faciliter une élimination précoce de ceux-ci, afin
de minimiser l'impact sur le Sprint.

• Mettez en évidence et favorisez une prise de décision rapide.

• Améliorez le niveau de connaissance de l'équipe.

 Scrum – Événements
Revue de Sprint
• Une revue de sprint a lieu à la fin de chaque sprint.

• Au cours de la revue de sprint, une présentation de l'incrément qui est en train d'être publiée est
revue.

• Lors de cette réunion, l'équipe Scrum et les parties prenantes collaborent pour comprendre ce qui
a été fait dans le Sprint.

• Sur la base de cela et de toute modification apportée au Backlog produit pendant le Sprint, les
participants arrivent aux prochaines étapes requises qui pourraient optimiser la valeur. Ainsi,
l'objectif de Sprint Review est d'obtenir des retours et des progrès à la fois.

• Le Sprint Review se déroule normalement pendant deux heures pour les sprints de deux semaines
et pendant quatre heures pour les sprints d'un mois.
 Scrum – Événements
Revue de Sprint

Le Scrum Master s'assure que –

• La réunion a lieu.

• Les participants comprennent le but.

• La réunion se concentre sur l'ordre du jour requis et se termine dans la durée requise.
 Scrum – Événements
Revue de Sprint

La revue de sprint comprend les aspects suivants –

• Les participants incluent l'équipe Scrum et les principales parties prenantes, invitées par le
Product Owner.

• Le Product Owner explique quels éléments du Product Backlog ont été terminés pendant le sprint
et ce qui ne l'a pas été.

• L'équipe discute de ce qui s'est bien passé pendant le Sprint, des problèmes rencontrés et de la
manière dont ces problèmes ont été résolus.
 Scrum – Événements
Revue de Sprint

• L'équipe démontre le travail qu'elle a accompli et répond aux questions, le cas échéant, sur
l'incrément.

• L'ensemble du groupe discute ensuite de ce qu'il faut faire ensuite. Ainsi, la revue de sprint
fournit une contribution précieuse à la planification de sprint du sprint suivant.

• L'équipe Scrum examine ensuite le calendrier, le budget, les capacités potentielles et le marché
pour la prochaine version prévue de l'incrément de produit.

• Le résultat du Sprint Review est un Product Backlog mis à jour, qui définit les éléments probables
du Product Backlog pour le prochain Sprint.
 Scrum – Événements
Rétrospective de Sprint
▪ La rétrospective de sprint a lieu après la revue de sprint et avant la prochaine planification de
sprint. Il s'agit généralement d'une réunion d'une heure pour des sprints d'une durée de deux
semaines et d'une réunion de trois heures pour des sprints d'une durée d'un mois.

Le but de la rétrospective de Sprint est de –

• Combinez les apprentissages du dernier Sprint en ce qui concerne les personnes, les relations,
les processus et les outils.

• Identifiez les principaux éléments qui se sont bien déroulés et les améliorations potentielles.

• Création d'un plan de mise en œuvre d'améliorations pour augmenter la qualité des produits.

La rétrospective Sprint est une opportunité pour l'équipe Scrum d'introspecter et de s'améliorer
dans le cadre du processus Scrum afin de rendre le prochain résultat du Sprint plus efficace.
 Scrum – Artefacts

Les artefacts Scrum fournissent des informations clés dont l'équipe Scrum et les parties prenantes
doivent être conscientes pour comprendre le produit en cours de développement, les activités
réalisées et les activités prévues dans le projet.

Les artefacts suivants sont définis dans Scrum Process Framework –

• Backlog produit
• Backlog de sprint
• Graphique Burn-Down Sprint
• Increment

Ce sont les artefacts minimum requis dans un projet Scrum et les artefacts de projet ne sont pas
limités par ceux-ci.
 Scrum – Artefacts
Backlog produit
• Le Backlog du produit est une liste ordonnée des fonctionnalités nécessaires dans le cadre du
produit final et constitue la source unique d'exigences pour toute modification à apporter au
produit.

• Le Backlog produit répertorie toutes les fonctionnalités, fonctions, exigences, améliorations et

correctifs qui constituent les modifications à apporter au produit dans les versions futures.

• Les éléments du Backlog de produit ont les attributs d'une description, d'une commande,
d'une estimation et d'une valeur.

• Ces éléments sont généralement appelés User Stories.

• Le Product Owner est responsable du Product Backlog, y compris son contenu, sa disponibilité
et sa commande.
 Scrum – Artefacts
Backlog produit

• Un backlog de produit est un artefact évolutif.

• La version la plus ancienne de celui-ci peut contenir uniquement les exigences initialement
connues et les mieux comprises.

• Le Product Backlog est développé au fur et à mesure que le produit et l'environnement dans
lequel il sera utilisé progressent.

• Le Backlog produit change constamment pour intégrer ce qui est nécessaire pour le rendre
efficace.

• Tant qu'un produit existe, son Backlog produit existe également.

 Scrum – Artefacts
Backlog produit

• Au fur et à mesure que le produit en cours de construction est utilisé et gagne en valeur, le
Backlog Produit devient une liste plus large et plus exhaustive.

• Les changements dans les exigences de l'entreprise, les conditions du marché ou la technologie
entraînent des changements dans le Backlog Produit, ce qui en fait un artefact en direct.

• Le raffinement du Backlog de produit signifie l'ajout de détails, d'estimations et d'un ordre de

priorité aux éléments du Backlog de produit. Il s'agit d'un processus continu exécuté par le
Product Owner et l'équipe. L'équipe Scrum décide comment et quand le raffinement doit être
effectué.

• Les éléments du Backlog de Produit peuvent être mis à jour à tout moment par le Product
Owner ou à la discrétion du Product Owner.
 Scrum – Artefacts
Backlog produit

• Les articles du Backlog de produit les plus élevés sont généralement plus clairs et plus détaillés
que les articles de commande inférieure.
• Des estimations plus précises sont faites en fonction de la plus grande clarté et de plus de
détails. Plus l'ordre est bas, moins le détail est important.

• Les éléments du backlog de produit susceptibles d'être les conditions requises pour le prochain
Sprint sont affinés afin que ces éléments puissent être développés pendant le Sprint.

• Les éléments du Backlog de Produit qui peuvent être développés par l'équipe au cours d'un
Sprint sont considérés comme prêts pour la sélection lors d'une réunion de planification de
Sprint.
 Scrum – Artefacts
Backlog de sprint

• Le Sprint Backlog est l'ensemble des éléments du Product Backlog sélectionnés pour le Sprint,
plus un plan pour livrer l'incrément de produit et réaliser l'objectif du Sprint.

• Le Sprint Backlog est une prévision de l'équipe sur les fonctionnalités qui seront mises à
disposition dans le prochain incrément et le travail nécessaire pour fournir cette fonctionnalité en
tant qu'incrément de produit fonctionnel.
 Scrum – Artefacts
Backlog de sprint

• Le Sprint Backlog est un plan avec suffisamment de détails qui peuvent être compris mais
l'équipe doit suivre dans le Daily Scrum.

• L'équipe modifie le Sprint Backlog tout au long du Sprint, et le Sprint Backlog émerge pendant le
Sprint.

• Cette émergence se produit lorsque l'équipe travaille sur le plan et en apprend davantage sur le
travail nécessaire pour atteindre l'objectif de sprint.
 Scrum – Artefacts
Backlog de sprint

• Comme un nouveau travail est requis, l'équipe l'ajoute au Backlog Sprint.

• Au fur et à mesure que le travail est exécuté ou terminé, le travail restant estimé est mis à jour.

• Lorsque des éléments du plan sont jugés inutiles, ils sont supprimés.

• Seule l'équipe peut modifier son backlog de sprint pendant un sprint.

• Le Sprint Backlog est une image en temps réel très visible du travail que l'équipe prévoit
d'accomplir pendant le sprint, et il appartient uniquement à l'équipe.
 Scrum – Artefacts
Incrément

• L'Incrément est la somme de tous les éléments du Backlog Produit complétés au cours d'un Sprint
combiné avec les incréments de tous les Sprints précédents.

• À la fin d'un sprint, le nouvel incrément doit être un produit fonctionnel, ce qui signifie qu'il doit
être dans un état utilisable.

• Il doit être en état de fonctionnement, que le Product Owner décide ou non de le libérer.

• L'équipe Scrum doit avoir un consensus sur ce qui est considéré comme un incrément.

• Cela varie considérablement d'une équipe Scrum, mais les membres de l'équipe doivent avoir une
compréhension commune de ce que cela signifie pour que le travail soit terminé.

• Ceci est utilisé pour évaluer la fin du travail sur l'incrément de produit.
 Scrum – Artefacts
Incrément

• La même compréhension guide l'équipe dans la connaissance du nombre d'éléments de backlog

produit qu'elle peut sélectionner au cours d'une planification de sprint.

• Le but de chaque Sprint est de fournir des incréments de fonctionnalités potentiellement

libérables..

• Les équipes fournissent un incrément de fonctionnalité du produit à chaque sprint.

• Cet incrément est utilisable, donc un Product Owner peut choisir de le libérer immédiatement.

• Si la compréhension d'un incrément fait partie des conventions, normes ou directives de

l'organisation de développement, toutes les équipes Scrum doivent la suivre au minimum.

• S'il ne s'agit pas d'une convention de l'organisation de développement, l'équipe Scrum doit définir
une définition d'Incrément adaptée au produit.
 Scrum – Artefacts
Incrément

• Chaque incrément s'ajoute à tous les incréments précédents et est minutieusement testé,
garantissant que tous les incréments fonctionnent ensemble.

• Au fur et à mesure que les équipes Scrum mûrissent, on s'attend à ce que leurs définitions des
incréments s'étendent pour inclure des critères plus stricts pour une meilleure qualité.

• Tout produit doit avoir une définition d'incrément qui est une norme pour tout travail effectué
dessus.
 Scrum – Artefacts
Graphique Burn-Down Sprint

• À tout moment dans un Sprint, le travail total restant dans le Sprint Backlog peut être additionné.

• L'équipe suit ce travail total restant pour chaque Daily Scrum pour projeter la probabilité
d'atteindre l'objectif de Sprint.

• En suivant le travail restant tout au long du Sprint, l'équipe peut gérer sa progression.

• Sprint Burn-Down Chart est une pratique pour suivre l'évolution du travail effectué par l'équipe
Scrum. Cela s'est avéré être une technique utile pour suivre la progression du Sprint vers l'objectif
du Sprint.
 Scrum – Artefacts
Graphique Burn-Down Sprint

• Le Product Owner suit ce travail total restant au moins à chaque examen de sprint.

• Le Product Owner compare ce montant avec le travail restant lors des précédentes Revues de
Sprint pour évaluer les progrès accomplis vers l'achèvement du travail projeté au moment souhaité
pour l'objectif.

• Cette information est partagée avec toutes les parties prenantes.

 Scrum – Artefacts
Conclusion

• Les rôles, événements, artefacts et règles de Scrum sont inévitables. Si seules certaines parties de
Scrum sont implémentées, le résultat n'est pas Scrum.

• Scrum doit être mis en œuvre dans son intégralité et fonctionne bien s'il est aligné sur d'autres
techniques, méthodologies et pratiques.
 Scrum – User Stories

Comme vous l'avez compris, les User Stories sont couramment utilisées pour décrire les
fonctionnalités du produit et feront partie des Artefacts Scrum - Product Backlog et Sprint
Backlog.
 Scrum – User Stories
User Stories

• Dans le développement de logiciels, les fonctionnalités du produit jouent un rôle crucial.

• Ce sont les fonctionnalités que l'utilisateur aime finalement utiliser dans le produit final.

• Ils sont connus sous le nom d'exigences dans la terminologie générale.

• Le succès du projet de développement logiciel réside dans la compréhension précise et

appropriée des besoins des utilisateurs, puis dans leur mise en œuvre dans le produit final.

• Ainsi, les exigences ou les caractéristiques du produit doivent être parfaitement connues de
l'équipe du projet de développement.
 Scrum – User Stories
User Stories
• En 1999, Kent Beck a proposé un terme User Stories pour les caractéristiques du produit.

• Il a décrit qu'une User Story est racontée du point de vue de l'utilisateur concernant ce qu'il ou elle
veut avoir plutôt que ce que le système peut faire pour lui.

• Ainsi, la vue a complètement changé du produit à l'utilisateur et les User Stories sont devenues la
norme de facto pour les exigences dans tous les frameworks Agile.

• Dans les projets Scrum, le Product Backlog est une liste de user stories.

• Ces User Stories sont hiérarchisées et intégrées dans le Sprint Backlog lors de la réunion de
planification de Sprint.

• L'estimation est également basée sur les user stories et la taille du produit est estimée en User
Story Points.
 Scrum – User Stories
La structure du User Story

• La structure de la User Story est la suivante –

➢ En tant que <Type d'utilisateur> ,

➢ Je veux <Effectuer une tâche> ,

➢ Pour que <je puisse atteindre un objectif / un avantage / une valeur> .

Voyons comment une user story est conçue pour le scénario d'un client de banque retirant de
l'argent à un guichet automatique.
 Scrum – User Stories
La structure du User Story

• User Story: Retrait d'espèces du client

• Comme un Customer,

• je veux withdraw cash from an ATM,

• Pour que I don't have to wait in line at the Bank

 Scrum – User Stories
La structure du User Story
• Critères d'acceptation des user stories
Chaque user story a également un critère d'acceptation défini, de sorte que l'exactitude de la mise en
œuvre de la user story soit confirmée en passant le test d'acceptation basé sur le critère
d'acceptation.

Voici l'exemple de critère d'acceptation pour l'exemple du retrait d'espèces du client User Story.

Acceptance Criterion 1:
Given que le compte est solvable
• Et la carte est valide
• Et le distributeur contient de l'argent,
When le client demande l'argent
Then s'assurer que le compte est débité
• Et assurez-vous que l'argent est distribué
• Et assurez-vous que la carte est retournée.
 Scrum – User Stories
La structure du User Story

Acceptance Criterion 2:

Given que le compte est à découvert

• Et la carte est valide

When le client demande l'argent

Then assurez-vous que le message de rejet est affiché

• Et assurez-vous que l'argent n'est pas distribué

• Et assurez-vous que la carte est retournée.
 Scrum – User Stories
Écrire User Stories

• Le Product Owner est responsable du Product Backlog et donc des User Stories.

• Cependant, cela ne signifie pas que seul le Product Owner écrit les user stories.

• N'importe qui dans l'équipe Scrum peut écrire les user stories, et l'activité peut être répartie
dans le projet à mesure que les exigences s'affinent et que de nouvelles fonctionnalités sont
ajoutées.
 Scrum – User Stories
Exigences non fonctionnelles dans User
Stories

• Il est possible d'incorporer les exigences non fonctionnelles également dans les user stories.

• Dans l'exemple ATM donné, l'ATM qui doit être disponible pour l'utilisateur 24X7, 365 jours est
une exigence non fonctionnelle, qui peut être décrite par un cas d'utilisation.
 Scrum – User Stories
Gérer User Stories
• Les User Stories sont gérées dans le Product Backlog.

• Les User Stories sont classées par priorité.

• Les user stories les plus prioritaires sont affinées au niveau granulaire, tandis que les user stories
les moins prioritaires sont conservées à un niveau de détail moindre.

• Pour chaque sprint, les user stories les plus prioritaires et donc les plus granulées sont intégrées
dans le backlog de sprint.

• Si une user story doit être ajoutée au backlog du produit, sa priorité est d'abord déterminée, et
elle est placée en fonction de sa place selon la priorité.

• Les user stories peuvent être redéfinies à tout moment. Il est également possible de supprimer
n'importe laquelle des user stories si nécessaire.
 Scrum – User Stories
Avantages avec User Stories

• Le principal avantage de User Story réside dans la définition centrée sur l'utilisateur elle-même.
En effet, en fin de compte, c'est l'utilisateur qui utilisera le produit dans les scénarios utilisateur
pertinents. Il connecte les utilisateurs finaux aux membres de l'équipe.

• La syntaxe de la User Story elle-même garantit la capture de l'objectif, du bénéfice ou de la

valeur que l'utilisateur souhaite atteindre.

• Étant donné que les critères d'acceptation font partie de la user story elle-même, ce sera un
avantage supplémentaire pour l'équipe Scrum.
 Scrum – User Stories
Avantages avec User Stories

• Il est possible d'apporter des modifications à une user story au cours de l'exécution du projet.
• Si la portée de la user story devient grande, elle doit être divisée en user stories plus petites.
• Les conditions du critère d'acceptation peuvent également être modifiées.

•Au fur et à mesure que les incréments de produits fonctionnels sont fournis aux utilisateurs à la
fin de chaque sprint, l'équipe Scrum peut obtenir des commentaires des utilisateurs lors de la
réunion de révision du sprint.
•Cela permet l'incorporation de rétroaction dans le produit en continu.
 Scrum – User Stories
Conclusion

• Les User Stories de Scrum rapprochent les utilisateurs de l'équipe Scrum et évitent les surprises
de dernière minute.