Que se passe-t-il entre les sprints?

Je travaille sur un projet qui suit vaguement le modèle Scrum. Nous faisons des sprints de deux semaines. Quelque chose sur lequel je ne suis pas clair (et je n'ai pas de livre à consulter) est exactement ce qui est censé se passer entre les sprints: il devrait y avoir un processus de "wrap", où le produit est construit et livré, mais:

• combien de temps cela prend-il généralement?
• faut-il impliquer toute l'équipe?
• faut-il strictement terminer avant que les développeurs ne commencent à travailler sur les prochains éléments de sprint?
• est-ce lorsque la révision et les tests du code ont lieu?

Il y a trois développeurs, totalisant environ 1 ETP. Les sprints sont donc en effet très courts.

Je travaille sur un projet qui suit vaguement le modèle Scrum.

Pour être clair: vos managers vous ont probablement parlé de Scrum mais ce que vous effectuez n'est pas Scrum.

Combien de temps cela prend-il généralement?

Réunion de revue de sprint + La réunion rétrospective de sprint met fin au sprint en cours. Dans les sprints courts, ils devraient prendre quelque chose entre 30 minutes - 1 heure ensemble. Le jour ouvrable suivant commence un nouveau sprint en exécutant les réunions de planification de sprint 1 et 2. En fonction de la taille de l'équipe et de la durée du sprint, cette réunion peut prendre de 2 à 4 heures.

Faut-il impliquer toute l'équipe?

Toute l'équipe doit être impliquée dans les réunions mentionnées dans la réponse précédente.

Doit-il strictement se terminer avant que les développeurs ne commencent à travailler sur les prochains éléments de sprint?

Oui, car jusqu'à ce que la réunion de révision soit terminée, vous ne savez pas si le client accepte le résultat du sprint précédent et vous ne savez pas quelles histoires d'utilisateurs seront engagées dans la planification des réunions.

Est-ce lorsque la révision et les tests du code ont lieu?

Non. La révision et les tests du code font partie du sprint. Les développeurs doivent faire tout ce qui est nécessaire pour fournir un code de travail satisfaisant aux exigences. Cela peut inclure des revues de code et il doit toujours inclure une sorte de tests automatisés validant que le code fonctionne et fait ce qu'il est censé faire sinon la user story ne peut pas être considérée comme terminée.

Le principal changement mental est lié à l'AQ. De nombreux développeurs pensent que QA est là pour valider que le code fonctionne et fait ce qu'il est censé faire. Définitivement non. C'est le travail de développeur.

L'AQ doit participer au développement des produits. Leur principale responsabilité dans le sprint devrait être la communication avec le propriétaire du produit et la création de tests d'acceptation automatisés pour les critères d'acceptation (définition du fait) qui valideront que la user story est vraiment faite et que l'application passe toutes les nouvelles exigences. Dans les petites équipes, cela peut également être la responsabilité des développeurs.

Le contrôle qualité doit également effectuer des tests manuels pour maintenir la cohérence du produit et découvrir les fonctionnalités manquantes, valider l'expérience utilisateur avec l'interface utilisateur, etc. Le contrôle qualité n'est pas là pour rechercher les bogues et les tests de régression - les tests de régression doivent être hautement automatisés.

D'après mon expérience, c'est là que la plupart des entreprises qui migrent vers l'agilité échouent.

D'après mon expérience, il n'y a pas de temps entre les sprints, à part le week-end. Vers le milieu du sprint, les équipes avec lesquelles j'ai été membre travaillent avec le propriétaire du produit pour faire des travaux de préparation d'histoires ou des évaluations préliminaires en fonction des besoins. C'est la responsabilité du propriétaire du produit de garder l'arriéré plein - ces histoires sont ce sur quoi l'équipe va travailler, avec une certaine contribution du propriétaire du produit concernant les priorités. Une fois le sprint en cours terminé, le prochain sprint commencera, en utilisant le travail que nous avons mis pour préparer des histoires et des tâches pour le prochain sprint.

Il y a des frais généraux (beaucoup de réunions, questions-réponses et évaluations des exigences), mais dans l'ensemble, cela fonctionne - nous progressons régulièrement avec peu de temps d'arrêt. Les sprints ont généralement duré deux ou trois semaines. L'AQ a généralement lieu une fois les histoires terminées. Cependant, l'équipe QA peut avoir d'autres tâches à accomplir. En ce qui concerne la préparation des histoires, les tâches peuvent incomber aux membres supérieurs de l'équipe ou à toute l'équipe. Cela peut varier en fonction de la taille de l'équipe et du processus convenu. Les révisions de code ont généralement lieu pendant l'AQ, ou à la fin du sprint si le temps est compressé. Et s'il n'y a pas assez de temps pour terminer les histoires, en pratique, ces histoires sont poussées au prochain sprint. Un dimensionnement et une estimation appropriés sont très importants ici.

... et quand est l'estimation? Planification?

Les histoires devraient être vraiment faciles pour ne pas avoir de temps entre les sprints.

Et je ne sais pas de quel type de test parlez-vous mais les développeurs feront des tests unitaires et d'intégration, rien de plus.

Je travaillais sur un projet avec parfois 2 ou 3 jours entre les sprints et ça fait du bien. Maintenant, je travaille sur un projet où il n'y a pas de temps et tout est flou. La dernière fois du sprint, nous avons un déploiement de production et cela prend un certain temps de mon dernier jour de sprint.