déploiement de mi-sprint avec mêlée (grands projets de public web «brownfield»)

Question

Schwaber & Beedle's 'scrum' book (et l'autre littérature de mêlée que j'ai lu) semble se concentrer sur avoir un produit libérable à la fin du sprint. Le développement Web pour un site établi (au moins dans notre cas) consiste à développer des «améliorations» (de différentes tailles) et de nombreuses petites «corrections». Le déploiement (sur le Web) uniquement à la fin du sprint ralentirait le déploiement de grandes améliorations (ce qui est probablement une bonne chose), mais ralentirait considérablement le déploiement de petites améliorations et corrections (les bogues traînent plus longtemps).

Les déploiements en milieu de sprint sont-ils hérétiques en mêlée? Les sprints sont-ils applicables dans notre cas? Ai-je mal compris les sprints?

Answer 1

Le travail achevé à la fin d'un sprint doit être examiné par le propriétaire du produit lors de la réunion d'examen. Si vous relâchez à mi-chemin, cela peut ne pas être le cas.

Si vous pensez que le travail est terminé avant la fin du sprint, vous pouvez:

1. Ajouter plus de travail en choisissant les plus éléments prioritaires du carnet de libération
2. Raccourcir futurs sprints

Compte tenu de votre description de l'environnement de travail, j'opterais pour 2.

Vous pouvez également envisager une autre méthodologie agile qui pourrait être plus appropriée. Iate à votre environnement.

Je ne voudrais pas publier mi-sprint.

Answer 2

Je pense vraiment déployer à production mi-sprint sonne comme une mauvaise idée. Un vrai focus-stealer.

Peut-être que raccourcir la longueur du sprint serait quelque chose pour vous?

Answer 3

Si vous voulez effectuer un développement piloté par scrum strict, alors les déploiements à mi-sprint sont hérétiques. À mon avis, une approche strict-scrum n'est pas le meilleur outil à utiliser pour un scénario. J'utiliserais une approche plus classique où vous avez défini des packages de déploiement et des tâches qui leur sont assignées. vous développez sur un seul tronc et si toutes les tâches d'un package de déploiement donné sont effectuées, vous le déployez. Mais soyez conscient des contraintes au sein de votre code et de votre projet.

Answer 4

Vous pouvez jeter un oeil à la méthode Alistair Cockburn Crystal "Orange Web". Il a adapté les principes agiles aux contraintes du site Web public.

Answer 5

Avoir un contenu libérable à la fin d'un sprint n'empêche pas les lancers à mi-course. En fait, lorsque votre équipe a des responsabilités de soutien à la production, c'est nécessaire.

Je poser quelques questions au sujet de ces mi-sprint de presse que:

1) Est-ce que la valeur ajoutée de la version antérieure dépasse le coût du déploiement? 2) Avez-vous évalué le risque de chacun de ces mini-déploiements pour vous assurer qu'ils ne se retournent pas et créent plus de travail? 3) Pouvez-vous obtenir des commentaires de la part de vos clients sur ces mini-versions afin de vous assurer qu'elles libèrent ce qu'elles veulent? 4) Avez-vous envisagé de raccourcir vos sprints?

"Le développement strict scrum-driven" (présenté ci-dessus) est, pour moi, un oxymore. Le mantra est inspecter et adapter.Je m'attaque à la suggestion que Scrum est brandi comme une doctrine contre une meilleure réactivité à vos parties prenantes.