qui paye les bugs apres une revue de sprint ?

Bonjour

Une des grandes questions qu'on me pose souvent est comment gérer les bugs lors de la revue de sprint?

je parle de VRAIS bugs techniques de la part des devs.

En principe selon la méthode, ils donnent lieu à de nouvelles tâches sans user points pour le sprint suivant.
Mais la grande question est la FACTURATION: comment faire comprendre au client qu'au sprint suivant il payera x % pour corriger des bugs qu'on a fait.

Considère t on que ces bugs sont à l'unique charge du prestataire ? Dans ce cas cela signifierait que le prochain sprint ne pourra commencer qu'une fois les bugs corrigés

merci pour vos réponses
Cyril

Salut,

En théorie les bug n'ont pas a être présenté à la review. Le but de la review est de présenter les nouvelle fonctionnalité développé dans le sprint afin d'avoir du feedback et de voir si on va dans la bonne direction, si les dev correspondent aux attente, etc... Un bug n'est pas une nouvelle fonctionnalité. Un bug, c'est quelque chose qui était censé déjà marcher mais qui ne marchait pas.
En pratique, il peut être intéressant de parer d'un bug critique ou bloquant qui vient d'être, juste a fin de communiquer et rassurer, mais ce n'est pas la raison première de la review.

Ensuite, plusieurs solution sont possible:
- Le bug est présent sur une version releasé et a un impact visible pour l'utilisateur. Auquel cas c'est un bug qui rentre dans le cadre de la maintenance. A toi de voir comment tu facture la maintenance.
- Le bug est présent sur une version pas encore releasé. Dans ce cas, c'est juste le dev qui n'est pas fini.
- Le bug n'a pas d'impact visible pour l'utilisateur. Auquel cas ce n'est pas un bug mais une dette technique (ne pas oublier que tout logiciel fonctinnel contient un nombre pair de bug ^^). En soit la dette technique n'est pas vraiment facturable. C'est ton problème, pas celui du client.

Il est bon de toujours garder un ration de 20% de maintenance/dette technique et 80% de dev dans les sprint pour éviter les fameux "sprint de stabilisation", difficilement justifiable.
Donc quand tu facture 10 jours au client, dans la pratique tu ne bossera que 8 jours sur ses features et 2 jour pour le reste.

Voilà, j'espère que ça t'aidera :)

Bonjour et merci pour cette réponse.
J'ai alors un autre souci : en théorie il existe des stories 'bug' et 'remboursement de dette'. Dans le premier cas, si le bug est déjà présent dans une version livrée sa facturation entre dans le cadre de la maintenance, et dans le second cas c'est pour la pomme du prestataire.

c'est bien cela ? on a donc des stories facturées au client et d'autres non

merci
cyril

Citation:

Envoyé par pulsarinformatique

Bonjour et merci pour cette réponse.
J'ai alors un autre souci : en théorie il existe des stories 'bug' et 'remboursement de dette'. Dans le premier cas, si le bug est déjà présent dans une version livrée sa facturation entre dans le cadre de la maintenance, et dans le second cas c'est pour la pomme du prestataire.

c'est bien cela ? on a donc des stories facturées au client et d'autres non

merci
cyril

Bonjour,
D'après la question posée pour ce fil de discussion, le vocabulaire que tu utilises et les attitudes que tu décris, je ne pense pas que ton projet se déroule dans un environnement agile, ni que vous utilisiez réellement Scrum.
Pour avoir travaillé dans ce type d'environnement, j'ai trouvé que les choses devenaient plus claires, plus simples, plus faciles à gérer et fonctionnaient mieux dés qu'on admettait cette évidence ("the elephant in the room"). On pouvait alors aller vers le déploiement de méthodes plus en adéquation avec la culture d'entreprise (RUP ? RAD ? DSDM ? etc suivant la culture).

Pour te répondre, il me semble utile de revenir aux bases.
Le framework Scrum permet à une équipe de découvrir quels process fonctionnent dans son contexte de travail.
Scrum est un framework agile, pas une méthode complète de gestion de projet. (Une méthode dirait à l'équipe quel process elle doit adopter).

Les méthodes agiles visent la production de valeur, pas l'amélioration de la productivité. La conception du produit est au coeur du processus de création de valeur.
Faire le bon produit, celui qui génère de la valeur, est bien plus important que faire le produit au moindre prix. On vise l'impact marché plutôt que l'optimisation d'un processus industriel.

A partir de ces éléments, tu as les informations pour répondre toi-même à la question "qui paie les bugs ?".
Au final, qui fait le chèque pour payer les développements/le produit ? Toujours l'entreprise cliente, et in fine ses clients finaux.
Dans ton cas ce qui t'intéresse c'est de savoir si la correction du bug est une activité qui peut être refacturée au client : cela dépend des détails du contrat, c'est une expertise de juriste.
Donc il vaut mieux que tu te tournes vers le service juridique de ton entreprise.

La question des pénalités n'a pas sa place dans un contrat agile : le client paie pour un temps de développement, et l'équipe lui livre fréquemment un logiciel en état de marche.
Si des défauts non acceptables sont découverts, il faut s'interroger sur la definition of done.
Quelle qualité est attendue ? Comment testez-vous la qualité du produit livré ?

Si les défauts sont acceptables, et correspondent au niveau de qualité attendue, alors il n'y a pas de problème, puisqu'il n'y a pas à corriger ces défauts (notion de qualité suffisante).

Tu poses également la question du moment où on peut démarrer un sprint.
Le guide Scrum le dit clairement : un nouveau sprint commence dés que le précédent se termine.
Les sprints sont des intervalles de temps fixes. On ne peut pas rallonger un sprint, il n'existe pas d'inter-sprint, il n'y a aucune question à se poser sur les sprints.
Même la question de l'interruption d'un sprint est presque toujours caduque : c'est un événement tellement rare et traumatisant que seul un scrum master très expérimenté peut l'envisager.

Enfin, tu parles de différents types de user stories (des stories 'bug' et 'remboursement de dette'). Cela n'existe tout simplement pas.
Scrum ne dit pas comment formaliser les exigences fonctionnelles.
Les praticiens de l'agilité empruntent souvent à eXtreme Programming (XP) le concept de User Story.
Les Users Stories de XP sont de simples conversations, et n'empruntent aucun formalisme (ni ticket Jira, ni carte bristol).
La formule "en tant que ... je veux ... afin de ..." est un guide optionnel pour tenir ces conversations, de même l'acronyme INVEST n'est là que pour s'assurer qu'on a bien tenu la bonne conversation.
Les User Stories techniques sont un contre sens, puisqu'elles ne correspondent pas à des conversations avec un utilisateur.
L'objectif des User Stories est d'aider l'équipe Agile à raisonner en terme de valeur produite plutôt qu'en terme de contraintes techniques.

J'espère t'avoir éclairé et avoir répondu directement à ta question.

Scrum est un un excellent framework, mais peu d'entreprises savent façonner la culture nécessaire pour en tirer bénéfice.
Dans un contexte inadapté, le risque est que les équipiers et les clients soient déçus.
Scrum demande des changements radicaux, décrits clairement dans le Scrum guide. Scrum ne peut pas être appliqué partiellement (c'est écrit noir sur blanc dans le Scrum guide).
Si ton entreprise et votre client ne sont pas prêts à ces changements, il vaut mieux opter pour autre chose.
L'agilité est un chemin, et l'étape qui vous donnera le plus bénéfice dans votre contexte actuel est probablement d'aller vers une méthode qui corresponde mieux à votre contexte de travail actuel.
Vous et votre client en tirerez plus de bénéfices et d'épanouissement.

Pour démarrer, le meilleur conseil que je puisse te donner est de vous initier au framework Cynefin, qui vous permettra de définir le cahier des charges de la méthode la plus adaptée à votre contexte actuel (simple, compliqué, complexe, chaotique, ou indéterminé/désordre).
Un indice : il n'existe pas d'environnement de projet informatique qui soit simple ou compliqué du point de vue Cynefin.

Que ma réponse ne te fasse pas croire que tu fais ou penses les choses de travers.
Ta question est une excellente question, révélatrice pour moi de l'environnement dans lequel tu évolues.
A toi d'inspecter les artefacts de cet environnement et t'adapter, tenter des expériences pour l'améliorer :-)