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.

« Planification du premier sprint | Page d'accueil | Test des applications WPF et XBAP »

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.

 

10:57 | Lien permanent | Commentaires (0) | Tags : Démarrage, Travail d'équipe, Sprint planning, Vélocité, reste à faire, feedback