Commentaires sur : Planifier Moins Pour Produire Plus http://www.agilex.fr/2009/03/planifier-moins-pour-produire-plus/ Agile, Lean, Scrum et informations diverses Fri, 12 Mar 2010 14:55:28 +0100 http://wordpress.org/?v=2.8.4 hourly 1 Par : Alexandre Boutin http://www.agilex.fr/2009/03/planifier-moins-pour-produire-plus/comment-page-1/#comment-484 Alexandre Boutin Fri, 10 Apr 2009 16:02:38 +0000 http://www.agilex.fr/?p=521#comment-484 Mon objectif n'est pas de comparer la productivité d'une équipe agile versus non agile. Mon constat est qu'un individu chargé à 100% (ou plus) est moins productif qu'un individu chargé à 80%. Celui à 100% va tomber dans un bouchon et sa productivité réelle sera 30% ou 40% et celui à 80% sera lui productif à 80% ... voir plus (je l'ai constaté). Les méthodes agiles sont basées sur un système de PULL qui fait que les équipes ne seront jamais chargées à 100% et auront donc une productivité supérieure (vélocité). Mais je propose également une solution pour les méthodes traditionnelles ... celle de charger les équipes à seulement 80%. Mon objectif n’est pas de comparer la productivité d’une équipe agile versus non agile.
Mon constat est qu’un individu chargé à 100% (ou plus) est moins productif qu’un individu chargé à 80%.
Celui à 100% va tomber dans un bouchon et sa productivité réelle sera 30% ou 40% et celui à 80% sera lui productif à 80% … voir plus (je l’ai constaté).
Les méthodes agiles sont basées sur un système de PULL qui fait que les équipes ne seront jamais chargées à 100% et auront donc une productivité supérieure (vélocité). Mais je propose également une solution pour les méthodes traditionnelles … celle de charger les équipes à seulement 80%.

]]> Par : Fabrice Aimetti http://www.agilex.fr/2009/03/planifier-moins-pour-produire-plus/comment-page-1/#comment-481 Fabrice Aimetti Fri, 10 Apr 2009 15:38:27 +0000 http://www.agilex.fr/?p=521#comment-481 Bonjour, Ton article me donne 2 pistes : 1) Aujourd'hui, on compte 18 JxH par mois, soit 217 JxH à l'année pour modéliser la production d'un Équivalent Temps Plein (ETP). Si je comprends bien, sur un projet en mode agile, il convient de considérer qu'un ETP équivaut à 15 Jours x Homme par mois, soit environ 180 JxH à l'année. Effectivement, on retombe sur des problèmes d'objectifs de productivité fixées aux équipes travaillant dans des usines logicielles... 2) Ou alors, on peut aussi comprendre qu'un sprint doit être planifié en tenant compte du fait que 20% de l'activité d'un ETP sera consacré à d'autres tâches (correctif urgent, capitalisation, ...). Et là, on retombe plutôt sur une exigence de planification plus réaliste du sprint. Normalement, cela doit se retrouver dans la vélocité de l'équipe, c'est bien ça ? Cordialement, Fabrice Bonjour,
Ton article me donne 2 pistes :
1) Aujourd’hui, on compte 18 JxH par mois, soit 217 JxH à l’année pour modéliser la production d’un Équivalent Temps Plein (ETP). Si je comprends bien, sur un projet en mode agile, il convient de considérer qu’un ETP équivaut à 15 Jours x Homme par mois, soit environ 180 JxH à l’année. Effectivement, on retombe sur des problèmes d’objectifs de productivité fixées aux équipes travaillant dans des usines logicielles…
2) Ou alors, on peut aussi comprendre qu’un sprint doit être planifié en tenant compte du fait que 20% de l’activité d’un ETP sera consacré à d’autres tâches (correctif urgent, capitalisation, …). Et là, on retombe plutôt sur une exigence de planification plus réaliste du sprint. Normalement, cela doit se retrouver dans la vélocité de l’équipe, c’est bien ça ?
Cordialement, Fabrice

]]> Par : Bruno Orsier http://www.agilex.fr/2009/03/planifier-moins-pour-produire-plus/comment-page-1/#comment-263 Bruno Orsier Tue, 31 Mar 2009 15:02:34 +0000 http://www.agilex.fr/?p=521#comment-263 Je suis bien d'accord avec toi. Toutefois nous avons constaté que les équipes Scrum avaient beaucoup du mal à entendre ces arguments, et il est très difficile de convaincre les équipes de travailler sur un tout petit nombre d'histoires. Les bouchons ont de beaux jours devant eux. En ce qui me concerne, il me semble important que la définition de "terminé" contienne le fait que tout les membres de l'équipe aient travaillé sur l'histoire et puissent la maintenir. Ca éviterait trop de travail en parallèle et en silos. Une autre piste est que les équipes apprennent à travailler sur le modèle 1 chirurgien / N assistants (pour une histoire donnée - les rôles changent pour l'histoire suivante). Dans ce modèle les assistants peuvent ne rien faire pendant quelque temps (sacrilège!) mais ils sont immédiatement disponibles. Le problème est que tout le monde veut être chirurgien en même temps... [Ref pour l'équpe chirurgicale : The mythical man-month, F. Brooks, 1974] Bruno Je suis bien d’accord avec toi. Toutefois nous avons constaté que les équipes Scrum avaient beaucoup du mal à entendre ces arguments, et il est très difficile de convaincre les équipes de travailler sur un tout petit nombre d’histoires. Les bouchons ont de beaux jours devant eux.

En ce qui me concerne, il me semble important que la définition de « terminé » contienne le fait que tout les membres de l’équipe aient travaillé sur l’histoire et puissent la maintenir. Ca éviterait trop de travail en parallèle et en silos.

Une autre piste est que les équipes apprennent à travailler sur le modèle 1 chirurgien / N assistants (pour une histoire donnée – les rôles changent pour l’histoire suivante). Dans ce modèle les assistants peuvent ne rien faire pendant quelque temps (sacrilège!) mais ils sont immédiatement disponibles. Le problème est que tout le monde veut être chirurgien en même temps…

[Ref pour l'équpe chirurgicale : The mythical man-month, F. Brooks, 1974]

Bruno

]]>