Discussion :

[ClaudeAubry]

L'agilité se définit souvent comme la capacité à répondre aux changements, voire même à les favoriser. Pour beaucoup, c'est un progrès significatif. Mais de nombreuses organisations travaillent dans un mode de changements quasi-permanents, et le passage à Scrum peut représenter une transition rude en repoussant les changements au sprint suivant.
Je viens d'écrire un article qui expose des pistes pour traiter des tâches urgentes qui arrivent pendant un sprint, tout en restant dans un cadre Scrum.
L'article publié sur Developpez.com s'appelle "Scrum et les changements pendant un sprint" avec comme sous-titre "traiter les changements en flot continu avec une dose de Kanban".
Votre feedback est le bienvenu.

[Bruno Orsier]

Très intéressant, merci pour cette contribution. J'apprécie particulièrement les explications sur la vélocité qui "absorbe" certaines tâches, en se réduisant naturellement.

Il serait peut-être utile d'expliquer comment on expérimente pour trouver une bonne valeur de la limite de TAF (dans l'idée du chap. 6 de Kniberg/Skarin) ?

Bruno

[ClaudeAubry]

Merci Bruno.
La première fois la limite de TAF dépend énormément du contexte, en particulier de la quantité de changements et de la constitution de l'équipe. Il me semble important de définir d'abord sur quoi limiter le TAF (je donne quelques idées : le sprint, l'état en cours, les tâches en cours par personne,...), de partir au début sur une limite assez haute et de la diminuer progressivement.
Claude

[foucha]

Merci pour l'article, c'est agréable d'avoir un aperçu du Kanban en français ! Au fait, comment ça se prononce?

Le Kanban semble bien approprié pour les bugs urgents, surtout par rapport à la méthode du mou, où on a plus du mal à poser la limite. Est-ce que parce qu'on a 2 jours max de mou, on arrete les taches urgentes une fois que c'est atteint?... On s'habitue à traiter des taches urgentes pas forcément si urgentes, il peut y avoir moins de priorisations, bref il manque un cadre. As tu vu des projets où réserver du mou fonctionnait bien? Je me demande s'il ne vaut mieux pas directement toujours tester du Kanban à la place.

[kaymak]

bonjour,

Une petite coquille c'est glissée dans le paragraphe suivant :

II.4. Planification du sprint
Si on applique bien Scrum avec une signification de fini explicite, ces tâches récurrentes sont bienconnues au début du sprint. Elles sont ajoutées dans le tableau des tâches au moment de la réunion de planification du sprint.

Si l'équipe travaille bien, elles seront finies à la fin du sprint et une autre instance de ces tâches seracréée lors du prochain sprint.

merci pour cette introduction, très intéressante.

a plus

[ClaudeAubry]

Merci pour l'article, c'est agréable d'avoir un aperçu du Kanban en français ! Au fait, comment ça se prononce?

Moi je prononce kanban comme han ! à la française.

Le Kanban semble bien approprié pour les bugs urgents, surtout par rapport à la méthode du mou, où on a plus du mal à poser la limite. Est-ce que parce qu'on a 2 jours max de mou, on arrete les taches urgentes une fois que c'est atteint?... On s'habitue à traiter des taches urgentes pas forcément si urgentes, il peut y avoir moins de priorisations, bref il manque un cadre. As tu vu des projets où réserver du mou fonctionnait bien?

En fait je pense qu'il faut toujours avoir du mou en gestion de projet, parce qu'il y a toujours des aléas qui se produisent (impediments en Scrum). Donc j'ai plutôt vu des projets qui ne fonctionnaient pas bien par absence de mou.