Le SigmaT11 est fini, place à l'agile tour

Un peu plus d'une soixantaine de personnes ont assisté à la conférence de vendredi. La présentation d'IceScrum, avec Benjamin et Stéphane, s'est plutôt bien passée (pas d'effet démo). Le support est disponible, ceux des autres présentations aussi.
Le prochain SigmaT aura lieu le 11 décembre, mais en attendant, l'événement local, c'est l'étape toulousaine de l'agile tour, le 22 octobre.

Commentaires

1. Le mardi 22 septembre 2009, 23:43 par Sylvain

Une question à propos d'IceScrum : est-il possible de définir un sprint contenant des histoires utilisateurs (ou autres tâches) de différents projet ?

Non. Une équipe, un backlog, un produit (projet). Pendant un sprint, l'équipe travaille sur des tâches associées à des stories de son backlog de produit. Quel est le problème derrière votre question ?
2. Le mercredi 23 septembre 2009, 13:13 par Lume

Juste pour vous signaler un concurrent gratuit d'Icescrum qui a pour les personnes qui travaille avec TFS l'avantage d'être directement relié au Work Items. http://www.telerik.com/products/tfs... J'en profite pour vous remercier pour ce blog il m'a grandement aidé à mettre en place scrum dans mon équipe.

3. Le mercredi 23 septembre 2009, 23:09 par Sylvain

Le problème derrière ma question ? Est-ce vraiment un problème...

L'idée est que nous travaillons sur plusieurs produits, chacun avec son backlog. Certains produits dépendent d'autres produits. Donc, au sein d'un sprint, on souhaite avancer sur un produit, permettant d'avancer sur un autre. Un sprint, un backlog de sprint remplis de tâches et de stories de 2 backlogs de 2 produits. Je ne crois pas être en dehors des principes ?

Si. Les stories réalisées pendant un sprint par une équipe ne peuvent pas provenir de 2 backlogs de produit différents. Faites un seul backlog de produit (comme vous avez des produits "dépendants", ça devrait avoir un sens). En revanche, il est possible d'avoir un seul backlog de produit avec plusieurs équipes Scrum qui y travaillent, chacune ayant son propre plan (backlog) de sprint.
Pour en revenir à IceScrum, il n'offre pas cette possibilité (dite scrum de scrums) pour l'instant. C'est dans le backlog depuis longtemps, mais il faut des ressources. Je recherche des sponsors pour nous aider à la développer...
4. Le jeudi 24 septembre 2009, 21:39 par Sylvain

Un seul backlog de produit avec plusieurs équipes Scrum ok. Mais nous n'avons pas les ressources pour cela. En revanche, nous avons plusieurs produits avec dépendances. Comme nous ne voulons pas aller à l'encontre du principe du time boxing, nous avons décidé de travailler, potentiellement, sur plusieurs produits pendant un sprint.

Cela semblait logique... Manifestement ça ne l'est pas. Quel(s) principe(s) enfreignons-nous ?

Au passage, je tiens à vous remercier pour le temps que vous consacrer à transmettre vos connaissances et compétences.

5. Le mercredi 07 octobre 2009, 02:21 par Oaz

"nous avons décidé de travailler, potentiellement, sur plusieurs produits pendant un sprint.
Cela semblait logique... Manifestement ça ne l'est pas. Quel(s) principe(s) enfreignons-nous ?"

De mon point de vue, cela reste possible si l'on considère qu'il y a en fait plusieurs équipes (une par produit) et que les équipiers passent d'une équipe à l'autre entre les sprints. La vélocité sera peut être plus difficile à mesurer mais ça peut rester jouable.

Avec une équipe qui travaillerait simultanément sur plusieurs backlogs de produit, le backlog de sprint serait tout simplement impossible à établir : il faudrait arbitrer des priorités entre plusieurs produits ce qui revient, au final, à n'avoir qu'un seul backlog de produit.

Si on est dans le cas où "beaucoup" de produits sont à faire évoluer en parallèle avec un nombre de personnes très limité, je favoriserais pour ma part l'option "1 sprint = 1 produit". Pendant une ou deux semaines, tout le monde travaille sur le produit A puis au sprint suivant tout le monde passe sur le produit B, etc.
Cela permet de faire évoluer rapidement les divers produits en fonction des attentes des utilisateurs tout en gardant une équipe focalisée sur un objectif unique (et ainsi éviter le phénomène de silo où chaque produit devient la "propriété" d'un développeur)