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.

 

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.

086af15f750295ebd2b3428fb3ecc070.jpg

Du même projet, voici le sprint backlog d'une itération.

95641a101f2499b9316022242712c041.jpg

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.