Une vue synthétique sur le méthodologie Agile Scrum. C'est une présentation qui a été faite dans le cadre d'une formation interne. Pour ceux qui ne connaissent rien ou pas grand chose de la méthode agile, c'est un survol rapide non exhaustif mais qui met les idées en place, enfin il faut espérer ! Nous n'avons pas joint les documents (tableurs excel notamment) qui aident au pilotage du projet mais ils sont faciles à refaire. Ces 2 présentations ont donné lieu à un article sur le Blog Hecube Voir http://bit.ly/13CDrqo

1. Agile ?

2. ✓L'évolution majeure
Le développement web ou logiciel présente une évolution majeure : on est passé
d'un processus de direction de projet prédictif à un processus itératif.
✓Gestion du temps et UX
C'est donc la gestion du temps et des impératifs client qui prédominent désormais
et qui a changé radicalement le gestion de projet.
3WDOC
Time is money

3. 3WDOC
Cascade vs Agile
✓Développement en cascade
Un développement en cascade se fait à partir d’un cahier des charges complet, qui
aboutit à la livraison d’un produit «fini»
✓Développement agile
Un développement agile se fait par versions successives (itérations) où le prestataire
livre, sur plusieurs mois, des versions qui s’enrichissent progressivement.

4. ✓Pour mémoire
+ de la 1/2 des fonctionnalités développés ne sont pas utilisées
+ de la 1/2 des des défauts sont liés à un mauvais recueil des besoins
✓Accoucher le client
Le but est de recueillir les besoins, sans viser l'exhaustivité afin de trouver un
langage commun. C'est cette maïeutique que vise la méthode agile vis à vis du
client afin qu'il exprime ses besoins et les hiérarchisent.
3WDOC
Le graal
information & communication

5. ✓Mauvaise communication
✓Exhaustivité Illusoire
✓Défaillance de client (ne sait pas)
3WDOC
Recueil des besoins
Pourquoi c'est difficile de recueillir les besoins du client....

6. ✓Cela va mieux en le disant !
Sortir tout ce qui est implicite
✓Laisser du temps au temps mais pas trop...
Le recueil des besoins et la hierarchisation s'inscrit dans une démarche itérative
3WDOC
Faire émerger les besoins
Un besoin pas seulement une fonction mais la capacité du système à assurer cette
fonction.

7. ✓Utilité et «Usability» (bienveillance du produit)
✓Efficacité (moins d'efforts)
✓Efficience (le plus rapide)
✓Satisfaction (meilleur expérience possible)
3WDOC
Pourquoi nous «agilons» ?
Les valeurs agiles sont les suivantes :

8. ✓La boucle du feedback est connu sous le nom de démarche en T, les besoins
«grosse maille» puis les besoins affinés.
3WDOC
La boucle du feedback
Le feedback, c’est le retour utilisateur/client

9. ✓Brainstroming
✓Benchmark
✓Interviews
✓Workshop
✓Analyse de l'existant
✓Observation comportement utilisateur en situation
3WDOC
Les techniques de recueil
Les techniques de recueil des besoins :

10. ✓N’avoir aucune déperdition d'information
✓Assurer la tracabilté nécessaire des informations
3WDOC
Formaliser les besoins
Il faut impérativement :
✓En mode agile, la fonctionnalité livrée constitue le
support de discussion. La méthode privilégie le langage
utilisateur.

11. 3WDOC
Le recueil des besoins
3 approches
✓Approche IEEE
Une approche qui définit les exigences essentielles (fonctions, performances, contraintes de
conception, attributs de qualité). Ex: A la demande du candidat, le système affichera le CV. Voir
tableur_approche_ieee.xls
✓Approche UML
C'est la méthode utilisant des cas d'utilisation (UC), User-Case.
✓Approche user stories
Une exigence est formulé avec le langage utilisateur, en 1 ou 2 phrases pour servir un but.

12. 3WDOC
Le product backlog
La pièce maitresse
Le PB regroupe l'ensemble des besoins/exigences ou des livrables à
réaliser. C'est la "file d'attente" ou le portefeuille des fonctionnalités dont
certaines seront sélectionnées au cours des itérations (sprint).
Les composants du PB sont les PBI (product backlog items)
Ces 3 approches constituent le PRODUCT BACKLOG (PB)
✓Les PBI sont hiérarchisés en fonction de leur valeur ajoutée (VA)
✓Le PB est sous le responsabilité du «product owner»

13. 3WDOC
Hiérarchiser les besoins
La hiérarchie des besoins se fait selon :
✓Le bénéfice attendu
✓Le coût de développement estimé
✓L'opportunité d'apprentissage pour l'équipe
✓Le risque de développement

14. 3WDOC
Le degré de satisfaction
du client
Il faut enfin intégrer le degré de satisfaction du client :
✓Exigences obligatoires
✓Exigences exprimées
✓Exigences latentes

15. 3WDOC
Mesure des exigences
Il faut enfin intégrer le degré de satisfaction du client :
✓Modèle de kano
✓Modèle des poids relatifs (Cf voir tableur_des_poids_relatifs.xls)
✓Modèle de moscow
M pour "Must-have" => Indispensable
S pour "Should-have" => Souhaitable
C pour "Could-have" => Possible
W "Want to have but Won't have" => Eliminé

16. 3WDOC
Exemple
Modèle des poids relatifs
Exemple : Voir tableur_des_poids_relatifs.xls. Dans le tableur des poids relatifs,
chaque item (exigence, story...) se voit attribué une pondération de 1 à 9.
✓Bénéfice à avoir la fonctionnalité, 1 = peu de valeur, 9 = bcp de valeur.
✓Préjudice à NE PAS avoir la fonctionnalité, 1 = peu de préjudice, 9 = bcp de
préjudice.

17. 3WDOC
A suivre
Planifier son projet, Suivre et piloter son projet

18. 3wdoc.com
blog.3wdoc.com
twitter.com/3wdoc
facebook.com/3wdoc