Parfois pour faire les choses propres en Scrum, il faut impérativement faire un freeze time afin de tester au mieux avant de faire une démo ou une mise ne production. Si le devops amène une nouvelle approche pour les démos (déploiement continue sans test humain), il faut bien comprendre que toutes les structures n’ont pas eu encore le temps de faire ce type de transformations longues et difficiles.
Nous allons voir dans cet article une méthode qui permet de combler un soucis de fluidité et/ou de tests automatisés dans les mises en production. Cependant, il faut avouer que les contextes qui imposent cette pratique du freeze time dans les équipe Scrum diminuent avec le temps ce qui est une excellente nouvelle.
Qu’est-ce que le freeze time ?
Le freeze time est en fait un laps de temps que l’ensemble de l’équipe va dédier aux tests humains afin de préparer une démonstration du produit faites généralement lors de la review et pour assurer au maximum que le produit ne sera pas buggué en production.
Lors de ce freeze time, le Product Owner (PO) testera le produit, l’UI vérifiera que tout correspond à ses demandes (si vous avez un UI) et les développeurs corrigeront tous les bugs trouvés par le PO en live ; lorsqu’il n’y aura plus de bugs à corriger, les devs ne devront surtout pas reprendre leur développement car le but de cette phase du sprint est de stabiliser au maximum le produit pour la démo et la mise en production.
Les développeurs pourront profiter du temps restant pour travailler sur différents sujets qui n’impacteront pas le produit lors de cette fin de sprint : recherche sur un sujet, auto formation, refactoring sur une autre branche (GIT)…
On va par exemple dire qu’on arrêtera les développements en cours tous les jeudis midi de la deuxième semaine du sprint pour réaliser les tests et les éventuels correctifs.
Voici un exemple plus visuel :
Dans quel contexte faire un freeze time ?
Vous l’aurez compris, le freeze time n’est pas à faire dans toutes les équipes Scrum. C’est une méthode certes efficace mais qui est là pour combler un manque cruel dans les développements (rarement à cause des développeurs).
Par exemple, toutes les équipes qui ont une stack devops très avancée n’auront aucun intérêt à faire cela comme celles qui ont la maturité de réaliser de nombreux tests automatisés.
Pas de stack devops, pas de tests automatisés
Les équipes qui ont besoin de ce freeze time sont les équipes qui testent chacune des US en continue sur un espace de recette mais qui ne sont pas sûr que tout refonctionnera correctement en pré-production (espace quasi identique à la production) ; souvent dans ce cas, je conseille même au PO d’attendre la mise en pré-production pour commencer les tests (ce qui du coup rend le burndown chart inutile). Ce risque est accru par le manque de tests automatisés ou par des environnements différents entre la production et la recette.
Il est très important que les démonstrations fonctionnent parfaitement et ne font pas perdre du temps aux participants (utilisateurs clés, parties prenantes, managers…) pour s’assurer au maximum qu’ils seront de retour aux prochaines démos futures.
Il faut bien comprendre que leur présence est essentielle dans ce processus agile car on profitera de leurs feedbacks pour améliorer le produit. Il est souvent plus facile de les faire fuir que de les faire venir donc on travaillera au maximum leur fidélité.
Un freeze time pour les mises en production
Pas idéal mais c’est un contexte que j’ai déjà vu dernièrement : l’équipe ne peut pas mettre la mise en production dans le « Done » car celle-ci est trop longue et complexe à faire pour la faire à chaque Sprint ou exige politiquement de ne faire des mises en production qu’à chaque release complète.
On est tous d’accord que ce type de scrum est à la limite du « faire de l’agile » mais en tant que coach agile je ne peux que proposer des solutions efficaces pour améliorer l’ensemble (parfois le temps de travailler le problème initiale).
Le freeze time avant chaque mise en production peut permettre d’avoir un produit plus fiable en production mais cela ne sera pas alors forcément à chaque sprint.
Conclusion
Vous connaissez à présent une nouvelle technique qui vous permettra de combler certains problèmes que vous pourriez rencontrer dans des équipes qui font du Scrum mais qui peuvent être dans des contextes pas toujours optimales.
1 Rétrolien / Ping