Manager une équipe de développement Web

Epopée ?

Comment traduisez-vous "epic", vous?

Mike Cohn, dans sa bible des "user story", évoque le terme "epic" lorsqu'une story est trop importante pour être intégré dans un sprint. Elle doit être décomposée en user stories plus fines. Par exemple "En tant qu'internaute, je souhaite réserver un voyage en ligne" est une "epic". Il parle aussi d'epic à propos de user stories très complexes, ou qui nécessitent de plonger dans l'inconnu, sans vraiment avoir la possibilité d'une décomposition simple en stories plus petites. Il faut alors tâcher de les décomposer en story d'investigation d'un côté, et de mise en oeuvre, de l'autre.

Dans un projet pour lequel j'interviens en phase d'étude de faisabilité technique, j'ai synthétisé l'ensemble des besoins clients en sept grosses "user stories". Je trouvais ce matin interessant de communiquer sur ces sept méga-stories, mais le terme "epic" ne me satisfaisait pas du tout. Autant, je trouve que l'expression "user story" est parlante en elle-même, et compréhensible pour tout un chacun, parce qu'on a tous vécu des love story, qu'on comprend globalement la signification des storyboards, et que même la notion de use case, finalement, est assimilée par un grand nombre de personne. Mais allez dire à votre boss "je découpe ce projet en 7 epics" sans qu'il lève le sourcil d'un air soupçonneux! Et osez poursuivre plus tard devant le Directeur métier ! A mon avis, on vous prendra vite pour un joyeux félé.

Après réflexion, j'ai adopté l'épopée ! On pense à la Chanson de Roland, à la quête du Graal d'Arthur, à la légende d'Yvain... une petite pointe d'héroïsme pas très éloigné du quotidien des projets informatiques.

Mon agenda aux TechDays 2008

Un agenda ambitieux! je ne suis d'ailleurs pas du tout certain de pouvoir y participer plus d'une journée.

De l'ASP.Net et du développement Web en plat de résistance, avec une bonne dose de SharePoint, un peu de SilverLight, de MS Commerce et de e-commerce DotNetNuke, du Map, du Virtual Earth, saupoudré d'une pincée de 2.0.

Voilà! Aux plaisirs de s'y croiser.

Rétrospective du troisième sprint

Lundi 21 janvier - bureau Développement Web - 11h/12h30.

La nouveauté : c’est l’arrivée de Vincent, qui vient remplacer Hayian pendant son congé maternité. Je suis assez impatient de voir comment l’équipe, qui en décembre a intégré Robin assez rapidement, va intégrer en deux mois d’intervalle un second changement.

Pour ce premier contact avec notre méthode « Agile », j’ai invité Vincent à s’asseoir autour de notre table ronde, pour participer, à titre de spectateur, à notre rétrospective de sprint et à la planification de l’itération suivante.

Ce qui s’est bien passé :

- Le binôme avec Robin sur le développement des encarts a bien fonctionné. Il s’agissait pourtant d’une optique ambitieuse, avec une refonte globale de développement très ancien, permettant l’extensibilité de ce contrôle. De plus, le couplage fort qui existait entre les encarts et la page appelante a été supprimé. (Jerry)
- Le binôme avec Jerry a bien fonctionné : les phases de travail en commun et de travail individuel ont été bien alternées. (Robin)
- Le gros challenge de ce sprint, avec 37 user story points, a été tenu. (Frédéric)

Ce qui n’a pas aussi bien fonctionné que ce l’on pourrait en attendre :

- Mise en pré-production assez tendue : la présentation a été faite cette fois ci sur l’environnement de pré-production, et non sur l’environnement de développement. Le délai était serré et cela a créé quelques tensions dans l’équipe. (Jerry)

Ce qui pourrait être amélioré la prochaine fois :

- Mises à jour dans TFS : la même remarque que lors du sprint précédent. Nous devons nous améliorer de façon concrète sur ce point précis. Car notre burdown chart avait vraiment une drôle de tête (Frédéric) :

- Mises en pré-production : les tensions rencontrées en fin de sprint pourraient être évitées en effectuant des mises en pré-production précoces, dès le premier sprint, afin de ne pas avoir un lot trop important de modification à mettre en ligne en une fois. Dans un second temps, nous devons aussi travailler à une automatisation des builds, puis des tests unitaires, afin de fluidifier ces mises en pré-production. (Frédéric)