Trouver le Thème

J’aime bien aider les gens sur Scrum et l’Agilité. Plus je le fais, plus j’apprends et l’apprécie. Beaucoup de mes récentes rencontres en ligne ou dans la vraie vie partagent la même opinion. Jusqu’à ce matin, Je n’avais pas mis le doigt dessus.

Lors d’un échange en ligne, des gens discutaient à propos du Sprint Burndown Chart. Les opinions varient beaucoup à propos de son utilité, de la manière de l’utiliser et de son contenu. C’est OK, car chaque équipe et situation est différente. Un commentaire m’a particulièrement frappé. Une personne décrivait comment son graphique montrait la consommation des heures estimées pour les tâches. Chaque jour, si les heures estimées d’une tâche à faire changeaient, ils ajustaient le burndown, essentiellement en incluant dans le burndown les heures réelles.

Par exemple, prenez une tâche estimée initialement à deux heures. Le jour d’après, le développeur travaillant sur cette tâche indique une faible avancée. La tâche n’a pas été faite dans les quatre heures consommées. Maintenant, le développeur estime que la tâche prendra dix heures. Donc le point sur le burndown chart sera ajustée d’une augmentation de six heures pour tenir compte de la nouvelle estimation.

Cet exemple montre la volonté de cette équipe de suivre les heures réelles. Je suppose qu’ils souhaitaient les comparer avec leur estimation originelle pour mesurer leur précision, bien que cela n’ait pas été soulevé. (Il y a plusieurs raisons pour lesquelles, je n’apprécie pas cette manière de faire les choses, mais ceci est un autre sujet.)

D’autres exemples sur ce thème :

  • Les réunions de planification de 8 heures
  • Estimer un product backlog de 5 mois d’un seul coup
  • Deux jours de maquettage d’écrans avant d’écrire la story
  • Des feuilles de calculs de suivi de sprint plus détaillées qu’un diagramme de Gantt

Aussi lorsque je réfléchissais à propos du burndown d’heures réelles et d’autres pratiques qui constituent des gâches potentiels, le thème m’a frappé :

Le Big Design Up Front (BDUF) de Scrum

Il semble que beaucoup de personnes essayent d’éliminer le BDUF des produits, avec des mises en oeuvre de Scrum conçues complètement à l’avance :

  • Ils ont besoin de définir tous les champs possibles qui pourraient servir sur la carte de la story avant de commencer à utiliser les cartes de story.
  • Ils veulent suivre les heures et chaque moment passé sur les tâches, y allouer la part en pourcentage du temps passé des développeurs par rapport aux autres tâches.
  • Ils ont besoin d’un backlog sur feuille de calcul comportant l’identifiant de la story sous forme de date, la date de la dernière modification, les commentaires par service dans des colonnes séparées et les votes des priorités faits par chacun des cinq parties prenantes.
  • Ils préparent des formulaires de deux pages pour enregistrer la définition de fini et comment chacune s’accorde avec le(s) enregistrement(s) des cas d’utilisation appropriés.

Et ils font tout ceci avant même que la première équipe commence le premier sprint. Parce que, et bien, ils auront besoin de ces données, n’est-ce pas ? Peut-être qu’ils auront besoin d’un tel suivi d’information un jour. Tous les éléments ci-dessus pourraient être la bonne manière de faire les choses à un moment donné pour une équipe, une entreprise ou un produit en particulier. Est-ce que cela a un sens de concevoir toute l’infrastructure en amont, en ne sachant pas ce qui sera réellement nécessaire ?

Les Pratiques BDUF en Scrum

Enfin, après plusieurs semaines de discussions, de réunions, d’écriture de documents et de planification, ils commencent leur premier sprint. Et voici, maintenant, qu’ils ont toutes ces pratiques BDUF faisant partie de leurs processus Scrum. Des Product Owners qui ont plus de travail de paperasse que d’innovation. Des Scrum Masters qui doivent demander constamment les heures réellement consommées. Des burndown charts nécessitant un manuel d’instruction pour les interpréter. Un projet s’enlisant par les mêmes choses qu’il était supposé laisser derrière lui en “devenant Agile.”

Code simple, Scrum simple

Le meilleur code est simple, direct et pas plus complexe que ce qu’il doit être. Les meilleurs produits ont une fonction claire et apporte une plus-value à leurs clients. La meilleure information est directe, ciblée et présentée simplement. Le meilleur Scrum est aussi simple que possible. De même qu’il n’est pas possible de connaître toutes les réponses en créant un produit innovant avant de commencer le développement, il n’est pas possible de connaître toutes les choses nécessaires pour un processus Scrum exceptionnel et hautement productif. Commencez simple, de façon simple avec uniquement les éléments de base. Puis, rétrospective après rétrospective, l’équipe et l’entreprise apprennent ce dont ils ont besoin, trouvent des solutions de façon simple et reviennent aux véritables activités qui consiste à réaliser “le produit qui tue”.

Allez-y ! Vous apprendrez ce dont vous aurez besoin au fur et à mesure, plus vite que vous ne l’avez jamais imaginé !

Auteur : Alan Dayley
Source : “BDUF Scrum” – Don’t do it!
Date de parution originale : 09 Juillet 2010

Traducteur : Nicolas Mereaux
Date de traduction : 24/11/2011

Licence Creative Commons
Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.