Quizz, la question 4 sur la planification

L'énoncé était le suivant :

Pour réaliser la story « tableau de bord », il faut que le composant qui envoie les données fonctionne. Il est développé par une autre équipe. Vous êtes en train de mettre à jour le plan de release, à quelques jours du démarrage du prochain sprint.

Les réponses proposées :

  1. La story est planifiée dans le prochain sprint
  2. La story ne peut pas être planifiée tant que le composant n’est pas fini
  3. La story est planifiée dans le sprint après le suivant et on prévient l’autre équipe
  4. L’équipe développe elle-même le composant

Tout juste 100 votants. C'est un peu moins que pour les autres questions, peut-être parce la réponse ne paraissait pas évidente. D'ailleurs les résultats montrent que c'est assez partagé entre les 4 réponses.

21% ont choisi de planifier la story pour le prochain sprint. C'est risqué, probablement trop.

21% pensent qu'il faut attendre que le composant soit fini pour planifier la story. C'est prudent, mais trop prudent.

Une majorité relative, 46%, est pour planifier la story, mais pas dans le sprint qui va commencer, dans celui d'après. C'est raisonnable et c'est ce que je choisis aussi. C'est à ça que servent les plans, à prévoir un point de synchronisation entre des équipes. Il subsiste un risque, mais plus limité et il restera possible, en cas d'obstacle avéré, d'adapter le plan pendant le sprint suivant.

Les 11% restants sont pour que l'équipe développe elle-même le composant. Cela élimine les dépendances sur une autre équipe, mais c'est sûrement prématuré de prendre une telle décision tout de suite.

Commentaires

1. Le vendredi 09 septembre 2011, 23:19 par Remy

Ça me rappelle le sketche de Palmade sur les choix délirants !
La communication est essentielle et c'est une valeur agile.
Donc je demande à l'autre equipe quand elle pense finir.
Je m'explique un peu plus :
L'agilité, c'est beaucoup de bon sens. Je pousse beaucoup les équipes à tout faire pour mettre en oeuvre la bonne solution. Souvent, les contraintes ici et là obligent à choisir entre 2 solutions preformattées alors qu'on voudrait une 3ème solution.
Osons proposer le meilleur choix, même s'il n'est pas dans la liste pré-définie !
Pensons "out of the box"
Débranchons nous de la Matrice et rebranchons nos neurones !

2. Le lundi 12 septembre 2011, 10:07 par yjaigu

Moi j'aurais plutôt vu comme réponse d'ajouter une tâche de création d'un stub réutilisable ensuite pour les tests fonctionnels.

Mais bon, comme c'est un QCM et que cette réponse n'était pas proposée ...

3. Le lundi 12 septembre 2011, 21:18 par Oaz

Je suis d'accord avec yjaigu.
Si la story en question est vraiment prioritaire, il n'y a aucune raison valable pour repousser son implémentation et passer du temps à faire quelque chose de moins prioritaire.
Il y a toujours des solutions pour avancer sur une demande prioritaire.

Pour ma part, j'ai choisi la réponse 4 car c'est ce qui s'en approche le plus. On peut imaginer aussi des solutions intermédiaires où une partie de l'équipe va s'intégrer provisoirement dans l'autre équipe pour réaliser ce composant là.

Les réponses 2 ou 3, ça me fait typiquement penser à une discussion du genre :

équipe> on peut pas faire X car on a besoin de Y, il faut repousser X à plus tard
PO> On ne peut pas trouver une solution pour faire autrement ? X est vraiment prioritaire.
équipe> non, il vaut mieux faire les choses dans l'ordre sinon on va faire du travail pour rien et au final ça prendra plus de temps (NDR: argument fallacieux la plupart du temps)
PO> Bon ok, on repousse... (dépité)

4. Le mardi 13 septembre 2011, 23:28 par Jérôme

Assez d'accord avec Oaz... Moi j'ai mis 1, car je ne vois pas de raison de créer une telle dépendance. Et l'exemple n'est pas simple car il y a a priori de US non-INVEST, mais c'est un autre débat.
Pour moi, créer cette dépendance est dangereux, et puis rien n'indique que l'US de l'autre équipe sera finie pour le prochain sprint

5. Le dimanche 06 novembre 2011, 18:08 par Ludo

Personnellement je pense que si le composant est spécifié et il semble l'être vu que c'est planifié "à venir", l'utilisation d'un Mock s'impose.
Ca demande certes un travail supplémentaire pour la première équipe, mais elle n'est plus tributaire de la livraison du composant.
Le développement s'en retrouve encore plus agile je trouve.
Et d'ailleurs le Mock peut ainsi servir pour les conditions d'acceptation.