1.
Méthodes AGILE pour la gestion
des projets : SCRUM
Mai 2017
Digital - Architecture - Agility
1

2.
Bienvenue
Présentations
Organisation
Détails Pratiques
2

3.
Qui je suis?
Mohamed IBN EL AZZOUZI
R&D sur des produits opensource (Bonita/Novaforge) (2008)
Fondateur de International Business Sources (2011)
Startup Team Social workspace (2012)
Consultant Java/JEE - Architecture - Agilité (2013-2017)
Contacts : mie@ibsc-world.com
3

4.
Et vous?
4

5.
Organisation
Déroulement des cours :
n’hésitez pas à interrompre et intervenir
si un chapitre ne vous intéresse pas on peut le sauter
Planning
8h30 → 12h avec une pause au milieu
13h → 15h30
5

6.
Plan du cours
Jour 1 Jour 2 Jour 3 Jour 4
❏ Introduction.
❏ Démarche &
Organisation.
❏ Les Artefacts Scrum
❏ Notion du fini.
❏ TP1 : Découvrir les
outils Confluence et
Jira.
❏ Product
requirements
❏ Planification Scrum
❏ TP2 : Rédiger les
requirements
produit et créer des
user stories.
❏ Déroulement d’un
Sprint
❏ TP3 : Exécuter un
Sprint
❏ Continuer sur TP3
❏ Introduction au
Lean Kanban
❏ Question et
clarifications.
6

7.
Tooling
7

8.
Les ressources de la formation
Cours:
Cette présentation vous sera fourni à la fin de la formation.
Travaux pratiques
Implémenter la méthode Scrum en utilisant les outils Confluence et Jira.
8

9.
Problème : Application hr.com
Nous allons manager le cycle de vie d’une application cloud qui gère le
recrutement au sein d’un grand groupe.
9

10.
Jour 1 : Comprendre
l’agile et le Scrum.
10

11.
Plan
❏Introduction
❏Démarche et organisation
❏Le cadre Scrum
❏TP1
Plan du cours

12.
Méthodes Agile
 Groupes de pratiques et de pilotage de réalisation de projets.
 Agile = Simple et Flexible.
 Un mindset + des règles + des pratiques.
 Mise en place nécessite une conduite de changement.
 Organisme : https://www.agilealliance.org/
12

13.
Agile : Origines et principes
13
 Début des années 90 : volonté d’organiser la relation entre les
Développeurs et les Business.
 En 2001 : réunion entre 17 experts de méthodologie pour émerger
une méthode : naissance de L’agile.
 Rédaction du Manifeste Agile et les 12 Principes.

14.
Agile : Manifeste
14
 Individus et interactions plutôt que processus et outils.
 Fonctionnalités opérationnelles plutôt que documentation
exhaustive.
 Collaboration avec le client plutôt que contractualisation des
relations.
 Acceptation du changement plutôt que conformité aux plans.

15.
Agile : les 12 principes
15
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

16.
Agile : les 12 principes
16
5. Construire des projets autour d’individus motivés
6. Privilégier la conversation en face à face
7. Mesurer l’avancement du projet en termes de fonctionnalités de
l’application
8. Faire avancer le projet à un rythme soutenable et constant

17.
Agile : les 12 principes
17
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

18.
Gestion de projet classique
18
 Cycle en V, en Cascade.
 Expression détaillés du besoin.
 Gestion prédictive du projet.
 Gestion des risque  Contractualisation.

19.
Problèmes
19
Une enquête de 1994 du « Standish Group » :
 31 % des projets informatiques sont arrêtés en cours de route.
 52 % n'aboutissent qu'au prix d'un important dépassement des délais et du
budget tout en offrant moins de fonctionnalités qu'il n'en était demandé.
 seuls 16 % des projets peuvent être considérés comme des succès.

20.
Question
20
PlanBesoin
Besoin’
Livraison

21.
Les raisons d'être de l'agilité
“The ability to create and respond to change in order to succeed in an
uncertain and turbulent environment.” Agile Alliance.
 Supprimer l’éffet de Tunnel
 Livrer un produit et non pas un projet.
 Un produit = Logiciel/Matériel utilisable.
 Time to Market.
21

22.
Scrum
22

23.
Scrum
23
 Scrum n’est pas une méthode.
 Scrum est un cadre avec des règles et des pratiques « a
définir ».

24.
Scrum : un overview
24

25.
Scrum : Démarche
25
 Découper le projets.
 Rédiger les requirements / user stories.
 Automatiser au maximum : code, test, build, ship.

26.
Scrum : Rôles
26
 Product Owner.
 Scrum Master.
 Dev Team.

27.
Scrum : Events
27
 Sprint.
 Sprint planning.
 Daily meeting.
 Sprint Review
 Sprint retrospective

28.
Scrum : Artefacts
28
 Product Backlog.
 Sprint Backlog.
 Burn-down chart.
 Incrément.

29.
Scrum : Requirement model
29

30.
User Story
30
 Formulation d’un besoin sous la forme suivante
En tant que « Acteur » je peut faire « une fonctionnalité » afin de
« atteindre un but / business value »
 Item élémentaire du Backlog.

31.
Correspondance
31
 Business requirement  Epic.
 Use case  User Story.
 Requirements (Functional/Non Functional….) : Test
d’acceptance.

32.
Scrum : Organisation
32
 Equipe : Sénior, 5-8 personnes
 Sprint : 3 semaine max.
 Daily meeting : 1 min par personne.

33.
Principe du Pull
33

34.
Scrum : Notion du fini
34
Gestion : comment peut on qualifier un
développement est fini?

35.
Code fini
35
 Propre
 Refactoré.
 Testé unitairement
 Validé : code review.
 Intégré : Build.

36.
Scrum fini
36
 Code de toute stories sont est fini.
 Le sprint atteint son objectif.
 Tests fonctionnels/Intégration passés
 Install en production.

37.
TP1 : Découverte des
outils
37

38.
Jour 2 : Implémenter le
Scrum.
38

39.
Scrum : Requirement model
39

40.
Les Exigences Produit
40
 Les Exigences Produit : ou exigences de haut niveau. Elle
représentent ce que e système doit faire, décomposées en
fonctionnalités à développer.
 Exemple : Gérer les candidature

41.
Les Cas d'utilisation
41
 Les Cas d'utilisation : les scénarios d'exécutions pour les cas
d'utilisation identifiés dans la description du système à
développer.
 Exemple : Le responsable RH visualiser les candidature,
visualise un candidat…

42.
Les Exigences fonctionnelles
42
 Les Exigences fonctionnelles : déduire les exigences
fonctionnelles globales ou correspondantes à chaque cas
d'utilisation.
 Exemple : l’utilisateur doit pouvoir trier la liste des
candidature par ordre de réception.

43.
Les Exigences non-fonctionnelles
43
 Les Exigences non-fonctionnelles : performance, qualité,
sécurité...
 Exemple : Le temps d’affichage de la liste des candidature ne
doit pas dépasser les 500ms
 L’utilisateur doit etre authentifié pour pouvoir visualiser les
candidature.

44.
Le dictionnaire des données
44
 Le dictionnaire des données : description et types de
données utilisés.

45.
Les interfaces utilisateur
45
 Les interfaces utilisateur : description des écrans, éléments
des interfaces utilisateur.
 Les Règles métiers : algorithme à utiliser, règles de sécurités
imposées, contraintes...

46.
Les Règles métiers
46
 Les Règles métiers : algorithme à utiliser, règles de sécurités
imposées, contraintes...

47.
TP2 : Rédiger les
requirements et les
usecases
47

48.
Jour 3 : Implémenter le
Scrum.
48

49.
TP3 : Exécuter un
sprint
49

50.
Jour 4 : Introduction au
Lean Kanban.
50

51.
Le Lean
51
 Cadre de management de l’activité industrielle, apparue au
Japon dans les années 50 (Toyota)
 Réduction des pertes
 Rythme de production soutenu.
 Introduit en 2001 dans le domaine du Software avec les
méthode Agiles.

52.
Kanban
52
 Pull Method
 Customer Value
 Continuous Flow
 Waste Elimination
 Continuous Improvement

53.
Le Lean
53

54.
Kanban for support Team
54