agile user stories - 01 Dec 2016

Notre quotidien d'équipe projet auto-organisée

Richard HANNA
Écrit par Richard HANNA

Retour d'expérience sur la vie d'une équipe projet auto-organisée. Voici ce que nous avons mis en place progressivement, nos expérimentations, nos succès et nos échecs.

Cela fait maintenant un an que nous travaillons sur un projet aux multiples facettes dont l’équipe est constituée de quatre développeurs côté Elao, un Business Analyst et un Product Owner côté client. Notre méthodologie est très inspirée de Scrum et de XP. Notre équipe s’est construite avec l’aide de notre manager et coach Agile. Il nous épaule et nous challenge souvent pour faire émerger des améliorations. Voici ce que nous avons mis en place progressivement, nos expérimentations, nos succès et nos échecs.

Daily standup

C’est l’outil de synchronisation quotidienne de l’équipe et qui dorénavant démarre en musique, c’est toujours plus fun. Cela dure environ 5 minutes.

Nos outils

Board projet

Atelier

Au début du projet, toute l’équipe s’est rendue sur le terrain pour s’imprégner du domaine d’activité de notre client. Oui c’est “Vis ma vie”. Cela ne peut prendre qu’une demie-journée et c’est très instructif. On sait pourquoi on va développer tel ou tel outil. C’était finalement notre premier atelier.

L’atelier se déroule avec un ou deux développeurs et le Product Owner durant une demie-journée. Le but de nos ateliers est :

Et pour cela, il faut :

Prochaine étape après l’atelier : écrire les Users Stories dans Jira.

On essaye d’avoir une démarche LEAN ou au moins d’insuffler cette démarche à notre client pour la conception du produit.

De plus, chaque membre de l’équipe doit participer aux ateliers à tour de rôle ; ceci améliore l’implication et la connaissance du produit de tous les membres de l’équipe.

Cependant, nous n’avons que rarement eu à nos ateliers des utilisateurs de notre application (les parties-prenantes). C’est quelque chose sur lequel nous avons beaucoup insisté mais il n’est pas toujours possible d’avoir un cadre idéal.

Sprint

Le sprint a une durée fixe de 2 semaines ; durant l’été, nous avons effectué un sprint d’un mois, ce fut un échec.

Après avoir rencontré des erreurs applicatives durant nos démos avec le client en raison de déploiements réalisés la veille au soir, nous avons alors décidé d’arrêter le développement la veille de la cérémonie vers 16h. Ceci afin de finir les derniers code review (les stories pas prêtes à partir en démo, tant pis !), préparer la démo du lendemain et faire une rétrospective interne.

La Cérémonie se déroule avec tous les membres de l’équipe, pour que tout le monde ait le même niveau d’informations et participe aux estimations.

La Cérémonie est composée de 3 étapes :

Récemment, nous avons mis en place avec notre client 12 journée par sprint pour traiter la dette technique, dette technique que nous récoltons sous forme d’issues sur github.

La célérité d’un sprint n’était pas très bien ou pas du tout suivi au début. Un problème de sous-estimation d’un sprint avec trop de stories et trop de complexité (le fameux sprint d’un mois dont je parle plus haut) nous a fait vite recadrer cela.

Enfin, on a abandonné la définition d’un Sprint Goal en cours de route car cela prenait du temps d’en établir un et il ne nous apportait pas grand chose.

Definition of done

Voici la définition de fini pour le développement d’une User Story que nous avons fait évoluer ensemble au fil du projet.

Autant vous dire tout de suite : un développeur qui ne respecte pas ce DoD prend cher ! :)

Auto organisation et communication

L’équipe projet n’a pas de chef de projet. Une personne (moi) joue plus ou moins le rôle de “scrum-master” mais c’est surtout pour organiser et faire le daily standup, la rétrospective, … A terme ce rôle devrait être tournant dans l’équipe. Chaque personne de l’équipe donne son avis, peut déployer en démo ou en prod ou faire quoi que ce soit sur le projet.

Toute l’équipe participe à la conception du produit ou aux choix d’architecture logicielle notamment via les revues de design dont je parle plus bas.

Par ailleurs, il n’y a pas de personne attitrée pour discuter avec le client. Au début, un junior demande souvent “Peux-tu dire au client de…”. On lui répond systématiquement : “Dis-le-lui toi-même !”. Nous privilégions ainsi une relation directe avec le Product Owner. Responsabilisation++ de chacun dans l’équipe.

Et un mot sur la transparence ? On ne se cache rien (ou presque) : à la fois en interne ou vis à vis du client. On informe dès qu’il y a un problème ou un changement. Le client nous dit quand cela ne va pas ou nous fait des retours utilisateurs dès qu’il en a.

Organisation du développement

Revue de design

Rétrospective

La rétrospective agile est pour nous un superbe outil d’amélioration continue. Nous faisons deux rétrospectives par sprint :

Rétrospective

Le résultat de ces rétrospectives sont des axes d’améliorations reportés sur des Post-it qui sont revérifiés au prochain sprint. Si le problème est résolu, on jette le Post-it.

Enfin, nous expérimentons au fur et à mesure des formats différents de rétrospectives pour casser la routine et faire émerger de nouvelles améliorations.

Estimation du reste à faire

Au début du projet, l’estimation du reste à faire était toujours reléguée pour plus tard, car “on a le temps, c’est de l’agile”. Quand le temps alloué au projet a fondu, il a bien fallu s’y mettre; un outil existe pour cela : le Story Mapping. Il est facile de réaliser un Story Mapping sous forme de Post-it pour avoir une vision long terme et faire une estimation macro pour l’atterrissage.

Revue de design

Et maintenant ?

Et bien maintenant, nous pensons qu’il reste toujours des choses à améliorer. Aujourd’hui l’équipe est colocalisée et nous allons très bientôt intégrer des développeurs qui seront à distance dans notre équipe projet auto-organisée. Il faudra sans doute trouver de nouvelles solutions pour maintenir la communication et l’équilibre.

tl;dr

#AutoOrganisation #Communication #Transparence #AméliorationContinue

Résultats :