Nous avons déployé mardi 13 juillet la version 3.45 de notre solution avec une dizaine de nouvelles fonctionnalités !
Mais en fait, pourquoi organisons-nous ces versions ? Pourquoi un délai de 3 semaines ? Qu’est-ce que cela implique ? Comment cela fonctionne-t-il ?
QU’EST-CE QU’UN SPRINT ?
Le développement agile a consacré la notion de sprint qui désigne le process de développement au cours duquel vont s’enchaîner un certain nombre de tâches pour, à terme, s’achever par la conception d’un produit final. Dans notre écosystème chez Netanswer, le produit final est une nouvelle version de notre solution. Chaque fin de sprint donne lieu à une nouvelle release qui est déployée auprès de l’ensemble de nos clients utilisateurs.
Le fait de regrouper ces tâches au cours d’un sprint à plusieurs avantages :
- permettre de focaliser l’équipe sur un objectif réaliste et court terme ;
- permettre d’organiser et structurer ces développements ;
- permettre de mieux communiquer sur les délais aux clients car le sprint devient l’unité de temps ;
- permettre de gérer tout imprévu de développement car le retard se gère non pas au jour le jour mais à l’échelle du sprint.
Notre solution étant en SAAS et utilisée par plus de 180 clients et plus de 3M de membres finaux, il est important de limiter les régressions, et donc de structurer les développements pour faire ces tests de non régression. Evidemment les bugs critiques ou bloquants échappent à ce fonctionnement par sprint et sont les seules corrections qui sont mises en production et déployées en continu.
COMMENT S’ORGANISE UN SPRINT ?
L’équipe (project manager, product owner) reçoit au quotidien des demandes de développements ou en propose. Les project manager créent ce qu’on appelle des “User stories” : une description brève, autosuffisante (n’importe quelle personne extérieure doit pouvoir la comprendre), exhaustive (ne doit pas dépendre d’autres connaissances) et non ambiguë (on évite les déconvenues 😉) d’une demande.
Par exemple : Le client doit pouvoir en administration limiter le nombre de consultations hebdomadaires de l’annuaire par un membre cotisant. La phrase alors affichée dans l’annuaire sera “Oups, vous avez dépassé le nombre de consultations cette semaine”.
Ces user stories sont rédigées par les project manager dans un outil de ticketing, “redmine” dans notre cas, qui permet de les organiser et de les affecter de façon simple. Le client a aussi accès à “redmine” dans un souci de transparence.
La tâche du product owner avec le planificateur (notre CTO en l’occurrence) est donc de les prioriser et de placer ces “user stories” dans un sprint.
Un sprint est donc un ensemble de tickets.
RÉUNION DE PRÉSENTATION
Le sprint commence donc par une première réunion de cadrage avec toute l’équipe (PO, PM, Dév, CMO, UX designer…) qui permet de présenter les différents tickets qui sont au nombre de 60-80 en général.
Cela permet de répartir les tickets sur les développeurs, et de préciser alors les besoins de spécifications qui vont permettre dans une première phase aux maquettistes et analystes (conception/BDD/UX designer) de rédiger les spécifications, et de les faire valider par les PM ou clients.
TESTS
La seconde phase permet alors de tester les tickets et de les livrer sur un environnement de développement, soit en interne soit en externe.
VALIDATION
Au ⅔ du sprint, lors de nos petits déjeuners du vendredi (“friday breakfast”) les project manager présentent les différents développements. L’idée est de commencer à mieux comprendre les développements réalisés mais aussi de tester leur compréhension, leur ergonomie, et discuter le cas échéant d’option (on les active par défaut, quelle valeur, quel intérêt ?).
Quand on développe plus de 150 fonctionnalités par an, le point essentiel est qu’elles doivent toutes être compréhensibles par nos clients. Sinon, autant ne pas communiquer dessus 😉
On commence donc à voir quels sont les tickets sur lesquels on va communiquer et ceux qui seront passés sous silence, soit parce qu’ils sont trop techniques, soit parce qu’ils n’ont pas assez d’intérêt pour les clients.
COMMUNICATION
Lors d’une dernière réunion de fin de sprint, on valide les développements qui vont en effet être déployés (certains peuvent être arbitrés car non aboutis et remis au sprint suivant) et on décide des développements présentés à la release et l’ordre dans lequel ils vont être présentés. La CMO rédige alors la documentation ajoutée en administration et prépare la Newsletter envoyée au client.
DÉPLOIEMENT
Le matin de la release, lors du daily sprint on valide les derniers ajustements au besoin, et on lance en fin de matinée la création de la branche de développement qui va être déployée en production. La coupure sur les sites prend moins de 5 secondes et permet que la bascule d’une version soit quasiment transparente.
BILAN DE SPRINT
Le soir même l’équipe fait un bilan du sprint. Soucis, incompréhensions, erreurs à éviter ou améliorations sur lesquelles capitaliser ou enseignements pour le futur sprint.
Et le lendemain matin, on parle ….. du sprint suivant !
POURQUOI 3 SEMAINES ?
On nous pose souvent la question. Ce qui est primordial pour répondre aux besoins clients c’est d’avoir un cycle de développement court. Cela évite les régressions, cela permet de répartir plus facilement les développements (plus vous avez une durée de sprint importante plus c’est coûteux de décaler un développement dans le sprint suivant) et de ne pas limiter les sauts technologiques et surtout de lisser les nouvelles fonctionnalités.
Il est évidemment plus simple de fonctionner sur un nombre de semaines car c’est l’organisation du travail classique, mais évidemment un sprint par semaine c’est beaucoup trop court car cela ne permet pas de s’organiser.
On a testé les sprints de deux semaines pendant 2 mois mais on a vite arrêté car d’une part cela épuise les équipes qui ont l’impression d’enchaîner les sprints et cela ne permet pas de se poser sur des fonctionnalités complexes qui sont donc trop rapidement vues. Il faut aussi intégrer une phase de validation éventuelle par nos clients qui ne peuvent pas forcément être disponibles et mobilisables dans la semaine.
Nous fonctionnons donc sous sprints de 3 semaines depuis plus de 2 ans maintenant et on est convaincus que c’est le bon rythme. Plus court c’est ingérable, plus long c’est inutile !
ET POURQUOI LE MARDI ?
Par principe, nous excluons de sortir un nouveau site ou une release le vendredi veille de WE… Comme une sortie peut être décalée au lendemain pour un imprévu (cela nous est arrivé une fois en 43 releases !) on évite de la sortir le jeudi car le décalage ferait tomber le vendredi…
Par ailleurs, le lundi c’est un peu tôt dans la semaine car on peut avoir besoin de se coordonner avant la sortie ou communiquer auprès des clients.
Il restait donc le mardi et le mercredi. Mais comme le mercredi est en général pris pour les personnes en ⅘, cela voulait dire qu’on avait moins de clients présents quand la release sortait, on s’est donc orienté vers le mardi !
Et cela fonctionne bien avec le vendredi d’avant où on fait nos “friday breakfast” et qui permet donc de préparer la communication sur la release sur les 3 derniers jours.
BILAN ?
La mise en place en sprints de 3 semaines avait été consécutive à un séminaire d’équipe avec les développeurs.
Pour l’équipe et nos clients le fonctionnement en sprint de 3 semaines à résolu de nombreux soucis :
- respect du planning : on n’a plus besoin de réorganiser le planning au quotidien ou à la semaine puisque l’unité de temps est le sprint
- diminution du stress : les objectifs étant partagés dans l’équipe, cela diminue les incompréhensions et le stress car une tâche n’est pas terminée.
- plus de régressions : les environnements de développement étant réalignés avec la production en début de sprint, et les tests unitaires et d’intégration produit en temps et en heure, nous n’avons plus de régressions lors du passage en production
- meilleure communication client : les clients savent précisément quelles sont les échéances (auparavant on avait du mal à avoir une date exacte de mise en production ce qui créait du stress et de l’incompréhension client) de livraison
- meilleure communication produit : on peut prendre le temps à chaque release de bien communiquer sur nos nouveautés au travers de notre newsletter et surtout les communications sur les nouveautés sont attendues à chaque release par les clients c’est un rituel désormais.
La seule contrainte est que par principe un sprint en cours ne doit plus recevoir de nouveaux développements. C’est donc un souci car cela signifie qu’une nouvelle demande client ne peut donc en théorie être traitée avant le sprint suivant c’est à dire entre 3 semaines (si le sprint vient de se finir) et 6 semaines (si le sprint a démarré la veille). Cela a évidemment été douloureux à mettre en place au début (et des fois encore maintenant ;-), mais les clients ont maintenant compris l’intérêt de ce fonctionnement, et en sont parfaitement satisfaits. En effet il vaut mieux avoir une date précise et plus lointaine qu’une date qui est proche et qui est repoussée… La contrepartie de cette organisation est que nous pouvons nous engager sur les délais et sur une meilleure mutualisation des développements.
UNE QUESTION ?
