tâche projet.audit¶
résumé: | L’objectif de cette tâche est (1) de préparer l’audit, (2) de réaliser cet audit, puis (3) d’en faire la synthèse. |
---|---|
artefacts: |
|
Introduction¶
L’objectif d’un audit est de faire le bilan, le plus objectif possible, des résultats obtenus pendant un incrément ainsi que du processus méthodologique menant à ces résultats.
Il s’agit pour l’équipe de développement d’indiquer :
- ce qui a été fait, doit être amélioré, reste à faire,
(se baser sur les fichers
status.md
), - quels résultats ont été produits,
- quelles tâches ont été réalisées,
- quelles difficultés ont été rencontrées,
- quels empêchements bloquent ou freinent l’avancée du projet.
Il ne s’agit pas de “vendre” ce qui a été fait en en exagérant les mérites, mais plutôt de convaincre que ce qui a été fait est solide et que l’équipe est suffisemment fiable pour mériter l’octroi des ressources nécessaires à un nouvel incrément.
L’objectif de l’audit lui-même est d’intéragir avec le comité d’audit, de l’informer, mais aussi de recueillir les recommandations émises afin d’établir un rapport d’audit suivi d’actions précises.
Note
En Scrum le “sprint review” et la cérémonie correspondant le plus aux audits.
(A) Transparents¶
Chaque audit est basé sur une présentation effectuée à base
de transparents. La dernière version doit être convertie en fichier
.pdf dans projet/sprint<N>/audit/audit.pdf
(B) Contenu¶
La présentation doit être basée sur :
- les différentes captures d’écran réalisées au cours du sprint (plannings, diagrammes de classes, tableau GitHub etc.),
- les différents fichiers produits pendant le sprint,
- les différentes tâches ModelScript réalisées.
Il doit être possible, pour chaque transparent, de savoir à quel artefact et/ou quelle tâche, le transparent fait référence. Voir la section “Traçabilité” ci-dessous.
Si une rétrospective récente à eu lieu faire part des résultats de cette rétrospective dans la présentation.
(C) Suivis¶
Les éléments du modèle de suivis doivent être utilisés dans la présentation
pour montrer quelles décisions ou hypothèses ont été faites, quelles
questions sont à l’ordre du jour et quels empéchements ont freiné le
projet. Faire référence à chaque suivi par son identifiant (par
exemple Q3
) et par son titre.
(D) Glossaire¶
Les transparents doivent impérativement faire référence aux termes du glossaire. Lorsque possible utiliser les backquotes “`” pour faire référence à ces termes.
(E) Traçabilité¶
Chaque transparent, chaque élément de présentation doit faire référence,
autant que faire se peut, aux entités définies dans les modèles ou plus
généralement dans le projet. Faire référence aux scénarios (p.e. S1
),
aux incréments (p.e. I3
), aux questions (p.e. Q2
),
aux tâches (p.e. concepts.glossaires
), aux issues
GithHub (p.e. #12
), etc. Faire référence aux
artefacts par leur nom court (p.e. classes.cl1
).
Attention
La possibilité d’identifier de manière précise “de quoi parle” chaque transparent, chaque phrase, chaque image est un critère important d’évaluation. Chaque transparent devrait donc comporter plusieurs voire de nombreuses références.
Il peut être utile, mais pas indispensable ni facilement faisable, de donner un document à l’auditoire indiquant à quoi correspondent les références principales. Dans tout les cas, quelqu’un lisant les transparents avant ou après la soutenance devrait pouvoir retrouver tous les éléments cités.
(F) Présentation¶
Lors de la présentation effective, c’est la dernière version des transparents sur GitHub qui doit être présenté.
Pendant la présentation chaque membre du groupe doit parler et répondre aux questions qui lui sont posées (les questions peuvent être “nominatives”)
Un ou deux “secrétaires” doivent être nommés afin de prendre des notes tout au long de l’audit. Il peut être intéresant d’avoir deux secrétaires pour avoir “plus de notes”. Ce peut être utile lors d’échanges rapides avec l’auditoire. Le deuxième secrétaire est là aussi pour se substituer au premier lorsque celui-ci intervient.
Les notes prises pendant l’audit serviront de résumé d’audit.
Attention
Perdre des informations ou remarques faites pendant l’audit est une faute grave. Aucun client n’apprécie d’avoir à redire une fois de plus ce qui a été déjà dit lors d’une précédente réunion. Cela démontre un manque de professionalisme.
(G) Démonstration¶
Une démonstration du produit pendant l’audit est la bienvuenue. Cependant une telle démonstration n’a pas de caractère obligatoire.
Se reporter à la section
Démonstration de la tâche
projet.soutenance
pour plus de détails sur la manière d’organiser
une présentation.
Note
Les démonstrations d’audits n’ont pas le caractère formel que l’on trouve dans la démonstration de soutenance. Certains élements mentionnés pourront donc être simplifiés.
Si une démonstration est faite pendant une audit et qu’une autre démonstration a été faite précédemment, il est judicieux de montrer de manière explicite les différences entre les fonctionnalités successives. Ceci peut se faire sous la forme de phrases comme “Avant ici il y avait …”.
(H) Documents¶
Il peut être utile (mais en général pas nécessaire) de distribuer aux membres du comité d’audit des documents. C’est le cas notamment si certains transparents sont difficilement lisibles (p.e. les diagrammes de classes ou modèles de tâches).
(I) Compte rendu¶
Après l’audit faire tout d’abord un débriefing entre les membres de l’équipe.
Etablir ensuite un compte rendu faisant état des principales remarques faites lors de l’audit, suivies des actions à entreprendre. Le compte rendu d’audit doit se faire immédiatement après l’audit, au moins pour la partie “remarques effectuées”.
Le compte rendu doit être réalisé sous forme de texte dans le fichier
projet/sprint<N>/audit/resume.md
. Il peut s’agir simplement
de quelques lignes. Utiliser un style télégraphique,
une liste de points. Il ne s’agit pas d’un document formel mais simplement
d’un mémo principalement à destination de l’équipe. La forme n’est pas
primordiale mais le contenu est par contre particulièrement important
car c’est lui qui défini l’orientation du prochain sprint.
Attention
Si des décisions importantes ont été prises, les consigner dans le
fichier suivis/suivis.trs
.