Contenu connexe
Similaire à Communaute dot net Montreal juin2010
Similaire à Communaute dot net Montreal juin2010 (20)
Communaute dot net Montreal juin2010
- 2. Qui suis-je
! Dominic Danis
! Directeur du produit Urban Turtle à Pyxis
Technologies, firme spécialisée dans le
développement, la formation, le coaching ainsi
que le développement de produit agile.
! ddanis@pyxis-tech.com
2 © Copyright Pyxis Technologies
- 3. Petite mise en garde
! Scrum ne donne pas la recette secrète du
développement logiciel
! Scrum fournit simplement les mécanismes
permettant de mettre en lumière les
problèmes et difficultés que nous rencontrons
dans nos projets de développement logiciel afin
d’être en mesure de les régler
! Une équipe Scrum apprend à s'améliorer
continuellement
3 © Copyright Pyxis Technologies
- 4. Quels problèmes rencontrons-nous ?
Succès: Le projet est réalisé selon le
budget et les délais convenus. Il
comporte les fonctions et
caractéristiques demandées.
Défi: Le projet est en retard, le budget a
été dépassé ou il manque certaines
fonctions et caractéristiques demandées.
Échec: Le projet a été arrêté avant sa
fin ou le logiciel développé a été livré CHAOS Report du Standish Group, 2003
mais n’a jamais été utilisé.
4
4 © Copyright Pyxis Technologies
- 6. Nos solutions sont-elles utiles?
Statistiques de l’industrie
Jim Johnson, Standish Group, XP 2002
6 © Copyright Pyxis Technologies
- 7. Peut-on livrer plus rapidement ?
d'après les travaux d'Hakan
Herdogmus, GUAM 2005
7 © Copyright Pyxis Technologies
- 8. Problèmes de communication?
! Le développement logiciel est
un jeu coopératif d’invention
et de communication. Il est
apparenté au développement
de produit.
! Les sources de problème dans
notre profession sont les gens
et les interactions
dysfonctionnelles plutôt que
les processus et les outils.
Comment communiquez-vous?
8 © Copyright Pyxis Technologies
- 9. Alors pourquoi le développement
Agile?
1. Pour satisfaire rapidement notre client avec des
solutions logicielles utiles
2. Pour augmenter la qualité
3. Pour faire face à la complexité
4. Pour réduire les inefficacités
5. Pour éviter les longues périodes de stabilisation en fin
de projet
6. Pour maximiser la collaboration
7. Pour augmenter la motivation et l’engagement des
individus
8. Pour avoir du plaisir au travail
9 © Copyright Pyxis Technologies
- 10. Manifeste Agile
Nous sommes à découvrir de meilleures façons de
développer des logiciels en aidant les autres et en
développant nous aussi. Par ce travail, nous en sommes
venu à valoriser ce qui suit :
! Personnes et interactions plutôt que processus et outils
! Logiciel fonctionnel plutôt que documentation complète
! Collaboration avec le client plutôt que négociation de contrat
! Réaction au changement plutôt que suivi d’un plan rigide
En fait, bien que les éléments de droite soient importants,
ceux de gauche le sont encore plus.
10
10 © Copyright Pyxis Technologies
- 11. Principes Agiles (1 de 2)
1. Notre première priorité est de satisfaire le client en
livrant tôt et régulièrement du logiciel utile
2. Le changement est bienvenu, même tardivement dans
le développement. Les processus Agiles exploitent le
changement comme avantage compétitif pour le client
3. Le logiciel fonctionnel est la principale façon de mesurer
le progrès
4. Les gens d’affaires et les développeurs doivent
collaborer quotidiennement, et ce, tout au long du projet
5. La méthode la plus efficace de transmettre l’information
est une conversation face-à-face
11
11 © Copyright Pyxis Technologies
- 12. Principes Agiles (2 de 2)
6. Une attention continue à l’excellence technique et à la
qualité de la conception améliore l’Agilité
7. La simplicité — l’art de maximiser la quantité de travail
à ne pas faire — est essentielle
8. Les meilleures architectures, spécifications et
conceptions émergent d’équipes qui s’auto-organisent
9. Agile favorise le développement à un rythme normal
10. Régulièrement, l’équipe fait une réflexion sur les façons
de devenir plus efficace, s’ajuste et modifie son
comportement en conséquence
12
12 © Copyright Pyxis Technologies
- 13. Méthodologies Agiles
! Scrum
! Extreme Programming (XP)
! Adaptive Software Development
! Crystal Clear
! Feature Driven Development
! Dynamic Systems Development Method (DSDM)
! MSF for Agile Software Development
! RUP (Agile RUP—AUP)
13
13 © Copyright Pyxis Technologies
- 14. Pilier 1
Le processus empirique
© Copyright Pyxis Technologies
- 17. Itération : le sprint
Planification de Démo et
Mêlée quotidienne
sprint rétrospective
(max. 15 min.)
(max. 1 jour) (max. 1 jour)
1 2 3 4 5 6 7 n
Développement :
Conception, code, test, documentation
Sprint de 30 jours d’effort soutenu et ciblé (focused)
17 © Copyright Pyxis Technologies
- 18. Pilier 2
La valeur d’affaire en avant plan
© Copyright Pyxis Technologies
- 19. La valeur d’affaires au premier plan
Processus en
Processus
cascade
Scrum
Exigences Coût Calendrier
Contraintes S'appuie sur
Contraintes la valeur ou
S'appuie vision
sur le
plan
Estimation
Coût Calendrier Fonctionnalités
Du plan découle De la vision découle
les estimations relatives au les estimations relatives
coût et au calendrier. aux fonctionnalités.
Estimations
19 © Copyright Pyxis Technologies
- 20. Responsable de produit
(product owner)
! Un bon responsable de produit doit :
• Connaître la valeur commerciale du produit
• Avoir le pouvoir de réunir des intérêts et désirs variés
• Être disponible
• Diriger une équipe de gestion de produit
! Ses responsabilités sont :
• Communiquer la vision
• S’approprier les spécifications
• Évaluer les incréments du produit
• Collaborer avec l’équipe de développement (le plus possible)
• Collaborer avec l’équipe de gestion du produit (le plus possible)
20
20 © Copyright Pyxis Technologies
- 21. Gestion des exigences :
le carnet du produit
Chaque itération met en œuvre les exigences
prioritaires.
Chaque nouvelle exigence est insérée dans la liste
selon sa priorité.
Il est possible en tout temps de changer l’ordre de
priorité des exigences.
Les exigences peuvent être supprimées en tout
temps.
21 © Copyright Pyxis Technologies
- 22. Granularité des exigences
Des détails sont ajoutés au fil du temps
Épisodes
Scénarios
Vision
Tâches
6 mois 2-3 mois 1 mois
Implantation
Horizon de prévisibilité
22 © Copyright Pyxis Technologies
- 24. Comment faire du développement
incrémental?
24 © Copyright Pyxis Technologies
- 25. Processus en cascade
! « Ça ne fonctionne jamais! » —
Brian Marrick
! C’est un processus imprévisible,
ce qui cause des surprises, donc
de l’insatisfaction.
25 © Copyright Pyxis Technologies
- 26. Processus Scrum
! C'est un processus prévisible, ce qui aide à prendre des décisions éclairées.
! La date est fixée. Que doit-on inclure dans le produit ?
! Le produit est en état d'être déployé à la fin de chaque sprint.
26 © Copyright Pyxis Technologies
- 27. Définir « terminé »
! La définition de « terminé » capture la capacité
technique actuelle de l'équipe
! Avec le temps, la définition de « terminé » devrait
s'étendre à toutes les activités nécessaires à la livraison
en production
! Le travail qui n'est pas couvert pas la définition de «
terminé » (travail « non terminé ») doit être identifié et
porté au carnet de produit
! Tout élément qui ne respecte pas la définition de «
terminé » n'est pas présenté au directeur de produit
en fin de sprint
27 © Copyright Pyxis Technologies
- 28. Étendre la définition de « terminé »
! Conception révisée
! Code remanié
! Code révisé
! Tests unitaires
! Tests intégrés
! Tests de recette
! Tests de performance
! Tests d'ergonomie
! Documentation utilisateur
! Déploiement en pré-production
! Acceptation par les utilisateurs
28 © Copyright Pyxis Technologies
- 29. Suivi de l’avancement
! La courbe du travail restant à faire permet de déterminer la date
probable de livraison
29 © Copyright Pyxis Technologies
- 30. Pilier 4
L'équipe autogérée
© Copyright Pyxis Technologies
- 31. Équipe Scrum
! Une équipe Scrum
comprend
uniquement les
personnes suivantes :
• un responsable de
produit
• un ScrumMaster
• des « équipiers »
31 © Copyright Pyxis Technologies
- 32. Caractéristiques d’une équipe
Scrum
! S’auto-organise
! Est pluridisciplinaire et ne comporte pas de rôles
prédéterminés
! Compte 7 membres (+/- 2)
! Est responsable de son engagement
! Possède l’autorité nécessaire pour agir de manière à
respecter ses engagements
! Travaille dans des locaux ouverts et avoisinants
! Résout ses propres conflits
! Observe des règles de base de fonctionnement et de
comportement
32 © Copyright Pyxis Technologies
- 33. Le Scrum Master n'est pas un chef de
projet
Imposer Faire confiance
Contrôler Faciliter
Diriger Accompagner
33 © Copyright Pyxis Technologies
- 34. Mêlées quotidiennes
! Paramètres :
• Tous les jours
• Durée limitée à 15 minutes
• Tout le monde debout
• Pas de résolution de problèmes
! Trois questions :
1. Qu’ai-je fait hier?
2. Quels ont été les obstacles rencontrés?
3. Qu’est-ce que je compte faire aujourd’hui?
! Les membres d’équipes et personnes externes sont
invités
• Permet d’éviter des réunions inutiles
! Seuls les membres d’équipe peuvent s’exprimer
34 © Copyright Pyxis Technologies
- 35. Questions sur les mêlées quotidiennes
! Pourquoi tous les jours?
• “Comment un projet peut-il avoir un an de retard?”
• “Un jour à la fois.”
– Fred Brooks, The Mythical Man-Month.
! Est-ce que les mêlées quotidiennes peuvent être
remplacées par des rapports d’activité envoyés
par courriel?
• Non, non et NON!
• L’équipe entière possède une vision complète actualisée
quotidiennement
• Une pression par les pairs incite à faire ce que nous avons dit que
nous ferions
35 © Copyright Pyxis Technologies
- 36. Revue du sprint
! L’équipe présente ce qui a été réalisé pendant le sprint
! La présentation comporte une démonstration des
nouvelles fonctionnalités ou de l’architecture
• Ce qui n’est pas complété n’est pas démontré!
! Revue informelle
• Ne pas dépasser 2 heures
de préparation
! Participants
• Propriétaire du produit
• Clients
• Management
• Équipe
36 © Copyright Pyxis Technologies
- 37. Rétrospectives du sprint
! Dans le but d’améliorer le processus
• À la fin de chaque sprint
• Le ScrumMaster est facilitateur
! Évaluation de ce qui a bien été et ce qui devrait être
amélioré
! Le ScrumMaster établit la priorité
des améliorations avec l’aide de
l’équipe
• L’équipe conçoit des solutions aux
éléments de haute priorité
• 2-3 max!
• L’équipe met les solutions en œuvre
! L’équipe s’approprie le processus
37 © Copyright Pyxis Technologies
- 38. La transition
Du traditionnel vers l’agilité
© Copyright Pyxis Technologies
- 39. Erreurs communes
1. Faire de l’Agile « pour être dans le vent »
2. Faire du développement itératif et non incrémental
3. Commencer à sprinter seulement lorsque tous les
besoins sont recueillis
4. Effectuer des « mini waterfall »
5. Laisser les spécialistes travailler en silo
6. Avoir un responsable de produit qui ne s’implique pas
suffisamment
7. Ne pas partager une vision commune de « terminé »
8. Ne pas travailler en équipe
39 © Copyright Pyxis Technologies
- 44. Références – Rapport d’expérience
http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
44 © Copyright Pyxis Technologies