Scrum, Agilité et Rock'n roll

Commentaires

1. Le lundi 14 janvier 2013, 11:14 par Emilie

Je débute en agilité, et sur mon projet, nous avons mis en place un système à mi-chemin entre Scrum et Kanban, avec une semaine de traitement côté équipe dév + tests, et une semaine de recette côté client. Pendant que le client recette le lot N, nous développons N+1, traitons les éventuels retours de recette de N et préparons N+2.

Le DONE du traitement est atteint lorsque la demande a été traitée et homologuée. Le DONE de la recette est atteint lorsque le client valide la demande.

Pour ce sondage, dois-je considérer mes sprints comme durant une semaine ou deux ?

euh, là je dirais plutôt que vous ne sprintez pas...

2. Le mardi 15 janvier 2013, 18:37 par Chris

Le sondage est déjà clos ?

3. Le mardi 15 janvier 2013, 23:32 par Jean-Claude

2 semaines depuis le début c'est plus facile de livrer qu au début. Pour autant je ne pense pas réduire pour ne pas epuiser mon équipe.

4. Le mercredi 23 janvier 2013, 10:01 par Nico

"euh, là je dirais plutôt que vous ne sprintez pas..."
Merci pour l'explication Claude. Elle doit être contente Emilie à se poser plein de questions

5. Le lundi 28 janvier 2013, 09:20 par Emilie

Pourquoi est-ce que je ne sprinte pas ? Il me semblait qu'un sprint, ou une itération, consistait en une période courte de temps, pendant laquelle on réalise un incrément de produit, qui doit être livrable à la fin de l'itération (définition de DONE).

Le rythme que j'applique sur mon projet me semble répondre à ces critères. Le fait que je puisse commencer à travailler sur l'itération N+1 pendant que la recette / l'acceptation (et ses retours) s'effectue en parralèle ne me semblait pas contradictoire.

Ma question sur la durée du sprint d'une ou deux semaines est liée en fait à la définition de DONE. Un incrément "livrable" n'est pas forcément un incrément livrable en production. Beaucoup d'équipes considèrent que DONE = prêt à passer en recette, alors que pour d'autres, DONE = livrable en prod. D'où ma question.

Par ailleurs, j'ouvre un peu le débat, mais il est recommandé une période de démo en fin d'itération, afin de s'assurer que les critères d'acceptation des stories sont bien validés. Je comprend tout à fait ce principe. Toutefois, avec une équipe dispersée géographiquement et une application de gestion avec beaucoup de règles complexes et d'interconnexions avec d'autres systèmes, je vois mal comment tout vérifier en une seule session de démo. A mois que celle-ci dure deux jours complets, et le PO, et encore moins les utilisateurs, ne peut pas être disponible pendant deux jours en continu, ni même pendant une journée. D'où la solution d'étaler sur une semaine pour leur permettre de s'organiser (voire de s'auto-organiser ).

Avec Scrum, ce n'est pas lors de la démo qu'on vérifie les critères d'acceptation. Cela se fait pendant le sprint, dès que c'est possible sur une story. A la démo, on ne montre que ce qui est déjà considéré comme fini, c'est à dire les stories pour lesquelles on a déjà vérifié leur critère d'acceptation. Ce qui permet de garder une démo d'une heure.
Le PO est le responsable du produit devant les utilisateurs (et autres partie-prenantes), il a le pouvoir de déclarer une story finie. Pour que Scrum fonctionne, il faut que l'équipe soit en mesure de développer et finir la story à elle seule pendant le sprint. C'est pour ça qu'on parle d'équipe auto-organisée et pluridisciplinaire.
Faire intervenir les utilisateurs est une très bonne initiative, mais pas pour faire la recette, pour solliciter leur feedback, ce qui se traduira par de nouvelles stories.
Une requête pour finir : Emilie, s'il te plaît, arrête d'écrire DONE comme ça...ça m'énerve, je le disais déjà dans ce billet il y a quelques années. Encore plus avec des capitales