Gestion de Projet Agile

Transcription

1 Gestion de Projet Agile De la vision aux tests Université de Cergy-Pontoise Master SIC/ISIM 2 ième Année 1

2 Plan Vision et features du projet User story (ou story) Décomposer les features et stories Accepter une story par les tests Plan de tests 2

3 Vision du projet Définition La vision est l'expression d'une volonté de développer un excellent produit ou service. Exemple Faire un site de rencontre pour animaux car les gens dépensent beaucoup d'argent pour leurs petites bestioles. Nous pourrons ainsi vendre de l'accompagnement, des produits et des publicités. 3

4 Vision du projet Exemple formulé Pour Qui Produit Qui permet A la différence de Notre produit Les propriétaires d'animaux domestiques Aiment faire partager l'amour pour leurs animal Un site de rencontres en ligne De faciliter les rencontres entre les animaux et entre leurs maîtres Des rencontres au hasard Apporte la possibilité de choisir ses rencontres 4

5 Feature (fonctionnalité essentielle) Définition Une feature est un service fourni par l'équipe, observable de l'extérieur, qui contribue à un impact, et dont la description se situe à un niveau tel que toutes les parties prenantes comprennent facilement ce dont il s'agit. Notion d'impact Cela ressemble à une expression de besoin mais dépasse le niveau du besoin d'utilisateur 5

6 User story Rappel de définition Dans une approche de gestion de projet agile, une user story y est présentée comme un rappel pour une conversation, lancée dans le but de faciliter la planification. Objectif : La user story est un morceau fonctionnel qui apporte de la valeur et qui pourra être développé en un sprint 6

7 Décomposer features stories Approche moderne : Story Map Une carte à deux dimensions Dimension 1 : séquence Dimension 2 : nécessite Squelette de l'application : une liste de features organisées de façon chronologique (un enchaînement) Objectif : obtenir une première ligne en dessous du squelette la première release MMF : la feature minimale déployable 7

8 Décomposer features stories Un exemple avec MMF Feature Coaching Story Feature Coaching Story MMF Coaching gratuit Story Story Release courante Story Story Story MMF Coaching payant Story Story Story Release suivante 8

9 Plan type d'une story Formulation As a <type of user>, I want <some goals> so that <some reason> En tant que <acteur>, je veux <un but> afin de <une justification> Exemple En tant que membre du site, je veux demander un conseil à un éleveur afin de savoir quoi faire avec mon toutou qui aboie tout le temps. 9

10 Plan type d'une story Format liste avec exemple Acteur (qui?) : organisateur Intention fonctionnelle (quoi?) : connaître le nombre d'inscrits Justification (quel impact?) : choisir une salle avec la bonne capacité Conseil Quand on débute le projet, cette manière de formuler une user story est très utile pour éclairer sa valeur apportée 10

11 Techniques de décomposition Technique 1 : variation sur les données Exemple de story à décomposer En tant que maître sur le site, j'ajoute un animal Décomposée en 3 stories : En tant que maître, j'ajoute un chien En tant que maître, j'ajoute un chat (différent du chien, on ne le promène pas) En tant que maître, j'ajoute un caméléon (pas de photo!!) 11

12 Techniques de décomposition Technique 2 : selon les règles de gestion Exemple de story à décomposer On peut rechercher les ancêtres d'un chien à pedigree, mais c'est réservé aux maîtres ayant acheté pour plus de 100 euros de croquettes, qui sont membres du site depuis plus d'un an. Décomposée en 2 stories En tant que maître, je cherche les ancêtres de mon chien (sans vérifier les droits). En tant que maître, je n'accède à la recherche des ancêtres que si j'ai les droits pour cela. 12

13 Techniques de décomposition Technique 3 : selon exigence fonctionnelle ou non fonctionnelle Exemple de story à décomposer Une story de recherche nécessitant une performance plausible Décomposée en 2 stories Une première qui a pour but de fournir les résultats Une autre qui a pour but d'optimiser la recherche pour afficher les résultats en moins de deux secondes 13

14 Tests pour accepter les stories Principe Les tests d'acceptation sont nécessaires pour les stories réalisées avec du code. Orientation développeur Guide pour le développe ment Pilotage par tests unitaires (TDD) Pilotage par les tests d'acceptation (ATDD) Autres tests Boîte blanche Autres tests Boîte noire Critique du développe ment Orientation client 14

15 Une story et ses tests Principes de base 1 Une user story doit posséder au moins une condition d'acceptation. 2 A cette condition, sont associés un ou plusieurs tests. 3 Un test d'acceptation décrit l'exécution de la story. Remarque : Un nombre trop important de tests signifie que la story a une trop grande complexité il vaut mieux la décomposer 15

16 Définition d'un test Méthode BDD (Behavior Driven Development) Chaque test est formalisé avec trois rubriques : L'état de l'application avant l'exécution du test L'événement qui déclenche l'exécution de la story L'état de l'application après l'exécution Formalisme : Given WhenThen Etant donné un maître de chien de race Quand le maître inscrit son chien à une confirmation Alors il est informé de son inscription 16

17 Etapes pour accepter la story Quelques conditions Bac de départ Assez pour sprinter Bac de culture Sprint Tous les tests vérifiés Bac de récolte Tous les tests définis 17

18 Quand passer les tests? Principes de base L'équipe doit partir des tests d'acceptation pour concevoir et coder la story. Pendant le développement, il est fréquent que des tests soient modifiés et complétés, voire que de nouveaux tests soient ajoutés. A chaque nouveau build, pour éviter les régressions, il conviendrait donc de repasser tous les tests (ou la submit test suite) Intégration continue 18

19 Automatisation des tests? Objectif A la première itération, on passe T1 tests. A la deuxième, on passe T2 nouveaux tests. On suppose que le nombre moyen de tests par itération est Ti, Total = Ti x n x (n+1) / 2 Remarque : l'automatisation a un coût, vérifier si c'est rentable ou pas! 19

20 Quelques conseils Faire des tranches verticales En référence aux architectures en couches Vertical = à travers toutes les couches Ex. de l'ihm jusqu'à la base de données Le test n'est plus une phrase Forget about your Gantt diagram, dude! Se servir des tests pour communiquer! Pont entre le métier et le développement Rendre explicite le travail de test 20

21 Plan de tests à multi-dimensions Dimension "story" (quoi tester?) Tester pour accepter les user stories Relier les stories dépendance? Ainsi que les features Dimension "type" Test unitaires : réalisés par les développeurs, souvent longs, fastidieux, donc automatisés Tests fonctionnels : une plus grande granularité que les tests unitaires, automatisable ou non. Tests de performance : tests non fonctionnels Tests de scénarios : véritables tests d'un point de vue de l'utilisateur 21

22 Plan de tests à multi-dimensions Dimension "temps" La date et la fréquence de tests Dimension "stratégie" Qui écrit et effectue les tests? En cas de "K.O.", que faire? Dimension "environnement" Définir une configuration Remarque : le plan de test est bien un document évolutif qui doit être mis à jour sans arrêt. 22