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.

03 décembre 2005

Notre premier "Scrum planning"

Hier nous avons passer la journée en planification de notre premier sprint. Comme il s'agissait d'une nouvelle équipe nous avons débuté par identifier les règles qui nous régirait. Nous avons décider dans le contexte que la durée du spint serait de 2 semaines en raison de la petite envergure du projet. Nous avons décider de faire le daily scrum à 11h30 et que chacun devra mettre le reste à faire sur les items du sprint backlog à 11h00.

Nous avons ensuite identifié les personnes impliquées de près où de loin avec le projet et  déterminer leur rôles. Déjà cet exercice nous permet de voir que nous devrons rapidement les sensibiliser à notre façon de travailler et leur préciser nos attentes. Dans notre projet il y a:

  • 2 développeurs
  • 1 scrum master
  • 1 DBA
  • 1 Pilote (client)
  • 1 représentant de l'unité DSI
  • 3 personnes ressources

Il faut noter que nous avons identifié des personnes tout au long de la journée, à travers nos discussions.

Ensuite nous avons établi le product backlog à partir du dossier fonctionnel préparer lors d'une rencontre initial, il y a 2 mois, et de demandes suplémentaires relevée lors d'une rencontre de travail cette semaine. Seul un développeur était à cette rencontre avec le client. Cette discussion nous a permis de bien comprendre le contexte du projet. Malheureusement ni le client ni son représentant DSI n'était avec nous et nous avons dû faire des hypothèses sur plusieurs points (valeur, détails des fonctionnalités...). La photo suivante présente le product backlog qui totalise 30 points d'efforts.

medium_cimg0004_small_.3.jpgCette première phase de planification a débuter à 9h30 pour se terminer à 12h00. Le développeur principal devant s'absenter fréquemment (support d'implantation), nous avons pu avancé grâce à la présence dans la salle (sur un autre projet) de la personne qui avait fait l'estimé initial.

Après dîner nous avons travailler sur le sprint backlog. Nous avons estimé notre capacité à 36 points par sprint. Comme le projet fait 30 points, nous avons pris chaque item du product backlog et nous avons identifier les tâches et estimé les efforts en heures.

Cet exercice a été long à démarrer mais après une heure les choses allaient rondement. Beaucoup de questions sont ressorties et beaucoup d'échanges ont eut lieu, questionnant le contenu ou les statégies de solutions. Nous avons même découvert qu'une tâche était déjà complétée!

medium_cimg0003_small_.jpg

La photos montre le sprint backlog. Nous avons aussi vérifié si nos estimé en heures étaient comparable à notre estimation en point. C'était le cas.

 

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

15 novembre 2005

Photos de tableau blanc

Actuellement, nous planifions et replanifions le travail des prochaines semaines en collaborant autour d'un tableau blanc (Whiteboard). Ce plan à haut niveau change de semaine en semaine. Afin d'avoir beaucoup de flexibilité, nous travaillons directement avec des post-its sur le tableau et nous photographions le tout pour "documenter" le plan. En fait je devrais parler de stratégie.

Voici un exemple de photo (brut):medium_plan_sem_07_nov_v2_small_brut.jpg

La photo de gauche, plus bas montre la même photo, mais retouchée avec le logiciel Pixid Whiteboard Photo. Ce logiciel corrige la luminosité et les contrastes de couleurs en plus de corriger les distortions. medium_plan_sem_07_nov_v2.jpg