InfoQ 2 : Manifesto of done

2ème article sur InfoQ

A Manifesto of done

Alixx Skevington propose une "liste de critères", que je considère plus comme une liste de vœux ou de souhaits:

Je vais faire en sorte que mon code soit utilisable
Je vais faire en sorte d'écrire du code conforme au style défini par l’équipe
Je vais faire en sorte que mes méthodes soient de taille raisonnable
Je vais commenter tout mon code
Je suis d’accord pour tester mon code (Tests unitaires)
Je suis d’accord pour maintenir mes tests unitaires sur le code existant
Je suis d’accord d’essayer de maintenir une couverture de code à 80%
Je suis d’accord pour vérifier que mon code s’intègre correctement

S’en suivent quelques commentaires rajoutant ça et là de nouvelles règles.
De « Je vais repasser mes tests unitaires avant de commiter »
jusqu’à, à propos des commentaires de code « …, les commentaires mentent, … »

Mais ça veut dire quoi code utilisable ?
Conforme au style défini par l’équipe, c’est checkstyle ?
Les tests unitaires, quelle stratégie ? On teste tout, et on essaye de le maintenir.
La couverture à 80%, pourquoi ? Les 20% qui restent ne servent pas, n’ont pas de plus value au produit ? Le temps de définir quelles exigences font parties de ces 80%, n’aurait-on pas mieux fait de tout couvrir ?

Le fait que ces bons vœux ne sont pas précisément définis, va engendrer surcharge de travail pour essayer de contrôler la bonne tenue de ces critères.

Mais c’est pas du bon sens tout ça, voir même « nominal » pour tout développeur qui se respecte et respecte les autres membres de l’équipe avec qui il travaille.

Jay Packlick remet de l’ordre :
« Tout critère d’acceptance définissant le ‘done’ pour une feature doit être exprimé en tests et être passé ».