A Esendex nos développeurs sont toujours pleins d’enthousiasme et fourmillent d’idées meilleures les unes que les autres, ils sont également excellents dans leur travail, c’est-à-dire imaginer et écrire des codes. Mais pour nous assurer que ces codes profitent à nos clients nous nous devons d’être bien organisés.
La création des programmes à Esendex est pensée en cycles de deux semaines appelés « itérations ». Nous pensons que deux semaines est un laps de temps assez court pour nous permettre de rester entièrement concentrés sur un projet tout en nous offrant une marge nécessaire pour nous adapter à tout imprévu.
Au début de chaque itération tous les développeurs s’assoient ensemble et nous planifions le travail à réaliser et terminer – réellement terminer – au cours des deux semaines suivantes.
Avant de passer au planning, le travail est découpé en en tâches courtes et réparti via des cartes placées dans la colonne « en attente » de notre tableau KANBAN. Ces cartes sont divisées entre missions, bugs et tâches techniques. Tous les éléments nécessaires à la réalisation de chaque mission sont collectés au préalable, par exemple la duplication de notre interface utilisateur. Si nous ne rassemblons pas ces éléments avant la phase de planification il est impossible d’estimer la durée du projet.
En résumé, avant même de commencer à planifier nous avons déjà une idée de notre travail et de nos priorités.
Minimiser les imprévus
Pendant nos réunions nous traitons toutes les cartes par ordre de priorité en résumant le travail que chaque tâche représente et pour nous assurer que l’ensemble de l’équipe comprend l’organisation des deux semaines à venir. Cela prend souvent la forme d’une discussion, parfois accompagné d’un regard rapide au code source de notre plateforme. Si l’équipe n’arrive pas à se mettre d’accord sur la meilleure façon de réaliser une tâche, une autre carte mission peut être créée afin d’analyser le problème en profondeur et mieux en comprendre les enjeux afin de correctement la planifier.
Estimer la taille de chaque mission
Une fois que l’équipe est satisfaite et que nous sommes sûrs que chacun comprend son rôle par rapport à l’ensemble des tâches à réaliser il nous faut estimer la tailler de chaque mission. Il existe différentes méthodes pour cela, mais celle que nous préférons est le « Planning Poker». Le principe du Planning Poker est très simple ; chaque membre de l’équipe a en main un jeu de cartes (voir photo ci-contre), chaque carte comporte un nombre (1, 2, 3, 5, 8, 13, 30, 100), ces nombres correspondent à la difficulté estimée de la tâche et au temps nécessaire pour la terminer. Chacune à leur tour les missions sont présentées aux développeurs qui sélectionnent chacun une carte avec le nombre qui selon eux reflète le mieux sa difficulté. Suite à l’estimation de chacun l’équipe se met d’accord sur la valeur, en nombre de points, à accorder à la mission.
Au début la valeur attribuée à chaque tâche est assez arbitraire mais au fur et à mesure les tâches sont comparées et une sorte de valeur de l’effort et une relativité entre les différentes missions voit le jour :
« Si réparer le bug de la page d’accueil est un 3 et qu’ajouter la fonction de mise à jour des messages envoyés est un 5, alors connecté un nouveau réseau à notre API doit être un 30… »
Ainsi chaque duo au sein de notre équipe peut se référer à ces valeurs et peut facilement réaliser qu’une tâche est trop longue et doit être découpée en plusieurs tâches plus petites.
Transformer le temps en effort
En quelques semaines, l’équipe peut vite se rendre compte de combien de points (addition des nombres attribués aux tâches) peuvent être terminées au cours d’une itération, cela appelé la Vélocité de l’équipe. Cette vélocité sert à déterminer combien de tâches sont réalisables par l’équipe sur une période de deux semaines et ce qui ne l’est pas.
En savoir plus
Bien sur le planning n’est qu’une petite partie de notre organisation, il faudrait également parler de la priorisation, des phases de test, du lancement… mais planifiez vos missions avec succès et c’est une grosse épine en moins dans le flanc de votre équipe ! Si vous voulez plus d’informations, nous vous conseillons Agile Estimating and Planning de Mike Cohn, mais le plus important est de vous lancer et d’adapter les procédés aux besoins de votre équipe.
