Pour moi si ce n’est pas terminé on le remet dans le backlog
Aoutch… J’imagine que le manque de co-localisation doit pas être évident. Du coup, la communication asynchrone doit fatalement engendré un tempo plus lent.
C’est une organisation, un rythme à prendre, le gros de l’équipe est en Asie donc des matinées bien chargées, l’après midi workshop pour préparer / répondre aux points vus le matin. Il y a des moments c’est plus sport quand tu cumules congés, fêtes nat ou religieuses plus le décalage horaire 
1 « J'aime »
Exactement, ce passer des estimations n’empêche pas la visibilité sur l’avancement.
Allen Holub va plus loin :
« Compter le nombre de tâches* est suffisant ! »
*Une tâche est petite et utilisable par l’utilisateur.
Voir l’extrait de la conférence d’Allen HolubL’idée en fait est surtout d’essayer de trouver un point de référence et de s’y tenir pour pouvoir mesurer quelque chose dans le temps, le temps étant notre ami… si on change tout le temps de moyen de mesure, on s’y perd et les éléments ne sont plus comparables…
A partir du moment que l’équipe est d’accord et a choisi quel type d’élément elle veut mesurer et comment elle le mesure, l’équipe pourra avancer et s’améliorer.
1 « J'aime »
Ah, ce bon vieux Hollub… Sans parler du fait que d’avoir quelque chose de « petit » nécessite de facto une estimation, créer un système complexe avec des tâches « petite et utilisable par l’utilisateur », ça commence à me mettre en rogne. Je me fout qu’un truc soit « utilisable » si il n’apporte de valeur à aucune partie prenante. Je reprend l’exemple très simple d’une banque, mais un système où on ne peut que retirer de l’argent sans en avoir déposer au préalable est assez absurde, et je ne parle même pas des transferts d’argent, où on entre dans un monde complètement autre encore. Le focus technique dont fait parfois preuve la communauté du développement est quand même sacrément déconnecté des impératifs commerciaux.
Pour moi le système d’une banque fait déjà partie de la solution.
En quoi on a besoin d’une banque ?
Pas vraiment la question ici, dans la mesure où pour toute « petite tache » comme elles sont entendues par Allen, on est déjà dans le domaine de la solution et déjà plus dans le problème.
C’est l’idée de ne pas se bloquer dans une seule solution (le système de banque). Pour se donner la latitude d’explorer d’autres solutions.
C’est ce que tu as exprimé avec l’idée de plusieurs solutions testé en parallèle.
C’est ce que ces tests sont petits ?
Non, encore une fois, si tu veux tester l’hypothèse qu’une banque dans sa notion systèmique (c’est à dire qu’on a déjà validé le fait que la solution était une bonne hypothèse grâce à de la recherche utilisateur) est une solution viable, y’a pas 36 solutions: faut construire le schmilblik. T’as pleins de manière de l’implémenter par contre, d’où l’approche set-based au lieu d’une approche itérative.
1 « J'aime »
Est-ce qu’à un moment, tu va te retrouver avec une tâche qui dure plus d’une semaine ou plus de 5 story point ?
Aucune idée. Potentiellement oui. C’est très contextuel.
À quelle moment on peut considérer qu’on est dans la situation de l’effet tunnel ?
À quelle durée d’une tâche ?
Oui, c’est contextuel. Il faut prendre ces valeurs de manière relative.
En prenant une approche set-based, la question ne se pose pas. L’effet tunnel est impactant si le tunnel dans lequel tu te trouves est ta seule alternative.
Samuel, je ne suis pas profondément en désaccord avec toi.
Ce que souligne Allen Holub par cette étude de Vasco Duarte est purement statistique.
En pratique cela peut donner
Fait la moyenne de : 5, 3, 2.
=> ~3
C’est comme si on avait : 3, 3, 3
Variation négligeable
Si la moyenne des story point d’un Sprint est constante sur plusieurs Sprint.
Alors les résultats, sont comme si tous les tickets ont un story point de 1.
Trop de variations
Dans le cas où il y a trop de variations.
Alors il faut commencer par réduire ces variations avec de passer au comptage des tickets.
Et comment réduirais-tu les variations ?
Ce prémisse est plutôt important. Refait les même calculs en prenant des 5, 8, 13, avec toute l’imprécision et la variabilité que ces chiffres entrainent et la démonstration ne tient plus.
Dans certains contexte un 13 est le signal qu’il faut découper le ticket.
Et comment tu sais que c’est « assez » découpé ?
Un ticket fait plus qu’une “seule chose”* :
si on peut en extraire un ticket.
On se retrouve à faire une chose et bien la réaliser.
*Le découpage dont je parle est un découpage vertical.