Quand il n’y a pas de bottlenecks dans ton flux de travail. 
(Principles of product development flow)
Du coup, c’est après coup ? Ou c’est in tempo ?
Les deux. De toute façon, lorsqu’on parle de « découper », je prends le livre de Don Reinertsen : c’est aussi « enlever » des parties d’une tâche, voire d’un projet, en plus de limiter la taille des lots.
Avoir la réponse universelle « c’est assez découpé », c’est impossible. Par contre, diminuer ses lots par expérimentation jusqu’à avoir une taille cohérente qui améliore ton temps de livraison, ça t’amène à une meilleure gestion de l’économie de la boite.
De mon expérience, lorsqu’il y a des bottlenecks dans un flux, c’est toujours lié au fait de deux choses :
- Commencer trop de travail en même temps sans en finir,
- Ou avoir des tâches trop grosses et infinissables, donc déprimant (et ça amène plus de dépendances, en plus…)
2 « J'aime »
Je vois le lien avec l’approche batch de TPS.
Et pour allez dans ton sens, pour moi le « assez découpé » fait aucun sens mais plus pour un côté systémique, à savoir que tu vends pas des moitiés de produits.
1 « J'aime »
Est-ce qu’il y a des ressources qui parlent de cette approche ?
J’aimerais la comprendre.
ça vaux ce que ça vaux, mais au moins ça offre une idée de la chose.
1 « J'aime »
La meilleure ref sur le batch, c’est le livre de Don Reinertsen « Principles of Product Development Flow ». C’est totalement inspiré du TPS en allant sur le côté économique de la chose. Une super lecture, même si vraiment technique sur la stat et les process / PQM (product quality management)
2 « J'aime »
J’arrive comme un cheveu sur la soupe mais j’ai quand même l’impression que tout le monde parle de la même chose, j’ai un peu de mal à comprendre ce que vous voulez démontrer.
Je me range à l’avis de Benjamin : découper, au delà de réduire la charge de travail dans le flux de travail, permet aussi d’enlever le superflu. Ca apporte de la visibilité, des échanges et parfois des remises en question.
Et le découpage il peut se passer autant dans le domaine du problème
que dans le domaine de la solution, il me semble, pour répondre à des messages de l’après-midi. Le système bancaire ne s’est créé qu’en deuxième moitié du 19ème siècle, et c’était pas pour tout le monde et répondait à des forts enjeux industriels à l’époque. Et d’ailleurs c’est pas la même finalité dans l’un ou dans l’autre, dans le premier cas je réduis mon problème à des problèmes plus précis, plus ciblés, et dans l’autre je vais chercher à améliorer le flux de réalisation et réduire les bottlenecks.
Bref, à tous les niveaux, problème ou solution, le découpage est un enjeu fort, pour savoir véritablement ce que les parties-prenantes souhaitent et ce que les équipes techniques doivent réaliser.
2 « J'aime »
Je met un holà ici: Je te rejoins du côté de la solution et de la gestion du flux. Par contre, pour ce qui est du problème, on crée difficilement un système complexe à partir de plusieurs simplexes. La majorité du temps, on ne fait que passer de complexe à compliqué parce qu’on a voulu abstraire des dépendances systémiques. En plus de ça, dans tous les cas, dans ce domaine là, le but n’est pas tant la précision que l’ordre de grandeur.
L’avancement de ce qui est livré dans le cadre d’un sprint se fait sur c’est qui est livré/validé au niveau des fonctionnalités(ex des User Stories) et non pas des tâches techniques(qui sont dynamiques pour les dévs(pas obligatoires, peuvent en ajouter et en supprimer à tout moment contrairement aux US) pour les livrer.
D’où en tant que SM je ne propose pas aux Dévs d’estimer les tâches(et même si c’était le cas, ils ne les estimeraient pas en points mais en heures et cette estimation permettre juste de voir s’il y a un blocage par exemple si elle reste trop longtemps sans être fermée ou une indication qu’elle était trop grosse car une tâche bien découpée[SMART] pouvant être terminée entre 6hr et 12hr soit une journée / pour une bonne[INVEST] US entre 1 et 3 jours pour être terminée, dans les deux cas, ces « délais » ne sont que des recommandations et des points d’indications pour les dévs pour savoir s’il est nécessaire d’identifier, de découper beaucoup mieux les tâches ou le PO/le reste de l’équipe les US, dans cas se rendre compte que certaines PBIs identifiés au départ comme des US était en fait des Epics par exemple pour mieux affiner par la suite).
Les Dévs peuvent suivre(l’info est d’abord par et pour eux, ensuite fond l’effort de toujours rendre Transparent l’avancement pour le reste de l’équipe et ceux qui sont en dehors notamment au management) avec la MAJ de LEUR Burndown Chart(les équipes utilisent moins les Burn Up Chart) en suivant le nombre d’US(ou de points) restants par jour de sprint.
quel est le rapport entre poids d’une tâche et la management ?
une tâche est une tâche, c’est déjà un point à elle seule, pourquoi en ajouter ?
tu verras que je milite pour l’inverse : arrêtez d’estimer, découpez
il n’y a qu’en découpant jusqu’à arriver à une taille parfaite que vous allez devenir prédictible et que votre métier et … management, aura ce qu’il veut en terme de suivi
un petit article d’un de nos Scrum Master qui parle du sujet de mesurer plutôt que d’estimer dans une équipe qui était fortement convaincue par les estimations
Notre rythme Estime mieux !. Pourquoi on estime ? | by Jamal BOUNASSEH | Medium | Just-Tech-IT