Gestion des demandes entrantes » Historique » Version 48
Version 47 (Daniel Dehennin, 12/01/2016 16:37) → Version 48/61 (Daniel Dehennin, 12/01/2016 16:43)
{{toc}}
h1. Gestion des demandes entrantes
Les demandes des utilisateurs sont *obligatoirement dirigées* dans le tracker "*demandes*":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?set_filter=1&tracker_id=1.
À tout moment du processus, le statut des demandes peut être mis à *"pas un bug"*, dans quel cas le processus cesse pour cette demande. #FIXME# classé sans suite?
h2. Dans le courant du sprint
#FIXME# petite intro
h3. Pendant les mêlées quotidiennes
#FIXME# expliquer le principe de la mêlée
* *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 entrantes":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 en fonction des critères suivants :
* Assistances : pouvant survenir par messages électroniques ou IRC #FIXME#
* 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 rapide à effectuer peuvent être intégrées aux sprint en cours dans le au travers du scénario *Traitement express*, présent dans chaque sprint.
h3. Assistances Assistance
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. anomalies urgentes et les demandes rapides a effectuer.
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/projects/modules-eole/issues?set_filter=1&tracker_id=5* 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?set_filter=1&tracker_id=12*
*** 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?set_filter=1&tracker_id=12* 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*
*** Lie cette demande à la proposition de scénario.
*** Éventuellement il met à jour la description du 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?set_filter=1&tracker_id=12* :
*** É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?set_filter=1&tracker_id=11* 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"* 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":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?set_filter=1&tracker_id=5*. 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":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?set_filter=1&tracker_id=8*.
* 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/projects/modules-eole/issues?set_filter=1&tracker_id=5*. 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":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?set_filter=1&tracker_id=11* et *"proposition de scénario":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?set_filter=1&tracker_id=12* sont vides.
h1. Gestion des demandes entrantes
Les demandes des utilisateurs sont *obligatoirement dirigées* dans le tracker "*demandes*":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?set_filter=1&tracker_id=1.
À tout moment du processus, le statut des demandes peut être mis à *"pas un bug"*, dans quel cas le processus cesse pour cette demande. #FIXME# classé sans suite?
h2. Dans le courant du sprint
#FIXME# petite intro
h3. Pendant les mêlées quotidiennes
#FIXME# expliquer le principe de la mêlée
* *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 entrantes":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 en fonction des critères suivants :
* Assistances : pouvant survenir par messages électroniques ou IRC #FIXME#
* 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 rapide à effectuer peuvent être intégrées aux sprint en cours dans le au travers du scénario *Traitement express*, présent dans chaque sprint.
h3. Assistances Assistance
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. anomalies urgentes et les demandes rapides a effectuer.
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/projects/modules-eole/issues?set_filter=1&tracker_id=5* 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?set_filter=1&tracker_id=12*
*** 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?set_filter=1&tracker_id=12* 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*
*** Lie cette demande à la proposition de scénario.
*** Éventuellement il met à jour la description du 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?set_filter=1&tracker_id=12* :
*** É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?set_filter=1&tracker_id=11* 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"* 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":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?set_filter=1&tracker_id=5*. 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":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?set_filter=1&tracker_id=8*.
* 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/projects/modules-eole/issues?set_filter=1&tracker_id=5*. 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":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?set_filter=1&tracker_id=11* et *"proposition de scénario":https://dev-eole.ac-dijon.fr/projects/modules-eole/issues?set_filter=1&tracker_id=12* sont vides.