• Gestion des demandes entrantes
  • Dans le courant du sprint
    • Pendant les mêlées quotidiennes
    • Tri des demandes
    • Assistances
    • Anomalies urgentes
    • Anomalies non urgentes ou demandes d’évolution
  • Pendant la réunion de préparation des releases

Gestion des demandes entrantes¶

Il existe deux types de demandes entrantes :

• Les demandes des utilisateurs : elles sont obligatoirement dirigées dans le tracker Demandes.
• Les demandes de l’équipe EOLE : elles sont rédigées et placées dans le tracker Proposition de scénario avec le status En rédaction jusqu’à sa formalisation complète.

À tout moment du processus :

• L’équipe peut solliciter le scrum master et le product owner afin de déterminer la pertinence d’une demande
• une demande peut être classée sans suite ou fermée avec le status pas un bug, dans quel cas le processus cesse pour cette demande

Dans le courant du sprint¶

#FIXME# expliquer les sprints à destination des utilisateurs

Pendant les mêlées quotidiennes¶

#FIXME# expliquer les mêlées à destination des utilisateurs

• 1^er tour: Ce que j’ai fais la veille (y compris les demandes entrantes traitées = information à l’équipe)
• Avant le 2^e tour : visualiser les Demandes non affectées afin que toute l’équipe en prenne connaissance
• 2^e tour : Ce que je vais faire aujourd’hui: auto-assignation des demandes du tableau des tâches et entrantes
• 3^e tour : Les problèmes que je rencontre, notamment les doutes sur la gestion d’une demande et la sollicitation d’aide pour la gérer. (ATTENTION: On ne gère pas la demande pendant cette phase, on demande de l’aide).

Tri des demandes¶

Chaque membre de l’équipe trie ses Demandes en fonction des critères suivants :

• Assistances : aide à la mise en œuvre ou la maintenance des solutions EOLE
• Anomalies
  • Urgentes : régressions graves empêchant le fonctionnement des solutions EOLE
  • Non urgente : ce sont les demandes qui causent une régression ou ne sont pas conformes aux exigences.
• Évolutions : toutes les autres demandes.

RACCOURCI pour les demandes rapides à effectuer : Si la charge du sprint le permet, les anomalies non urgentes et les évolutions peuvent être intégrées au scénario Traitement express, présent dans chaque sprint.

Assistances¶

Un scénario Assistance aux utilisateurs, présent dans chaque sprint, accueille les demandes d’assistances ouvertes par les utilisateurs.

Leur processus de tri est terminé.

Anomalies urgentes¶

Un scénario Traitement express, présent dans chaque sprint, accueil les régressions graves empêchant le fonctionnement des solutions EOLE.

Leur processus de tri est terminé.

Anomalies non urgentes ou demandes d’évolution¶

ATTENTION: aucun scénario ne peut être créé pendant cette phase.

Chaque membre de l’équipe :

• Renseigne la catégorie :
  • version mineure : Pour les demandes ne changeant pas le comportement par défaut de la distribution et impliquant peu de changements fonctionnels.
  • version majeure : Pour les demandes impliquant de gros changements fonctionnels.
• Déplace la demande dans le service principal concerné.
• Gère la proposition de scénario :
  • S’il existe un scénario dans le tracker Scénario correspondant à la problématique de la demande
    • Le membre de l’équipe met la demande dans le tracker Tâche
    • Créé une demande dans le tracker Proposition de Scénario
    • Lie la demande à cette proposition de scénario
    • Dans la description de la proposition de scénario faire une référence au scénario initial.
  • S’il existe un scénario dans le tracker Proposition de scénario correspondant à la problématique de la demande :
    • Le membre de l’équipe met la demande dans le tracker Tâche
    • Défini cette proposition de scénario comme tâche parente
    • Éventuellement il met à jour la description de la proposition de scénario.
  • S’il n’existe pas de scénario correspondant à la demande, le membre de l’équipe met la demande dans le tracker Proposition de Scénario :
    • Éventuellement modifier le titre, il doit être :
      • Une action positive
      • Ne comprenant pas le nom d’un produit
      • Ni une solution au problème
      • Ni trop descriptif (« je ne peux pas lister les répertoires » devrait être « les répertoires doivent être listables »)
    • Les exigences doivent être spécifiées dans la description du scénario :
      • Si l’exigence existe dans squash il faut noter la référence dans la description
      • Si elle n’existe pas, il faut ouvrir une demande de création d’exigence (ne pas la créer directement dans squash, elle doit être approuvée)
    • Le membre de l’équipe créé les tâches associées au scénario et estime le temps pour chacune d’elle.

A la fin du sprint, le tracker Demande est vide.

Pendant la réunion de préparation des releases¶

En cours de sprint, une période est réservée à la préparation des releases. Actuellement cette réunion a lieu le vendredi après-midi de fin de sprint.

• Gestion des propositions de scénarios par l’équipe :
  • Les Proposition de Scénario associés à un scénario existant sont supprimés. Les tâches sont liées au scénario d’origine.
  • Les Proposition de Scénario pertinentes pour une release programmée sont déplacées dans le tracker Scénario. Le scénario entre dans le Backlog.
  • Les Proposition de Scénario non pertinentes pour une release programmée sont déplacés dans le tracker Bac à idées.
• Gestion du bac à idées par l’équipe : les demandes pertinentes pour une release programmée sont déplacées dans le tracker Scénario. Le scénario entre dans le Backlog.
• Gestion des demandes entrantes en souffrance : l’équipe détermine avec le product owner la suite à donner aux demandes restantes s’il y en a.

Les demandes du Backlog sont évaluées en points par l’équipe. Les demandes du Backlog sont placées dans une release par l’équipe (les catégories version majeure et version mineure des tâches du scénario est une indication pour connaître la release).

Les releases sont créées si elles n’existent pas.

A la fin de la réunion, les trackers Demande et Proposition de Scénario sont vides.