Cette présentation explique l'agilité, mettant l'accent sur son état d'esprit, le processus Scrum et les rôles clés tels que le Product Owner et le Scrum Master. Elle souligne l'importance de la collaboration, de la réactivité au changement et de l'amélioration continue dans le développement logiciel. Des exemples d'entreprises utilisant Scrum et des pratiques d'ingénierie agile sont également présentés.

1. L'agilité en quelques slides
03/2012

2. Présentation
●
Nicolas Deverge - ekito
●
Architecte & ScrumMaster
●
Speaker à l'AgileTour 2009
●
Speaker au SigmaT 12
●
Speaker en 2012 pour le PPN des IUT
Twitter : @ndeverge

3. L'Agilité
●
Ce que c'est
●
un état d'esprit
●
un processus léger
●
la transparence / la confiance
●
l'acceptation du changement
●
amélioration continue
●
pilotage par la valeur business
●
Ce que ce n'est pas
●
une solution à tous les problèmes
●
une méthode de gestion de projet
●
une méthode de développement rapide

4. Pourquoi les méthodes Agiles ?
●
Le cycle en V fonctionne mal en ingénierie
logicielle
●
Problème de l'expression du besoin
●
Fonctionnalités non utilisées
●
Effet tunnel

5. Pourquoi les méthodes Agiles ?

6. Manifeste Agile
●
l’interaction avec les personnes plus que
les processus et les outils
●
un produit opérationnel plus qu'une
documentation pléthorique
●
la collaboration avec le client plus que la
négociation de contrat
●
la réactivité face au changement plus que
le suivi d'un plan

7. Scrum
●
Une méthode Agile
●
Cadre
●
Boîte à outils
●
Décrit le processus d'organisation, pas les
pratiques d'ingénieries

8. Le processus Scrum en une
image

9. Le Sprint
●
Les projets Scrum progressent par une série de
sprints
●
La durée d’un sprint est de 2 à 4 semaines
●
Une durée constante apporte un meilleur rythme
●
Le produit (partiel) est conçu, codé et testé
pendant le sprint (mini cycle en V)

10. Les rôles
●
Product Owner
●
Définit les fonctionnalités du produit
●
Choisit la date et le contenu de la release
●
Responsable du retour sur investissement
●
Définit les priorités en fonction de la valeur
« métier »
●
Ajuste les fonctionnalités et les priorités à
chaque itération si nécessaire
●
Accepte ou rejette les résultats

11. Les rôles
●
ScrumMaster
●
Représente le management du projet
●
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

12. Les rôles
●
L'é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, …)
●
L’équipe s’organise par elle-même
●
La composition de l’équipe ne doit pas
changer pendant un Sprint
●
Le ProductOwner et le ScrumMaster font aussi
parties de l'équipe

13. Le backlog de produit
●
Contient l'ensemble des exigences
●
Users stories (exigences fonctionnelles)
●
Bugs
●
Spikes techniques
●
Chaque élément est priorisé et pondéré
●
« Business point »
●
« Points d'effort »

14. Priorisation &
Pondération
●
Priorisation
●
Grâce aux « Business points »
●
Si ça ne suffit pas, ateliers « Buy a feature »
●
Pondération
●
Grâce aux « points d'effort »
●
Relativement entre users stories
●
Estimation collective
– « Planning Poker »
– Par similitude

15. La planification de Sprint
●
A partir du backlog de produit priorisé et pondéré
●
Définition du “but du Sprint”
●
Sélection des users stories en haut du backlog
●
Par rapport à la vélocité

16. La planification de Sprint
Backlog de produit Backlog de Sprint n
+ prioritaire
Voir les Voir les
dispos 3 offres 2
Sprint n+1
Créer un
Réserver
5 compte 3
Accès à un
Payer
5 compte 2
Sprint n+2
Rembourser
- prioritaire 3 Si vélocité entre 6 et 9

17. Radiateur d'informations

18. La planification de Sprint
●
Puis découpage des Users Stories en tâches
techniques
●
Collectivement par l'équipe
●
Estimées en « reste à faire » (en heures
idéales)

19. Le Done
●
Pour être considérée comme terminée, une User-
Story doit répondre à certains critères :
●
Codée
●
Testée fonctionnellement
●
Testée unitairement
●
Documentée
●
etc...

20. Le déroulement
quotidien
●
“Daily Scrum” tous les matins
●
Coordination quotidienne de l'équipe
●
Timeboxé : pas plus de 3 minutes par
personne
●
3 questions :
– « Qu'est-ce que tu as fait hier ? »
– « Qu'as-tu prévu aujourd'hui ? »
– « As-tu des problèmes ? »
●
On en profite pour mettre à jour les tâches
techniques (et le reste à faire)
●
Le PO et le SM participent aussi !!

21. En fin de Sprint
●
La revue
●
2h max, toute l'équipe
●
Le PO fait une démo du produit
●
On regarde les métriques
●
On fixe les objectifs du Sprint suivant
●
On invite du monde !
– Stakeholders
– End users
– Sponsors

22. En fin de Sprint
●
La rétrospective
●
30 mn max, que l'équipe
●
Amélioration continue
●
Critique du processus en vue de l'améliorer
●
3 questions :
– « Qu'est-ce qu'il faut continuer ? »
– « Qu'est-ce qu'il faut arrêter ? »
– « Qu'est-ce qu'il faudrait commencer ? »

23. Quelques métriques
●
Burndown chart de Sprint
●
Hour burndown chart de Sprint
●
Burndown chart de Release
●
Velocity chart
97 101
120
100
82 86
69
80
61
60
Vélocité
40
21
20
0
Sprint1 Sprint2 Sprint3 Sprint4 Sprint5 Sprint6 Sprint7

24. Quelques pratiques
d'ingénierie (XP)
●
Pair Programming
●
Tests Unitaires & Test Driven Development
●
Intégration Continue
●
Compilation
●
Tests unitaires
●
Packaging
●
Documentation

25. Utilisateurs de Scrum
●
Microsoft ●
Nielsen Media
●
Yahoo ●
First American Real
Estate
●
Google
●
BMC Software
●
Electronic Arts
●
Ipswitch
●
High Moon Studios
●
John Deere
●
Lockheed Martin
●
Lexis Nexis
●
Philips
●
Sabre
●
Siemens
●
Salesforce.com
●
Nokia
●
Time Warner
●
CNES
●
Turner Broadcasting
●
BBC
●
...
●
INRA

26. Autres...

27. Des questions ?

28. Agence Centre Ville : Tél. : + 33 (0) 561 316 240
1 place de la Bourse, Fax. : + 33 (0) 561 713 500
31000 Toulouse www.ekito.fr
contact@ekito.fr

29. Copyright
●
Vous êtes libre de :
●
Reproduire, distribuer et communiquer cette création
au public
●
Modifier cette création
●
Selon les conditions suivantes :
●
Paternité. Vous devez citer le nom de l'auteur original
de la manière indiquée par l'auteur de l'oeuvre ou le
titulaire des droits qui vous confère cette autorisation
(mais pas d'une manière qui suggérerait qu'ils vous
soutiennent ou approuvent votre utilisation de
l'oeuvre).
●
Rien dans ce contrat ne diminue
ou ne restreint le droit moral de
l'auteur ou des auteurs.
http://creativecommons.org/licenses/by/3.0/