---
# System prepended metadata

title: Proposition de nouvelles pratiques de code/review

---

# Proposition de nouvelles pratiques de code/review

## Un processus de revue plus naturel et efficace

> Plutôt que de commenter les changements souhaités, les effectuer directement dans un commit bien séparé. L'auteur reverra ensuite ces changements, itérera éventuellement à nouveau et ainsi de suite jusqu'à convergence du code.

Les + :

- les deux protagonistes auront au moins une aussi bonne (quand elle ne sera pas meilleure) compréhension du code qu'avec la méthode traditionnelle ;
- gains de temps à plusieurs niveau :
  - on passe de deux envois de balle par itération à un seul (OP → reviewer → OP à OP → reviewer) ;
  - il est parfois plus simple de coder directement la solution que de l'expliquer en langague naturel. Si une explication / justification reste nécessaire alors c'est que l'implémentation ne se suffit pas à elle-même et mérite d'être commentée.


Les - :

- ???


## Démarrer les tâches comme elles se terminent : à deux

> Commencer en pair programming les tâches un petit peu complexes, puis laisser une seule personne la finir avant se réunir pour la review.

Les + :

- ce que l'ont conçoit bien s'énonce clairement, devoir partager la tâche force à la comprendre en profodeur ;
- c'est du rubber duck implenting en mieux car le camarade palmipède a une capacité de réponse critique ;
- celui qui n'a pas le clavier sera le reviewer et sera plus efficace dans ce rôle que si il découvrait tout au moment de commencer la revue. Ce processus se marie très bien avec celui présenté dans la section précédente ;
- pendant que l'implémenteur termine la réalisation, le challan s'en détache et prend du recule en vacant à ses occupations. Le projet mûrit ainsi différement ce qui sera bénéfique au moment de la review (ou avant si un idée lumineuse surgit d'un fond de pensées brumeuses).

Les - :

- il peut être difficile de détecter le moment où il faut arrêter le pair programming pour qu'une seule personne se concentre sur l'implémentation ;
- la définition des tâches méritant de suivre ce processus peut ne pas être évidente. Mieux vaut probablement en faire trop que pas assez au début. Une première approche pourrait être dès que l'une des conditions suivante est remplie :
    - le ticket est noté 8 ou plus,
    - l'implémentation ne découle pas directmeent du ticket,
    - il s'agit d'une tâche d'investigation,
    - à compléter...


# Propositions pour fluidifier l'organisation

## Ticketisation

Au moment de la création du ticket :

- le noter unilatéralement ;
- détailler son implémentation, pas simplement l'objectif.

Avant la review du ticket :

- chacun parcourt individuellement les tickets à traiter ;
- chacun peut augmenter la note d'un ticket, la baisser est interdit ;
- chacun peut augmenter la priorité d'un ticket, la baisser est interdit.

Pendant la review du ticket :

- si le ticket n'est pas clair, ne pas se contenter d'une explication orale. Ce qui n'est pas écrit doit être considéré comme vain, les tickets passant parfois plusieur sprints dans le backlog ;
- si quelqu'un juge la note trop basse, qu'il se manifeste ;
- si quelqu'un juge la note _vraiment_ trop haute, qu'il se manifeste (pour des écrat supérieurs à 3 points uniquements) ;
- les tickets sans priorité sont ignorés.

## Scrum / objectifs

- les objectifs sont annotés en amont de leur revue avec ce qui a été fait pendant le sprint, les nouvelles pistes accompagnent le document et sont documentées. Thomas en prend connaissance avant tout réunion ;- Thomas et Franck font un point général avant la revue avec tout le monde. Cette dernière peut d'ailleurs ne pas être jugée nécéssaire à la suite de l'entrevue.
- sont abordés lors de la revue uniquement les questions et les nouveaux objectifs.

## Instauration du "Cleanup day"

Un journée tous les deux sprints consacrée uniquement à de la qualité. Chacun est libre de travailler sur la partie du code de son choix.

## Instauration du "PoC day"

Un journée tous les deux sprints où chacun est libre de travailler sur ce qu'il veut, l'idéal étant un PoC rapide. Si ce jour est commun à toutes les équipes c'est encore mieuxc cela se rapproche d'un mini-hackathon interne.

Il est conseillé de prévoir à l'avance ce qui sera fait ce jour là pour éventuellement former de mini-équipes.


## Diminuer la fréquence et / ou la durée des dailys

Les ticket s'étalant souvent sur plusieurs jours il n'est pas toujours pertinent de se réunir de manière quotidienne, surtout après la reprise en présentielle. Deux ou trois fois par semaine serait preobablement suffisant. Il ne faut cependant pas hésiter à demander à parler aux autres membre de l'équipe.

Instaurer un temps de base : l'intervention de chacun ne doit pas durer plus de deux minutes. Des précisions peuvent être données une fois que tout le monde a parlé si cela est jugé nécessaire. Préparer ce que l'on va dire peut aider.
