Discussion :

[rad_hass]

Bonjour à tous,

Je suis entrain de mettre en place SCRUM dans mon projet, dans un souci d'amélioration du processus j'aimerai avoir vos lumières sur certains aspects qui me pose souci.

Dans l'idéal les tâches ne devrait pas évoluer en cours d'un SPRINT, mais si le Product Owner juge qu'un élément est devenu plus prioritaires il peut remplacer une tâche existante (corriger moi si je me trompe).

1 - Par contre comment gérer des éléments nouveaux qui doivent être fait en cours d'un SPRINT, par exemple les tâches techniques non planifiés et qui sont transverse ... Comme des problèmes avec le serveur d'intégration, ou la mise en place d'un nouveau système de test unitaire, ou encore l'intégration d'une nouvelle pratique (exemple TDD) ?

2 - Comment prévoir la gestion des anomalies ? Imaginons qu'une anomalie bloquante apparait en production quels sont les possibilités pour l'intégrer dans le SPRINT ? Faire la même chose qu'avec une nouvelle tâches devenu plus prioritaires ?

3 - Autre chose, imaginons qu'il y est des tâches planifiés pour un SPRINT (par exemple le déploiement d'un nouveau site en production) et que cette tâche au finale se voit sortir du SPRINT et décaler, comment mettre à jour le burndown du SPRINT ?

4 - Dernière question, comment gérer le burndown, si on a pas une vue complète sur tout les prochains SPRINT, faire un burndown par lot de SPRINT ? Utiliser plutôt un brunup pour mieux gérer un périmètre évolutif ?

J'arrête ici mes questions

Merci de m'avoir lu

PS : Si une idée d'un livre ou un article qui illustre ce genre de problématique vous viens, n'hésitez pas à me le signaler en vous remerciant.

[TheLeadingEdge]

le Product Owner juge qu'un élément est devenu plus prioritaires

C'est son droit de réestimer, mais pas des tâches qui ont été sélectionnées dans le backlog de sprint actif.
De plus le PO n'a pas a intervenir sur le déroulement d'un sprint lancé. Son seul interlocuteur doit être le scrum master.

Par contre comment gérer des éléments nouveaux qui doivent être fait en cours d'un SPRINT

Une fois qu'il est demarré un sprint est indivisible. Il est composé uniquement de ce qui est décrit dans le backlog de sprint au moment du démarrage du sprint et il est figé 1 fois qu'il est lancé. Ce n'est pas un puzzle. C'est 1 savant équilibre entre des demandes et la capacité de l'équipe du sprint à les réaliser.
Pour autant il y a 1 pratique qui consiste à charger un sprint à 80% avec des tâches ''critiques'' (M et S - must et should have) et à 20 % avec des tâches qui peuvent être reportées à un sprint ultérieur. C'est utile ds les 1ers sprints qd on n'est pas encore bien sur de la vélocité de l'équipe, et ça peut s'appliquer dans ce cas.

Aprés c'est à voir comment c'est considéré. Est-ce une nvelle entrée ds le BP ou est-ce de la maintenance ? Si c'est le cas et que la seule ressource possible pour intervenir est ds l'équipe de dev, soit ça devrait être pris en compte dans le calcul de la vélocité, soit il faut prévoir une tâche ''maintenance'' récurrente dans chaque sprint.

[edit]

Si une idée d'un livre ou un article qui illustre ce genre de problématique vous viens, n'hésitez pas à me le signaler

Agile Estimating And Planning de M. Cohn
[/]

[Heziva]

Bonjour,

Plusieurs solutions s'offrent à toi pour gerrer tes problématiques. Mais la principale chose à retenir, c'est que tu vas devoir adapter la méthode selon tes besoins.

Prenons un sprint. Ce sprint a sa liste d'User Stories, qui sont déclarés en début de Sprint et qui ne doivent pas être modifiés directement par le PO. Dans cette liste, il peut y avoir, en post-it d'une autre couleur, des bugs à traiter. Il peut y avoir également, en post-it d'une troisième couleur, des tâches non fonctionnelles à réaliser. Ces tâches peuvent être des spikes, ou des installations d'infrastructures, par exemple.
A ce backlog de sprint correspond, affiché à côté et en grand, une BD-Chart. Celle ci est mise à jours quotidiennement, non pas avec le consommé mais avec le reste à faire. Ce point est capital.
A tout moment, l'équipe peut demander à voir le PO pour renégocier les items en cours de sprint. Cette demande doit impérativement être justifiée par un retard ou une avance sur le planning.

Ainsi, admettons que le système de build continu tombe en panne au milieu d'un sprint. Deux solutions...
1°) Je ne change rien à mon backlog. Je traite ça en priorité.
Cette solution est tout à fait viable. Elle se fera ressentir sur la vélocité de l'équipe, ce qui impactera le BD Chart. On verra immédiatement que l'équipe est en retard, et on ira négocier du déscoppage avec le PO.
2°) J'ajoute une tâche non fonctionnel à mon backlog de sprint. Je traite ça en priorité.
De la même manière, cela impactera le backlog, et conduira à la négociation avec le PO.

J'ai travaillé en Scrum sur un projet où des demandent arrivaient de manière incessante, un peu comme tes annomalies blocantes. Au bout de deux semaines, il est apparu que la vélocité de l'équipe était de 15 points par jours au lieu des 40 initialement prévu. Nous avons pu immédiatement avertir qu'avec toutes ces demandes, il fallait déscoper une très grande partie du fonctionnel.

Là où j'en viens, c'est que ces ralentissement constants peuvent ne pas figurer sur le backlog. Le fait de les traiter impactera immédiatement la vélocité, et tu pourra lever les alertes correspondantes.

Un backlog, et sa BD-Chart associé n'est pas figé pendant un sprint. Simplement, le PO ne peut pas à son initiative en modifier les éléments.

J'espère avoir répondu à tes questions...

Jonathan

[Bruno Orsier]

1 - Par contre comment gérer des éléments nouveaux qui doivent être fait en cours d'un SPRINT, par exemple les tâches techniques non planifiés et qui sont transverse ... Comme des problèmes avec le serveur d'intégration, ou la mise en place d'un nouveau système de test unitaire, ou encore l'intégration d'une nouvelle pratique (exemple TDD) ?

2 - Comment prévoir la gestion des anomalies ? Imaginons qu'une anomalie bloquante apparait en production quels sont les possibilités pour l'intégrer dans le SPRINT ? Faire la même chose qu'avec une nouvelle tâches devenu plus prioritaires ?

3 - Autre chose, imaginons qu'il y est des tâches planifiés pour un SPRINT (par exemple le déploiement d'un nouveau site en production) et que cette tâche au finale se voit sortir du SPRINT et décaler, comment mettre à jour le burndown du SPRINT ?

4 - Dernière question, comment gérer le burndown, si on a pas une vue complète sur tout les prochains SPRINT, faire un burndown par lot de SPRINT ? Utiliser plutôt un brunup pour mieux gérer un périmètre évolutif ?

quelle est la durée de tes sprints ? Est-ce qu'une partie de tes problèmes ne disparaîtrait pas avec des sprints courts, type 1 semaine ? Dans ce cas chaque semaine tu as la capacité de planifier tes imprévus.

Pour les anomalies, s'il y a un flot régulier... eh bien il faudrait travailler sur la cause profonde. En attendant pour la gestion des rustines, il y a plusieurs solutions, par exemple on décide au démarrage que tel membre de l'équipe se mettra sur la résolution d'une anomalie dès qu'elle arrive (en arrêtant ce qu'il fait, donc il doit travailler uniquement sur des stories non critiques). Ou bien l'équipe considère qu'elle consacre 10 ou 20% de son temps aux anomalies, et se débrouille pour l'organisation exacte de son temps.

Bruno

[rad_hass]

Merci à tous pour vos réponses.

Pour autant il y a 1 pratique qui consiste à charger un sprint à 80% avec des tâches ''critiques'' (M et S - must et should have) et à 20 % avec des tâches qui peuvent être reportées à un sprint ultérieur. C'est utile ds les 1ers sprints qd on n'est pas encore bien sur de la vélocité de l'équipe, et ça peut s'appliquer dans ce cas.

Aprés c'est à voir comment c'est considéré. Est-ce une nvelle entrée ds le BP ou est-ce de la maintenance ? Si c'est le cas et que la seule ressource possible pour intervenir est ds l'équipe de dev, soit ça devrait être pris en compte dans le calcul de la vélocité, soit il faut prévoir une tâche ''maintenance'' récurrente dans chaque sprint.

Je pense que dans un premier temps c'est ce qu'il nous faudrait faire, on est effectivement dans les premiers sprints et l'idée d'une tâche récurrente de "maintenance" peut répondre au besoin.

1°) Je ne change rien à mon backlog. Je traite ça en priorité.
Cette solution est tout à fait viable. Elle se fera ressentir sur la vélocité de l'équipe, ce qui impactera le BD Chart. On verra immédiatement que l'équipe est en retard, et on ira négocier du déscoppage avec le PO.
2°) J'ajoute une tâche non fonctionnel à mon backlog de sprint. Je traite ça en priorité.
De la même manière, cela impactera le backlog, et conduira à la négociation avec le PO.

La seconde solution impacte également la vélocité, non ?

quelle est la durée de tes sprints ? Est-ce qu'une partie de tes problèmes ne disparaîtrait pas avec des sprints courts, type 1 semaine ? Dans ce cas chaque semaine tu as la capacité de planifier tes imprévus.

La durée de mes sprints actuellement est de 4 semaines, il serait peut être intéressant de la passer à 3 semaines, mais 1 semaine ça me parait bien trop court.

Pour les anomalies, s'il y a un flot régulier... eh bien il faudrait travailler sur la cause profonde. En attendant pour la gestion des rustines, il y a plusieurs solutions, par exemple on décide au démarrage que tel membre de l'équipe se mettra sur la résolution d'une anomalie dès qu'elle arrive (en arrêtant ce qu'il fait, donc il doit travailler uniquement sur des stories non critiques). Ou bien l'équipe considère qu'elle consacre 10 ou 20% de son temps aux anomalies, et se débrouille pour l'organisation exacte de son temps.

Effectivement on est entrain de travailler sur la cause profonde comme tu l'as très justement conseiller, mais c'est un peu long car il n y avait aucun contrôle anti-regression ... Pour résumer il n y avait aucun test automatisé, ni des tests unitaires ni des tests fonctionnels, ni même un serveur d'intégration et c'est ce qu'on est entrain de corriger ... Mais notre vélocité risque d'en prendre un sacré coup, il faudrait peut être qu'on crée des tâches de qualité.

En tout cas encore une fois, merci beaucoup pour vos conseil et avis avisés

[Maximil ian]

Dans l'idéal les tâches ne devrait pas évoluer en cours d'un SPRINT, mais si le Product Owner juge qu'un élément est devenu plus prioritaires il peut remplacer une tâche existante (corriger moi si je me trompe).

Pas en cours de Sprint, mais le PO peut modifier la priorité des items pour le sprint suivant dans le backlog de produit.

Le backlog de sprint est composé de tâches, il appartient à l'équipe de développement et elle seule a la main dessus. Le backlog de produit est composé d'items (exigences, user stories...) et il appartient au PO. C'est là qu'il peut agir.

1 - Par contre comment gérer des éléments nouveaux qui doivent être fait en cours d'un SPRINT, par exemple les tâches techniques non planifiés et qui sont transverse ... Comme des problèmes avec le serveur d'intégration, ou la mise en place d'un nouveau système de test unitaire, ou encore l'intégration d'une nouvelle pratique (exemple TDD) ?

Il est préconisé d'inclure ces tâches autant que faire se peut à l'intérieur de "vrais" items qui ont une valeur métier pour le PO. Il peut y avoir quelques items techniques dans un sprint si on ne peut pas faire autrement, mais le risque est de produire moins de valeur pour le client et de fausser la mesure de la vélocité.

2 - Comment prévoir la gestion des anomalies ? Imaginons qu'une anomalie bloquante apparait en production quels sont les possibilités pour l'intégrer dans le SPRINT ? Faire la même chose qu'avec une nouvelle tâches devenu plus prioritaires ?

Il y a plusieurs façons de fonctionner :

- Remettre en jeu un item pour le prochain sprint lorsque des bugs apparaissent sur celui-ci (il n'est plus considéré comme "done")
- Introduire une tâche séparée de bugfix dans le backlog pour le prochain sprint
- Faire du bugfix entre les sprints
- Introduire un sprint entier un peu spécial dédié au bugfix s'il y a beaucoup de bugs
- ...

Une anomalie bloquante et critique en production peut aussi être traitée sur-le-champ, mais si ça se reproduit trop souvent, ça risque de gréver la vélocité de l'équipe et de hacher le sprint, ce qui n'est jamais bon pour la qualité des tâches en cours de réalisation. Heziva en a donné un bon exemple.

3 - Autre chose, imaginons qu'il y est des tâches planifiés pour un SPRINT (par exemple le déploiement d'un nouveau site en production) et que cette tâche au finale se voit sortir du SPRINT et décaler, comment mettre à jour le burndown du SPRINT ?

Sortir une tâche d'un sprint est un fait rare qui devrait se faire avec l'aval du PO. La plupart du temps, on constate juste qu'on n'a pas pu finir un certain nombre de tâches à la fin du sprint et la vélocité est affectée en conséquence. Dans ce cas-là, on ne touche pas au burndown. Lorsqu'on enlève réellement une tâche, je pense que le burndown doit être refait.

4 - Dernière question, comment gérer le burndown, si on a pas une vue complète sur tout les prochains SPRINT, faire un burndown par lot de SPRINT ? Utiliser plutôt un brunup pour mieux gérer un périmètre évolutif ?

Je suppose que tu fais allusion au burndown de release. Pour le créer il faut effectivement déjà avoir fait un plan de release et savoir globalement ce qui se passera dans les prochains sprints.
Cependant le burndown de release ne fait pas partie des 3 artefacts de base de Scrum et on peut s'en passer si on a aucune visibilité à moyen terme.

PS : Si une idée d'un livre ou un article qui illustre ce genre de problématique vous viens, n'hésitez pas à me le signaler en vous remerciant.

[rad_hass]

Merci Maximilian pour ces réponses complète.

Pour le livre de Kniberg je l'ai déjà lu merci quand même pour le lien.

Autre question : Est ce que c'est une mauvaise pratique de modifier le temps de SPRINT (de réduire exceptionnellement la durée du sprint de) soit pour faire des essaies soit pour s'adapter au besoin du client ?

[Maximil ian]

Tu as un cas particulier en tête ?

Dans Scrum, les sprints sont des itérations à durée fixe. Ce qui veut dire fixée à l'avance, mais aussi identique dans le temps autant que possible. Avoir des sprints consécutifs de même durée est ce qui permet de mesurer la vélocité de l'équipe et de savoir sur quelle quantité d'items s'engager durant la réunion de lancement du sprint suivant. Ca facilite la mesure de la progression de l'équipe et permet de mieux répondre à la question de savoir s'il elle s'améliore en continu (un des fondements de l'agilité).

Si tu fais allusion à un rétrécissement du sprint en cours de route, la seule personne habilitée à stopper un sprint en cours est le Product Owner. En général, ce n'est pas parce que tout se passe trop bien et que l'équipe a tout fini à l'avance

En résumé, pour moi le sprint est le bloc atomique de Scrum, une de ses seules constantes et le seul moment où on s'autorise à être "moins agile" dans le sens où on ne va pas répondre immédiatement aux changements de besoin du client. Ces changements sont reportés à plus tard, au sprint suivant.

[rad_hass]

Tu as un cas particulier en tête ?

Je sens que je vais me faire recaler
Si on sait que le besoin du PO va évoluer à moyen terme et qu'il aura des besoins à court terme, peut on modifier la durée d'un SPRINT pour mieux répondre à son besoin ?

L'autre raison qui est plus acceptable je l'avoue est que la durée de 4 semaines n'est peut être pas très adapté donc pour essayer différentes durée et voir celle qui convient le mieux l'équipe.

Merci encore

[Maximil ian]

Je sens que je vais me faire recaler
Si on sait que le besoin du PO va évoluer à moyen terme et qu'il aura des besoins à court terme, peut on modifier la durée d'un SPRINT pour mieux répondre à son besoin ?

J'ai pas tout compris, mais si l'équipe pense que c'est une bonne idée et que le PO est d'accord, pourquoi pas expérimenter. L'avantage de Scrum c'est qu'avec tous les feedbacks qu'il procure (daily meetings, retrospectives...) chacun se rendra vite compte si c'était l'erreur du siècle ou pas

[Heziva]

Si on sait que le besoin du PO va évoluer à moyen terme et qu'il aura des besoins à court terme, peut on modifier la durée d'un SPRINT pour mieux répondre à son besoin ?

Je pense que ta question demande une réponse à plusieurs niveau.

Niveau "débutant". As tu bien compris et intégré la raison pour laquelle les sprints sont timeboxés de manière fixe ? Et pourquoi Scrum met un accent énorme sur le fait de ne pas modifier ces timebox ?
Attention à ne pas tomber dans le "Scrum but"
Deux ressources sur le sujet :
Changer les règles trop tôt n'est pas une bonne idée
We're doing Scrum, but... signifie ne pas faire Scrum du tout

Niveau "avancé" :
Les règles sont faites pour être dépassées lors de leur implémentation...

[rad_hass]

Merci pour vos réponses

As tu bien compris et intégré la raison pour laquelle les sprints sont timeboxés de manière fixe ?

Il est important d'avoir des durées fixes, pour d'une part avoir un calcul au plus juste de la vélocité de l'équipe mais aussi pour que l'équipe puisse avoir des repaires et s'habituer au rythme des sprints.
Par contre au départ il est important d'essayer différentes durée, pour connaitre celle qui convient le plus à l'équipe.