Accueil
Redmine nous aide à tracer les modifications sur vos développements et à fluidifier nos échanges.
1. Présentation¶
A chaque nouvelle demande de développement, un projet est créé sur Redmine pour y recenser l’ensemble des demandes concernant le développement. Un compte sera créé (user + mot de passe) pour le client si c’est sa première utilisation de la plateforme, qui lui permettre de se connecter et faire ses demandes.
Il y a trois profils d’utilisateurs sur Redmine qui correspondent aux trois partis engagés dans le développement
• Rapporteur : interlocuteur principal en charge du projet chez le client
• Manager : responsable Cegid en charge du projet
• Développeur : personne (ou équipe) en charge du projet côté développement
Le rôle de chaque profil ainsi que la procédure à suivre en cas de demande seront explicités dans ce document.
2. Création de la demande¶
Pour créer une demande, il faut se connecter sur le site redmine.cegid.fr avec les identifiants qui vous ont été fournis lors de la création de votre compte (mail de redmine).
Ensuite il faut cliquer sur le « + » à côté d’aperçu et choisir « nouvelle demande ».
Tracker
Il y a 3 types de demandes différentes :
• Anomalie : correspond à un dysfonctionnement de l’application par rapport aux spécifications définies lors de la signature du contrat,
• Evolution : correspond à un ajout ou une modification des spécifications concernant le projet. Les évolutions peuvent entraîner l’émission d’un devis complémentaire,
• Assistance : correspond à un recours à Cegid pour une question relative au projet.
Sujet
Le sujet de la demande doit être précis et ne concerner qu’un seul point des spécifications pour faciliter le suivi. En cas d’anomalies multiples, il faut poster plusieurs demandes.
Ex : lors d’un export csv, il y a 3 champs vides alors qu’un mapping avait été établi. Dans ce cas il faut créer trois anomalies (une pour chaque champ).
Description
La description doit être la plus précise possible pour que le problème soit compréhensible.
Si possible, il faut expliciter la valeur obtenue et la valeur que l’on doit avoir.
Statut
Lors de la création de la demande, il faut laisser le statut à nouveau.
Comme détaillé plus loin, il évoluera au cours du traitement de l’anomalie.
Priorité
Il y a cinq niveaux de priorité en fonction de la gravité de l’erreur :
• Bas : correspond à un détail dans le développement et n’entrave pas le fonctionnement du programme (ex : modification du nom d’un bouton ou de l’aspect visuel).
• Normal : correspond à une erreur n’empêchant pas le programme de tourner (ex : export de la mauvaise valeur pour un champ)
• Haute : correspond à une erreur bloquante empêchant le programme de s’exécuter complètement.
Les demandes sont traitées en fonction de leur niveau de priorité. Une analyse est faîte pour vérifier que le niveau de priorité choisi est le bon.
Assigné à
Lors de la création de la demande, il faut l’assigner à la personne responsable du projet chez Cegid.
L’assignation est ensuite de la responsabilité du responsable projet Cegid.
Fichiers
Pour faciliter le traitement de la demande, il est important que le développeur puisse comprendre l’erreur et la reproduire. Pour cela tous les fichiers utilisés ou produits par le programme sont à envoyer :
• Fichier d’export produit : permet d’identifier ce que le programme donne en sortie de traitement avant la correction,
• Fichier LOG : permet d’identifier les erreurs remontées par le programme,
• Table de correspondances/copie écran des options : permet de rproduire l’erreur en lançant le programme dans des conditions identiques à celle du client.
3. Suivi d’une demande : de la prise en charge à la fermeture¶
Analyse de la demande côté Cegid
Une fois la demande créée, le responsable du projet chez Cegid l’analyse sur différents critères :
• Type de demande (tracker) : est-ce une anomalie ou plutôt une évolution ?
• Description et fichiers : les informations présentes sont-elles suffisantes pour comprendre le problème et le résoudre ?
• Priorité : la priorité choisie est-elle en concordance avec le problème ?
Si la demande est validée, le manager modifie la demande :
• Statut : reste « nouveau »
• Assigné à : l’assignation passe au développeur qui recevra un mail pour le prévenir d’une demande
• Notes : un message peut être ajouté pour donner plus de détail au développeur si nécessaire
Si la demande est incomplète, le manager modifie la demande :
• Statut : devient « commentaire »
• Assigné à : l’assignation passe au rapporteur côté client qui recevra un mail pour le prévenir d’une demande
• Notes : un message sera ajouté pour demander des informations supplémentaires au client
Prise en charge côté Développeur
Quand la demande est validée, le développeur reçoit un mail l’avertissant qu’une demande lui a été assignée.
Il réalise une analyse complémentaire à celle de Cegid pour voir s’il dispose des informations nécessaires.
Si la demande est complète, il doit avertir le responsable projet de Cegid :
• Statut : devient « en cours », sauf correction immédiate, voir plus loin.
• Assigné à : ne bouge pas.
• Echéance : si le développeur ne peut pas corriger immédiatement la demande, il doit donner une échéance pour que les autres parties aient connaissance du délai de résolution de la demande.
Si la demande est incomplète, il doit envoyer une demande d’informations complémentaires à la personne concernée :
• Statut : devient « commentaire »
• Assigné à : le responsable projet Cegid ou le client, en fonction de la demande
• Note : un message sera ajouté pour demander des informations supplémentaires
Une fois l’anomalie reproduite et corrigée, il faut avertir le responsable coté Cegid :
• Statut : devient « résolu »
• Assigné à : le responsable projet Cegid
• Note : un message peut être ajouté pour expliquer d’où venait le problème
Validation de la correction coté Cegid
Après correction de l’anomalie par le développeur, le manager du projet reçoit un mail le notifiant que le point a été résolu.
Il doit alors tester le programme que lui aura envoyé le développeur.
Si la correction est validée :
• Statut : reste « résolu »,
• Assigné à : le rapporteur coté client,
• Note : un message peut être ajouté pour donner des explications ou des consignes.
Si la correction n’est pas validée, la demande est renvoyée au développeur :
• Statut : devient « commentaire »,
• Assigné à : l’assignation repasse au développeur qui recevra un mail pour le prévenir d’une demande,
• Notes : un message sera ajouté pour expliquer ce qui ne va pas.
Analyse des retours côté Client
Lors du traitement de sa demande, le client est amené à recevoir plusieurs notifications de la part de Cegid et/ou du développeur, pour compléter la description de l’incident.
Quand la demande est renvoyée pour manque d’information il faut revoir la demande :
• Statut : reste « commentaire »,
• Assigné à : le responsable projet Cegid ou le développeur, en fonction de la demande,
• Note : un message sera ajouté pour donner les informations supplémentaires nécessaires à la résolution de la demande,
• Fichiers : des fichiers peuvent être joins si nécessaire.
Fermeture d’une demande
Une fois la demande résolue, le client sera notifié par un mail. Le cas échéant, il recevra en parallèle un mail d’ULDL lui permettant de télécharger la nouvelle version de son programme.
Des tests devront être faits pour vérifier si la correction correspond à la demande.
Si les tests sont concluant, il faudra passer le statut de la demande à « fermé » pour signaler que le problème est résolu.
Si les tests ne sont pas concluants, il faudra avertir le responsable Cegid :
• Statut : devient « commentaire »
• Assigné à : le manager Cegid
• Note : un message sera ajouté pour expliquer en quoi la demande n’est pas résolu
• Fichiers : des fichiers peuvent être joins si nécessaire