« 2007-05 | Page d'accueil | 2007-10 »
24 septembre 2007
Planification du premier sprint
Demain matin se sera notre premier sprint planning, pour l'itération 1. Je ferai donc une courte introduction à ce qu'est le sprint planning pour l'équipe.
On a en main un premier backlog de produit, priorisé. On l'a même découpé en chunk de deux (2) semaines (grosso modo) avec des thèmes pour chaque itération et un release final dans la 6e itération.
Préalablement, j'ai reformuler les éléments du backlog en user stories dans la forme de "En tant que __acteur__ je désire __fontionnalité__ afin que __valeur__. J'ai esquissé pour 2 user stories le scénario de démonstration. J'ai aussi esquissé ce qui serait ma priorisation des users stories.
Le but du la rencontre de planification du sprint est de produire:
- un but pour le sprint;
- une liste des membres de l'équipe et leur niveau d'engagement;
- une liste des users stories, notre backlog de sprint;
- la date de la démo;
- l'endroit et le moment de la mêlée quotidienne.
La rencontre, comme la plupart des éléments dans les approches agiles est "timeboxé", i.e. la durée est définie à l'avance.
La rencontre se déroule typiquement de la façon suivante:
- Le propriétaire présente le but du sprint et les éléments du backlog de produit;
- Ensemble on détermine le moment et l'endroit de la démo, typiquement à la fin de l'itération, avant la rétrospective.;
- L'équipe estime et décompose les éléments au besoin. On explique les éléments à clarifier et on décrit comment le user story va être démontré;
- On sélectionne les users stories pour l'itération;
- On calcule la vélocité des tâches versus l'estimé des users stories.
- On spécifie le moment et le lieu de la mêlée quotidienne.
Voici un exemple de backlog de produit que nous avons réalisé dans une autre projet en décembre 2005.
Du même projet, voici le sprint backlog d'une itération.
21:15 Lien permanent | Commentaires (0) | Trackbacks (0) | Envoyer cette note | Tags : sprint planning, scrum, backlog
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.
14:56 Publié dans Scrum | Lien permanent | Commentaires (0) | Trackbacks (0) | Envoyer cette note | 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:
20:00 Lien permanent | Commentaires (0) | Envoyer cette note | Tags : simplicité, valeur, démarrage
13 septembre 2007
Démarrage et présentation de SCRUM
Cette semaine nous avons démarré un nouveau projet avec une équipe de 8 personnes, un chargé de projet, et 3 personnes "d'encadrement". Il s'agit d'un projet qui vise à former l'équipe à l'utilisation de .NET 3.0 et C#, une nouvelle techno pour la plupart des membres de l'équipe. Le projet durera trois mois et devra livrer des composants réutilisables et une application fonctionnelle en démontrant l'utilisation.
Pour mettre tous le monde dans le bain nous avons présenter une introduction à l'approche SCRUM à l'équipe en utilisant la présentation de Mike Cohn (ici). Cette présentation a été suivi d'un rappel des concepts de l'orienté objet. Dans les journées suivantes, l'équipe à assister à des présentations/vidéos animées par les experts (encadrement).
Cette première semaine (de 3 jours où les 2/3 des personnes étaient disponible) a visé à introduire l'équipe à .NET, à l'architecture à haut niveau et à présenter l'application à construire (il s'agit d'une application Access qui nous réécrivons en .NET avec WPF (XBAP), des services web et une BD Oracle.
Au cours d'une session de travail, l'équipe a identifié une liste de composants réutilisables (backlog) et les a priorisés.
En parallèle, on a procéder à l'acquisition des postes de travail et à leur installation. Le serveur Team Fondation Server était déjà fonctionnel, de même que l'environnemnent d'essais. On travaille avec VisualStudio 2005, .NET 3.0, Enterprise Library 3.0, Retina, Expression Blend 2.0 Beta.
On a aussi constitué un comité directeur des gestionnaires.
En résumé c'était le début de l'itération zéro 0, où nous avons:
- participation active des stakeholders
- définition des paramètres du projet (financement, ressources, portée, délais)
- construction de l'équipe (accueil et mise en contexte)
- modélisation initiale des spécifications
- modélisation de l'architecture générale
- installation des équipements requis (locaux, postes, téléphones...)
17:15 Publié dans Scrum | Lien permanent | Commentaires (0) | Envoyer cette note | Tags : Démarrage