Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

24 septembre 2007

Sommes-nous agile?

Sommes-nous agile?

Le projet est démarré depuis quelques jours, et l'équipe a assisté à une présentation d'une heure sur Scrum. On est dans ce qu'on appelle une iteration 0, itération où dans notre cas on introduit l'équipe à plusieurs choses:

- l'équipe elle-même, puisse que les personnes ne se connaissent pas;
- les concepts de l'orienté objet, au moins un rafraichissement des notions;
- la technologie .NET, puisque peu ont des bases en C# et .NET;
- l'architecture distribuée et les services web;
- les possibilités de WPF et de xbap de .NET 3.0;
- l'application à réécrire;
- la notion de composant réutilisable.

On me demande "Jean, on applique l'approche agile, n'est-ce pas?".

Je réponds qu'il faut nuancer car on comprendra que dans ce contexte, il est difficile d'introduire en plus une nouvelle approche (Scrum et ses techniques: backlog, sprint backlog, user stories, mêlée quotidienne, burndown) et les techniques d'ingénieries appropriées (intégration continue, test-driven, test-first...). D'autant plus que le but ultime est de développer autour de la technologie et bâtir des composants réutilisables, avant de développer selon une approche agile. Autrement dit le but est de former et de réaliser des composants, le moyen étant de le faire de façon agile.

Donc comment être agile, du moins se mettre dans un esprit qui nous y fait tendre, sans adopter ces pratiques en bloc à priori?

Le premier élément que j'ai chosi, est d'établir un rythme autour d'itérations de deux semaines.

Le second élément est de rammener les actions de l'équipe dans le contexte de la valeur, du point de vue du client.

Ces choix sont d'abord stratégiques. Nous avons une pression importante de la gestion à démontrer un avancement, une progression. Le choix d'itérations de deux semaines permet de revenir rapidement à la gestion avec quelque chose de concret. Cette durée permet d'avoir un total de 7 itérations (0, 1 ,2, 3,4, 5,release) durant notre projet. Plus d'itérations serait difficile, d'autant plus que l'équipe est en partie à 3 jours-semaine. Plus long et on n'aurait pas suffisament de feedback sur l'avancement réel.

Le choix de la "valeur" va aussi dans ce sens. Il est primordial dans notre situation de montrer concrètement l'avancement de la réalisation de fonctionnalités reliés à l'application.

Ces deux éléments, rythme et valeur, représentent à eux seul un changement important pour l'équipe compte tenu de nos paradigmes existant et bien ancrés. Les courtes itérations donnent un cadre sur lequel le processus peut être constamment amélioré, adapté et qui supporte l'introduction graduelle des techniques. Le focus sur la valeur permet de focusser l'équipe sur les objectifs et de constamment recadrer les actions dans une perspective client.

Par exemple, tant qu'à regarder du code "exemplaire", pourquoi ne pas le faire avec le code de l'application proprement dite. Ainsi on démontre de la valeur au client par du code utile et par une formation spécifique aux besoins immédiats.

Pour revenir à la question de départ, "sommes nous agiles?", je dirais que non, puisqu'il manque énormément d'éléments de l'agilité, mais que dans le contexte et après une semaine, on aborde le problème avec deux des principes agiles (customer value, et l'adaptation par le feedback rapide des itérations).

On aurait pu considérer d'autres principes mais dans notre contexte et culture organisationnelle, ceux choisis m'apparaissent comme ceux qui permettent de démarrer rapidement et d'obtenir des résultats rapides. Ces autres principes seront introduit plus tard.

 

08:56 Publié dans Scrum | Lien permanent | Commentaires (0) | Tags : valeur, rythme, principes

09 décembre 2005

Un question de rythme

Hier, on en était à notre quatrième daily scrum, à l'heure prévue (11h30), il manquait un joueur. Que faire? Reporter le daily scrum à 13h30, alors que tous seraient présent? L'annuler, simplement (on se rencontre demain de toute façon)? Le tenir, avec des abscents? L'équipe penchait pour reporter en après-midi. Pas moi!

Plusieurs raisons me pousse à recommander la tenu à l'heure dite, ce sont: rythme, règles simples, planification, visibilité.

Les approches agiles ont des rythmes réguliers à diverses fréquences. Dans le cas de SCRUM, il y a le rythme quotidien, marqué par le daily scrum et le mensuel marqué par le début et la fin d'un itération. Si on brise le rythme, on risque de désynchroniser la machine. Le daily scrum à lieu à 11h30, comme la mort, c'est une des certitudes de la vie! Si on commence à les recéduler, à quel heure aura lieu celui de demain?

En Scrum, peu de règles encadrent nos processus, si on se permet de les briser à la première occasion, quel rigeur démontrons nous? Qu'est-ce qui nous garde du chaos? L'équipe s'est donné une règle en cas d'abscence physique, situation dans laquel la personne abscente participe par téléphone. Si la personne n'est pas disponible, elle n'est pas disponible, on s'en passe!

Le fait de planifier le daily scrum à heure fixe simplifie la planification, je sais d'avance que dans 12 jours, à 11h30, je suis en rencontre pour une dizaine de minute. Si j'ai un empêchement planifié, je peu planifier une façon de "participer" au scrum. Si c'est un empêchement imprévu, alors c'est imprévue, on vit avec!

Enfin, ça donne de la visibilité à l'abscence (et à la présence). C'est une bonne façon de voir la participation d'un individu (client ou réalisateur). Est-ce qu'il est souvent abscent? Quel en est la raison?