Comment rater un Sprint ?
Comment planter un sprint ? Comment faire en sorte que le dernier jour rien ne soit fait et la livraison compromise ? Voici les trois erreurs à ne pas faire qui vous garantissent une fin de sprint pressurisée :
Dès le début du Sprint, le Scrum Master demande à l’équipe de ne prendre qu’une tâche chacun à la fois dans la colonne « En cours ». Ceci limite de facto le nombre de tâches au nombre de développeurs. N’oubliez pas de définir également une règle pour la colonne « A vérifier ». Une façon simple est de la limiter également au nombre de développeur.
Ainsi, avant de prendre une nouvelle tâche, le développeur vérifiera une autre tâche si le nombre de tâches à vérifier est déjà important. Ceci évitera qu’à la fin du sprint, il n’y ai rien dans « Terminé », 50 tâches « A vérifier », etpotentiellement tout à refaire.
Pour aller dans le même sens, comment valider qu’une tâche est terminée. En développement : comment valider qu’une fonctionnalité est développée ? J’ouvre l’application sur le poste du développeur et je regarde si cela s’affiche ? Evidemment non.
Premièrement, ne demandez pas au développeur ayant développé la fonctionnalité de la tester : conflit d’intérêt. Même si ce dernier est honnête, un deuxième œil est toujours plus utile et objectif. Ensuite, définissez clairement ce que veut dire terminé : pour moi, une fonctionnalité terminée est validéetechniquement et fonctionnellement sur un environnement similaire en terme de configuration à celui de production du client. La version du serveur d’application, la taille de la JVM, le système d’exploitation, la base de données, j’en passe, doivent-être identiques à ce qui hébergera votre application en production. Dès le premier sprint, votre priorité devra être de vous munir d’un tel environnement et d’obtenir toutes ces informations.
Les fiches de tests sont également importantes, d’une part pour vous munir d’un panel de tests suffisant pour parcourir l’ensemble de la fonctionnalité développée, mais aussi en tant que livrable afin de montrer que vous avez réalisé un ensemble de test sur cette fonction. Une intégration continue bien mise en place vous aidera à optimiser les temps de tests et de déploiement.
Je l’ai observé à de maintes reprises : l’œil du développeur qui s’oriente en haut à droite lorsque pendant le point quotidien il soustrait les huit heures travailléesla veille au Reste à Faire initial pour vous donner le reste à faire actualisé. Messieurs les Scrum Master, ne vous contentez jamais du chiffre, challengez-le. Demandez ainsi un découpage du temps restant, quelles sont les actions qui le composent, et si l’engagement est pris. Avec le temps, les développeurs prennent l’habitude de ne même plus regarder le chiffre de la veille mais bien de proposer une nouvelle estimation sur la base de ce qu’ils ont réalisé la veille et de ce qu’il leur reste réellement à faire.