La première chose à faire c’est justement d’être ouvert à cette discussion entre vous développeurs et product owner
Être transparent sur les problèmes que tu ressens, que tu vois et écouter les enjeux du PO par rapport au produit et à sa hiérarchie.
Vous gagnerez tous en efficacité si vous partagez les mêmes visions en terme de produit et aussi en terme d’organisation. Faut pas que les uns aient le sentiment de subir les impératifs des uns ou les exigences des autres.
Je suis sûr que plein de petits ajustements peuvent être faits en commun accord entre vous et lui pour que chacun s’y retrouve :
donner un sens au sprint
adapter le process de délivrer
se donner un process pour le traitement des feedbacks et bugs qui peuvent perturber votre flow sans nuire à la réactivité
gérer les parties prenantes
etc.
Tout peut commencer pr des échanges informels autour d’un café pour tâter le terrain et mener le PO à participer à un atelier de travail autour des pratiques agiles par exemple. Je suis sur que lui aussi doit éprouver certaines frustrations.
Bonjour, normalement on livre a la fin d’un sprint, livrer en cours de sprint est contre productif. Car en effet il y a un décalage avec le but du sprint, l’increment qui sort de ce sprint et la release souhaitée.
Pour moi vous devez faire un point où vous déciderez soit de faire les releases a la fin du sprint, soit de caler les sprints en fonction des dates de releases souhaitées.
Si vous voulez faire simple et donc efficace, il faut absolument que l’increment du sprint soit la release.
Plusieurs Increments peuvent être créés durant un Sprint. La somme des Increments est présentée lors de la Sprint Review, ce qui permet de démontrer l’utilité de l’empirisme. Toutefois, un Increment peut être livré aux parties prenantes avant la fin du Sprint. La Sprint Review ne doit jamais être considérée comme le seul moment pour délivrer de la valeur.
Source: Scrum Guide 2020
Ok, je viens de me rendre compte de mon erreur. J’ai extrapolé en fonction de mes récentes expériences ou on faisait des livraisons pendant le sprint alors que ça mettait en péril le sprint en cours.
Effectivement @Samuel_Abiassi@nicobiot si on est capable de livrer à chaque incrément qui apporte de la valeur, et non pas uniquement sur lensemble des incréments qui composent le sprint, et que c’est le besoin du produit autant le faire.
Par contre ma proposition tient toujours, si j’ai bien compris le problème @Vincent_Cueto. Vu que vos livraisons arrivent toujours au même moment, ça peut valoir le coup d’aligner le rythme du sprint et le rythme des releases.
J’aimerais que ce soit aussi simple pour nous mais une livraison demande des tests IOS / Windows tablettes et PC plus une procédure qu’on ne peut pas automatiser actuellement pour placer les builds dans les bibliothèques applicatives. L’instantanéité de la chose est pour nous littéralement impossible, question de contexte et on est très loin des 15 minutes.
Ce que je constate c’est que tous le monde lis le scrum guide comme une bible mais dans les faits tout est flou car à appliquer au cas par cas, j’ai beau le lire et le relire dans tous les sens je ne comprend pas comment arriver à mes fins.
Sincèrement je suis perdu, je veux améliorer notre fonctionnement, je sais que tout ce que nous faisons n’est pas SCRUM, et y arriver parait être un très long périple.
C’est effectivement du bon sens on se pose déjà ces questions sans savoir l’appliquer c’est extrêmement frustrant.
On a tendance à mélanger les problématiques d’intégration continue avec celles de déploiement continue mais elles sont drastiquement différentes. Dans ton cas @Vincent_Cueto, et même sans connaitre les tenants et aboutissants en terme de marché/contexte/utilisateurs, je comprends tout à fait les questions que tu te poses sur la livraison d’une version.
En l’état, le fait est que ce que demande Scrum à la fin d’un sprint, c’est un élément « potentiellement livrable ». Pas une livraison systématique. C’est notamment important sur des contextes où des mis-à-jour sont bloquantes pour l’utilisateur et invasives. Dans ce genre de cas, plus les maj sont espacées, mieux c’est.
Etant gamer par exemple, attendre que tous les mods avec lesquels je joue se mettent à niveau par rapport à une MaJ d’un jeu est souvent irritant. C’est notamment pour ça que beaucoup de jeu avec MaJ utilisent des environnements publics de test pour pouvoir quand même récupérer du feedback avant le déploiement « live ».
Dans ton cas particulier, j’aurais quand même une chose à te proposer, toute simple: pourquoi vous ne calez pas vos durées de sprint sur le calendrier de release ? Ou mieux : Pourquoi vous n’essayeriez pas des sprints d’une semaine ?
En adaptant à des sprints d’une semaine c’est envisageable effectivement non seulement d’avoir un sprint goal cohérant mais aussi ce concentrer uniquement sur une livraison (Actuellement on travaille sur le lot 5 mais on livre le lot 4 non terminé du sprint précèdent …)
Par contre comment faire les mois de Mai ou une semaine dure 3 jours au lieu de 5 par exemple ?
Comment gère t’on la répétition des sprints review/planning ? Elle seront fatalement plus courte en théorie mais en pratique est-ce vraiment le cas ?
Adaptation. Semaine avec jours fériés = Sprint plus court = focus plus court et éventuellement l’occasion de bosser sur des trucs un peu annexe pour tester autre chose.
Dans des organisations qui sont peu habitués à scrum. J’ai tendance à pousser des process simples, a savoir a la fin d’un sprint on doit avoir un élément potentiellement livrable, a ce moment le PO décide si oui ou non on le livre. Peut importe si cet élément possède tout le lot 4 et un bout du lot 5, le PO choisi si il veut déployer cet élément.
Ça a l’avantage de faire toujours la même chose au même moment, du coup le processus de livraison est plus maîtrisé car anticipé. Là où livrer le lot 4 en milieu de sprint peu interférer avec d’autres sujets.
L’inconvénient c’est que ça intègre des éléments du lot 5, si on ne les veux vraiment pas, ça ne marche pas ou alors il faut faire du feature flipping.
Dans tous les cas ça demande de bien travailler son processus de livraison.
Si un changement de rythme ou de temps de sprint n’améliore pas les choses, il faut peut être travailler au niveaux des processus CICD ou juste au niveau du git flow.
