Définir et évaluer les tâches permettant de réaliser les stories. Est-ce utile ou néfaste ?


Lors de la deuxième partie du sprint planning, l’équipe revoit les stories sélectionnées dans le sprint backlog et détermine les actions à prendre pour réaliser ces stories.

Dans bien des cas, elle essaie d’identifier toutes les tâches, de la facon la plus exhaustive possible, qui seront nécessaires à l’accomplissement de la story.
En même temps elle essaie d’évaluer le temps que prendra chaque tâche. Les tâches étant découpées suffisament petites pour ne jamais depasser 2 jours hommes, on pense être en mesure d’avoir une évaluation précise.

Avons-nous besoin de ces informations ? Nous sont-elles utiles ou néfastes ?
Le besoin :
En fait le besoin exprimé pour cette information provient de notre vieille habitude de waterfall, on ne fait que transformer les sprints en mini-projets waterfall. Partant de cela on prétend avoir une analyse exhaustive et des délais parfaitement évalués.

Agir ainsi c’est un peu oublier ce qui nous amène à Scrum : reconnaitre qu’un développement de logiciel est un projet complexe d’une part, et que l’humain n’est pas habile à évaluer dans l’absolu d’autre part.

Il y a aussi un besoin de rassurance qui nous pousse à vouloir définir et évaluer : est-ce-que les stories choisies sont réalisables dans la durée d’un sprint ?
À cela deux réponses :

  • La première qui répond encore à ce besoin de plannification : Scrum, à travers l’étude statistique de la vélocité de l’équipe nous fournit un indicateur qui nous permet d’identifier le volume (en temps que complexité ) de stories qui seraient réalisables dans un sprint.
  • La deuxième sous forme de question plus philosophique : Vu que le backlog de sprint n’est absolument pas un engagement, quel est l’interêt de savoir si il est vraiment réalisable ?

Il y a aussi le product owner et le manager de l’équipe de développement qui expriment le besoin de voir que les choses avancent.
Ils disent vouloir voir que l’on est dans le temps… Dans le temps de quoi ?
Le temps lui est un élément fixe, mais dans un sprint c’est le périmètre qui est ouvert. L’équipe, elle, fait de son mieux pour réaliser un maximum de stories d’un niveau de qualité supérieure.

Et puis ultimement ce n’est pas le temps qui interesse le product owner ce sont les STORIES!
Donc la vraie métrique qui l’interesse ce n’est pas le burndown en heures mais plutôt le burnup en stories.
Le burnup en tâches est aussi une métrique interessante si on garde en tête que le découpage initial n’est pas exhaustif et qu’il s’ajoutera des tâches tout au long du sprint.

L’utilité :
Ces informations ne pourraient être utiles que dans la mesure ou elles seraient exactes.
Or elles ne peuvent être exactes que lorsque l’équipe est inchangée et collabore depuis longtemps, lorsque la technologie est maitrisée et lorsque la complexité des stories est faible et l’incertitude inexistante. Donc dans la pratique on peut affirmer que cela ne sera jamais utile ou rarement sur des projets en phase-out.

Ces informations seront en fait utiles lorsque l’on commence à adopter Scrum, elles serviront à demontrer qu’elles ne sont pas fiables et donc inutiles. C’est un peu paradoxal j’en conviens mais Je demeure convaincu que c’est une étape nécessaire de l’apprentissage et de l’appropriation de la philosophie agile scrum.

Néfastes :
Ces informations créent une pression indue et donc un stress sur l’équipe et sur le product owner. J’ai déjà lors d’un post précédent abordé le problématique du stress dans les équipes agiles-scrum, et j’avais alors expliqué le lien entre la notion de délai, de temps évalué et le stress ressenti par les membres de l’équipe.
Lorsque les membres de l’équipe débordent du temps évalué, la qualité s’en ressent immèdiatement : on tourne les coins ronds, on bacle les tests d’intègration et on oublie les tests manuels.

C’est d’ailleurs en abordant un problème de qualité par l’approche des « 5 pourquoi » que l’on a réalisé ce qui m’a amené à écrire cet article. En voici, en substance, le contenu.

Pourquoi est-ce-que la qualité n’est pas satisfaisante?
Parceque l’on n’accorde pas l’attention nécéssaire aux tests et à la qualité même.

Pourquoi on n’accorde pas l’attention ?
Parcequ’on déborde déjà du temps évalué.

pourquoi est-ce-que l’on déborde ?
Parceque l’on a sous évalué.

Pourquoi avons-nous sous évalué ?
Parceque c’est complexe et qu’on ne maîtrise pas forcement la technologie.

Pourquoi on continue à évaluer si c’est si complexe et si souvent erroné?
Pour s’assurer de se stresser inutilement ?

La solution : ne pas évaluer !

Quelle décision avons nous prise en rapport à ceci ?
Ne plus évaluer le temps des tâches, le statut « à faire », « en cours » et « fini » sera suffisant.

Advertisements