Université Mohammed V de Rabat

Ecole Nationale Supérieure d'Arts et Métiers

Filière INDIA (2ème année) A.U. : 2023/2024 Pr. A. El Qadi

Série n°3 en Ingénierie logicielle

Rappel:
Scrum : est un schéma d’organisation de développement de produits complexes. Il est défini par ses créateurs
comme un « cadre de travail itératif qui se concentre sur les buts communs en livrant de manière productive et
créative des produits de la plus grande valeur possible ».
Scrum est considéré comme un groupe de pratiques répondant pour la plupart aux préconisations du Manifeste
Agile.
Sprint: En développement logiciel, un sprint est un rassemblement de personnes impliquées dans un projet
afin de se concentrer sur le développement de ce projet. Un sprint dure en général de deux à sept jours.
User Story: La rédaction d'une user story doit rendre le besoin utilisateur simple et compréhensible. Cette
phrase doit seulement contenir 3 éléments descriptifs : Qui; Quoi; Pourquoi
1. Le contexte → en tant que <rôle/personas>
2. La fonction → je veux <fonctionnalité>
3. Le bénéfice → afin de (pour) <raison/objectif>

Ce sont les membres de l'équipe qui formulent ensemble les user stories. En général, ils écrivent les phrases
sur des affichettes avant de valider le product backlog avec le client.
Une bonne user story est :
1. Independent → pas de dépendance entre les user stories.
2. Negotiable → la user story peut être arbitrée par le client et l'équipe.
3. Valuable → un besoin est toujours associé à la user story.
4. Estimable → l’équipe doit être en capacité d'estimer la user story.
5. Small → la user story est décrite précisément.
6. Testable → les critères d’acceptation de la user story sont atteignables.
La motivation de l'équipe augmente lorsque l’aboutissement de son travail est concret. C'est pourquoi les user
stories du projet se divisent toujours en courtes actions. La tâche représente bien le niveau de découpage
élémentaire pour une user story.
Les user stories prévues à gérer à une date lointaine sont décrites synthétiquement. Encourager l'équipe à
détailler les tâches dont la réalisation est imminente. On peut évaluer la pertinence des tâches avec la grille de
critères SMART :
1. Specific → toute l'équipe comprend ce qu’il y a à faire.
2. Mesurable → l'équipe sait comment s’assurer que la tâche est réalisée.
3. Achievable → l'équipe dispose de tous les moyens pour réaliser la tâche.
4. Relevant → la tâche participe bien à la concrétisation de la user story.
5. Time Bound → la tâche a une durée connue et limitée de travail.
User strory/ Cas d'utilisation:
Une user story est généralement "En tant qu'utilisateur, je veux faire quelque chose pour avoir un résultat /
avantage.
Un cas d'utilisation (qui est vraiment textuel, BTW) est généralement: pré-condition, actions et réponses,
post-conditions, scénarios alternatifs, etc.
En UML, l'utilisateur devient acteur et le je veux faire quelque chose devient le cas d'utilisation. Le résultat /
avantage représente le facteur objectif / succès pour le cas d'utilisation (et, d'une certaine manière, les post-
conditions). Les conditions préalables et postérieures sont des contraintes. les actions et les réponses peuvent
être exprimées sous forme d'interactions (diagrammes de séquence), d'activités et de machines à états.
User points : Chaque User Story se voit attribuer un nombre de points.
On prend l’User Story la plus petite et on lui affecte le poids de 1, ensuite on cherche le poids relatif des story
par rapport à cette première Story.
Vélocité : est le nombre de Story points que l’équipe est capable de parcourir en une itération (sprint). Par
exemple, si la taille du projet est estimée à 100 story points et la vélocité de l’équipe est estimé à 10 points
pour une itération (sprint) de 2 semaines. Le projet prendra donc (2×100)/10 = 20. Ce qui fait que le projet
prendra 20 semaines.
Exercice 1:
1. Quel est le but de la mêlée quotidienne, ou stand-up meeting ?
a. Le fait de se lever de son siège et de remettre son corps en activité est un team-building en soi.
b. Cela permet, pour chaque membre de l'équipe, de communiquer sur ses avancements et ses points de
blocage.
c. Cela oblige l'équipe à travailler en une même unité de lieu.
d. Cela aide à savoir où concentrer ses efforts pour ne pas livrer le projet en retard.
2. En scrum, qui valide les user-stories pour qu’elles passent de "test" à "done"
a. le scrum master
b. le product owner
c. l’équipe de développement
d. toute l’équipe
3. L’équipe de développement peut-être composée :
a. de développeurs front et de développeurs back
b. de développeurs, d’un business analyst et d’un testeur
c. d’un testeur et de développeurs
d. de développeurs, d’un PMO et d’un testeur
4. Quels artefacts existent en scrum ?
a. le definition of done
b. le definition of ready
c. le sprint backlog
d. l’increment backlog
5. Le product owner est responsable :
a. de valider que les items sont bien « done »
b. de la gestion du product backlog
c. que l’équipe de développement comprenne bien les items
d. de rendre transparent le sprint backlog
6. Le scrum master doit :
a. avoir des connaissances avancées sur la gestion d’un product backlog
b. faciliter les cérémonies scrum
c. travailler avec les autres scrum master de l’entreprise
d. coacher l’équipe de développement si nécessaire
7. Le scrum :
a. est un cadre de travail
b. est une méthode agile
c. ne s’occupe pas de la maintenance applicative
d. est un cadre léger
8. Le scrum permet dans des cas exceptionnels d’annuler un sprint. Quelles phrases sont vraies ?
a. l’équipe de développement peut demander au product owner d’annuler le sprint
b. seul le product owner est autorisé à annuler un sprint
c. un sprint recommence la semaine suivante pour ne pas perturber les dates des cérémonies
d. seul le scrum master est autorisé à annuler un sprint
9. Quelle(s) affirmation(s) sont vraies concernant la sprint planning ?
a. tous les items choisi en sprint planning ne sont pas forcément finalisés.
b. seule l’équipe de développement valide sa capacité de faire (le nombre d’items du sprint)
c. un sprint planning peut durer jusqu’à 8h
d. l’équipe de développement doit définir comment elle va réaliser les items
10. Quels types de projets de développement logiciel peuvent être exécutés par Scrum Project Management
Framework?
a. Progiciels complets
b. projets clients
c. Sous-systèmes, composants ou parties de systèmes plus importants
d. Tous types de projets de développement de logiciels
e. Aucune des réponses données
11. Qu'est-ce qui est défini par le cadre Scrum?
a. Règles et rôles
b. Directives de document
c. Artefacts et événements
12. Où sont stockées les exigences du client?
a. dans le backlog du produit
b. dans le backlog de sprint
c. dans une base de données
d. Dans une spécification d'exigence de produit Scrum
e. Nulle part. Le propriétaire du produit Scrum les connaît
13. Lesquels des rôles principaux suivants sont définis par Scrum Framework?
a. Scrum Tester
b. L'équipe Scrum
c. Scrum Manager
d. Scrum Master
e. Propriétaire du produit Scrum
14. Quels sont les événements principaux suivants définis par Scrum Framework?
a. Réunion de planification du sprint
b. Réunion rétrospective de sprint
c. Réunion d'examen du sprint
d. Réunion d'examen de l'état du mi-sprint
e. Réunion Scrum quotidienne
15. Quel concept n'est pas défini dans le cadre Scrum?
a. Scrum Master
b. Chef de projet
c. Propriétaire du produit Scrum
d. Scrum quotidien
e. Burndown du produit Scrum
16. Qu'est-ce qui est important dans tous les projets Scrum?
a. Auto-organisation
b. la communication
c. hiérarchies claires dans l'entreprise
d. Amélioration continue
17. Quels sont les avantages du cadre Scrum?
a. Les exigences à granularité fine ne sont définies que lorsqu'elles sont réellement nécessaires.
b. Toutes les activités de conception, de création et de test d'une fonctionnalité donnée sont regroupées
au cours d'une phase.
c. Des changements sont attendus et bien accueillis par l'équipe Scrum.
d. Toutes les réponses données
e. Aucune des réponses données
Exercice 2:
Une entreprise de développement du logiciel cherche à concevoir et à réaliser une application Web de gestion
des appels d’offre, des prestataires, des services, des infrastructures et des progiciels.
Pour la performance de ce système de gestion d’information, et pour satisfaire les exigences du client en
moindre coût et délai, l'entreprise utilise la méthode agile Scrum pour le déroulement du projet.

Développement du Sprint1 « Authentification, Inscription et Gestion de profil » Ce premier sprint s’étale sur
18 jours et se décompose en trois items: S’inscrire (4jours); S’authentifier (6jours); Gérer profil (8jours).
Soit les deux diagrammes de use cases ci-dessous correspondant à ce premier sprint:
include
Inscrire Gérer le profil s'authentifier

Internaute include
Gérer le profil s'authentifier Prestataire Désactiver profil Consulter profil
extend
extend
Modifier image Modifier profil
Prestataire

et les 5 user-stories suivantes: S’inscrire ; S’authentifier ; Consulter profil ; Modifier profil; Modifier image
de profil ; Désactiver profil
1. Décrire le Backlog du sprint 1 : Donner la description, et le numéro de priorité de chaque user story.
2. Transformer la Description textuelle du cas d’utilisation « S’inscrire » ci-dessous en user story, en
décrivant les étapes clés (titre, type, description, règles métiers, et les cas de tests, ...)

Exercice 3: On considère le cas utilisation RetirerArgentDistributeur

Créer l’User story correspondant à ce cas d’utilisation en décrivant les étapes clés (titre, type, description,
règles métiers, et les cas de tests, ...)
Précondition : le distributeur contient des billets; il est en attente d'une opération.
Postcondition: si de l'argent a pu être retiré, le nouveau solde = solde avant - l'argent retiré.
Déroulement normal:
(1) le client introduit sa carte bancaire
(2) le système lit la carte et vérifié si la carte est valide
(3) le système demande au client de taper son code
(4) le client tape son code
(5) le système vérifié que le code est correct
(6) le client choisit une opération de retrait
(7) le système demande le montant à retirer, etc
Variantes:
(A) Carte invalide : le système rejette la carte et le cas d'utilisation se termine;
Contraintes non fonctionnelles:
(A) Performance : le système doit réagir dans un délai inférieur à 4 secondes, quelque soit l'action de l'utilisateur.
...