Coding sprint
Index
Un Sprint, c’est quoi ?
Voir coding sprint sur wikipedia
Un sprint, de 1 à 4 semaines, regroupe une équipe de développement focalisée sur un code, avec une liste de fonctionnalités à livrer à la fin du sprint.
Ainsi, plutot que d’avoir un développeur seul et des développements longs, il s’agit de faire avancer un code par bonds, en sprint successifs.
Avantages - inconvénients
Info
1 ingénieur pendant 6 mois ou 6 ingénieurs pendant 1 mois ?
Avantages
- Les compétences - On regroupe les compétences de plusieurs experts, plutôt qu’un seul qui doit se former à tout (gui, framework, backend, storage, unit test, devops…) ainsi qu’aux best partices pour chacun.
- rapidité - corolaire du précédent point. On va beaucoup plus vite.
Inconvénients
Warning
Ce n’est pas adapté à tout !
Si le travail nécessite un long aprentissage, le sprint n’est probablement pas adapté. Typiquement si le devt est sur la partie scientifique, il est probable que le sprint n’est pas adapté.
Il convient bien pour des choses assez standard (devops, gui, portage,intégration…). Bref pour tout ce qui n’est pas du coeur scientifique.
Les Rôles
Product owner
Le product owner définit les fonctionnalités du code final, au rythme des sprints. Il priorise les tâches et spécificités produit au fil de la méthode. Il représente le produit.
Dans notre contexte, c’est souvent le scientifique.
Il doit être présent avant le sprint pour définir avec le scrum master le backlog du sprint (la liste des fonctions attendues du sprint).
Info
Il doit être présent chaque jour du sprint en début et fin de journée, et joignable entre temps, afin de répondre rapidement aux éventuelles questions.
Warning
Il doit avoir une vision précise de ce que doit être le logiciel à la fin de chaque sprint, et au delà. Toute hésitation, flou dans sa vision, rendra le sprint inéficace, voir contre productif.
Scrum master
Le scrum master est là comme un chef de projet, mais dans une démarche agile. Il est chargé de dynamiser les interactions, le travail en autonomie, la communication autour du projet et de veiller au respect du process Scrum.
Déroulé d’un sprint
Avant le sprint
Préparation du backlog
Le scrum master et le product owner définissent dans les grande lignes les livrables du sprint, et en définissent la durée.
outil utilisé : gitlab/github, milestone et issues.
Tip
A noter l’importance de la dette technique à évaluer, et des éventuels travaux de remise à jour avant tout développement de fonctionnalité nouvelles.
En fonction de ces besoins, des disponibilités, le scrum master définira la date du sprint et l’équipe qui sera constitué.
Tip
Un ou plusieurs membre de l’équipe projet est obligatoire dans le sprint. Principalement le developpeur principal qui devra reprendre la suite du développement après.
préparation de l’équipe
Les membres de l’équipe doivent faire de la veille technologique active pour apréhender les technologies spécifiques du projet.
Info
Cette partie est complexe et très variable d’un projet à un autre, d’un individu à un autre.
Début du sprint
Discussion et établissement du backlog
La préparation du sprint se fait en présence de l’ensemble de l’équipe projet et du product owner. La première action consiste à se mettre d’accord sur un planning. C’est à ce moment que débute réellement le sprint.
Durant cette réunion de préparation, l’équipe doit s’assurer que le backlog est suffisamment fourni et détaillé. C’est le rôle du product owner de structurer efficacement le backlog et d’opérer à une première sélection des fonctionnalités demandées. Les objectifs à réaliser durant le sprint peuvent ensuite être discutés et décidés avec l’ensemble de l’équipe.
Tip
Le backlog structuré en tâches ou stories (1 story = N tâches)
Apprentissage
Les premiers jours concernent la prise en main du langage, framework, compilateur, outils, etc… Cela peut prendre de quelques heures à une semaine.
Info
A l’issue de cette période, une revue du backlog est nécessaire, au regard des compétences de l’équipe, et de la mesure de la dette technique.
Au quotidien dans le sprint
Une réunion quotidienne (ou daily scrum) est organisée. Elle ne doit pas durer plus de 15 minutes et se déroule debout. C’est sans aucun doute la meilleure façon pour que la réunion ne dure pas plus longtemps. Chacun à son tour explique ce qu’il a accompli la veille, les problèmes éventuels qu’il rencontre, et ce qu’il a prévu de réaliser le jour même. C’est une méthode très efficace pour faire un point complet sur l’avancement des travaux en cours. Tout le monde est au même niveau d’information, et si quelqu’un a une solution à un problème exposé, il peut apporter son aide pour le résoudre. De cette façon, un développeur ne restera pas longtemps bloqué, car n’importe quel membre de l’équipe en aura connaissance et sera à même de l’aider.
Cette réunion quotidienne va également permettre d’identifier rapidement tout retard dans la réalisation des tâches. Si ce retard risque de mettre en péril la livraison prévue à la fin du sprint, des fonctionnalités moins prioritaires peuvent être retirées du backlog. Elles pourront alors être réintégrées dans un sprint suivant.
Adaptation durant le sprint
Les résultats des développements sont envoyés au fur et à mesure au product owner et non en fin de sprint (environ une mise en production par jour).
Le product owner peut changer d’avis en cours de sprint :
- Si les changements sont mineurs, le sprint est adapté dynamiquement
- Si les changements sont majeurs, le sprint est annulé (et un nouveau est démarré)
Cloture du sprint
réunion de présentation
A la fin du sprint, une réunion de démonstration est organisée. C’est l’occasion pour l’équipe de présenter ce qui a été réalisé durant le sprint.
Le product owner pourra ainsi vérifier et valider que ce qui a été développé correspond bien à ce qui était demandé.
Rétrospective
Une dernière réunion a lieu en toute fin de sprint : la rétrospective. C’est l’occasion pour tous de s’exprimer librement et d’expliquer ce qui s’est bien passé et ce qui s’est moins bien passé durant le sprint. Il peut s’agir des conditions de travail, de la façon de communiquer entre l’équipe et le product owner ou au sein même de l’équipe, des choix technologiques, des outils de travail…
Cette réunion est la pierre angulaire de ce qui fait l’une des forces de la méthode agile scrum : l’amélioration continue. Des actions peuvent alors être décidées pour renforcer ce qui s’est bien passé, et pour corriger les éventuels problèmes rencontrés, afin que les prochains sprints soient encore plus efficaces et productifs.
Après le sprint
ON SE REPOSE !
Repos
Comme son nom l’indique, c’est un sprint. Et on ne sprint pas continuellement. Ils est nécessaire que le product owner se penche sur son nouveau code, se l’approprie, et retourne à un mode de développement plus traditionnel pendant quelques mois.
Il en est de même pour l’équipe de développement. Retour à la vie normale.
Le backlog
Backlog
- À faire (tâches à prendre en début de journée) : Au début du sprint, toutes les tâches sont dans cette colonne.
- En cours (tâches en cours de développement) : Elles doivent être terminées le soir (sinon, re-conception ou découpage envisagés)
- En revue : Le code doit être approuvé par le référent technique avant de partir en test fonctionnel.
- En test : Le code est testé par le chef de projet et/ou par le client.
- En production : Le code est déployé pour usage.