Manager une équipe de développement Web

Revue du troisième sprint

Du 7 au 18 janvier - bureau Développement Web - 10h/10h15.

Les scrums quotidiens se suivent. Les tâches sont traitées selon un bon timing. Quelques tâches complémentaires apparaissent.

De manière tout à fait autonome, le binôme Jerry/Robin, coach/junior, expert/débutant perdurent et semble très bien fonctionner. Cette association s’est faîte de manière toute naturelle, sans qu’une directive quelconque du Chef de Projet impose la formation de ce binôme, car il est tout à fait naturelle, au sein d’une équipe qui tend vers un objectif unique et partagé, que l’expérimenté prenne en charge le profil plus junior, pour le rendre plus efficace et l’amener vers l’autonomie. 

Je suis personnellement très satisfait de cette tournure des évènements. L’auto-affectation des tâches signifie aussi l’auto-affectation des responsabilités. Notre nouvelle organisation permet à chacun de nous de travailler sur toute l’étendue de son talent individuel, et non uniquement selon les compétences perçues par le Chef de Projet.

Mais au fil du développement, nous nous apercevons d’un problème important concernant l’harmonisation des couleurs. Notre user story « En tant qu'internaute, je vois un look & feel homogène.» n’était pas du tout une bonne user story. Dans notre esprit, elle voulait dire « modifier les homes pour prendre en compte le nouveau design ». Car le nouveau design concernait seulement ces pages. Mais que doit-on faire sur les autres ? Du point de vue de l’internaute, ce look & feel homogène doit bien être présent sur l’ensemble du site. Mais cela impose donc une réflexion plus fine, et plus de temps de mise en œuvre.

Je remets la discussion de ce point à notre revue de sprint. D’un côté, je sais que ce n’est pas très « agile », dans le sens où j’introduis ici un effet tunnel : on développe, et le jour de la présentation, je soulève un problème comme un lapin de mon chapeau. Mais de l’autre, j’ai quand même une raison de procéder ainsi : nouveau et ancien design ne sont pas totalement incohérent l’un avec l’autre, et l’internaute n’aurait pas été « choqué » de naviguer dans un premier temps sur un mélange des deux design. Je préfère donc discuter ce point de manière collégiale, laissant à Christophe le choix de trancher entre « arrêter la release et mettre en ligne la semaine prochaine, avec un mélange de l’ancien et du nouveau design sur certaines pages » et de l’autre « aller jusqu’au bout du changement de design et arrêter la release au sprint suivant ».

Vendredi 18 janvier - bureau Développement Web - 12h.

Un mauvais point pour moi !

François, notre analyste métier, passe en coup de vent me voir pour me demander si je peux repousser le début de la revue de sprint de 14 heures à 14 heures 30. Comme je crois ne pas y voir d’inconvénients, j’accepte.

Un peu plus tard, Christophe m’appelle pour m’indiquer que ce décalage d’une demi-heure ne l’arrange pas du tout car il a ensuite un autre rendez-vous. Il ne pourra donc pas assister à l’ensemble de la revue.

Agile, oui ! Laxiste, non ! On ne m’y prendra plus : les grandes étapes collaboratives ne doivent en aucun cas être déplacées, décalées ou supprimées.

Vendredi 4 janvier - bureau Développement Web - 14h30/16.

Je convie Olivier à notre présentation, et nous commençons donc sans Christophe, et pour continuer dans les mauvaises habitudes, j’effectue une nouvelle fois la présentation. 

Je rappelle tout d’abord notre objectif de 5 user stories, dotées de 37 user story points. Cette fois, nous avons pu tout terminer. 37 points dans la caisse ! Sur trois sprints, cela nous donne donc une vélocité moyenne de 26 points par sprint.

Lors de la démo, c’est essentiellement Françoise, notre graphiste, qui émet des remarques, toutes pertinentes. Je les note au fur et à mesure, pour en faire des fiches de bugs.

J’évoque ensuite le problème constaté sur la cohérence de l’ancien et nouveau design. Après débat, nous sommes tous d’accord pour deux semaines d’effort complémentaire au titre de la release courante. Cet effort nous permettra, entre autre, d’aller jusqu’au bout du nouveau look & feel et d’allonger la période de tests.

Nous écrivons une nouvelle user story « En tant qu'internaute, je navigue sur un site cohérent du point de vue de la charte graphique ». On s’aperçoit de la difficulté d’écrire une user story relative au design.

Planification du troisième sprint

Lundi 7 janvier - bureau Développement Web - 9h30/11h00.

Nous voici donc déjà à notre troisième réunion de planification de sprint, la dernière avant notre première release.

Sachant que Mélanie doit nous fournir les textes pour alimenter les éditos, Jerry suggère d’intégrer dans ce sprint la user story « En tant que gestionnaire de contenu, je veux contextualiser les contenus multimedia ». Mélanie pourra ainsi rédiger et saisir ses contenus de manière autonome, sans devoir nous demander à chaque modification de les réintégrer dans la base de données. Nous sommes tous d‘accord avec Jerry, même si cela nous impose plus de développement au départ, nous serons vite gagnant côté développement, et ce sera plus gratifiant pour Mélanie d’être complètement indépendante.

L’équipe est ambitieuse et pleine de volonté. Elle s’engage donc à effectuer 5 user stories, pour une vélocité anticipée de 37 user story points ! Pourquoi pas, le challenge est motivant. Dès la fin de la réunion, Hayian s’attaque à la Master Page, pour coder en feuille de style le nouveau design. Jerry et Robin s’associent pour s’attaquer aux « bonnes affaires ».

Rétrospective du second sprint

Lundi 7 janvier - bureau Développement Web - 9h/9h30.

Une rétrospective assez rapide, puisque seuls Jerry et Robin y ont participé réellement.

Ce qui s’est bien passé :

• Du fait des vacances, était-il judicieux de maintenir un sprint? : Le sprint 1 était assez court, du fait de Noël et du jour de l'an, et des congés des uns et des autres, qui a nécessité de la part de Jerry d'effectuer beaucoup de tâches de production et peu de projet. On peut donc effectivement se poser la question de la nécessité d'un sprint sur 15 jours. Cependant, deux user stories ont été effectuées pendant ce sprint : le plan du site et la home avec les entrées générationnelles. Donc, le sprint a en fait eu sa dose d'efficacité. Je ne suis pas certain que sans sprint, autant de travaux auraient été effectués.
• Refactoring, partage et apprentissage : Robin a eu l'impression de faire un peu de travaux en double, mais le fait de développer d'abord, puis de prendre ensuite des conseils auprès de Jerry pour refactoring et adaptation pour intégrer les bonnes pratiques a été instructif.

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

• Mises à jour dans TFS manquantes : il aurait été bien de mettre à jour au fur et à mesure l'avancement des travaux dans TFS pour obtenir un Brundown Chart plus intéressant.

Revue de sprint

Vendredi 4 janvier - bureau Développement Web - matin.

Une matinée studieuse.

Robin manie son Tree View avec dextérité, et réussi à rendre présentable son plan du site.

Jerry, après quelques efforts sur les feuilles de style, parvient aussi à faire une Home impeccable.

Ouf ! On peut y aller.

Vendredi 4 janvier - bureau Développement Web - 14h/15h30.

Je n’invite cette fois-ci aucun collègue de la DSI, mais je convie en revanche Erwan, qui vient juste de rejoindre l’équipe Multimedia, et Françoise, qui a effectuer le design de la home. Par ailleurs, Mélanie, absente la fois précédente, est bien présente.

Au départ, nous avions un objectif de réalisation de quatre user stories. Nous en avons terminé  deux. Notre vélocité a donc été de 16 story-points lors de ce sprint. Elle avait été de 26 lors du sprint précédent. Ce n’est pas si mal, finalement, sachant que la moitié de l’équipe était en congé, sans compter Noël et le Jour de l’An.

Je me charge une nouvelle fois de la présentation, prenant ainsi le pli d’une mauvaise habitude…à corriger lors d’une prochaine présentation.

En faisant cette présentation, je m’aperçois finalement que l’équipe a bien avancé, et que mes sentiments de la veille étaient plutôt dénué de fondement. Nous disposons d’une nouvelle home, conforme, à quelques détails, près au design demandé, et surtout, proposant toutes les nouvelles fonctionnalités attendues. De même, le plan du site propose une navigation adaptée à la nouvelle structure du site, tout en ayant été bien dépoussiéré par Robin, qui l’a entièrement réécrit à partir des nouveautés du framework ASP.NET 2.0 en utilisant des contrôles Tree View.

La présentation permet aussi à Mélanie d’exprimer quelques réserves sur le choix de certains visuels. Elle mentionne un travail effectué par ailleurs, qui pourrait être réutilisé dans ce cadre.

Enfin, Christophe et Françoise nous dévoilent le design des « homes » intérieures : il y a le menu, mais aussi le style des éditos, la présentation des bonnes affaires, la modification complète du menu annexe. En résumé, d’importante modification de présentations, que nous synthétisons dans la nouvelle user story : « En tant qu’internaute, je vois un look & feel homogène », user story dont je ne suis pas particulièrement fier, et l’avenir me permettra de comprendre pourquoi.

Je sors de cette revue de sprint le moral au beau fixe. La présence de Françoise a permis d’enrichir encore la portée de nos échanges autour du projet et du partage de sa vision.

Retour de congés

Jeudi 3 janvier - bureau Développement Web - 10h/10h20.

Je rentre après 10 jours de congés de fin d’années. Comment vais-je retrouver mon équipe ? Comment les développements ont-ils avancé ? J’avais confié avant de partir l’animation des scrums du matin à Jerry, mais je me sentais quand même un peu comme un chien de berger cher à Ken Schwaber, ayant abandonné le troupeau dont il a la charge pour gambader dans la prairie.

Jerry avait noté jour après jour le travail effectué et les éventuels problèmes rencontrés, par Robin et lui-même. Plusieurs sentiments contradictoires se sont alors mélangés :

• J’étais très content de son initiative,
• J’étais très satisfait aussi de constater qu’en mon absence, les échanges quotidiens avaient bien été respectés,
• En revanche, j’avais l’impression que peu de choses avaient avancées,
• Et que surtout, beaucoup de problèmes de production les avaient empêchés d’avancer comme ils l’auraient souhaité,
• Enfin, le suivi des tâches dans TFS n’a pas été mis à jour régulièrement, donnant un Sprint Burdown Chart en plateau :

Il reste une journée avant le sprint review. Je regarde le plan du site de Robin et j’y vois des problèmes de présentations, dans le choix des couleurs, dans la disposition des rubriques. J’insiste bien sur le fait que nous ne montrons que ce que nous pourrions mettre en production. Le plan, en l’état, ne me semble guère présentable.

Je regarde ensuite la Home de Jerry et je m’aperçois tout de suite d’un problème dans la gestion des Roll Over sur les vignettes. Jerry ne s’en était pas aperçu, étant dedans à temps plein. Pourra-t-il corriger ?

A vrai dire, j’ai quand même un coup de stress à ce moment là. Que va-t-on pouvoir montrer demain ? Rien ! Dois-je annuler la revue de sprint ? C’est la tempête dans mon crâne.

Planification du second sprint

Jeudi 20 décembre - bureau Développement Web - 14h/16h.

Pour notre seconde réunion de planification de sprint, l’équipe s’est légèrement modifiée par rapport à la première fois. Mina, de « Pig » devient « Chicken », et Robin passe « Pig ».

J'emprunte ici à Mike Vizdos sur son blog www.implementingscrum.com/blog/index.php l'une de ses admirables planches de BD pour illustrer le propos qui précède.

Nous reprenons notre paquet de carte « planning poker » et j’explique à Robin, nouveau dans l’équipe, le fonctionnement de la méthode de planification.

Nous arrivons assez vite aux chiffrages de nos nouvelles user stories.

Le plus important reste à faire : planifier le prochain sprint. Un sprint assez spécial, car il englobe Noël et le Jour de l’An, et tous les congés des uns et des autres. On se pose donc la question de l’opportunité de sa mise en place. Je reste ferme, insistant sur l'importance du rythme imposé par la succession des sprints, craignant que si le rythme est cassé dès notre seconde itération, le risque est grand de ne jamais en voir de troisième…

Nous sélectionnons les quatre user stories, en fonction des priorités discutées la veille lors de la revue de sprint, après avoir découpé en tâche les deux nouvelles users stories.

Nous mettons à jour notre radiateur d’information. Pour prendre en compte la remarque d’Hayian, nous écrivons les tâches sur des post-its roses, au lieu des anciens post-its verts, en tâchant de nous appliquer.

De même, le sprint est créé dans TFS, avec les tâches associées.

Notre première rétrospective de sprint

Mercredi 19 décembre - bureau Développement Web - 16h/18h.

La revue de sprint juste terminée, nous nous réunissons de nouveaux autour de notre table ronde, mais cette fois entre membres de l’équipe de développement uniquement, en dehors de Mina qui est excusée, pour notre première rétrospective.

L’idée est simple : nous avons travaillé quinze jours de manière soutenue. Nous avons présenté ce que nous sommes parvenu à terminer. Il est utile de faire un petit break et d’échanger sur ce que nous pensons s’être bien passé, ce qui pourrait être amélioré et ce qui ne s’est pas si bien passé que cela.

Tour à tour, nous prenons la parole.

Ce qui s’est bien passé :

• Bon ressenti externe : à travers les échanges avec certaines personnes de la DSI, on constate un bion ressenti de notre méthode de travail. La communication effectuée a suscité curiosité et intérêt. Mon boss m'a même demandé à ce que l'idée du journal de bord soit poursuivie. De même, la réunion de revue du Sprint s'est déroulée dans une très bonne ambiance. (Frédéric)
• Adaptabilité immédiate : La modification de la segmentation en cours de sprint a été faite instantanément, montrant bien comment la méthode nous permet une complète adaptabilité - agilité! (Hayian)
• Partage des tâches : Le partage des tâches lors des scrums du matin, l'intégration de toute l'équipe, la visibilité, le radiateur d'information, tous ces éléments sont très bien. (Hayian)
• Visibilité sur le projet : Le fait de suivre le projet au jour le jour par l'intermédiaire des scrums du matin permet d'avoir une très bonne visibilité. Cela a été apprécié par toute l'équipe. Cette technique contribue à lutter contre l'effet tunnel individuel du développeur scotché à son guidon, qui ne voit pas forcément comment avancent les autres. (Jerry)
• Utilisation de Team Foudation Server : L'utilisation de Team Foudation Server concernant la gestion des tâches est très appréciable. (Jerry)
• Répartition naturelle des tâches : La répartition des tâches lors des réunions (Scrums) du matin s'est faîte naturellement. La méthode garantit bien une auto-affectation logique et cohérente des tâches. (Jerry)

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

• Estimation des charges associées aux tâches : Il semble que les estimations associées aux tâches de développements aient été un peu trop optimistes, alors que les charges associées aux tâches liées à la base de données aient été un peu trop pessimistes. (Frédéric)
• Dépasser le cadre de l'équipe DSI : La question qui se pose est de comment associer plus fortement à la démarche méthodologique d'autres profils au delà de l'équipe WEB DSI. (Frédéric)
• Tâche sur post-it pas très lisible : Les tâches écrites à la main sur les post-its vert ne sont pas très lisibles. Il serait bien de les imprimer à partir de TFS et de voir comment les afficher sur le radiateur d'informations. (Hayian)

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

• Non disponibilité des créas : Le fait que les créas n'est pas été livrée à temps nous a empêché de terminer le sprint. Nous aurions pu faire plus sinon. il faudrait voir comment améliorer cette partie du process. (Jerry)

Bien entendu, toutes ces informations sont entrées dans Team Foundation Server :

Puisqu’on parle de TFS, voici le profil du Sprint Burdown Chart de la fin du sprint :

Notre première "Sprint Review"

Mercredi 19 décembre - bureau Développement Web - 14h/16h.

Pour cette première revue de sprint, j’avais convié nos collègues de la DSI à participer à la présentation de nos développements. Je suis heureux d’accueillir le DSI et les deux chefs de projets.

Côté métier, Christophe et François sont présents. Côté développement, Haiyan, Mina et Jerry. Robin, qui vient d’intégrer l’équipe, assiste aussi.

Je rappelle l’objectif principale de la réunion : présenter les fonctionnalités, nos fameuses user stories, que nous avons pu développer entièrement. J’explique que je prends cependant quelques libertés avec ce qui se fait habituellement en présentant tout de même ce qui n’est pas terminé du fait du design. Je précise bien que normalement, nous ne devrions présenter que ce qui est terminé, et qui peut être mis en production tel quel.

Comme c’est la première fois, je fais cette présentation. La prochaine fois, ce sera quelqu’un d’autre de l’équipe.

Au départ, nous avions un objectif de réalisation de quatre user stories avec un total de 34 stort points. Nous avons finalement terminé deux user stories, pour un toal de 28 points.

Une user story de 3 points a été terminé du point d evue développement, mais le design reste à faire. Nous la montrons quand même, car il s’agit plus que d’y ajouter les CSS.

Enfin, ce que nous n’avons pas fait : une user story de 3 points.

En terme de vélocité, le terme utilisé pour résumer notre rythme d’avancement, elle se situe donc pour l’instant à 28 story-points. Ce chiffre doit petit à petit se préciser au fil de notre avancée.

Après la démo, les personnes conviées non directement impliquées dans le projet s’en vont. Nous évoquons alors la préparation des quinze jours à venir, avec la définition de 5 nouvelles users stories.

Puis Christophe nous présente le design de la home, définitivement validé, qui nous pourrons donc intégrer à nos développement dès l’itération suivante.

Le Manager agile

Au début, juste après avoir commencé la lecture du livre de Jérôme Barrand, "Le Manager Agile", j'avais eu quelques regrets d'en avoir fait l'achat. Car cet ouvrage s'adresse au directeur général d'une entreprise, à un manager de haut niveau qui souhaiterait impulser une nouvelle dynamique de management par la posture "agile".

J'étais donc un peu désappointé. En tant que responsable de développement informatique, ce livre était a priori hors de mes compétences.

Puis après l'avoir laissé trainer quelques mois sur une étagère, je l'ai ouvert de nouveau. Cette seconde lecture m'a semblé beaucoup plus enrichissante que la seconde. Je conseille donc cet ouvrage, pour tout les managers informatiques intéressés par l'agilité, et qui sont prèts à prendre un peu de hauteur, et s'interroger sur la signification pratique de la posture agile, en tant que principes généraux de management d'entreprise. L'écriture est parfois rude, mais le contenu est passionnant.

Le coeur de l'ouvrage dresse des outils d'aide au diagnostic d'agilité d'une organisation. Comme on peut s'en apercevoir assez vite, la mise en place de Scrum au sein d'une équipe de développement permet, à son niveau, d'atteindre l'ensemble des critères énoncés.

En voici la synthèse.

D'abord, les septs critères de définition d'une stratégie agile :

• un processus participatif de prise de décision : autrement dit, adieu le roi de droit-divin!
• un partage de la finalité : la mise en avant de la coopération doit être mise en avant, à tous les niveaux de l'entreprise.
• le leadership : c'est le Scrum Master, c'est Pablo Correa avec l'équipe de foot de l'AS Nancy Lorraine, c'est le chef de convoi cher à Jean-Claude Denis dans ses formations au management
• l'évaluation de la performance : on passe du contrôle à la mesure, du résultat au fonctionnement, de la performance individuelle à la performance collective. La victoire est celle de l'équipe, et non celle du Directeur Générale ou du chef de projet.
• la reconfigurabilité des ressources : la stratégie doit développer les ressources de l'entreprise en pensant à l'adaptabilité de ces ressources selon le contexte et l'environnement.
• la création de valeur : innover, innover, innover mais innover pour augmenter la satisfaction client.
• l'intensité des coopérations : stimuler toujours et encore la coopération entre les services, les personnes, les disciplines, horizontalement et verticalement.

Après la stratégie de l'entreprise, ce sont sept principes agiles auquel il s'agit de vérifier l'adhésion :

• l'anticipation
• la coopération
• l'innovation
• la culture client
• la culture du changement : le changement n'est pas une menace, mais une extraordinaire opportunité de progrès
• l'offre globale : au delà du produit, apporter aux clients services, coopération, relation privilégiée, respect, partage ...
• la complexité réduite à l'échelle humaine

Après les principes agiles, il faut se poser la question des comportements agiles, décrits selon cinq critères :

• le partage
• la confiance
• la responsabilité
• l'hybridation : la performance est toujours le résultat du mélange des profils, des compétences, des envies, des motivations (celà ne vous rappele pas les qualités d'une Scrum Team?)
• l'aptitude au changement : sur cette aptitude face au changement, Jérôme s'oppose à l'attitude classique de "gestion du changement". Il ne faut pas gérer le changement, mais bien vivre avec une culture du changement, et prendre conscience que le changement est une source intarissable d'enrichissement personnel et collectif.

Et pour finir, au quotidien, dans les pratiques de l'entreprise, statégie agiles, principes agiles et comportements agiles définissent des pratiques managériales, qu'il convient de mesurer selon dix critères d'agilité :

• le fonctionnement par processus : chaque acteur d'un processus est évaluer par l'acteur amont et l'acteur aval, et non plus par le supérieur hiérarchique
• la symbiose environnementale : savoir faire, réagir, anticiper de manière proactive
• la modularité synergique : une organisation mobile, ni verticale, ni matricielle, mais plutôt neuronale
• l'autonomie
• la pédagogie managériale
• la communication
• l'interopérabilité
• la veille
• les dynamiques collaboratives
• les perspectives d'épanouissement

En conclusion : l'entreprise Scrum est une entreprise agile. Alors, parlera-t-on bientôt du Scrum Master de Total ou du Scrum Master de Vinci ?

Proactivité envers le changement

Mardi 11 décembre - bureau Développement Web - 15h.

François, notre business analyst, nous annonce, assez embêté, que notre directrice marketing, après avoir vu les créas, n’est pas d’accord sur l'option de segmentation qui a été suivie, pour tun ensemble de raisons qui me paraissent par ailleurs tout à fait justifiées.

J’évoque ce fait nouveau avec Hayian et Jerry. Nos premiers réflexes archaïques de Maîtrise d'Oeuvre du style, « ce n’était pas au cahier des charges », « on ne peut pas faire sans exploser les délais » et « on a déjà commencé, c’est trop tard » passés, nous menons une réflexion rapide sur ce que cela peut impliquer.

Fondamentalement, comme nous avons travaillé par user story, cette nouvelle donne ne change rien, les user stories sur lesquelles nous avons déjà bien avancé restent exactement les mêmes.

Mardi 11 décembre - bureau Développement Web - 16h.

Nous nous réunissons, Christophe, notre product owner, François, notre business analyst, et moi-même, qui fait donc office de scrum master "non certifié", autour de notre petite table ronde. Je demande à Hayian et Jerry de rester à l’écoute et d’intervenir éventuellement.

Christophe nous résume la discussion qu’il a eu avec sa directrice, suite à la vision des créas, et demande s’il est possible techniquement de revoir la nomenclature initiale. Je réponds que cela n’est pas vraiment problématique, que notre réflexion en terme de user story nous permet de mieux anticiper ces changements. Nous ne craignons plus les changements, car nous sommes prêts pour les traiter !

Mercredi 12 décembre - bureau Développement Web - 10h.

Notre réunion du matin nous permet de prendre en compte les impacts de la modification de la veille : nous rajoutons une tâche de 2 heures concernant la redéfinition des données et de leur documentation. Hayian et Jerry estiment de leur côté qu’une heure de temps reste sur chacune de leur tâche lié au moteur de recherche et au menu.

Conclusion

Dans un schéma classique, avec cahier des charges à dimension contractuelle, spécifications détaillées, conception et planification par les tâches, une évolution du besoin comme celle-ci aurait posé plusieurs problèmes :

• avec les effets « tunnel » courant dans ce style de schéma, il y aurait eu un risque élevé que l’évolution du besoin n’apparaisse que lors des premières phases de recette, c’est-à-dire bien après toutes les phase d’études diverses et variées, de rédaction de cahier des charges (car un besoin comme celui-la n’est jamais visible dans la littérature touffue d’un cahier des charges, aussi bien fait soit-il), de conception du modèle de données, de conception du modèle objet, de codage, etc …
• une tension serait apparue entre le service demandeur, le pilotage de la maîtrise d’œuvre et le prestataire.
• après, plusieurs options :
  - l’évolution du besoin n’est pas prise en compte, le service demandeur est frustré, et les retombées attendues du projet sont absentes,
  - l’évolution du besoin est prise en compte, à un coût prohibitif, nouvelle source de tension entre la maîtrise d’œuvre et le prestataire, et le ROI ne sera pas celui escompté
  - l’évolution du besoin est prise en compte, sans surcoût, mais vite fait mal fait, source de bugs, de nouvelles tensions, etc …

Or, si le besoin « client » ou « utilisateur » est celui-là, à quoi cela sert-il de développer quelque chose qui n’y corresponde pas ?

Nos trois premiers scrums du matin

Jeudi 6 décembre - bureau Développement Web - 11h/11h10.

Photo © Bernard Flenet
Nous sommes de nouveau réunis ce jeudi matin, Mina, Haiyan, Jerry et moi-même, mais cette fois debout face au radiateur d’informations.

Mina nous dit qu’hier, elle a pu terminer la création des nouvelles tables (tâche estimée à 4 heures) en dehors de la documentation et qu’aujourd’hui, elle s’attaquera à l’alimentation des nouveaux critères, tâche qu’elle pense pouvoir terminer (tâche estimée à 2 heures).

Jerry n’a rien fait hier concernant le projet mais aujourd’hui, il peut s’y attaquer. En étudiant, les tâches affichées sur le radiateur d’information, il lui semble optimal de s’affecter la tâche de création du nouveau menu. Cette tâche estimée à 8 heures est indépendante des autres et il peut très vite mettre en œuvre le menu.

Hayian n’a rien fait hier sur le projet et ne pense pas pouvoir effectuer quelque chose aujourd’hui.

De mon côté, j’explique que je suis en train de prendre en main Team Foundation Server pour la saisie des user stories et des tâches. Je m’occuperai de la documentation des nouvelles tables pour permettre la fermeture de la tâche initiée par Mina.

Vendredi 7 décembre - bureau Développement Web - 10h/10h10.

Mina et Jerry sont en congé. Nous ne sommes donc que deux ce vendredi matin devant le radiateur d’informations. Mais nous savons que Mina a terminé l’alimentation des tables.

Hayian est fière d’annoncer qu’hier, finalement elle s’est affectée la tâche d’évolution du moteur de recherche et a pu commencer à analyser la nouvelle structure et les données de Mina. Elle pense qu’il lui reste encore 7 heures de travail, sur les 8 estimées au départ.

En cours de journée, Hayian me demande deux fois de l’aide :

- nous échangeons quelques temps sur notre compréhension mutuelle des nouvelles options du moteur et de la structure de donnée. Le chemin pensé au départ s’avère une fausse route : ce n’est pas grave, la bonne solution parait en définitive plus simple, et surtout, le temps passé a permis de mettre au rebut une mauvaise solution.
- certains cas manquent dans la base, ce qui empêche Hayian de tester correctement sa procédure stockée. Je la libère aussitôt de ce problème pour lui permettre de se concentrer sur son développement.

Lundi 10 décembre - bureau Développement Web - 10h/10h10.

Mina est en congé. Hayian, Jerry et moi-même nous retrouvons devant le radiateur d’information.

Hayian explique le temps passé à explorer une fausse piste. Elle pense qu’il lui reste encore 5 heures sur le moteur de recherche, ce qui pourra être fait dans la journée.

Jerry nous dit que jeudi, il avait pu construire le fichier XML de configuration du menu, et la structure associée. Il pense finir aujourd’hui les 4 heures nécessaires à clore cette tâche. Mais il ne peut pas s’engager à prendre une autre tâche, car il doit procéder le matin à une importante mise en production technique par ailleurs.

Notre radiateur d'informations

Afin de conserver à chaque instant une vision claire du projet et de son avancement, Jerry et moi-même construisons un radiateur d’informations sur le mur vitré de notre bureau. Quelques feuilles A3 scotchées au mur, puis nous choisissons des post-it jaunes pour les user stories, et des post-it verts pour les tâches. Les user stories (post-it jaunes) sont disposées horizontalement par ordre de priorité sur la ligne du haut : on y retrouve leur intitulé, leur priorité, leur charges relatives en user story points et leur numéro d’identification dans Team Foudation Server. Sous chaque user stories, nous disposons les tâches associées, avec leur charge.

Bien entendu, les post-it peuvent s’envoler, se décoller…et toutes cette information est aussi disponible au sein de Team Foundation Server. Le cube Olap Services de Sql Server nous permet de générer un grand nombre de rapports, de listes de user stories et de tâches associés, de calculer et d’estimer notre vélocité. Tous ces rapports sont disponibles au sein de Visual Studio, dans l’espace de travail des développeurs, mais aussi sur le site Share Point du projet, pour être accessible de toutes les personnes intéressées par le projet. On peut y voir par exemple un aperçu de notre vélocité.

Ou encore, on peut y retrouver à tout instant une photo des tâches en cours, de leur affectation, du temps estimé et du temps restant.

Notre tout premier sprint !

Mercredi 5 décembre - bureau Développement Web - 14h/15h.

Nous sommes de nouveau réunis autour de notre petite table ronde : Mina, Haiyan, Jerry et moi-même. Nous choisissons de planifier nos deux prochaines semaines. Cette planification consiste à prendre les user stories selon l’ordre de priorité défini par Christophe, de les découper en tâches, de les chiffrer en heures, et de nous arrêter quand il nous semble que nous ne pourrons pas en faire plus. En terme Scrum : il s'agit de mettre en place notre premier Sprint.

Au préalable, nous étudions quelles sont nos capacités individuelles en nombres d’heures quotidien pour travailler sur ce projet, sachant que même à temps plein, il est rare de pouvoir dépasser 6 heures de temps utile en moyenne, car il y a toujours des emails à traiter, quelques coups de fils, des réunions, des bugs à corriger, etc …

Nous évaluons nos capacités respectives à :

- Haiyan : 5 à 6 heures par jour
- Jerry : 5 à 6 heures par jour
- Mina : entre ½ et 1 heure par jour
- moi-même : entre 2 et 3 heures par jour.

Ensuite, concernant le découpage d’une user story en tâches, nous nous mettons d’accord pour ne pas dépasser 16 heures.

Enfin, s’agissant d’un travail en équipe, comme pour l’estimation, le consensus doit être atteint pour valider le découpage en tâche.

Nous commençons par le découpage de notre plus grosse user story, la plus risquée aussi, en terme d’impact. Nous trouvons 9 tâches, pour un total de 36 heures effectives, y compris une tâche de 4 heures de test d’intégration permettant de valider la user story.

Nous nous arrêtons sur le découpage de user stories, avec un total de 74 heures effectives, à répartir sur les deux prochaines semaines.

Je saisis l’ensemble de ces informations dans Team Foundation Server, via le template ScrumForTeamSystem de Conchango. Je choisis d'appeler ce premier sprint "Sprint 0".

Estimation relative de nos premières "user stories"

Mercredi 5 décembre - bureau Développement Web - 10h/11h30.

Nos User Stories en poche, il s’agit ensuite pour nous, développeurs, de les estimer, pour ensuite les planifier.

Cette double opération estimation/planification m’a toujours laissé perplexe, car je n’y suis jamais réellement arrivé. Au départ, je cherchais à estimer moi-même les charges en jours des tâches que j’avais identifiées, avant de les assigner aux développeurs. A force de me tromper, j’ai compris que je n’avais aucune justification pour faire ce travail d’estimation, développant peu moi-même, en quoi pouvais-je avoir une idée du temps à passer sur une tâche. Alors j’ai demandé à chaque développeur d’effectuer ces estimations. Cela n’a guère mieux fonctionné, les développeurs ayant en général une fâcheuse tendance à l'excès d'optimisme, m’obligeant le plus souvent à multiplier les charges estimées par un certain coefficient. Sans compter les tâches que l’on oublie, les tests en particulier.

Alors, pour changer, toute l’équipe de développement, Mina, Haiyan, Jerry et moi-même nous nous sommes réunis en cercle autour de notre petite table ronde, et avons commencer une partie de « planning poker » (à lire, la description de la méthode chez Mike Cohn, son inventeur) pour estimer de manière relative nos « User Stories »..

Les règles sont très simples. Chacun dispose d’un jeu de 13 cartes. Les neuf premières cartes :

Les suivantes, y compris la carte "pause café" :

Et enfin, la carte "Mystère?" :

S’agissant d’une estimation relative, on associe à chaque User Story un certain nombre de points virtuels, des User Story Points, destinés à mesurer la taille estimée relative. Autrement dit, en attribuant 2 points à une User Story, cela signifie qu’on estime qu’elle est deux fois plus grosse qu’une user story de 1 point, et 4 fois moins grosses qu’une user story de 8 points. Mais cela ne veut pas dire qu’une user story noté 5 possède une charge estimée de 5 jours, 5 heures ou 5 mois.

Chaque carte représente donc un certain nombre de user story points, selon une sorte de suite de Fibonaci. Car en effet, s’il est assez aisé de dire qu’une user story est deux fois plus grosse qu’une autre en passant de 1 à 2, est-il possible de dire qu’une user story vaut 10 points, et qu’une autre vaut 11 points ? de dire qu’une user story vaut 40 point, et qu’une autre vaut 39 points ?

Après avoir expliqué la notion des user story point, il reste à préciser le processus d’estimation. L’estimation est collective. Car chacune des personnes autour de la table est censée avoir un rôle à jouer dans le projet, et possède donc une idée de ce qui doit être effectué.

On s’accorde d’abord sur une user story d’importance moyenne, que tout le monde a bien compris, et dont tout le monde imagine parfaitement le contenu. Notre choix se porte sur la première user story, dans l’ordre de priorités de Christophe : « En tant qu'internaute, je veux identifier ***. ». Pas franchement compliqué. Nous nous entendons pour lui attribuer 3 points. C’est parti !

On passe à la suivante : « En tant qu'internaute identifié, je retrouve un espace correspondant à mes attentes en terme de ***. » On débat sur notre vision de cette user story. Ce n’est pas refaire tout le site, c’est juste mettre en place une page structurée correctement, qui tient compte de l’univers associé. Chacun réfléchit en silence aux points à attribuer à cette user story. Puis chacun met simultanément sur la table, face visible, la carte correspondante à son estimation. Nous sommes a peu près d’accord : 8 points.

En discutant de la user story « En tant qu'internaute, je veux avoir accès à l'ensemble de *** », nous nous apercevons qu’elle contient aussi la user story « En tant qu'internaute, je veux choisir *** ». Elles ne sont donc pas indépendantes, nous ne pouvons pas les séparer. Nous détruisons donc « En tant qu'internaute, je veux choisir *** ». Bien sûr, « En tant qu'internaute, je veux avoir accès à l'ensemble de *** » nous parait énorme. Mais 20 points, après débat semble correct.

La user story « En tant qu'internaute, je veux avoir accès au *** que je cherche » ne va pas du tout faire l’unanimité. Mina l’estime à 13 points, Haiyan à 5, Jerry pose 2 points, je mets 1 points. Que se passe-t-il ? Dans l’esprit de Jerry et dans le mien, il s’agissait simplement de rajouter le moteur par accès direct sur la home. Mais Mina nous fait remarquer que cette user story inclut aussi une présentation détaillée. Nous nous accordons finalement sur une user story à 8 points.

Sur la user story « En tant qu'internautes ados ou enfants, je retrouve *** correspondant à mon âge », Jerry pose une carte « ? » car il n’a jamais travaillé sur ce site particulier.

La réunion a été animée, fructueuse et harassante, étant donné la concentration nécessaire à cette estimation relative, mais pas suffisamment, cependant, pour que quelqu’un pose la carte « Pause café ». Quant à la carte « 0 », elle n’a pas non plus été utilisée.

Ce travail d’estimation effectué, nous nous donnons rendez-vous pour le début de l’après-midi, afin de planifier nos 15 prochains jours : notre premier sprint! Je profite de cette petite interruption pour saisir dans Team Foundation Server notre estimation en user story points, visible dans la colonne « Estimated Effort ». La priorité apparaît dans la colonne « Relative Value ».

 

Notre premier "Product Backlog"

Mardi 4 décembre - bureau Développement Web - 14h/16h.

Il s’agit de notre première réunion d’échanges élargis autour d'un nouveau projet, avec Christophe, le directeur produit et François, business analyst, côté Direction Marketing, Mélanie, responsable des contenus, Mina, Haiyan, Jerry et moi-même pour le développement.

Nous avons installé notre petite table ronde à côté d’un bureau, ce qui nous permet d’être à peu près en demi-cercle, faisant face au mur sur lequel sont projetés les différents éléments de nos échanges.

Pour commencer, François, notre business analyst, nous présente les grandes lignes du projet, en particulier le découpage du projet en deux lots : un premier lots de fonctionnalités associés à des contenus statiques, un second lot permettant la gestion dynamique de ces contenus. La première «release» doit sortir fin janvier. La seconde mi-mars. Chacun interagit à sa manière et selon sa compréhension. Des points sont précisés.

Quand tout le monde semble avoir le même degré de connaissance du projet, j’expose à mon tour la notion de user stories, unités fonctionnelles indépendantes, testables et livrables en terme de vision client. Je développe mon propos à partir de quelques slides inspirés de ceux de Mike Cohn :

Slide #1 : Rappel des objectifs

• Découper en « user story » le contenu du projet
• Estimer les charges relatives associées à chaque « user story »
• Prioriser les « user stories » que nous aurons écrites

Slide #2 : Pourquoi ?

• S’entendre sur des fonctionnalités à apporter
• Coopérer de manière intensive sur des objectifs communs
• Ne pas attendre des spécifications complètes pour commencer
• Converser, échanger, partager
• Éviter les effets tunnels
• Analyser, coder, tester sur des cycles plus courts
• Livrer des fonctionnalités terminées

Slide #3 : Qu’est-ce qu’une « user story »?

• Une « user story » est une manière simple de décrire en quelques
  mots l’expression d’un besoin « utilisateur », qu’il s’agisse d’un
  internaute ou d’un utilisateur interne.

Slide #4 : Investir en « User Stories »

• Indépendantes
• Négociables
• Valorisables
• Estimables
• « Small »
• Testable

Je délivre ensuite quelques exemples qui pourraient s’appliquer à notre projet. Mon exposé terminé, un léger blanc s’installe, puis Mélanie me fait remarquer que mon exemple de User Story « En tant qu’internaute, je veux choisir simplement un ***. » n’est pas très judicieux, car elle ne serait pas testable, car comment juger du « choisir simplement » !

La remarque est oh combien judicieuse ! Et le débat qui s’ensuit prouve que toute l’assemblée s’est accordé sur ce qui fait une bonne User Story.

Tout le monde joue ensuite le jeu, et des discussions animées nous amènent de manière collective à nous déterminer sur 13 user stories, dont certaines sont apparues au fil de l’eau, sans être associées à l’expression des besoins de départ.

Une fois ce travail effectué, Christophe, le directeur produit, se charge de les classer selon leur ordre de priorité.

Nous sommes tous assez contents d’avoir atteints ce résultat aussi vite. Deux heures fructueuses.