L’un des grands concepts des méthodes Agile est le découpage d’un gros travail en petits lots. En Scrum, on parle de sprints, en français, des itérations. Ce mode de fonctionnement présente de nombreux avantages mais demande une grande rigueur.
Terminer les stories !
Un sprint délimite un cadre dans lequel l’équipe va s’engager sur la réalisation d’un périmètre fonctionnel défini par le product owner. Ce périmètre est délimité en fonction de la capacité de production de l’équipe de développement afin que l’objectif de l’itération soit atteignable. Il est donc primordial de figer ce périmètre lorsque le sprint à commencé !
Mais ce n’est pas chose simple. Si les livraisons et la recette se font en continu, vous verrez les testeurs et le métier vous renvoyer vos stories. On peut alors très vite perdre le contrôle et passer beaucoup plus de temps sur une story que prévu initialement. Il en va de la réussite du sprint et de l’appréciation de la qualité du travail réalisé.
J’ai pris l’habitude de demander au product owner de saisir de nouveaux tickets pour ses remarques et retours sur une story livrée. On peut alors réintroduire ces demandes dans le backlog et les traiter comme les autres stories en les priorisant et en les embarquant dans un futur sprint. A l’inverse, si les retours sont faits sur la story initiale, vous aurez beaucoup de mal à la terminer et vous avez de grandes chances de la retrouver dans le prochain sprint alors que la demande initiale a été traitée. Cela fausse tous les indicateurs. La vélocité en prend un coup et l’équipe se décourage sur ces stories qui reviennent comme des boomerangs.
Pour réussir à terminer les stories, il faut définir ce qu’on entend par « terminé ». Et Scrum a des outils pour ça : le DOD et les critères d’acceptation.
Definition Of Done (DOD)
Ce concept Agile est méconnu et trop souvent inutilisé. Il prend généralement la forme d’une checklist. Exemple :
- toutes les sous-tâches de la story sont réalisées
- le développeur a mené des tests sur son environnement de travail
- le nouveau code ne génère pas d’erreurs ou de warnings dans les logs
- le code a passé les tests de qualité
- le code a passé les tests unitaires
- le code a été mergé sur la branche de développement
- le code a été livré sur l’environnement de recette
- …
Il parle plus à l’équipe de développement qu’au product owner. Il faut évidemment l’adapter au contexte du projet. Le DOD peut être global, c’est à dire valable pour chaque story. On peut aussi le redéfinir pour l’adapter à une story.
Les critères d’acceptation
Les critères d’acceptation d’une story sont fonctionnels et exprimés par le product owner. Ils servent à formaliser dans quelles conditions il estimera que la fonctionnalité livrée correspond à la fonctionnalité demandée. Par exemple, pour une notation « 5 étoiles » :
- Sur un article pas encore noté, je vois le message « Soyez le premier à évaluer cet article ».
- Sur un article déjà noté, je vois la note moyenne attribuée à l’article, arrondie à la décimale 0.5.
- Sur un article que je n’ai pas encore noté, je peux attribuer à l’article une note de 1 à 5.
- Sur un article que j’ai déjà noté, je ne peux pas attribuer une note.
- …
On peut aussi définir des critères d’acceptation plus techniques, notamment par rapport aux performances :
- La fonctionnalité de notation « 5 étoiles » ne doit pas augmenter le temps de chargement de la page de plus de 3%.
Il est possible de travailler d’avantage sur la formalisation des critères d’acceptation afin d’en faire des tests automatisés grâce à des solutions comme Behat.
Et les tickets de retours ? On en fait quoi ?
Il est naturellement difficile de satisfaire tous les critères d’acceptation dès la première livraison. Donc le product owner va créer des tickets pour vous transmettre ses retours sur les fonctionnalités livrées. Vous allez retrouver ces demandes dans le backlog où elles doivent être traitées comme les stories initiales : priorisées, estimées et embarquées (ou pas) dans les futurs sprints.
Si vous utilisez Jira, vous avez la possibilité de créer des sous-tâches de la story pour formaliser les retours. C’est cohérent et pratique mais cela présente une contrainte : vous ne pouvez pas terminer la story tant que toutes ses sous-tâches ne sont pas terminées. Et comme on essaie de terminer les stories pour maîtriser nos sprints, c’est contre-productif…
Si ces tickets de recette sont en trop grand nombre et qu’il est trop fastidieux de les estimer, on peut réserver un « effort » à leur consacrer pendant les futurs sprints. C’est une bonne façon d’améliorer en continu la qualité du produit. On peut aussi ajouter un sprint final de recette pendant lequel on ne réalisera rien de nouveau et qu’on consacrera uniquement au traitement des retours du métier.
Terminer les sprints !
Avec un peu de rigueur et beaucoup de communication, vous parviendrez à terminer la réalisation des stories et donc à clôturer vos sprints. C’est bon pour votre équipe qui voit le projet avancer et pour le product owner qui voit son application s’enrichir. Vous aurez alors des indicateurs fiables et vous pourrez réellement mesurer la vélocité.