À quelle fréquence sortir dans Scrum sprint

À quelle fréquence vous relâchez-vous pendant un sprint. Seulement à la fin du sprint ou à chaque fois qu'une fonctionnalité est prête. Et comment gérer les versions de correction de bugs?

TL; DR: libération chaque fois que cela est approprié

Nous faisons des versions chaque fois qu'il est utile de faire une version. Parfois, cela signifie faire une version après qu'une seule fonctionnalité ou correction de bogue soit terminée. Parfois, cela signifie publier une collection de fonctionnalités et / ou de corrections de bogues.

Cela ne signifie pas que nous avons souvent des «urgences» qui nécessitent des versions rapides. Cela signifie que nous avons travaillé dur pour faciliter les versions. Notre code est testé, étiqueté et emballé avec chaque build. Nous utilisons des tests d'acceptation automatisés et, par conséquent, nous avons développé une grande confiance dans le code qui réussit ses tests. Étant donné que nos packages sont immédiatement disponibles via un dépôt local yum, le déploiement d'une version est trivial.

Jamais pendant. Cela viole le principe de base d'un "sprint". Vous courez jusqu'à ce que vous ayez terminé ce que vous vous êtes engagé à terminer. Après avoir terminé, c'est vraiment fait et ça marche vraiment. Vous pouvez ensuite le libérer.

La sortie peut être un type de sprint distinct où les choses sont emballées pour la sortie.

Les versions de correctifs peuvent être de courts sprints. Ne pas avoir un horaire régulier de sprints de même longueur est considéré par beaucoup comme une mauvaise idée. Par conséquent, la règle habituelle est que les corrections de bogues sont simplement un travail de haute priorité qui se produit lors du prochain sprint.

Si c'est une urgence, vous avez trop de choses en cours - support et développement - et vous devriez envisager de changer l'organisation pour avoir moins de choses en cours.

Si le travail que l'équipe s'engage à effectuer est propice à plusieurs versions dans le sprint, libérez-le aussi souvent que vous le souhaitez.

Il en va de même pour les versions corrigeant les défauts - s'il est logique de les publier, faites-le.

Le dernier job Agile sur lequel j'ai travaillé a été publié à chaque sprint; le code était gelé tous les deux jeudis (sprints de deux semaines), puis le produit était emballé et publié sur un serveur UAT pour que nos clients puissent travailler. C'était pendant le développement initial du produit; pour un produit mature, en particulier un programme distribuable et non une application Web, vous ne voudriez probablement pas imposer à vos utilisateurs une mise à niveau toutes les deux à trois semaines.

Presque toutes nos versions comprenaient un mélange de points d'histoire et de défauts (bugs). Les défauts comptés comme "heures non idéales"; il y a 5 heures idéales dans une journée de travail, ce qui signifie un codage tête en bas du nouveau travail ponctuel. Les trois à quatre autres heures par jour sont des réunions, des discussions, la conception, parfois des «pics» (recherche ciblée / développement de la preuve de concept) et le travail sur les défauts; des choses qui contribuent à un meilleur produit et qui sont une partie nécessaire du processus, mais qui ne peuvent tout simplement pas prendre tout le sprint de toute l'équipe. La seule fois où nous avons fait des versions uniquement défectueuses, c'était quand il n'y avait pas de travail narratif disponible dans le backlog à partir d'un IPM; Ensuite, nous avons simplement programmé un sprint QA où nous avons été chargés de "tuer autant de défauts que possible". Parce que ne pas avoir d'exigences prêtes à l'emploi est TOUJOURS la faute du bon de commande (et le bon de commande a fonctionné pour les clients), nous pourrions simplement émettre un avis de modification de contrat et travailler avec ce que nous avions. Bien sûr, une fois le travail de l'histoire terminé et que nous étions dans le développement de la "garantie", il n'y avait plus que des défauts.

Dans un projet Agile bien géré, le manque d'exigences ne devrait jamais se produire; l'arriéré devrait toujours avoir un travail de sprint prêt à être repris. Mais, parfois, l'OP est submergé de production d'exigences; parfois, les BA / testeurs retardent la publication des histoires dans l'arriéré de développement, pour des raisons liées à la qualité des exigences ou à des conflits d'histoires; Parfois, une équipe décide qu'elle doit "jouer" sur une histoire qui n'est pas bien définie ou bien estimée, et il n'y a rien qui puisse facilement reprendre les cycles restants. Bref, même en Agile, la merde arrive.

Qu'entendez-vous par libération? Si vous voulez dire PSP - produit probablement livrable, vous avez deux options:

• Scrum par livre (ou Scrum niveau 2) vous avez PSP à la fin du sprint et c'est ce que vous montrez lors d'une réunion rétrospective
• J'ai également rencontré le terme Scrum niveau 3 où l'équipe a maîtrisé leurs outils comme le contrôle de source et l'intégration continue et est passée à la livraison continue. Une telle équipe est en mesure d'avoir PSP après chaque build nocturne (ou chaque build dans le meilleur des cas). Avoir PSP après chaque build ne signifie pas que vous le montrez au client après chaque build - ce n'est encore qu'une version interne.

La principale différence entre le niveau 2 et le niveau 3 est qu'au niveau 2, vous devez faire un effort pour créer la PSP finale à la fin du sprint, mais au niveau 3, vous mettez d'abord de l'argent et des efforts dans vos outils et configurations et vous avez préparé la PSP automatiquement tout le temps = aucun effort manuel n'est impliqué. Atteindre pleinement le niveau 3 est rare.

Il n'y a absolument aucune règle dans Scrum sur le moment où de nouvelles fonctionnalités peuvent être déployées. Chaque équipe doit avoir une "définition du fait", qui devrait toujours inclure des critères de test. Une fois qu'une fonctionnalité est "terminée", elle est prête pour le monde réel et s'il n'y a pas d'autres dépendances ou conditions qui doivent être remplies avant de pouvoir être déployée, il n'y a aucune raison d'attendre la fin du Sprint pour déployez-le.

Rien de tout cela ne signifie qu'il n'est pas présenté à la réunion Sprint Review / Planning. Le concept est que tout ce que l'équipe a réalisé est montré au PO (et aux autres PME clientes) afin qu'il puisse l'intégrer dans sa compréhension croissante du système à mesure qu'il évolue.

Après quelques semaines, nous avons trouvé une bonne solution qui répond à nos besoins. On décide de sortir quand on veut. Comment nous procédons:

1. chaque fois que quelqu'un décide de libérer la branche de développement réelle, il fusionne tous les changements dans la branche principale, l'a étiquetée avec le nouveau numéro de version et a poussé sur notre système de transfert.
2. que notre QA et toutes les autres équipes reçoivent un courrier avec un véritable journal des modifications et testent le système de mise en scène
3. s'ils ont trouvé des bogues, nous les corrigeons dans le maître, le poussons à la mise en scène, puis fusionnons le maître dans la branche de développement
4. lorsque le système de mise en scène a passé l'AQ, le maître est mis en ligne

C'est ça. Nous utilisons git et maven comme système CI et nous avons une bonne couverture de test. C'est une des raisons pour lesquelles on peut aimer ça.

Répondre à une question qui remonte à presque 2 ans peut être un peu redondant, mais j'espère que pour ajouter de la valeur à ceux qui viendront à cette question, j'aimerais ajouter environ 2 centièmes. :)

Pour répondre à la question: Vous devriez de préférence libérer ce qui a été commis dans le sprint, à la fin de ce sprint. Cela est lié à toutes les autres parties / processus / directives de Scrum qui visent à obtenir la meilleure valeur commerciale au bon moment.

MAIS les urgences, les bugs, les événements inattendus, etc. peuvent vous forcer la main, c'est là que le concept si "Release Planning" pourrait être utile. Avec «Release Planning», je ne parle pas de planification de type cascade mais plutôt de planification des attentes qui pourraient aider à gérer le backlog de produit et la priorité des histoires dans les sprints ect.

Mais peut-être que le commentaire de David sur la question doit être pris en compte. Scrum n'est pas toujours la bonne réponse.