Scrum - Méthodes agiles

jeudi 26 juin 2008

Planification de l'itération

Bien avant de passer à Scrum, je faisais du processus itératif. J'ai encadré de nombreux projets qui appliquaient un processus itératif, genre RUP. Comme dans Scrum, il y avait une planification à 2 niveaux : plan grosses mailles pour le projet et plan détaillé pour l'itération. Le concept est le même, mais la façon de préparer le plan diffère, essentiellement sur 2 aspects :

  • le timing
  • la responsabilité

Côté timing, avec Scrum c'est simple : le plan de l'itération n se fait au début de l'itération n lors de la réunion prévue pour ça. Avec un processus plus axé sur le contrôle par la hiérarchie, le plan d'itération doit suivre un workflow de validation. Cela se passait à peu près comme ça, dans l'avant Scrum :

  • quelques jours avant la fin de l'itération n, le chef de projet prépare le plan de l'itération n+1,
  • lors de la revue de l'itération n, le plan de l'itération n+1 fait partie des livrables présentés au management,
  • compte tenu des retours faits lors de la revue, le chef de projet ajuste le plan.

Il fallait aussi prendre en compte les travaux effectués entre la date de la revue n et le début de l'itération n+1 (il pouvait s'écouler quelques jours)

Côté responsabilité, la planification est clairement l'affaire de l'équipe avec Scrum. Avant, le plan d'itération était de la responsabilité du chef de projet même s'il était dit explicitement dans le RUP que :

  • le chef de projet travaille en collaboration avec l'architecte pour définir le contenu de l'itération,
  • le plan d'itération doit être évalué en interne avant d'être présenté à une revue. Chaque membre de l'équipe doit adhérer aux critères d'évaluation et être d'accord sur le planning proposé.

La pratique Scrum d'une équipe autonome et responsabilisée rend caducs ces aller-retours entre le chef de projet, les membres de l'équipe et le management.

flèche Haut de page

mercredi 11 juin 2008

Compter les heures, c'est mal

Suite du débat...

Mon point de vue : trouver de l'intérêt dans le comptage des heures, c'est probablement le symptôme d'une mauvaise application de Scrum.

Lire la suite -->

flèche Haut de page

jeudi 29 mai 2008

Spécialistes ou généralistes ?

Les équipes agiles sont plus efficaces avec des généralistes ou des spécialistes qui se généralisent

Lire la suite -->

flèche Haut de page

jeudi 22 mai 2008

Pas de volontaire pour les tâches chiantes ?

La question ne se pose pas dans les équipes Scrum.

Lire la suite -->

flèche Haut de page

mardi 6 mai 2008

Des formations adaptées à chaque rôle

Tout le monde n'est pas ScrumMaster.

Lire la suite -->

flèche Haut de page

samedi 12 avril 2008

On refait la partie

Esprit d'équipe et rétrospective aussi pour le tarot

Lire la suite -->

flèche Haut de page

jeudi 27 mars 2008

Des équipes bien formées

Par Infoq, je viens de lire un article Well Formed Teams and Agile: An Opportunity to Thrive qui définit 3+2 attracteurs pour penser efficacement et constituer des équipes hyper-productives, comme dit Jeff Sutherland.

Etre guidé par le produit, travailler sur une chose à la fois en cycles courts (timeboxed) et garder le travail visible, ça fait partie de la base de Scrum. Le +2 est également favorisé par Scrum qui offre des canaux (la structure) pour favoriser les conversations.

L'article donne ensuite les caractéristiques communes des équipes qui sont considérées comme bien formées. La première est que l'équipe soit regroupée géographiquement dans un seul endroit (colocation). Je confirme absolument. Dans toutes les expériences récentes de mises en oeuvre de Scrum auxquelles j'ai participé ou qui me sont racontées, les difficultés les plus importantes sont venues d'équipes distribuées entre plusieurs locaux. Evidemment les problèmes sont décuplés si la distribution se fait sur plusieurs pays dans des continents différents, avec des horaires différents et des cultures différentes.

Ces organisations avec des équipes distribuées cherchent des palliatifs pour appliquer Scrum quand même, plutôt que de remettre en question la répartition des membres de l'équipe. Dommage que ce ne soit pas ceux qui connaissent Scrum qui décident...

flèche Haut de page

samedi 22 mars 2008

Les méthodes agiles, un héritage de mai 68

C'était hier une journée Mai 68 sur France Inter, qui a pris de l'avance en célébrant le 22 mars.

Lire la suite -->

flèche Haut de page

samedi 1 mars 2008

Evaluation de la collaboration dans une équipe

Le succès d'un projet repose largement sur les personnes qui y participent et sur la façon dont elles travaillent ensemble. Cela est bien connu mais pas toujours appliqué dans nos organisations hiérarchiques. Les méthodes agiles cherchent à favoriser absolument cette idée de collectif, à travers, notamment, les réunions et les travaux en groupe. Comment savoir si ça fonctionne ? Evaluez votre niveau...

Lire la suite -->

flèche Haut de page

mardi 16 octobre 2007

Travail collaboratif sur les projets

Avec la Bureautique2.0

Lire la suite -->

flèche Haut de page

vendredi 7 septembre 2007

Scrum for les bleus

Jour J pour la Coupe du Monde

Lire la suite -->

flèche Haut de page

mardi 28 août 2007

No scrum no win

C'est aussi vrai quand on applique Scrum que pour un match de rugby

Lire la suite -->

flèche Haut de page


Fatal error: Undefined class name 'bbclone' in /home/.sites/22/site13/web/dotclear/themes/ZenTheme_pour_package/template.php on line 214