Vous êtes sur la page 1sur 16

Plan

- Introduction sur le Génie Logiciel et l’Interaction Homme-Machine, briques de


base méthodologiques

- UML

- Méthodes agiles avec SCRUM

- Modèles de base en Interaction Homme-Machine

- Conclusion

© C. Kolski
Modèle de développement de logiciel : vers des méthodes agiles
- Concepts clés : impliquer au maximum le demandeur (client), permettre une grande réactivité à
ses demandes, viser la satisfaction réelle du client en priorité aux termes d'un contrat de
développement (objectif des méthodes traditionnelles) (Lire : MESSAGER ROTA, 2008)
 Modèle itératif, incrémental et adaptatif

- Manifeste agile (2001) : concepts communs aux méthodes se voulant agiles http://agilemanifesto.org/
01 - La plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à forte
valeur ajoutée.
02 - Le changement est accepté, même tardivement dans le développement, car les processus agiles exploitent le
changement comme avantage compétitif pour le client.
03 - La livraison s’applique à une application fonctionnelle, toutes les deux semaines à deux mois, avec une
préférence pour la période la plus courte.
04 - Le métier et les développeurs doivent collaborer régulièrement et de préférence quotidiennement au projet.
05 - Le projet doit impliquer des personnes motivées. Donnez leur l'environnement et le soutien dont elles ont besoin
et faites leur confiance quant au respect des objectifs.
06 - La méthode la plus efficace de transmettre l'information est une conversation en face à face.
07 - L’unité de mesure de la progression du projet est un logiciel fonctionnel (ce qui exclut de comptabiliser les
fonctions non formellement achevées).
08 - Les processus agiles promeuvent un rythme de développement soutenable (afin d’éviter la non qualité découlant
de la fatigue).
09 - Les processus agiles recommandent une attention continue à l'excellence technique et à la qualité de la
conception.
10 - La simplicité et l'art de minimiser les tâches parasites, sont appliqués comme principes essentiels.
11 - Les équipes s'auto-organisent afin de faire émerger les meilleures architectures, spécifications et conceptions.
12 - À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son processus
de travail en conséquence.
© C. Kolski
Modèle de développement de logiciel : vers des méthodes agiles
- Méthodes agiles représentatives : Rapid Application Development (RAD, MARTIN, 1991),
Scrum (1995), Extreme programming (XP, 1999)…
(+ des méthodes se revendiquant agiles, cf. UP, RUP (JACOBSON et al., 2000)

- Exemple : Extreme programming (XP, née avec le livre de Kent BECK,1999)

 Orientée réalisation d'application (sans négliger l'aspect gestion de projet), adaptée aux équipes
réduites avec des besoins changeants ; développement et test en binôme

 Cinq valeurs fondamentales : communication (entre développeurs, décideurs et clients),


simplicité (pour faciliter les évolutions), feed-back (par livraisons fréquentes), courage
(Certains changements demandent du courage), respect (pour les autres et pour soi-même)

Pour aller plus en profondeur : http://www.extremeprogramming.org/


© C. Kolski
Méthode agile SCRUM
- Scrum : premières expérimentations en 1993, présentation d’un article court de Ken
SCHWABER dans la conférence OOPSLA’1995 puis des principes plus détaillés dans (SCHWABER,
1995)

=> Scrum traduit par mêlée, en anglais ; analogie avec le rugby dans une publication de Hirotaka
TAKEUCHI et Ikujiro NONAKA en1986)

http://www.lerugbynistere.fr/videos/video-ecosse-france-comment-la-melee-du-xv-du-chardon-se-comporte-t-elle-0902181657.php

- Actuellement : la plus populaire des méthodes agiles

- Nombreux livres disponibles à la B.U. : AUBRY (2010), BODET (2011), LAYTON (2015)…

© C. Kolski
Méthode agile SCRUM
- Scrum :

 Orientée gestion de projets, inspirée du modèle spirale, découpage du projet en incréments


nommés « sprint » (durée de quelques heures à un mois, si possible : deux semaines) :
estimation, planification opérationnelle, réalisation de livrable, démonstration (puis rétrospective)

Backlog : liste de fonctionnalités, user stories…

© C. Kolski
Méthode agile SCRUM
- Les 3 rôles principaux de Scrum :

Product Owner : porteur de la vision du produit à réaliser, travaille en


interaction avec l’équipe de développement
 Généralement un expert du domaine métier du projet
(client ou représentant du client)

Equipe de Développement : chargée de transformer les


besoins exprimés par le Product Owner en fonctionnalités
utilisables ; équipe pluridisciplinaire (encapsulation
d’autres rôles tels que développeur, architecte logiciel,
DBA, analyste fonctionnel, graphiste/ergonome,
ingénieur système)

Scrum Master : doit maîtriser Scrum et s’assurer que ce dernier est


correctement appliqué ; rôle de coach à la fois auprès du Product Owner
et de l’équipe de développement ; doit donc faire preuve de pédagogie.
Il est chargé de s’assurer que l’équipe de développement est pleinement
productive. Généralement le candidat tout trouvé au rôle de Scrum Master
est le chef de projet ; devra cependant renoncer au style de management
« commander et contrôler » pour adopter un mode de management
https://betterhumans.coach.me/@coachsweetin
participatif.

(adapté de : https://agiliste.fr/guide-de-demarrage-scrum/)
© C. Kolski
SCRUM
- Exemple de Backlog de produit (product backlog) :
(extrait parmi les éléments restant à faire)

http://unprojetdeboutenbout.free.fr/?cat=4
Composé d’histoires (User stories)
Format : « En tant que … », « je souhaite … », « afin que/de … »
Chaque histoire doit avoir une valeur ajoutée (business value )
© C. Kolski
User story (récit utilisateur)
(utilisé dans les méthodes agiles, début avec Extreme Programming (XP) en 1998)

- User story (récit utilisateur) : phrase simple permettant de décrire dans le langage de tous les jours
avec suffisamment de précision le contenu d'une fonctionnalité à développer

► Structure : En tant que <qui>, je veux <quoi> afin de <pourquoi>


(pourquoi : facultatif)

Exemples :

En tant qu’utilisateur, je veux qu’en cas de sortie il y ait un message d’avertissement demandant
une sauvegarde afin de sauver ce qui a été modifié depuis la dernière sauvegarde

En tant que utilisateur de profil technico-commercial, je veux que le système puisse me fournir
les prix en TTC et HT

En tant que technicien de maintenance, je veux pouvoir modifier des fichiers à distance afin
d’éviter de me déplacer pour pas grand chose

© C. Kolski
User story (récit utilisateur)
(utilisé dans les méthodes agiles)

- Une bonne User Story doit respecter les caractéristiques réunies sous le sigle INVEST :

Indépendante : assure l’indépendance d’une User Story vis-à-vis des autres user stories du
backlog.

Négociable : une User Story doit être un support de discussion en vue d’une amélioration du
besoin initial.

Valorisable : la réalisation d’une User


Story doit rendre un service à l’utilisateur.
Elle n’a de sens que si elle apporte
une valeur métier.

Estimable : une User Story doit être bien


définie pour être facilement chiffrable;
Suffisamment petit : une User Story doit
être réalisable sur un sprint.

Testable : une User Story doit être


accompagnée de ses critères d’acceptabilité
pour faciliter sa validation.

http://blog.palo-it.com/2014/02/11/rediger-un-user-story-les-bonnes-pratiques/
© C. Kolski
Méthode agile SCRUM
- 4 types de réunions (1/4) :

 Réunion de planification d'un sprint (sprint planning meeting) (pas plus de 8 heures pour un
sprint d'un mois), réunion de toute l’équipe Scrum :

décider des éléments du carnet du produit qu'elle traitera dans le cadre


de la prochaine itération, et comment elle s'organisera pour y parvenir

Sortie :
- le carnet du produit priorisé ;
- la capacité de production (vélocité) prévue pour ce sprint (estimation théorique pour
le 1er sprint ; estimation basée sur la productivité réelle obtenue, pour les sprints suivants)

=> Découper en activités d'une durée limitée (généralement une journée au plus) le travail
à effectuer pendant le sprint
© C. Kolski
Méthode agile SCRUM
- 4 types de réunions (2/4) :

 Mêlée quotidienne (Daily Scrum) (15 mn, journalier), réunion de planification « juste à temps »
entre développeurs :

3 sujets à aborder par chacun :


Qu'ai-je fait hier ? Que dois-je faire aujourd'hui ? Quelles sont
les difficultés rencontrées ?

Si besoin de plus de 15 mn : continuer librement après sur points


non complètements traités

=> Réunion permettant : la synchronisation de l'équipe, l'évaluation de l'avancement vers


l'objectif de l'itération, la collecte d'information nécessaire à l'auto-organisation

© C. Kolski
Méthode agile SCRUM
- 4 types de réunions (3/4) :

 Revue de sprint (sprint review) (à la fin du sprint, au maximum 4 heures), réunion avec l’équipe
Scrum et les parties prenantes :

Objectif : valider l'incrément de produit réalisé pendant le sprint (en


passant en revue les éléments du carnet de produit sélectionnés en
début de sprint) ; démonstration des éléments finis (complètement
réalisés), les éléments non finis (partiellement réalisés) n’étant pas
présentés

=> Une fois le bilan du sprint réalisé, mise à jour du carnet du produit en fonction de ce qui a
été réalisé (fini) ; discussion de l'état courant du projet (budget, financement, conditions du
marché), pour ajustement des éléments de carnet de produit et planification selon les
opportunités découvertes (nouvelles idées)
© C. Kolski
Méthode agile SCRUM
- 4 types de réunions (4/4) :

 Rétrospective du sprint (Sprint retrospective) (à la fin du sprint, au maximum 3 heures), réunion


de l’équipe Scrum :

Objectif : adaptation aux changements qui surviennent au cours du projet et amélioration


continue du processus de réalisation.

Qu’est-ce qui a bien fonctionné ?


Qu’est-ce qui est à améliorer pour le sprint suivant ?

© C. Kolski
Support logiciel pour les méthodes agiles (dont SCRUM)
- Outil de gestion de projet agile permettant d’avoir une vue globale des tâches du sprint (et de leur état) :

Exemple de tableau SCRUM de l’outil de gestion de projet Agile Jira Software (Atlassian)
https://www.atlassian.com/fr/software/jira

- Voir aussi l’article : « Jira : 5 alternatives qui font concurrence à l’outil d’Atlassian »
https://www.ionos.fr/digitalguide/sites-internet/developpement-web/alternatives-a-jira/
© C. Kolski
Conclusion sur SCRUM

- Très utilisée dans de nombreuses entreprises actuellement

- Comme pour toutes les méthodes du Génie Logiciel : utilisée telle quelle ou adaptée selon les
besoins de l’entreprise et ses spécificités

Ex. : prévision (ou non) de la possibilité d’avancer ou retarder la fin d’un sprint selon
l’avancement des tâches à réaliser (« on a besoin de deux jours de plus pour pouvoir
montrer F14 au client 14 », « quand tout est terminé, c’est la fin du sprint », « c’est la fin du
sprint aujourd’hui, on n’a pas fini, donc on montrera T122 au client à l’issue du prochain
sprint »)

Ex : le Product Owner peut être dans l’entreprise, faire partie de la maîtrise d’oeuvre (« je suis
en contact direct et constant avec le client ») ou être un client (représentant de la maîtrise
d’ouvrage) ; objectif : grande proximité, interaction immédiate (ou presque) possible

Ex : chiffrage d’une tâche à réaliser (nombres d’heures ou de jours) : par les membres de
l’équipe (si expérimentés), vérification/validation par le Scrum master (ou non) selon la
configuration de l’équipe, ou par le Scrum master directement

Ex : choix des tâches à réaliser durant un sprint : choix par les membres (« J’aimerais prendre
celle-là », « euh… moi aussi ») et/ou arbitrage/attribution par le Scrum master

Ex : accepter (ou non) l’idée que selon l’avancement de la réflexion, des développement et/ou des
échanges avec le client, on puisse ajouter des tâches durant le sprint
© C. Kolski
Bibliographie
AUBRY C. (2010). SCRUM, le guide pratique de la méthode agile la plus populaire. Dunod, Paris.
BECK K. (1999), Extreme Programming Explained, Addison Wesley (5ème édition en 2005).
BODET G. (2011). Scrum en action. Pearson.
JACOBSON I., BOOCH G., RUMBAUGH J. (2000). Le processus unifié de développement logiciel.
Editions Eyrolles, Paris.
LAYTON M.C. (2015). SCRM pour les nuls. Editions First, Paris.
MARTIN J. (1991). Rapid Application Development. MacMillan, New-York.
MESSAGER ROTA, V. (2008). Gestion de projet, vers les méthodes agiles. Eyrolles, Paris.
SCHWABER K., Controlled Chaos : Living on the Edge. Cutter Business Technology Journal, March.
TAKEUCHI H., NONAKA I. (1986). The New New Product Development Game, Havard Business
Review, janvier-février 1986.

Beaucoup de tutoriels sur le web (dont des videos sur Youtube), par exemple :

https://www.scrum.org/resources/scrum-guide

https://agiliste.fr/guide-de-demarrage-scrum/ (auteur : Florent Lothon)

© C. Kolski

Vous aimerez peut-être aussi