Juin 2023

Présentation Générale Le Concept AGILE

Le Concept SCRUM Les Rôles SCRUM

Les Processus SCRUM Les Artefacts SCRUM

2
Le mot « agile » est un adjectif qui signifie : se déplacer rapidement et
facilement, ou penser rapidement et de manière intelligente (dictionnaire
Oxford Advanced Learner).

Cependant, « Agile » (avec un « A » majuscule) est utilisé pour désigner un

ensemble de cadres utilisés pour le développement et la gestion d'initiatives.

L'objectif principal des frameworks Agile est de rendre le développement

plus rapide et plus fluide, et de créer un résultat plus satisfaisant pour le
client.

Presque tout le monde dans le secteur informatique a entendu parler d'Agile

et est prêt à l'essayer ; si oui ou non eux et leurs clients sont prêts pour un tel
changement.

Il y a même des clients qui s'attendent à ce que vous soyez Agile, alors qu'ils
n'acceptent pas certaines de ses conséquences (par exemple, le manque de
documentation initiale)
4
 Planification
•
•
Analyse des Livrables
Collecte des Informations
Clôture
• Planification Technique & Fonctionnelle Clôture • Evaluation
• Calendrier des activités • Cloture des contrats
• Plan du Projet • Rapport Final
• Kick-off Technique • Réunion de cloture
Initiation

4 Mois
1
2 3
8
Initiation Exécution
• Préparation de l’environnement
• Approbations & Signature des Contrats • Phase 1,2 & 3: Service Operations, Transition & Design
• Engagement des parties prenantes • Déploiement, Configurations & Intégration
• Cahier de Charges • Test Utilisateurs et Performance
• Acquisition des Licences • Transition & Go Live
• Hypothèse et Stratégie • Phase 4: Service Strategy, CSI & Reporting
• Charte du Projet • Déploiement, Configurations & Intégration
• Kick-Off • Test Utilisateurs et Performance
• Transition & Go Live
• Organisation & Gouvernance 5
• Conduite au Changement
6
Il existe plusieurs méthodes utilisant une approche
adaptive plutôt que prédictive:

➢ Scrum
➢ Extreme Programming
➢ Rapid Application Development
➢ Adaptive Software Development
➢ Crystal Clear
➢ Dynamic Software Development Method
➢ Feature Driven Development

7
 L’Equipe L’Application
Personnes et interactions plutôt Logiciels fonctionnels plutôt
que processus et outiils 01 que documentation complète

04 AGILE Manifesto 02

Acceptation du Changement 03 La Collaboration

Réagir au changement plutôt que Collaboration avec le client plutôt
suivre un plan que négociation de contrat

8
 Changement Collaboration Communication
bienvenu quotidienne Face à Face
Livraisons Motivations &
Satisfaction Client fréquentes encouragements

Logiciel comme Ajustements

benchmark Simplicité
Rythme continus Attention continue
soutenable Auto-organisation à la technique et à
la conception
9
Nous définissons généralement le périmètre dans un document ou un concept simple ou structuré.
Ce concept est généralement appelé Product Backlog dans les projets Agile. Un backlog de produit
contient un certain nombre d’ "éléments", et chaque élément décrit un élément constitutif de la
solution finale.

Nous avons trois alternatives pour définir les items du Product Backlog :

1. Spécification des exigences - c'est la manière la plus traditionnelle de définir le périmètre. Il est
formé de termes techniques clairs pour l'équipe de développement et généralement basés sur
des relations architecturales entre les éléments.

2. Cas d'utilisation (Use Case) - il est basé sur la compréhension et les besoins de l'utilisateur
plutôt que sur une description technique, et décrit un scénario détaillé avec toutes les actions
qu'un utilisateur imaginaire fera et les comportements attendus de la solution.

3. User story - similaire à un cas d'utilisation, mais ne contient pas tous les détails du
comportement de l'utilisateur et se concentre uniquement sur les besoins et le but de
l'utilisateur.
10
La définition technique d'une fonctionnalité n'est pas utile, nous préférons donc utiliser la manière
non technique de définir la portée, c'est-à-dire les cas d'utilisation et les user stories.

Entre ces deux, les user stories sont privilégiées, car plus faciles à comprendre. La user story
comporte trois parties : En tant que …, je veux …, [pour que …]

1. « En tant que… », définit le rôle qui va interagir dans l'histoire ; par exemple. utilisateur final,
administrateur ou gestionnaire.

2. « Je veux… », définit l'attente du rôle ; par exemple. rechercher des appartements, calculer la
taxe, accorder l'autorisation à quelqu'un et s'inscrire sur le site. Attention, il ne s'agit que
d'actions et une phrase comme « en tant qu'administrateur, je veux que mon système utilise SQL
Server » n'est pas une user story ! Une user story consiste à faire quelque chose, plutôt qu'à
avoir quelque chose.

3. "pour que...", cette partie facultative de la user story explique la raison de cette action et aide à
l'interprétation de la story. La raison de certaines histoires est si évidente que vous n'aurez
peut-être pas besoin de la mentionner
11
Il existe deux règles essentielles concernant les items du Product Backlog :

1. Ils doivent être non techniques. En effet, le Product Backlog est notre outil de communication
avec le client non technique. Normalement, un enfant de dix ans devrait être capable de
comprendre chaque user story.

2. Ils doivent être indépendants les uns des autres, afin que nous puissions les développer
librement dans n'importe quel ordre.

Nous écrivons généralement les éléments du Product Backlog sur des fiches ou des notes
autocollantes et les plaçons sur un tableau physique.

Cette approche est préférable à l'utilisation d'une application, sauf si vous avez des équipes
distribuées.

12
SCRUM tient son origine du terme sportif de rugby signifiant :
mêlée.

Tout comme cet aspect technique de la partie du jeu, la

méthodologie demande à ses acteurs d'être soudés dans
l'accomplissement d'un projet, dans l'atteinte d'un but.

Mais tout comme au rugby, une mêlée n'est pas un processus

unique. C'est une partie du jeu que l'on retrouve
fréquemment pour faire avancer l'équipe.

Les racines de SCRUM se retrouvent dans la publication de

Takeuchi et Nonaka dans « The New Product Development
Game ». Jeff Sutherland, Ken Schwaber & Mike Beedle
officialisent le concept entre les années 1995 et 2001.

14
SCRUM est un processus agile qui permet de produire la plus grande
valeur métier dans la durée la plus courte.

SCRUM veux avant tout produire un logiciel fonctionnel et mettre en

avant la rentabilité et surtout la satisfaction client. Ce dernier doit
pouvoir donc juger sur le tas de l'avancement de son produit.

Dans la méthodologie SCRUM, le métier définit les priorités. L'équipe

de développement s'organise elle-même pour déterminer la
meilleure façon de produire les exigences les plus prioritaires (on
parle de « bottom up »)

Finalement, à chaque fin de sprint, tout le monde a un pouvoir de

décision. L'équipe devra décider de livrer le produit en l'état, ou de
continuer à améliorer le produit sur une itération supplémentaire.

15
Comme le montre le graphique ci-dessus, SCRUM s'impose comme un
modèle d'efficacité, pronant l'expression : "aller à l'essentiel"
16
Pour mettre en place correctement une méthodologie SCRUM efficace, il faut :

➢ Equipe responsable, en auto-organisation : l'équipe de développement se doit d'être autonome

pour palier aux éventuels changements d'un client trop indécis.

➢ Avancement du produit par une série de « sprints » : les itérations sont courtes, 2 à 4 semaines
au plus, pour permettre des interventions rapides en cas de problèmes.

➢ Exigences définies : en fait d'exigences, on parlera surtout d'éléments à mettre en oeuvre. Ces
éléments sont regroupés sous l'appelation de "Backlog du produit".

➢ Pas de prescription de pratiques d’ingénierie : on reste dans un esprit d'autonomie de

développement.

➢ Utilisation de règles génériques : on permet l'établissement d'un environnement agile propre au

projet.

17
Product Owner Client

Scrum Master Manager

Equipe SCRUM Utilisateur

19
Le Directeur de produit (Product Owner), représente à la fois les clients et les utilisateurs. Mais le
terme de directeur est ici à prendre au sens de guide plus que de chef hiérarchique. En effet, ses
responsabilités se bornent à l'établissement des limites du projets et de chaque itératon.

L'avantage du Directeur de Produit est sa relation avec le client. Il peut néanmoins et pour des
raisons évidentes de productivité travailler dans le même espace que l'équipe de développement.
Celui-ci sachant de façon précise les attentes du client, il peut répondre directement interrogations
des collaborateurs.

Finalement, le Directeur de Produit définit les fonctionnalités du produit. Voici une liste de ses
responsabilités :

➢ Choisit la date et le contenu de la release

➢ Responsable du retour sur investissement
➢ Définit les priorités dans le backlog en fonction de la valeur « métier »
➢ Ajuste les fonctionnalités et les priorités à chaque sprint si nécessaire

20
Le SCRUM Master représente le management du projet. On l'assigne bien souvent au rôle de
manager de projet ou de Chef d'équipe. Son travail principal consiste remédier aux imprévus. C'est
celui qui interviens dans le cas ou une situation ou un événement peut empêcher ou retarder la
progression du travail prévu au cours du sprint.

Voici quelques unes de ces caractéristiques :

➢ Responsable de faire appliquer par l’équipe les valeurs et les pratiques de Scrum
➢ Résout des 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
➢ Protège l'équipe des interférences extérieures

21
Une bonne équipe SCRUM est assez réduite et comporte finalement 5 à 10 personnes. L'échange est
un atout primordial dans l'utilisation de SCRUM, il faut donc garder l'aspect dialogue au sein de son
équipe de développement. Une équipe trop grande amène souvent plus de dissension que
d'approbation.

Les caractéristiques d'une bonne équipe :

➢ Regroupant tous les rôles : Architecte, concepteur, développeur, spécialiste IHM, testeur, etc.
➢ A plein temps sur le projet, de préférence
➢ Exceptions possibles (administrateur, …)
➢ Organisation autonome

La composition de l’équipe ne doit pas changer pendant un Sprint.

22
Les fonctions du client sont les suivantes:

➢ Il demande le produit et contracte l’organisation pour le développement du produit

➢ Il s’agit d’un responsable qui achète un développement de produit par un sous-traitant
➢ Dans les projets internes, il s’agit principalement du sponsor au projet, c’est-à-dire la personne
validant le projet et le budget

Les missions du client sont les suivantes:

➢ Il commande le produit
➢ Il paye pour le développement du produit
➢ Il donne des feed-back et des révisions

23
Les fonctions du Manager sont les suivantes:

➢ Il permet à l’Equipe de constituer un environnement optimal pour le déroulement du projet

SCRUM
➢ Il donne de la structure et de la stabilité
➢ Il travaille de concert avec le SCRUM Master pour réorganiser l’organigramme de la structure et
donner des directives si nécessaire.

Les missions du Manager sont les suivantes:

➢ Il s’assure que l’organization puisse survivre en cas de défaillance

➢ Il crée des règles et des lignes directrices

24
Les fonctions de l’utilisateur final sont les suivantes:

➢ Il connaît les besoins et définit le produit à travers l’élaboration des fonctionnalités

➢ Ce rôle peut être joué par un grand nombre de personnes

Les missions de l’utilisateur final sont les suivantes:

➢ Il connaît ses besoin set ses exigences

➢ Il donne son feed-back lors des revues
➢ Il participle au Sprint Planning

25
26
Ce processus du processus de gestion du projet En première partie :
vise à organiser les exigences d’affaires, établir le
coût et le calendrier précis du projet (y compris 1. 4h avant de manger
une liste des livrables et leurs dates de livraison), 2. On effectue la création du Backlog produit
planifier l’organisation du travail et obtenir 3. On détermine les enjeux du Sprint
l’autorisation des gestionnaires. 4. Participants : Product Owner, SCRUM Master,
l'équipe
En SCRUM la planification se fait par niveau,
chaque niveau correspondant à un Sprint. Une Deuxième partie:
réunion de collabrateur s'effectue généralement
sur 8h et en deux temps. 4h après manger :)
Participants: Scrum Master, l'équipe

En SCRUM l'équipe choisit, à partir du backlog de produit, les éléments qu'elle

s'engage à finir.Une fois le backlog de sprint est créé, les tâches sont identifiées
et estimées (1-16 heures). Finalement on peut alors lancer le Sprint.
28
Le SCRUM meeting est une réunion organisée de la façon suivante :

• Tous les jours

• 5 minutes
• Debout

Le SCRUM meeting n'est pas fait pour ésoudre mais plutot pour identifier les problèmes. Finalement
Tout le monde peut participer au meeting, mais seuls les membres de l'équipe peuvent parlés.
Le SCRUM meeting est effectué pour répondre à 3 questions essentielles :

1. qu’est ce que j’ai fais hier?

2. qu’est ce que je fais aujourd’hui?
3. quels sont les problèmes?

Toute l'quipe interviens et le tour de parole doit être scrupuleusement respecté pour éviter que le
SCRUM dérive sur des discussions techniques et déborde des 15 minutes. Si le besoin s'en fait sentir,
des discussions sont alors menées librement après le SCRUM.

29
A la fin du sprint, tout le monde se réunit pour effectuer la Revue de sprint, qui dure au maximum 4
heures. L'objectif de la revue de sprint est de valider le logiciel qui a été produit pendant le sprint.

L'équipe présente ce qu'elle a fait pendant le sprint. Habituellement la revue de Sprint se fait avec
une démonstration des nouvelles fonctionnalités ou de l'architecture ( des livrables)

La Revue de Sprint est une rpésentation informelle. Ici il ne s'agit pas de présenter un PowerPoint ou
tout autre diapositives, l'idée est ici simplement de montré ce qui a été réalisé et qui donc
fonctionne.

La préparation est simple et nécessite généralement moins de 2 heures. Tout le monde peut
participer à cette présentation.

30
Cette étape est une démarche courante en fin de projet.

En SCRUM elle s'effectue à chaque fin de Sprint. L'idée ici est de réfléchir régulièrement à ce qui
marche et ce qui ne marche pas. Pour cela l'équipe prend en général 15 à 30 minutes pour se réunir
et faire un point.

On applique ici un principe de Start / Stop / Continue : ce qu’on aimerait faire, arreter de faire,
continuer a faire.

31
En quelques mots voici ce que constitue un Backlog de Produit :

➢ Une liste de tout ce qui va entraîner du travail au projet

➢ Chaque élément doit apporter de la valeur aux utilisateurs ou clients du produit
➢ Les priorités sont définies par le directeur produit
➢ Les priorités sont revues à chaque sprint

Exemple de Backlog Produit :

33
Le Backlog de Sprint est un engagement. Chaque développeur s'engage sur un temps de travail pour
chaque tâches établies. Suite à cela on évalue quotidiennement grâce aux SCRUM meeting les
différences de prévision. Voici les principales caractérisitques du Baclog de produit :

➢ L'estimation du reste à faire est ajustée tous les jours

➢ Le backlog est adaptable
➢ Le travail du sprint émerge progressivement
➢ Si un travail n'est pas clair, il faut définir une tâche avec plus de temps et la décomposer après
➢ MAJ du travail restant quand il devient connu

Il est interressant de noter que le travail en SCRUM n'est jamais assigné par un autre. N'importe qui
peut ajouter, supprimer ou modifier le Backlog de Sprint tant que l'assignation se fait
personnellement

34
Le Brundown Chart est un indicateur temporelle de l'évolution des tâches en cours dans le Sprint.
Nous disions précédement que le travail de l'équipe était adaptable et attribué de façon personnelle à
chaque membre.

Mais l'objectif restant de pouvoir, à chaque instant, visualiser l'état du projet, SCRUM met en place ce
que l'on nomme le SCRUM Board et qui réflechit sous forme de post-it sur un tableau :

➢ Les tâches à faire

➢ Les tâches en cours
➢ les tâches terminées

Suite à une utilisation adéquate de ce tableau, l'on est a même de remplir quotidiennement un
graphique qui représente finalement l'évolution du planning du Sprint, où l'on peut identifier
rapidement quelles ont été les tâches qui posent ou ont posé des problèmes.

35
36
Merci