Exemple contrat agile

756 vues

Publié le

Exemple de contrat agile expliqué sur notre blog : https://www.logilab.org/blogentry/294046

Ce PDF est un exemple de contrat mis en place par Logilab, légèrement anonymisé. Il rappelle quelques éléments d'agilité et définit :

le cycle de développement (itération, recette, etc)
les livrables et environnements
le mode de fonctionnement avec notre extranet de suivi (une variante de cette forge)

Miroir du PDF sur https://www.logilab.org/file/294042/raw/Exemple%20contrat%20agile.pdf

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
756
Sur SlideShare
0
Issues des intégrations
0
Intégrations
3
Actions
Partages
0
Téléchargements
12
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Exemple contrat agile

  1. 1. Le contrat agile sur mon super projet Par Logilab, le 6 mai 2015
  2. 2. Niveau 0 Qu'est ce qu'on fait là ? 2
  3. 3. Objectif Logilab aide les partenaires à développer un logiciel Les partenaires sont représenté par le Comité de Projet (COPROJ) parmi lesquel figure un Product Owner (PO) Le logiciel consiste en un truc qui fait ceci et cela afin d'être formidable “ 3
  4. 4. Niveau 1 Ça commence quand ? Ça finit quand ? 4
  5. 5. Ticket / User Story ? • Une US est une définition haut-niveau d'un besoin • Son implémentation est effectuée en une ou plusieurs tâches mesurables, exprimées par des tickets • Logilab et le COPROJ définissent ensemble les US et tickets 5
  6. 6. Ticket / User Story » Les US sont numérotées et décrites dans des tickets du sous-projet "mon- projet-us" » Les tickets y sont liés via la relation est une dépendance de 6
  7. 7. Recette ? • Après une livraison, il faut valider son contenu • Le contenu a été précédemment défini dans une version, qui contient des tickets • La livraison est présentée par Logilab au COPROJ, qui procède ensuite à sa recette 7
  8. 8. Recette -détail Un ticket est validé (ou non) par les membres du COPROJ » Chacun ajoute sur le ticket l'étiquette <login>_okou <login>_ko » Le COPROJ passe le ticket dans l'état validéou rejetté(avec création d'un nouveau ticket décrivant les points à revoir / corriger dans ce cas) Le COPROJ peut également créer des tickets pour les idées / points à discuter générés par la recette 8
  9. 9. Recette -agenda • La livraison et sa présentation ont lieu pendant la réunion du mardi du COPROJ • Les membres du COPROJ sont alors invités à faire leur recette individuelle • Lors de la réunion du vendredi le COPROJ finalise la recette - Logilab ne fait rien avant et n'est pas censé avoir besoin d'aller repêcher des infos ailleurs que dans les nouveaux tickets 9
  10. 10. Definition of done? • Critères objectifs devant être présents pour considérer la tâche ou une US comme faite • Contrat entre le développeur et le client, définissant dans l'idéal la procédure de recette de la fonctionnalité • Peut être établit par ticket ou par US 10
  11. 11. Definition of done Logilab et le COPROJ se mettent d'accord sur la définition de fait d'une US ou d'un ticket » Le développeur passe le ticket dans l'état fait » Les membres du COPROJ ajoutent une étiquette <login>_ok 11
  12. 12. Definition of validé Tous les membres du COPROJ ont effectué leur revue et émis un avis positif » Lors de la revue finale le COPROJ passe le ticket dans l'état validé 12
  13. 13. Niveau 2 Comment on fait ? 13
  14. 14. Backlog? • Le backlog constitue la réserve de choses à faire, au cas où on manquerait... • Il est constitué d'US prêtes et d'autres plus ou moins bien définies • Il est bon d'avoir une ou deux itérations de tickets/US prêtes en stock 14
  15. 15. Backlog Logilab et le COPROJ alimentent en continue le backlog Des ateliers peuvent être dédiés au travail sur le backlog » Le backlog est constitué de l'ensemble des tickets dans l'état ouvertet non affectés à une version 15
  16. 16. Definition of ready? • Un ticket est prêt quand le périmètre fonctionnel et la définition de fait sont assez clairement définis pour que Logilab fasse une estimation du coût - et que c'est fait ! • Une US est prête quand l'ensemble des tickets qui la constituent sont prêts 16
  17. 17. Definition of ready Logilab et le COPROJ décident quand une US ou un ticket est prêt » On ajoute l'étiquette readyà l'US ou au ticket 17
  18. 18. Sprint Planning? • Avant le lancement du sprint d'une itération, il faut décider de son contenu • On sélectionne parmi les tickets prêts, selon un volume spécifié par Logilab 18
  19. 19. Sprint Planning Logilab crée une version correpondante à l'itération » Logilab et le COPROJ sélectionnent ensemble les tickets parmi ceux avec l'étiquette readydu backlog en les affectant à la version correspondante 19
  20. 20. Estimation • Logilab évalue le coût en indice de difficulté : étiquettes size_S(1), size_M(2), size_L(3), size_XL(5) et size_XXL(8) • Logilab calcule en fin d'itération la vélocité en fonction du volume de jours consommés et du nombre de tickets faits (voir les coefficients entre parenthèses) • Logilab pourra ainsi estimer le volume sur lequel s'engager à la prochaine itération en fonction du volume de jours disponibles estimé 20
  21. 21. Sprint • Logilab travaille à l'implémentation pendant 3 semaines consécutives • Le PO reste à disposition pour répondre à d'éventuelles demande de précisions • Chaque sprint est suivi d'une semaine de recette • Logilab reste à disposition pour répondre aux questions et corriger d'éventuels problèmes bloquants 21
  22. 22. Gestion des commandes • Lors du sprint planning, Logilab fournit le nombre de jours consommés lors de l'itération précédente et une estimation du nombre de jours disponibles pour l'itérations à venir (par poste) • Une commande est passée sur la base de l'estimation et du nombre de jours à rattraper sur l'itération précédente (positif ou négatif) 22
  23. 23. Suivi Logilab fait voeux de transparence ! » État fait ou non d'un ticket » Indicateur d'avancement de la version » Indicateur de consommation de la commande » Visibilité des développements » Réunion de suivi hebdomadaire 23
  24. 24. Niveau 3 On oublie rien ? 24
  25. 25. Environnement de démonstration Description précise de l'environnement de démonstration : version des différents composants, configuration du serveur et qui l'héberge 25
  26. 26. Environnement de validation Description précise de l'environnement de validation : version des différents composants, configuration du serveur et qui l'héberge 26
  27. 27. Livrable Description précise des livrables et des moyens de mise à disposition 27
  28. 28. Livraison • La version passe dans l'état publié • tag dans l'entrepôt de code source • Mise à disposition des livrables : code source uniquement tant que l'environnement de production n'est pas défini • Installation dans l'environnement de démonstration • Mise à disposition des livrables 28
  29. 29. Cycle • Sprint ponctué par une présentation de la livraison le mardi • Recette par les membres du COPROJ jusqu'au vendredi, où il valide la livraison et décide des grandes lignes de l'itération suivante • Le lundi, Logilab et le PO préparent le backlog pour l'itération suivante • Sprint planning de l'itération suivante sur site le mardi après-midi suivant • C'est reparti ! 29
  30. 30. Évènements particuliers • Rétrospectives : on fait le point sur une période de temps passé (réunion, itération(s)...) afin de voir ce qui s'est bien et mal passé et agir en conséquence par la suite • Ateliers de travail : on discute de points particuliers nécessitant un peu plus de temps / concentration (éléments du modèle de données, alimentation du backlog, etc.) • Jalon : on se met d'accord sur un objectif à viser à moyen terme (5 / 6 mois) 30

×