Webpulser s’inspire des méthodes agiles pour son processus de développement logiciel. Nous utilisons en particulier Scrum. Cet article ne répondra pas aux questions de certains d’entre vous : “Mais que sont les méthodes agiles ?”, “Scrum… Mais qu’est ce donc encore que cette bête la ?” ou encore “Kanban ? Ca se mange ?”. De bien beaux livres existent déjà et remplissent leur rôle à la perfection – Scrum dan les tranchées pour Scrum, par exemple. Il fut mon livre de chevet pendant 3 semaines lors de mes premiers pas dans l’agence -. Non, cet article s’agit plutôt d’un cas d’étude, celui de notre agence et de son envie d’associer scrum et kanban. Curieux ? Dans ce cas, allons y !
Il était un sprint chez Webpulser
Notre tableau est composé de quatre colonnes : “to do” (c’est le backlog du sprint), “in progress”, “à valider” et “done”. Une grande story (post-it rose) est découpée en un ensemble de plus petite tâches (post-it jaune). Chaque développeur choisi une tâche dans “to do”, la met sous son nom dans “in progress” et la place dans “done” une fois testée sur le serveur de préprod. Dès qu’une grande story est terminée, elle est placée dans “à valider”.
Toute bonne journée démarre par un café. Mais aussi par un daily scrum. Pendant une quinzaine de minutes, chaque membre de l’équipe racontera son travail de la veille, ce qu’il prévoit de faire durant la journée et les difficultés qu’il a rencontrées. Cette petite réunion est auto-animée mais encadrée par notre scrum master.
Tout bon sprint (D’une durée choisie de 2 semaines) démarre par une planification le lundi matin de la première semaine. C’est durant cette réunion que nous définissons le backlog de l’équipe et que nous estimons les tâches. Une démo / rétro le vendredi matin de la deuxième semaine cloture le sprint. Lors de ce même vendredi, l’après midi est réservée à des séances de veille technologique et d’ateliers.
Et le reste du temps ? Et bien… Nous développons !
Problématique
Cette implémentation de scrum fonctionne bien lorsque le sprint se déroule comme prévu. Cependant, cela soulève quelques problématiques dans certains cas :
- gestion des urgences / maintenance : Comment prévoir et planifier les tâches urgentes ou de maintenance qui apparaissent au cours du sprint ? Doit-on prévoir moins de tâches dans le backlog pour avoir la flexibilité nécessaire de les traiter ? C’est une question importante car cela répresente une part non négligeable de notre activité.
- goulot d’étranglement (on remet la tâche « en todo » et on passe à autre chose) : Il arrive, par manque d’informations ou bug inexplicable, qu’une tâche ne se termine pas. L’un des premiers réflexes, est de la remettre discrètement dans le backlog et de passer à autre chose. On y reviendra “quand on aura les infos ou le temps”
- validation des stories : les validations ont tendance à s’accumuler sans qu’on ne les vérifient… Ce qui conduit à des modifications et corrections “à la dernière minute”.
- les tâches persistantes : Certaines tâches ne sont jamais prises et reste sur le tableau de sprint en sprint…
Une solution… Il était une “future” journée chez Webpulser
Ajoutons un peu de Kanban à notre journée, et voyons ce qu’elle devient !
Notre tableau est composé à présent de cinq colonnes : “backlog”, “to do”, “in progress”, “à valider” et “done”. La grande diffèrence ici est que chaque colonne comporte un nombre limité de tâches. Il est impossible d’ajouter une tâche dans une colonne pleine. Cela permet notamment de nous “forcer” à valider les tâches. De plus, une nouvelle colonne “backlog” est apparue. Elle porte bien son nom. La gestion des priorités sera faite dans la colonne “to do”. En effet, le chef de projet aura tout le loisir d’échanger des tâches entre “to do” et le “backlog”.
Une bonne journée démarre toujours par un café… ou un bon thé. Mais encore et toujours par un daily scrum. Son déroulement ne changera pas.
Le sprint en cours durera toujours 2 semaines… Stop… Pourquoi ne pas le supprimer ? Les sprints de 2 semaines fonctionnent bien lorsqu’il y a de gros projets en cours de développement. Mais dans les cas ou les tâches sont irrégulières ou en majorité constituées de maintenance, les phases de démo et de plannification ont beaucoup moins de sens. Ajoutons donc un peu de flexibilité quant à la périodicité de ces phases. La démo aura donc lieu quand nous aurons des choses à montrer.
Et le reste du temps ? Et bien… Nous développons toujours !
Bibliographie
- Scrum dan les tranchées
- Kanban et Scrum : Tirer le meilleur des deux
- Introduction en 10 minutes à Scrum (vidéo en anglais)
- Notes sur l’agile tour 2012 à Lille
Rédigé par Thomas Vanlerberghe