L'importance du Definition Of Done

Nous voici en bilan d'itération d'une équipe agile, l'objectif du client est de valider les stories et de déterminer la vélocité de l'équipe

• "La story 30 est-elle bien terminée ?" demande le client

• "Oui mais il manque des tests Fitnesse", répond le chef de projet

• "Bon, s'il manque que les tests Fitnesse, on peut la mettre à terminé plus tard. On va voir ce que ça donne ", dit le client

• Le client teste l'application à partir de son navigateur web

• "Mais il manque la validation du champ de saisie !", s'exclame le client

• "Oui, c'est pas grave, on le fera ensuite, tu peux mettre la story en jaune, on la mettra à vert cette après-midi", dit le chef de projet

• "Bon ...", dit le client (qui commence à perdre confiance)

• "La story suivante, ..., 41, où en est-elle ?", demande le client

• "On l'a développé mais pas commité sur le serveur d'intégration, mais Marco qui est là peut te la montrer sur son poste de développement", répond le chef de projet

• "Non, mais ça va pas !", dit le client

• "C'est pareil, tu sais", dit le chef de projet

Ce genre de réunion peut vous arriver à partir du moment où l'équipe n'a pas défini ce qu'est le Definition Of Done pour elle. Sans DOD, vous pouvez rester dans le doute, le client peut perdre confiance et l'équipe peut oublier que le code doit être de qualité. Plus grave, sans DOD ou règles de qualité fixées par l'équipe, l'équipe sera limitée dans son développement et son efficacité

Exemple de DOD d'une équipe:

• > 80% de couverture de code par les tests unitaires
• Build OK sur plateforme d'intégration
• Test manuel de chaque story
• Revue de code croisée
• Fitnesse valide