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

20 septembre 2007

Premiere concrétisation de valeur

Cette semaine on est encore en mode formation, les ressources étant présentes à hauteur de 3 jours par semaine. Le projet a été lancer il y a plus de 10 jours et déjà nos gestionnaires ont hâte de voir quelque chose de concret. J'ai donc proposer à l'équipe de consacrer une journée à une grosse démo de formation où notre expert réaliserait un premier écran d'un bout à l'autre. De la BD à l'écran accèsssible par le fureteur web. Ce scénario à permet de :

  • mettre en lumière l'architecture prescrite par rapport aux notions théorique déjà présentées ;
  • démontrer concrètement ce qu'implique l'architecture choisie en terme d'efforts et d'outils (uniquement VisualStudio 2005 et Toad);
  • voir la quantité de code requise, incluant l'utilisation des composants réutilisables existants;
  • démontrer un premier écran hyper-simple, mais fonctionnel, de l'application finale;
  • démontrer l'utilisation de vraies données (issues de l'application que nous réécrivons)
  • vérifier l'installation des postes de travail et de l'environnement Team Foundation Server pour la gestion des sources;

Il faut lever notre chapeau à Alina, notre experte, qui a codé durant 6 heures une application de A à Z, sous le regard percant des 8 apprenants. La première demi-heure nous a permis de définir en équipe quel écran et quels informations seraient utilisées, de mêmes que les grands tâches requises pour arriver à montrer quelque chose de fonctionnel. Naturellement, elle avait un matériel de formation qui expliquait étape par étape quoi faire (qu'elle avait rédiger auparavant pour le bénéfice des apprenants) mais le défi était quand même là!

Elle à donc créé les éléments suivants:

  • La solution et les divers projets dans VisualStudio;
  • La base de données et la table requise;
  • Les objets d'affaires, essentiellement la "demande";
  • La couche d'accès aux données, avec Retina;
  • La facade de services web;
  • Le projet de test du service web;
  • La couche de présentation, un XBAP utilisant le CAB "composite application block";
  • Un version fonctionnelle dans le gestionnaire de source de l'équipe.

Voici un aperçu de l'écran:

d35b4491713b4c653684fb3ea1196a99.png

21 novembre 2005

Réflexes aux démarrage de projet

Ce matin, on démarre la réalisation d'un projet (maintenance évolutive), après avoir fait l'offre il y plusieurs semaines. Ce petit mandat, d'une vingtaine de jours, sera réalisé par une seule personne en quatre semaines.

Quels pratiques pourraient m'aider dans ce projet? Je retiens trois points: a) participation du client, b) engagement du réalisateur et c) planification et suivi par priorité client.

A) Le chargé de projet va prendre contact avec le client pour lui annoncer le démarrage et la date de fin prévue. Comme le client veut ça avant la fin d'année et qu'on va être capable de le faire, on part sur une note positive. Suggérons au client de s'impliquer, au moins à chaque semaine, idéalement au jour le jour. Proposons lui, de lui montrer ce qui est réalisé au fur et à mesure. Ça donne de la visibilité à l'avancement et ça nous donne un feedback sur ce que l'on produit et sur notre façon d'interagir avec lui. On pourrait, par exemple, arranger une conférence téléphonique en fin de journée pour faire le tour des travaux réalisés.

B) L'estimation des efforts a été réalisée par une tierce personne. Demandons au réalisateur, s'il se sent à l'aise avec les estimés. Quand je donne un estimé, je me sens plus "engagé" envers le projet, que lorsque quelqu'un d'autre fait l'estimation pour moi.

C) Assurons-nous que le plan est organisé de sorte que les fonctions prioritaires, celles qui ont le plus de valeur pour le client, sont réalisées en premier. Découpons le plan de façon à pouvoir montrer quotidiennement (ou aux 2-3 jours max) une fonction désirée par le client, quelque chose qui serait déployable. Démontrons cette fonction afin d'obtenir les commentaires du client (ici, prend la forme d'une acceptation). A chaque semaine, réévaluons la situation (estimé du reste à faire, priorisation des travaux, façons de faire).