Distribution EOLE

{{toc}}

h1. Gestion des demandes entrantes

Il existe deux types de demandes entrantes :

* Les demandes des utilisateurs : elles sont *obligatoirement dirigées* dans le tracker "*Demandes*":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?query_id=108.

* Les demandes de l’équipe EOLE : elles sont rédigées et placées dans le tracker "*Proposition de scénario*":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?query_id=70 avec le status "*En rédaction*":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?query_id=189 jusqu’à sa [[Gestion_des_demandes_entrantes#Anomalies-non-urgentes-ou-demandes-dévolution|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

h2. Dans le courant du sprint

#FIXME# expliquer les sprints à destination des utilisateurs

h3. Pendant les mêlées quotidiennes

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

* *1<notextile></notextile>^er^ tour*: Ce que j’ai fais la veille (y compris les demandes entrantes traitées = information à l’équipe)

* *Avant le 2<notextile></notextile>^e^ tour* : visualiser les "*Demandes*":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?query_id=108 non affectées afin que toute l’équipe en prenne connaissance

* *2<notextile></notextile>^e^ tour* : Ce que je vais faire aujourd’hui: *auto-assignation* des demandes du tableau des tâches et entrantes

* *3<notextile></notextile>^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).

h3. Tri des demandes

Chaque membre de l’équipe trie ses "*Demandes*":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?query_id=108 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.

h3. Assistances

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

Leur processus de tri est terminé.

h3. 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é.

h3. 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*":https://dev-eole.ac-dijon.fr/issues?query_id=187 correspondant à la problématique de la demande

*** Le membre de l’équipe met la demande dans le tracker "*Tâche*":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?set_filter=1&tracker_id=6

*** Créé une demande dans le tracker "*Proposition de Scénario*":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?query_id=70

*** 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*":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?query_id=70 correspondant à la problématique de la demande :

*** Le membre de l’équipe met la demande dans le tracker "*Tâche*":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?set_filter=1&tracker_id=6

*** 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*":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?query_id=70 :

*** É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*":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?query_id=108 est vide.

h2. 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*":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?query_id=70 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*":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?query_id=70 pertinentes pour une release programmée sont déplacées dans le tracker "*Scénario*":https://dev-eole.ac-dijon.fr/issues?query_id=187. Le scénario entre dans le "*Backlog*":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?query_id=186. 

** Les "*Proposition de Scénario*":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?query_id=70 non pertinentes pour une release programmée sont déplacés dans le tracker "*Bac à idées*":https://dev-eole.ac-dijon.fr/issues?query_id=178.

* 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*":https://dev-eole.ac-dijon.fr/issues?query_id=187. Le scénario entre dans le "*Backlog*":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?query_id=186.

* 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*":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?query_id=186 sont évaluées en points par l’équipe. Les demandes du "*Backlog*":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?query_id=186 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*":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?query_id=108 et "*Proposition de Scénario*":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?query_id=70 sont vides.