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.

01 octobre 2007

Mon bilan de la première semaine de l'itération 1

Mon premier reflexe serait de pousser une soupir. Ce fut une autre semaine intense. Tous n'a pas fonctionné comme sur des roulettes, mais globalement c'est très positif. Et heureusement que tous ne fonctionne pas idéalement, là ça nous fait de la place pour s'améliorer!

Le niveau d'énergie est bon, la dynamique de groupe s'installe tranquillement mais non sans heurts. Je remarque comment nous avons une culture du travail autonome, i.e. que les personnes préfèrent travailler seul pour faire leur bout et que les gestionnaires préfèrent qu'il n'y ait qu'une personne par tâche afin de ne pas dépenser inutilement. Naturellement, je ne suis pas d'accord avec ce point de vue, surtout dans un contexte d'apprentissage. Néanmoins on devra probablement faire attention de laisser un peu plus de temps "isolé" aux personnes pour leur ménager un espace temporel et physique où elles peuvent réfléchir à leur rythme. Même moi j'ai besoin de ce temps pour prendre du recul par rapport à la situation. Le fait que les ressources sont à 3 jours-semaine apporte une pression importante à maximiser les efforts. Une pression peut-être indue.

La session de planification de l'itération s'est bien déroulée, en un peu plus d'une heure et nous a permis d'estimer les users stories en groupe en mode wideband delphi à main lever. On a ainsi décrit les fonctionnalités attendues et nous les avons priorisées. On a estimé notre vélocité à 36 points (dans notre cas des demi-journées idéales) et on a pris 27 points dans le backlog.

Le suivi quotidien du reste à faire nous a ammener à 27, 26, 32+, 32.5+. Le reste à faire augmente!!! Personnellement ça ne me surprend pas et plusieurs raisons peuvent expliquer la situation. On a observer:

- sous-estimation des efforts
- découverte de nouvelles  chose à faire en réalisant le travail
- ajout de tâches "externes" (architecte techno, DBA)

La sous-estimation des efforts est normale compte tenu que l'équipe a eut peu de temps pour le faire (on avait une proposition) et qu'ils sont peu habituer de le faire. Chez nous c'est le chargé de projet qui prend ça en charge dans bien des cas! L'autre éléments c'est que il y avait beaucoup de monde pour "décider" et peu de temps pour discuter.Il en va de même pour la découverte des nouvelles tâches. Je pense que la prochaine itération devrait être meilleure à cet égard car l'équipe aura une expérience de ce qui est attendu, de ce qu'on fait avec et de comment ça les concerne.

L'ajout de tâches externes n'est pas problématique puisqu'elle vient avec des ressources supplémentaires, donc notre vélocité est de fait augmentée.

Le reste à faire augmente aussi parce qu'on traite de sujet qui n'ont pas de rapport direct avec l'objectif de l'itération. Ce sont toutes des discussions intéressantes mais qui apporte peu en regard des objectifs court terme. C'est le cas en ce qui a trait à la modélisation. Actuellement, on est dans une logique de BDUF (Big Design UpFront) qui est un reflexe acqui ou au moins un conditionnement profond. Pour ammener l'équipe à "laisser émerger" l'architecture, on va avoir besoin de petits gains d'abord. Au reste je constate que l'architecture .NET est relativement lourde. Je comparais ce développement avec d'autres de mes expériences (Ruby on rails, Enhydra, ColdFusion) où en une journée ou deux j'avais un écran d'application fonctionnel .

Le suivi quotidien de cette première moitié de l'itération permet de déduire qu'on ne sera pas en mesure de tous livrer pour la fin de l'itération. Les plus audacieux pourrait aussi dire que ça augure mal pour ce qu'on a planifier pour le premier release (6 itérations) et ils n'auraient pas tord. Ce qui est intéressant c'est qu'on peu faire le constat après quelques jours seulement et qu'on peu d'ors et déjà prendre action. Ca vaut la peine de mentionné que le suivi ne porte pas de jugement, mais se veut une façon d'obtenir du feedback pour prendre action ("inspect and adapt") Dans notre cas je recommande de gérer les attentes de la gestion et de revoir le niveau d'engagment des ressources (le fameux 3 jr-sem).

La mécanique de suivi devra être expliquée plus en détail la semaine prochaine. J'ai eu l'occasion de le faire auprès de quelques personnes et liéaction est toujours positive.

Étant en apprentissage, nous avons diviser les 8 personnes en équipes de 4 avec un coach, pour la première journée et en équipe de 2 avec un coach depuis. Le modèle à 2 personnes fonctionne bien. Il faut cependant s'assurer d'une continuité lors du changement de paire. Il va falloir ce donner des règles (principes) de fonctionnement à ce sujet pour éventuellement en arriver au "shared code ownership". Pour le moment l'exercice montre que l'équipe ne fait pas encore corps, donc qu'on a une groupe et non une équipe. Notez que je ne porte pas de jugement, pour moi c'est simplement une progression normale.

Parlant de principe, lors d'une courte discussion avec le chargé de projet en faisant un premier bilan ensemble, nous avons identifié deux principes:

- ce sont les experts qui décident des orientations techniques
- un apprenant devra toujours accompagner un expert, i.e. un expert ne doit pas travailler seul.

Je proposerai lundi que ces principes soient proposés à l'équipe et mis en évidence quelque part sur notre radiateur d'information.

Parlant de radiateur d'information, celui-çi sert de plus en plus. Après avoir mis des diagrammes importants sur le mur et encouragé l'équipe à le faire, de nouveaux éléments pertinents sont apparu. Pratique à encourager.

 

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

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...)

11:15 Publié dans Scrum | Lien permanent | Commentaires (0) | Tags : Démarrage

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).