Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Quels sont les différents moyens pour augmenter la productivité dans une équipe agile ?
Retour de discussion avec un Microsoft User Group

Le , par kolodz

0PARTAGES

Hier, j'étais au MUG (Microsoft User Group) de Lyon et parce que j'aime la bière je suis allé à l'after. Il se trouve que j'y ai entendu une conversation particulièrement intéressante sur l'Agilité et la productivité.

La discussion a débuté autour de la question suivante :
La productivité étant mesurée en unité de bidule par unité de temps.
Pour augmenter, la productivité, il y a deux moyens :
Produire plus de bidule dans le même temps.
Produire le même nombre de bidules dans un temps plus court.
Quelle est la différence ces deux types d'augmentation de productivité ?
Note : prenez le temps de réfléchir vous-même à la question avant de poursuivre.

La réponse basique est :
Aucune, on produit plus, c'est tout.
Bien sûr la question n'est pas simple. Par exemple, dans le contexte d'une équipe travaillant en Agile, si on augmente le nombre de tâches à faire dans un sprint, l'équipe aura probablement tendance à rechercher des améliorations dans la réalisation des tâches. Cependant, si on réduit la durée d'un sprint, il est probable que celle-ci s’intéresse au coût fixe d'un sprint (réunion de début de sprint et de fin de sprint...).

Conclusion : En changeant l'approche donnée, nous n'obtenons pas les mêmes améliorations.

Je trouve ce point important, mais la conversation ne s'est pas arrêtée là. Par la suite, elle a été orientée vers un peu plus vers le point de vue client par rapport à une équipe « Agile » suite à deux questions :

  • Quelle est la durée écoulée entre l'expression du besoin et la mise en production ?
  • Si j'avais une baguette magique qui réduit les temps de développement à 0, quel serai le gain par rapport au processus actuel ?


Dans le cadre de notre discussion, il y avait globalement 2 semaines entre l’expression du besoin et l'intégration dans un sprint de deux semaines et une semaine supplémentaire pour la mise en production. Le temps total est donc de 3 ou 5 semaines dans le meilleur de cas.
Si on suppose un temps de développement nul, malgré le gain évident de productivité, il y a un gain de temps si et seulement si le développement dépasse la durée d'un sprint (ce qui en théorie n'est pas possible ).

Du point de vue du client, le délai n'a pas changé. On a potentiellement produit plus, car on a réalisé des story en plus (avec moins de valeurs, car moins prioritaire). Mais le fait est que le client attend exactement le même temps.

Conclusion : Une augmentation de productivité locale ne se répercute pas forcément dans une augmentation de productivité globale. Formuler d'une autre manière :
La productivité d'une entreprise n'est pas la somme de la productivité de ses employés.
Note : Il faut bien comprendre que l'idée de ces deux argumentaires est de critiquer les aspects négatifs des méthodes agiles. Cependant, la personne ayant soulevé cet argumentaire en comprends les bénéfices.

J'avoue ne pas être sûr de la conclusion finale. Il est probable qu'on se dirige vers de l'agilité où les sprints sont définit par leur contenu et non par leur durée. Ainsi, à partir du moment où les X story du sprint sont finit, on déclenche une fin de sprint. Mais cela veut aussi dire qu'il y aura probablement plus souvent plusieurs personnes sur la même tâche ce qui, en entreprise, est considéré comme contre-productif. Peut-être à raison, peut-être à cause d'un manque de pratique...

Cela soulève la question des temps « mort », le fameux moment où tu finis une tâche et, au lieu d'enchainer sur la suivante, tu vas discuter 2/3 minutes avec ton collègue pour savoir sur quoi il travail. Apprendre ce qu'il fait, éventuellement l'aider... Est-ce du temps non productif ? Ou un investissement payant ?

Cordialement,
Patrick Kolodziejczyk.

Note : je vais probablement faire un billet sur la conférence en elle-même, mais celle-ci demande un peu plus de temps pour être présenté proprement.

Et vous ?

Qu'en pensez-vous ?

Une erreur dans cette actualité ? Signalez-le nous !

Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web