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.

« Premiere concrétisation de valeur | Page d'accueil | Planification du premier sprint »

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