Université de Tunis Institut Supérieur de Gestion

Rapport de Projet de Fin d’Études Présenté en vue de l’obtention de la

Licence Fondamentale en Informatique de Gestion

Conception et Développement d’une Application Android de Gestion de Projets Agiles

Présenté par :

Chourouk Ben Messaoud

réalisé au sein de l’entreprise Sagemcom

Sous la direction de :

Ahmed Badreddine Professeur, ISG Tunis Encadrant pédagogique

Christian Jannot Directeur, Sagemcom Encadrant professionnel

Année Universitaire 2019-2020

Dédicace

“

Je dédie ce travail :

À ma chère mère, à qui je dois la vie et une part essentielle de ma personnalité. Qu’elle sache que l’amour qu’elle me donne continue à m’animer.

À mon cher père, décédé trop tôt, j’espère du monde qui est sien maintenant, il apprécie cet humble geste comme preuve de reconnaissance.

À mon frère, mes grands-parents, ma famille qui me donnent de l’amour et de la vivacité.

À tous mes amis , à qui je souhaite plus de succès.

Qu’ils trouvent ici le témoignage de ma profonde gratitude et reconnaissance.

”

- Chourouk

Merci !

Remerciements

Au terme de ce travail, je remercie les personnes qui m’ont apporté leurs

soutiens. Qu’ils trouvent ici l’expression de toute ma reconnaissance.

Je tiens à exprimer toute ma reconnaissance et remerciements à M. Chris- tian Jannot, mon encadrant professionnel, pour la précieuse expérience qu’il m’a fait vivre durant la période du stage, pour tous les précieux conseils et les informations qu’il m’a prodigués et d’avoir consacré du temps à l’enca- drement et le suivi de ce travail.

Je tiens à remercier également M. Ahmed Badreddine, mon professeur encadrant, pour son aide, pour les conseils et les informations qu’ils m’a pro- digués.

D’une autre part, je remercie l’ensemble du corps administratif et ensei- gnant de l’Institut Supérieur de Gestion de Tunis pour avoir porté un vif intérêt à notre formation.

Que les membres du jury trouvent ici l’expression de ma gratitude d’avoir

pris le temps d’évaluer l’honneur de ce travail.

Table des matières

Introduction générale

1 Contexte général du projet

1.1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.1.1 Présentation générale de Sagemcom . . . . . . . . . . . 17

1.1.2 Domaines d’activités de Sagemcom . . . . . . . . . . . 17

1.2 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . 18

1.2.1 Description de l’existant . . . . . . . . . . . . . . . . . 18

1.2.2 Critiques de l’existant

. . . . . . . . . . . . . . . . . . 18

1.2.3

Solution proposée . . . . . . . . . . . . . . . . . . . . . 19

1.3 Langage et méthodologie de conception . . . . . . . . . . . . . 20

1.3.1 Présentation de la méthode Scrum . . . . . . . . . . . 20

1.3.2 L’équipe Scrum . . . . . . . . . . . . . . . . . . . . . . 21

1.3.3 Les artefacts de la méthodologie Scrum . . . . . . . . . 22

1.3.4 Les événements Scrum . . . . . . . . . . . . . . . . . . 22

1.3.5 Langage de modélisation . . . . . . . . . . . . . . . . . 23

1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2 Sprint 0 : Planiﬁcation et architecture

2.1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2.1 Description du contexte

. . . . . . . . . . . . . . . . . 25

Table des matières

2.3

Identiﬁcation des besoins fonctionnels et non fonctionnels . . . 25

2.3.1

Identiﬁcation des acteurs . . . . . . . . . . . . . . . . . 25

2.3.2 Les besoins fonctionnels

. . . . . . . . . . . . . . . . . 26

2.3.3 Les besoins non fonctionnels . . . . . . . . . . . . . . . 27

2.4 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.4.1 Planiﬁcation des sprints

. . . . . . . . . . . . . . . . . 31

2.5 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . 32

2.6 Diagramme de classes global . . . . . . . . . . . . . . . . . . . 33

2.7 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.7.1 Architecture matérielle . . . . . . . . . . . . . . . . . . 34

2.7.2 Protocole et format de données

. . . . . . . . . . . . . 35

2.7.3 Architecture Android MVP . . . . . . . . . . . . . . . 36

2.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3 Sprint 1 Authentiﬁcation, Inscription et gestion de proﬁl

3.1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.2 Sprint Backlog

. . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.3 Analyse

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.3.1 Diagramme de cas d’utilisation du Sprint 1 . . . . . . . 40

3.3.2 Raﬃnement du cas d’utilisation « S’inscrire » . . . . . 41

3.3.3 Raﬃnement du cas d’utilisation « S’authentiﬁer » . . . 42

3.3.4

Raﬃnement du cas d’utilisation « Gérer proﬁl » . . . 43

3.3.5 Prototypes des interfaces . . . . . . . . . . . . . . . . . 44

3.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.4.1 Diagramme de séquence détaillé du cas d’utilisation «

S’inscrire » . . . . . . . . . . . . . . . . . . . . . . . . 45

3.4.2 Diagramme de séquence détaillé du cas d’utilisation «

S’authentiﬁer » . . . . . . . . . . . . . . . . . . . . . . 46

3.4.3 Diagramme de séquence détaillée du cas d’utilisation «

Gérer proﬁl » . . . . . . . . . . . . . . . . . . . . . . . 47

Table des matières

3.4.4 Diagramme de classes du premier sprint

. . . . . . . . 48

3.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.5.1

Interfaces du Sprint . . . . . . . . . . . . . . . . . . . . 48

3.6 CONCLUSION . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4 Sprint 2 : Application dédiée au Product Owner

4.1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.2 Sprint Backlog

. . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.3 Analyse

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.3.1 Diagramme de cas d’utilisation du Sprint 2 . . . . . . . 54

4.3.2 Raﬃnement du cas d’utilisation « Gérer projets » . . . 55

4.3.3 Raﬃnement du cas « Gérer ressources » . . . . . . . . 57

4.3.4 Raﬃnement du cas d’utilisation « Suivre les projets et

le Dashboard » . . . . . . . . . . . . . . . . . . . . . . 59

4.3.5 Prototypes des interfaces . . . . . . . . . . . . . . . . . 60

4.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.4.1 Diagramme de séquence détaillé du cas d’utilisation «

Gérer projets » . . . . . . . . . . . . . . . . . . . . . . 61

4.4.2 Diagramme de séquence détaillé du cas d’utilisation «

Aﬀecter ressources» . . . . . . . . . . . . . . . . . . . . 62

4.4.3 Diagramme de séquence détaillé du cas d’utilisation «

Attribuer rôle » . . . . . . . . . . . . . . . . . . . . . . 63

4.4.4 Diagramme de séquence détaillé du cas d’utilisation «

Suivre les projets » . . . . . . . . . . . . . . . . . . . . 63

4.4.5 Diagramme de classes du deuxième sprint

. . . . . . . 64

4.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.5.1

Interfaces du Sprint . . . . . . . . . . . . . . . . . . . . 64

4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5 Sprint 3 : Application dédiée au Scrum Master

5.1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Table des matières

5.2 Sprint Backlog

. . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.3 Analyse

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.3.1 Diagramme de cas d’utilisation du Sprint 3 . . . . . . . 70

5.3.2 Raﬃnement du cas d’utilisation « Gérer Sprint » . . . 71

5.3.3 Raﬃnement du cas d’utilisation « Gérer user-stories et

Consulter Backlog produit » . . . . . . . . . . . . . . . 72

5.3.4 Raﬃnement du cas d’utilisation « Gérer tâches » . . . 73

5.3.5 Raﬃnement du cas d’utilisation « Consulter Velocity

Chart» . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.3.6 Raﬃnement du cas d’utilisation « Consulter Tableau

de Kanban » . . . . . . . . . . . . . . . . . . . . . . . 75

5.3.7 Prototypes des interfaces . . . . . . . . . . . . . . . . . 76

5.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.4.1 Diagramme de séquence détaillé du cas d’utilisation «

Gérer sprints » . . . . . . . . . . . . . . . . . . . . . . 77

5.4.2 Diagramme de séquence détaillée du cas d’utilisation

« Gérer User-stories » . . . . . . . . . . . . . . . . . . 79

5.4.3 Diagramme de séquence détaillée du cas d’utili-sation

« Assigner tâche » . . . . . . . . . . . . . . . . . . . . 80

5.4.4 Diagramme de séquence détaillée du cas d’utilisation

« Consulter Tableau de Kanban »

. . . . . . . . . . . 81

5.4.5 Diagramme de classes du troisième sprint . . . . . . . . 82

5.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

5.5.1

Interfaces du Sprint . . . . . . . . . . . . . . . . . . . . 83

5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

6 Sprint 4 : Application décidée aux développeurs

6.1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.2 Sprint Backlog

. . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.3 Analyse

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.3.1 Diagramme de cas d’utilisation du Sprint 4 . . . . . . . 89

Table des matières

6.3.2 Raﬃnement du cas d’utilisation « Consulter mes tâches

» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.3.3 Raﬃnement du cas d’utilisation « Mettre à jour mes

tâches» . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6.3.4 Raﬃnement du cas d’utilisation « Consulter le nombre

d’heures passées et restantes » . . . . . . . . . . . . . . 91

6.3.5 Prototypes des interfaces . . . . . . . . . . . . . . . . . 92

6.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

6.4.1 Diagramme de séquence détaillé du cas d’utilisation «

Consulter mes tâches » . . . . . . . . . . . . . . . . . . 93

6.4.2 Diagramme de séquence détaillée du cas d’utilisation «

Mettre à jour mes tâches » . . . . . . . . . . . . . . . . 94

6.4.3 Diagramme de séquence détaillée du cas d’utilisation «

Consulter le nombre d’heures passées et restantes . . . 95

6.4.4 Diagramme de classes du quatrième sprint . . . . . . . 96

6.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

6.5.1

Interfaces du Sprint . . . . . . . . . . . . . . . . . . . . 97

6.6 CONCLUSION . . . . . . . . . . . . . . . . . . . . . . . . . . 98

7 Rétrospective

7.1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

7.2 Environnement de développement . . . . . . . . . . . . . . . . 100

7.2.1 Environnement matériel

. . . . . . . . . . . . . . . . . 100

7.2.2 Environnement logiciel

. . . . . . . . . . . . . . . . . . 100

7.2.3 Technologies utilisées . . . . . . . . . . . . . . . . . . . 102

7.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Conclusion générale

Webographie

104

105

Table des ﬁgures

1.1 Logo de Sagemcom. . . . . . . . . . . . . . . . . . . . . . . . . 17

1.2 Produits de Sagemcom . . . . . . . . . . . . . . . . . . . . . . 17

1.3

(a) Trello (b) Asana (c) Jira . . . . . . . . . . . . . . . . . . . 18

1.4 Processus scrum.

. . . . . . . . . . . . . . . . . . . . . . . . . 21

1.5 Burndown Chart

. . . . . . . . . . . . . . . . . . . . . . . . . 22

2.1 L’expérience utilisateur . . . . . . . . . . . . . . . . . . . . . . 28

2.2 Planiﬁcation des sprints

. . . . . . . . . . . . . . . . . . . . . 31

2.3 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . 32

2.4 Diagramme de classe global

. . . . . . . . . . . . . . . . . . . 33

2.5 Architecture de l’application . . . . . . . . . . . . . . . . . . . 34

2.6 Fonctionnement de l’architecture

. . . . . . . . . . . . . . . . 35

2.7 Architecture MVP . . . . . . . . . . . . . . . . . . . . . . . . 36

3.1 Diagramme de cas d’utilisation du sprint 1 . . . . . . . . . . . 40

3.2 Raﬃnement du cas d’utilisation « S’inscrire » . . . . . . . . . 41

3.3 Raﬃnement du cas d’utilisation « S’authentiﬁer » . . . . . . . 42

3.4 Raﬃnement du cas d’utilisation « Gérer proﬁl » . . . . . . . . 43

3.5 Maquette des interfaces du premier Sprint

. . . . . . . . . . . 44

3.6 Diagramme de séquence détaillé du cas d’utilisation « S’ins-

crire » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.7 Diagramme de séquence détaillé du cas d’utilisation « S’au-

thentiﬁer » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Table des ﬁgures

3.8 Diagramme de séquence détaillé du cas d’utilisation « Gérer

proﬁl » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.9 Diagramme de classes du premier sprint

. . . . . . . . . . . . 48

3.10 Interfaces de l’authentiﬁcation

. . . . . . . . . . . . . . . . . 49

3.11 Interfaces d’inscription . . . . . . . . . . . . . . . . . . . . . . 49

3.12 (a) Interface d’accueil (b) Menu . . . . . . . . . . . . . . . . . 50

3.13 (a) Consulter proﬁl (b) Modiﬁer proﬁl

. . . . . . . . . . . . . 51

4.1 Diagramme de cas d’utilisation du sprint 2 . . . . . . . . . . . 54

4.2 Raﬃnement du cas d’utilisation « Gérer projets » . . . . . . . 55

4.3 Raﬃnement du cas d’utilisation « Gérer ressources » . . . . . 57

4.4 Raﬃnement du cas d’utilisation « Suivre les projets » . . . . . 59

4.5 Maquettes des interfaces du deuxième Sprint . . . . . . . . . . 60

4.6 Diagramme de séquence du cas "Gérer les projets"

. . . . . . 61

4.7 Diagramme de séquence du cas "Aﬀecter ressources" . . . . . 62

4.8 Diagramme de séquence du cas "Attribuer rôle" . . . . . . . . 63

4.9 Diagramme de séquence du cas "Suivre les projets" . . . . . . 63

4.10 Diagramme de classes du deuxième sprint

. . . . . . . . . . . 64

4.11 (a) Consulter les projets (b) Créer un projet (c) Supprimer un

projet

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.12 (a) Consulter les ressources (b) Créer une ressource (c) Aﬀec-

ter une ressource . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.13 (a) Tableau de bord (b) Liste des projets

. . . . . . . . . . . 66

5.1 Diagramme de cas d’utilisation global du « Sprint 3 » . . . . . 70

5.2 Raﬃnement du cas « Gérer sprint » . . . . . . . . . . . . . . . 71

5.3 Raﬃnement du cas « Gérer user-stories» . . . . . . . . . . . . 72

5.4 Raﬃnement du cas d’utilisation « Gérer tâches » . . . . . . . 73

5.5 Diagramme de cas d’utilisation du cas « Consulter Velocity

Chart » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.6 Raﬃnement du cas « Consulter Tableau de Kanban » . . . . . 75

Table des ﬁgures

5.7 Maquettes des interfaces du troisième Sprint . . . . . . . . . . 76

5.8 Diagramme de séquence du cas « Gérer Sprint » . . . . . . . . 78

5.9 Diagramme de séquence du cas « Gérer user-stories » . . . . . 79

5.10 Diagramme de séquence du cas « Assigner tâche » . . . . . . . 80

5.11 Diagramme de séquence du cas « Consulter le tableau de Kan-

ban » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5.12 Diagramme de classes du troisième sprint . . . . . . . . . . . . 82

5.13 (a) Liste des Sprints (b) Créer sprint (c) Modiﬁer sprint

. . . 83

5.14 (a) Liste des user-stories (b) Supprimer user-story (c) Créer

user-story . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.15 (a) Liste des tâches (b) Créer une tâche (c) Supprimer une

tâche

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.16 To do (a) In Progress (b) Done (c)

. . . . . . . . . . . . . . . 85

5.17 Velocity Chart

. . . . . . . . . . . . . . . . . . . . . . . . . . 85

6.1 Diagramme de cas d’utilisation du quatrième Sprint . . . . . . 89

6.2 Raﬃnement du cas d’utilisation « Consulter mes tâches » . . . 89

6.3 Raﬃnement du cas d’utilisation « Mettre à jour mes tâches »

6.4 Raﬃnement du cas d’utilisation « Consulter le nombre d’heures

passées et restantes » . . . . . . . . . . . . . . . . . . . . . . . 91

6.5 Maquettes des interfaces du quatrième sprint

. . . . . . . . . 92

6.6 Diagramme de séquence du cas « Consulter mes tâches » . . . 93

6.7 Diagramme de séquence du cas « Mettre à jour mes tâches » . 94

6.8 Diagramme de séquence du cas « Consulter le nombre d’heures

passées et restantes » . . . . . . . . . . . . . . . . . . . . . . . 95

6.9 Diagramme de classes du quatrième sprint . . . . . . . . . . . 96

6.10 (a) Tableau de bord (b) Liste des projets

. . . . . . . . . . . 97

6.11 (a) Liste des tâches (b) Mettre à jour la tâche (c) Consulter

la tâche

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Liste des tableaux

1.1 Diﬀérence entre XP et Scrum . . . . . . . . . . . . . . . . . . 20

2.1 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.1 Sprint Backlog du Sprint 1 . . . . . . . . . . . . . . . . . . . . 39

3.2 Description textuelle du cas d’utilisation "S’inscrire" . . . . . 41

3.3 Description textuelle du cas d’utilisation "S’authentiﬁer" . . . 42

3.4 Description textuelle du cas d’utilisation "Consulter proﬁl" . . 43

3.5 Description textuelle du cas d’utilisation "Modiﬁer proﬁl" . . . 44

4.1 Sprint Backlog du Sprint 2 . . . . . . . . . . . . . . . . . . . . 53

4.2 Description textuelle du cas d’utilisation "Consulter projet" . 55

4.3 Description textuelle du cas d’utilisation "Supprimer un projet" 56

4.4 Description textuelle du cas d’utilisation "Attribuer rôles" . . 57

4.5 Description textuelle du cas d’utilisation " Aﬀecter les Res-

sources" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.6 Description textuelle du cas d’utilisation "Suivre les projets" . 59

5.1 Sprint Backlog du Sprint 3 . . . . . . . . . . . . . . . . . . . . 69

5.2 Description textuelle du cas "Consulter Sprint" . . . . . . . . 71

5.3 Description textuelle du cas d’utilisation "Créer Sprint" . . . . 72

5.4 Description textuelle du cas d’utilisation "Modiﬁer user-story" 73

5.5 Description textuelle du cas d’utilisation "Consulter tâches" . 74

Liste des tableaux

5.6 Description textuelle du cas d’utilisation "Consulter Velocity

Chart" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.7 Description textuelle du cas d’utilisation "Consulter Tableau

de Kanban" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.1 Sprint Backlog du Sprint 4 . . . . . . . . . . . . . . . . . . . . 88

6.2 Description textuelle du cas d’utilisation "Consulter mes tâches" 90

6.3 Description textuelle du cas d’utilisation "Mettre à jour mes

tâches" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

6.4 Description textuelle du cas d’utilisation "Consulter le nombre

d’heures passées et restantes" . . . . . . . . . . . . . . . . . . 92

Introduction

La méthode agile précisément la méthode SCRUM, intervient depuis quelques années dans les entreprises. Elle tend à devenir l’outil indispensable. Souvent synonyme de rapidité, cette méthode permet à une entreprise de piloter un projet dans des délais réduits tout en impliquant son client dans le processus.

Cependant, la maîtrise de cette méthode peut dérouter les nouveaux ar-

rivants, étant donné la complication de la nomenclature.

Sagemcom, l’entreprise qui m’a accueilli pendant plus que 4 mois de stage, organise régulièrement des formations aﬁn de former les salariés et les nouveaux arrivants.

Dans ce cadre, L’entreprise m’a conﬁé la mission de conception et de dé- veloppement d’une application Android de gestion de projets agiles, qui a pour but d’initier à l’agilité les stagiaires des centres Elife (et du centre de formation Sagemcom).

Le présent rapport est organisé en sept chapitres : Le premier chapitre, intitulé "Contexte général du projet" sera consacré à la description de l’or- ganisme d’accueil. Ensuite, nous identiﬁerons les problématiques aﬁn de pro- poser la solution adéquate et nous présenterons la méthodologie de travail adoptée.

Le deuxième chapitre, intitulé "Sprint 0 : Planiﬁcation et architecture", nous nous intéressons à déﬁnir le plan de réalisation et à produire le Backlog produit, et à présenter une vue architecturale de notre application.

Les quatre chapitres qui suivent, se concentreront sur l’étude et la réali-

sation des sprints de notre projet.

Le dernier chapitre représente la phase de clôtures, dans lequel nous allons

Introduction

présenter les diﬀérents outils utilisés pour la réalisation de notre projet. L’étape ﬁnale est une conclusion générale dans laquelle nous évaluerons notre travail ainsi que les objectifs atteints.

Chapitre 1

Contexte général du projet

1.1

Introduction

“ Ce chapitre représente un premier aperçu du projet réalisé. En

eﬀet, nous commençons par une brève présentation de l’orga- nisme d’accueil. Nous enchaînons ensuite par une description et une critique de l’existant, qui va nous guider vers la solu- tion proposée et la méthodologie de conception adoptée.

”

1.1. Introduction

1.1.1 Présentation générale de Sagemcom

Figure 1.1: Logo de Sagemcom.

Sagemcom dont le logo est présenté dans la ﬁgure 1.1 est un groupe fran- çais leader européen sur le marché des terminaux communicants, répondant à des besoins essentiels au monde qui nous entoure : décodeurs, box Inter- net et compteurs communicants multi-énergies."Le chiﬀre d’aﬀaires total du groupe s’élève à 2,1 milliards d’euros. L’eﬀectif de 5 500 personnes est réparti dans plus de 50 pays."[1]

1.1.2 Domaines d’activités de Sagemcom

Sagemcom opère principalement sur trois marchés majeurs : le broadband,

l’énergie et le retail, comme le montre la ﬁgure 1.2.

— Sagemcom Broadband oﬀre à ses clients des produits customisés,

intégrant les dernières ruptures technologiques.[2]

— Sagemcom Energy & Telecom met à disposition de ses clients une compétence exclusive dans le développement et l’intégration de solutions hardware et software.[3]

— Sagemcom Audio et vidéo solutions propose aux clients, une gamme de décodeurs personnalisables pour toutes les technologies de transmission.[4]

Figure 1.2: Produits de Sagemcom

1.2. Etude de l’existant

1.2 Etude de l’existant

L’étude de l’existant permet de déterminer les points faibles et les points forts d’un projet. Elle permet d’identiﬁer les diﬀérentes imperfections dans un système existant aﬁn de les corriger.

1.2.1 Description de l’existant

Les méthodes agiles sont très populaires en usage aujourd’hui. Cependant il est très important de disposer des bons outils pour mener un projet agile correctement. Dans cette partie, nous présentons des cas de ﬁgures des 3

meilleurs outils de gestion de projets agiles à l’échelle internationale.

— Trello : Il consiste sur le découpage du projet en plusieurs tâches et mini tâches, représentées par des cartes. Ces cartes peuvent être contenu dans des planches qui déﬁnissent l’état ou le type de ces tâches. [5]

— Asana : C’est un outil de gestion de projet SCRUM qui permet aux

équipe d’avoir un suivi sur leur travail. [5]

— Jira : C’est une application de gestion de projet. Jira permet égale- ment de faire le suivi de bugs, la gestion des incidents et l’aﬀectation des tâches aux diﬀérents collaborateurs d’un projet.[5]

(a)

(b)

(c)

Figure 1.3: (a) Trello (b) Asana (c) Jira

1.2.2 Critiques de l’existant

Lors de l’étude que nous avons menée dans la section précédente, nous

avons relevé les problèmes suivants :

Critique de l’application Jira

— La diﬃculté de la prise en main de l’application.

1.2. Etude de l’existant

— Il faut du temps pour s’habituer à son utilisation. — Son ergonomie est trop complexe.

Critique de l’application Asana

— Les limites de l’oﬀre gratuite de l’outil. — Diﬃculté dans la diﬀérenciation de certaines fonctionnalités.

Critique de l’application Trello

— Absence de gestion des ressources. — Absence de suivi du temps et la gestion d’équipe est faible. — Une seule interface ce qui limite la ﬂexibilité de l’application. — Prise en charge limitée.

En général, ces applications sont conçues pour des clients expérimentés. En plus de cela, les applications de gestion de projets agiles sont généralement des applications hybrides ou bien web et non pas des applications natives.

1.2.3 Solution proposée

Les applications mentionnées ci-dessus, ne répondent pas à notre besoin. En eﬀet, nous avons besoin d’une application mobile, simple d’utilisa- tion que nous pourrons utiliser pour initier à l’agilité les stagiaires des centres Elife (et du centre de formation Sagemcom). Comme solution, nous pro- posons une application mobile Android, gratuite, de gestion de projets agiles destinée aux trois acteurs de l’équipe Scrum (Product Owner, Scrum Master et Développeurs) qui dispose de ces fonctionnalités fondamentales :

— Gestion et suivi des projets. — Gestion et suivi des ressources. — Gestion et suivi des sprints. — Gestion et suivi des user stories. — Gestion et suivi des tâches. — Rapports du temps. — Suivi des statistiques et du tableau de bord. — Suivi du tableau de Kanban.

1.3. Langage et méthodologie de conception

1.3 Langage et méthodologie de conception

La méthodologie est l’ensemble des processus qui oﬀre la possibilité de pi- loter et d’organiser le développement d’un projet. On distingue deux familles de méthodes :

— Les méthodes classiques : C’est les méthodes les plus répandues en management et gestion de projet. Elles reposent sur le principe de la déﬁnition de phases séquentielles où il faut valider l’étape précédente aﬁn de passer à la suivante.[6]

— Les méthodes Agiles : Elles reposent sur le principe du dévelop- pement itératif dans lequel on divise un projet en plusieurs étapes appelées itérations.[6]

Suite à l’étude comparative des deux approches, nous avons penché pour l’uti- lisation d’une méthode agile. Cependant il existe plusieurs méthodes agiles diﬀérentes, dont les plus utilisées sont Scrum et Extreme Programming (XP) [7].

Le tableau 1.1, clariﬁe les diﬀérences entre ces deux méthodes [8] :

Méthode Scrum

Méthode XP Durée de l’itération (1 à 2 semaines) Durée de l’itération (2 à 4 semaines) Possibilités de changer des scénarios en cours de l’itération Diﬀérents rôles attribués aux membres de l’équipe (programmeur, testeur, coach etc.)

Il est interdit de changer les fonctionnalités durant l’itération Seulement trois rôles sont déﬁnis (Scrum-master, Product-owner et l’équipe)

Table 1.1: Diﬀérence entre XP et Scrum

Ces deux méthodes améliorent la transparence et l’adaptabilité des pro- jets informatiques. Elles valorisent la coopération dans le travail de l’équipe et l’adaptation aux changements. Pour bien mener notre projet, nous avons préféré utiliser Scrum comme méthode de conception et de développement.

1.3.1 Présentation de la méthode Scrum

Scrum est une méthode agile qui consiste à découper un projet complexe en plusieurs cycles ou itérations. Ces cycles peuvent alterner entre plusieurs

1.3. Langage et méthodologie de conception

phases avec un rythme assez rapide. De nos jours, Scrum est la méthode agile la plus populaire.[9] La ﬁgure 1.4 ci-dessous illustre la mise en place de Scrum.

Figure 1.4: Processus scrum.

1.3.2 L’équipe Scrum

L’équipe Scrum est pluridisciplinaire, elle comprend trois acteurs,un pro- priétaire de produit, une équipe de développement et un Scrum Master .[10]

(cid:63) Le Product Owner : le propriétaire du produit est le gérant du car- net du produit. C’est lui qui accepte ou refuse le travail présenté.[10]

(cid:63) Le Scrum Master : Le Scrum Master est responsable de la bonne

compréhension et application de Scrum. [10]

(cid:63) Équipe de développement : Elle peut contenir plusieurs rôle tels

que les concepteurs ou bien les développeurs.[10]

Dans le contexte de notre projet, Mr Christian Jannot, notre encadrant du stage est à la fois le Scrum Master et le Product Owner, et nous sommes, l’équipe de développement.

1.3. Langage et méthodologie de conception

1.3.3 Les artefacts de la méthodologie Scrum

(cid:63) Le Backlog de produit : Le Backlog contient une liste qui en- globe les exigences imposées par le client, et les fonctionnalités a implémenter.[11]

(cid:63) Le Backlog de sprint : Il contient la liste des user-stories présentes

dans le Backlog de produit. [10]

(cid:63) Burndown Chart : Le graphique d’avancement illustré par la ﬁ- gure 1.5, est un graphique qui permet d’illustrer la progression de l’équipe.[10]

Figure 1.5: Burndown Chart

1.3.4 Les événements Scrum

(cid:63) Le Sprint : C’est le coeur de Scrum. L’itération dure entre deux et quatre semaines. Au bout d’un sprint, une version du produit utilisable est livrée.[10]

(cid:63) Le sprint planning : C’est un évènement qui précède le début du

sprint et permet de ﬁxer les objectifs de ce dernier.[10]

(cid:63) La mêlée quotidienne (Daily Scrum) : C’est une réunion courte d’environs quinze minutes qui permet d’avoir une vue d’ensemble de l’avancement du projet.[10]

(cid:63) Revue du Sprint : C’est une réunion faite à chaque sprint, au cours de laquelle on clôture ce dernier en faisant un bilan détaillé, et on en entame un nouveau. [10]

(cid:63) Rétrospective de Sprint : Une réunion de 45 minutes par semaine de sprint. Le Scrum Master coordonne cette réunion. Elle a pour but

1.4. Conclusion

de mettre en valeur les idées de chacun et de soulever d’éventuels obstacles rencontrés.[10]

1.3.5 Langage de modélisation

Pour concevoir notre application, nous avons choisi UML [Uniﬁed Mode- ling Language] qui est un langage de modélisation, qui permet de déﬁnir les modèles objets à travers un ensemble de diagrammes.[12] En eﬀet, c’est la méthode la plus convenable à notre projet qui se base sur le principe de la programmation orientée objet. Ce langage possède une variété de diagrammes qui couvrent nos besoins.

1.4 Conclusion

Dans ce chapitre, nous avons présenté l’organisme d’accueil ainsi que ses diﬀérentes activités. Nous avons également présenté le cadre général de notre projet et la méthodologie qui sera adoptée.

Chapitre 2

Sprint 0 : Planiﬁcation et architecture

2.1

Introduction

“ Ce chapitre vise à identiﬁer les besoins, cerner les rôles des

utilisateurs préparer le plan de réalisation. Dans un premier temps, nous allons identiﬁer les acteurs de notre projet et ceux qui toucheront de façon directe à notre application. Dans un second temps, nous allons lister les besoins fonctionnels et non fonctionnels de l’application. Nous présenterons par la suite, les besoins de notre système et nous ﬁnirons par pro- duire le Backlog produit ainsi qu’une première planiﬁcation des sprints.

”

2.2. Analyse des besoins

2.2 Analyse des besoins

Tout au long de cette partie, nous allons identiﬁer et préciser les besoins à satisfaire représentant les fonctionnalités à réaliser dans notre application.

2.2.1 Description du contexte

Dans le cadre de la formation ELIFE, Sagemcom fera une formation sur le management de projet agile. L’entreprise nous a conﬁé le développement d’une application Android qui permettra aux étudiants de comprendre les concepts de base de l’agilité, de les mettre en application et de visualiser l’avancement en mode projet et multi-projets.

2.3 Identiﬁcation des besoins fonctionnels et non

fonctionnels

Dans cette section, nous allons déﬁnir les principaux acteurs de notre

application et identiﬁer les besoins fonctionnels et non fonctionnels.

2.3.1

Identiﬁcation des acteurs

(cid:63) Le Product Owner : Dans notre application, il est aussi l’adminis- trateur. Il possède une vue synthétique de l’avancement de ses projets. Il peut gérer des projets, déﬁnir les objectifs, nommer le Scrum Mas- ter, aﬀecter l’équipe et assigner les rôles.

(cid:63) Le Scrum Master : Il possède une vue synthétique sur ses projets et une vue détaillée sur les sprints et les user-stories en cours. Il peut gérer des user-stories, gérer des sprints, déﬁnir les tâches par user-story et allouer les tâches aux membres de l’équipe. Il supervise l’avancement des sprints, des user-stories et des tâches.

(cid:63) Le développeur : Il possède une vue synthétique sur ses projets, sprints, user-stories et une vue détaillée sur ses tâches. Il a la possibi- lité de mettre à jour l’avancement sur les tâches. Il peut ainsi consulter le nombre d’heures passées, heures restantes et le pourcentage de com- plétude prévu et estimé de chaque tâche.

2.3. Identiﬁcation des besoins fonctionnels et non fonctionnels 26

2.3.2 Les besoins fonctionnels

Dans cette partie, nous allons identiﬁer les fonctionnalités des acteurs de l’application. Un besoin fonctionnel c’est un cas d’utilisation en termes de UML. La phase d’identiﬁcation des acteurs nous a permis de repérer trois acteurs qui sont le Product Owner, le Scrum Master et l’équipe de dévelop- pement. Par conséquent, les fonctionnalités à assurer par l’application sont regroupées en trois catégories comme suit :

Les fonctionnalités du Product Owner

— Authentiﬁcation et gestion de proﬁl : Le Product Owner doit s’authentiﬁer pour accéder à son compte. Il peut par la suite consulter son proﬁl et modiﬁer ses cordonnées.

— Gestion des projets : Le Product Owner peut consulter la liste de ses projets, créer, modiﬁer ou bien supprimer des projets. Il peut également suivre le pourcentage de complétude de chaque projet.

— Gestion des ressources : Le Product Owner peut consulter la liste des utilisateurs. Nommer le Scrum Master de chaque projet, aﬀecter les développeurs à des projets. Il peut également assigner les rôles.

— Consultation du tableau de bord et suivi de l’avancement des projets : Le Product Owner peut suivre l’avancement de ses projets grâce à un tableau de bord qui lui permet de visualiser les statistiques de complétude sous forme d’un diagramme circulaire (Chart Pie).

Les fonctionnalités du Scrum Master

— Authentiﬁcation, Inscription et gestion de proﬁl : Le Scrum Master doit s’authentiﬁer pour accéder à son compte ou s’inscrire. il peut par la suite consulter son proﬁl et modiﬁer ses cordonnées.

— Consultation de la vue synthétique des projets

: Le Scrum Master peut consulter une vue globale de ses projets, il peut ainsi suivre le pourcentage de complétude de chaque projet.

— Gestion des sprints : Le Scrum Master peut consulter la liste de ses sprints, créer, modiﬁer ou bien supprimer des sprints. Il peut éga- lement suivre le pourcentage de complétude de chaque sprint.

2.3. Identiﬁcation des besoins fonctionnels et non fonctionnels 27

— Gestion des user-stories : Le Scrum Master peut consulter la liste de ses user-stories, créer, modiﬁer ou bien supprimer des user-stories.

— Gestion des tâcbes : Le Scrum Master peut consulter la liste des tâches, créer, modiﬁer ou bien supprimer et assigner des tâches aux développeurs.

— Suivi du Velocity chart : Le Scrum Master peut consulter un Ve-

locity Chart pour suivre l’avancement de ses sprints.

— Suivi du Backlog et du tableau de Kanban : Le Scrum Master peut consulter son Backlog produit et suivre le tableau de Kanban qui lui indique l’état de chaque user-story.

Les fonctionnalités des développeurs

— Authentiﬁcation, Inscription et gestion de proﬁl : Le dévelop- peur doit s’authentiﬁer pour accéder à son compte ou s’inscrire. Il peut par la suite consulter son proﬁl et modiﬁer ses cordonnées.

— Consultation de la vue synthétique des projets, sprints et user stories : Le développeur peut consulter une vue globale de ses projets, sprints et user-stories.

— Consultation des tâches : Le développeur possède une vue détaillée

sur les tâches qui lui sont assignées.

— Mise à jour des tâches : Le développeur peut mettre à jour l’état

de ses tâches.

— Suivi de la complétude des tâches : Le développeur peut consulter le nombre d’heures passées, la charge restante et le pourcentage de complétude relative à chaque tâche.

2.3.3 Les besoins non fonctionnels

Ce sont les normes de base qui garantissent un meilleur fonctionnement

de notre application Parmi ces besoins, on peut citer :

— Design de l’expérience utilisateur : Il s’agit de prévoir les exi- gences et le comportement des utilisateurs aﬁn de rendre l’interface plus ergonomique et facile d’utilisation. L’UX design se base sur les objectifs stratégiques de l’application, des facteurs technologiques et

2.3. Identiﬁcation des besoins fonctionnels et non fonctionnels 28

des problématiques de design et de conception.[13] Le diagramme 2.1 , résume l’expérience utilisateur 3 catégories :

Figure 2.1: L’expérience utilisateur

— Design de l’nterface utilisateur : L’UI représente le point de contact visuel entre l’utilisateur et le produit qu’il utilise. L’interface utilisa- teur est donc toute la partie graphique d’un site web, d’une application ou d’une interface quelconque.[14] Pour créer un bon design UI nous devons respecter les normes ergo- nomiques tel que :

(cid:63) la hiérarchie (cid:63) les contrastes (cid:63) le positionnement

— La sécurité : Nous devons sécuriser notre application. D’où le be- soin de procéder à l’authentiﬁcation des diﬀérents utilisateurs. Il faut aussi assurer la conﬁdentialité des données, et ce en appliquant des cryptages au nive