Catégorie : Agile

Le danger de la réévaluation des tâches…

Concernant la réévaluation des tâches lors du Scrum quotidien.

Après quelques semaines d’utilisation de Scrum, nous avons donné la possibilité aux membres de l’équipe de faire une réévaluation des tâches lors du Scrum quotidien.

Ceci avait pour but de prendre en compte tous les dépassements de durée sur les tâches.
Mais nous avons constaté un effet pervers : la réévaluation entraînait une baisse de la vélocité car elle devenait une facilité pour les membres de l’équipe et dégageait la pression positive créée par le Sprint.
Agilité bien ordonnée commençant par soi-même, nous avons donc décidé de revenir en arrière et de ne plus réévaluer les tâches 🙂

Scrum, un retour aux post-it …

Avec Scrum, les post-it en force …

Dans la méthode Scrum, toutes les users stories énoncées par le product owner dans son backlog sont découpées en tâches au début du sprint lors de la réunion de planification. Chaque tâche est estimée en heures et chacune doit faire moins de 16h afin d’éviter l’effet tunnel et de tourner en rond sur les problèmes.
Elles sont consignées sur des post-it qui évoluent dans 3 états :

  • A faire
  • En cours
  • Fini

Tous les matins, chaque membre de l’équipe fait bouger les post-it en fonction de ce qu’il a traité et des tâches sur lesquelles il s’était engagé la veille.
Il doit répondre à trois questions :

  • Qu’as-tu fais hier ?
  • Qu’est-ce que tu vas faire aujourd’hui ?
  • Quels sont les problèmes rencontrés ?

Une notion très importante que nous avions minimisé au début est la définition du terme « Fini » sur lequel l’équipe doit s’entendre. Que veut dire fini ? Une tâche est-elle finie quand le développement est fini ? Quand les tests sont validés ? Vaste débat …
Pour notre part nous avons opté pour la définition suivante. Une tâche est finie lorsque :

  • le développement est réalisé conformément au backlog
  • les tests sont réalisés conformément au backlog
  • elle est validée par le product owner

Un petit exemple de tableau des tâches Scrum :

Tableau des taches Scrum

 

Les users stories sont en vert et les tâches correspondantes en rose.
Les tâches de tests sont en orange. Les tâches en jaune sont des bugs.

Nous démarrons le sprint 8 aujourd’hui avec un beau challenge de 152 points sur 3 semaines avec les congés de chacun.

Affaire à suivre…

Organisation et méthodologie Scrum

Quelques retours sur notre organisation avec la méthode Scrum.

Nous avons mis en place la méthodologie Agile Scrum dès le début du projet de développement de l’offre ViaXeo.

Cette démarche est issue d’un constat sur nos vies antérieures et plus particulièrement sur les méthodologies de projets classiques. Ces dernières, souvent lourdes à mettre en œuvre et consommatrices de temps, ne nous permettaient pas d’obtenir les résultats escomptés.

Les phases de spécifications détaillées sont souvent lourdes, la validation des clients est partielle et le résultat ne correspond pas souvent aux attentes du client… et les problèmes commencent.

Dans un contexte tel que ViaXoft, jeune startup dynamique dans le tourisme, en pleine création d’une nouvelle application, nous avons décidé de mettre en place Scrum pour plus d’agilité.

Le principe de Scrum (mêlée en anglais) est de motiver une équipe autour d’un objectif commun pour réaliser ce dernier sur une courte période appelée Sprint.

Nous avançons donc au rythme de sprints de 2 semaines en nous focalisant sur des objectifs précis à chaque fois.

Après une petite phase de réglage, Scrum nous permet maintenant d’obtenir des résultats rapidement avec des premières fonctionnalités et des écrans clés de l’application.

Au début de chaque sprint, l’équipe s’engage sur la réalisation d’un objectif défini par le product Owner sous la forme d’un product backlog priorisé (liste de fonctionnalités). Le sprint est rythmé tous les jours par le « Scrum Meeting » où chaque personne de l’équipe explique ce qu’il a traité la veille, s’engage sur ce qu’il va faire aujourd’hui et expose les différents problèmes qu’il a pu rencontrer.

A la fin du sprint, le product Owner valide ou non les résultats lors de la présentation faite par l’équipe (Revue de Sprint).

La rétrospective qui suit la revue permet d’identifier ce qui a marché ou non sur le sprint et permet de mettre en place des actions correctives pour le sprint suivant.

Au-delà des aspects organisation interne, Scrum nous offre aussi plus d’agilité au niveau de l’implication client. Nous pouvons les faire participer plus activement à la construction du produit ViaXeo en leur montrant périodiquement les résultats obtenus par rapport à leurs attentes.

Pour conclure, je dirai que pour l’instant nous n’avons que des résultats positifs qui nous encouragent à continuer sur l’agilité et la méthode Scrum ….

A suivre

Loading...
X