Introduction à l'agilité et aux sprints Scrum

L’agilité est une approche puissante pour créer, développer et lancer de nouvelles idées, tout en améliorant continuellement le rendement de l’équipe.

Autrement dit : mener des projets réussis et utiles qui ravissent les clients et les membres de l’équipe.

Autrement dit : augmenter les profits de façon durable, et dans la bonne humeur.

Bien appliquée, l’agilité donne des principes pour garder le cap sur les grandes priorités, s’adapter quand de nouvelles informations ou exigences arrivent, et apprendre des embûches, tout en gardant une équipe heureuse et productive.

Malheureusement, beaucoup d’équipes pratiquent, sans le savoir, une agilité à rabais, moins efficace. Elles en souffrent beaucoup et n’arrivent pas à expliquer l’écart entre les prévisions et les résultats.

Aujourd’hui, on repart de zéro, pour que nos lecteurs aient tout ce qu’il faut pour bâtir (ou rebâtir) sur des bases solides.

Pour commencer…

C’est quoi, l’agilité?

• L’agilité n’est ni un système, ni un cadre, ni un ensemble de routines.
• L’agilité est une philosophie, une façon de penser, un état d’esprit.

Pour commencer, regardons le…

Manifeste agile

• Les individus et leurs interactions plus que les processus et les outils
• Des logiciels opérationnels plus qu’une documentation exhaustive
• La collaboration avec les clients plus que la négociation contractuelle
• L’adaptation au changement plus que le suivi d’un plan

Autrement dit, nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.

(source : agilemanifesto.org)

C’est tout! Simple, non? Vous restez sur votre faim? Un petit détour par Wikipédia donne une version plus détaillée :

• Les outils et les processus sont importants, mais il est plus important d’avoir des personnes compétentes qui travaillent bien ensemble.
• Une bonne documentation aide les gens à comprendre comment le logiciel est construit et comment l’utiliser, mais le but premier du développement est de créer du logiciel, pas de la documentation.
• Un contrat est important, mais il ne remplace pas une collaboration étroite avec les clients pour découvrir ce dont ils ont besoin.
• Un plan de projet est important, mais il doit rester assez souple pour s’adapter aux changements de technologie ou d’environnement, aux priorités des parties prenantes, et à la compréhension que les gens ont du problème et de sa solution.

Alors, comment mettre ça en pratique?

C’est là que les 12 principes agiles entrent en jeu : ils précisent les choses.

Aujourd’hui, on se concentre seulement sur le n^o 1 :

1. Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des logiciels à grande valeur ajoutée.

Comment mettre en place des cadres pour la livraison continue? Une des réponses les plus répandues, c’est d’organiser le travail en sprints.

À noter : jusqu’ici, on a parlé de la philosophie agile, mais la pratique des sprints décrite plus bas vient de Scrum, un cadre de gestion de projets logiciels très répandu.

C’est quoi, des sprints?

Les sprints imposent une contrainte qui vous oblige à progresser par itérations. Le travail prévu doit être :

• réaliste
• simple
• relativement bien réfléchi
• bien testé

…sinon, vous allez souffrir. Et croyez-nous, vous allez souffrir.

Heureusement, une rétrospective bien préparée vous permet de transformer cette souffrance en croissance, en progrès et en plaisir.

(crédit : la majeure partie de ce qui suit est tirée de atlassian.com/agile, un de nos blogues préférés sur l’agilité. Le blogue déborde d’information utile; on a fait de notre mieux pour en tirer l’essentiel ci-dessous. Les références sont indiquées section par section, au besoin.)

Avantages des sprints

Crédit : Atlassian

• concentrer les efforts pour donner vie aux idées
• livrer un incrément de travail concret
• éviter de travailler sur trop d’éléments à la fois
• découper les gros projets complexes en petites bouchées

Définition d’un sprint

Crédit : Atlassian

• Un sprint est une courte période de durée fixe pendant laquelle une équipe Scrum s’efforce de terminer une quantité de travail établie d’avance.
• Les sprints sont au cœur même de Scrum et des méthodes agiles, et bien réussir ses sprints aidera votre équipe agile à livrer de meilleurs logiciels avec moins de maux de tête.
• On pense souvent que Scrum et l’agilité, c’est la même chose. Ce n’est pas le cas. L’agilité est un ensemble de principes, et Scrum est un cadre pour faire avancer les maudites affaires.
• Lecture approfondie / facultative : The Scrum Guide

Le cycle de sprint Scrum et ses rituels

Crédit image : Atlassian

Les bases de la planification agile

Bien planifier, c’est essentiel pour réussir. La planification agile a une subtilité : on accepte d’avance que le plan va changer à mesure qu’on avance dans le projet et qu’on découvre ce qu’on ne savait pas.

C’est pour ça qu’on découpe le travail en petits modules, chacun pensé en fonction de ce qu’il apporte à l’utilisateur, qu’on peut réorganiser plus facilement.

On appelle ces modules…

Récits

Crédit : Atlassian

• Un récit utilisateur (user story) est une explication informelle et générale d’une fonctionnalité logicielle, écrite du point de vue de l’utilisateur final. Son but est d’exprimer comment une fonctionnalité logicielle apportera de la valeur au client.
• Un récit utilisateur place les utilisateurs finaux au centre de la conversation.
• Un récit utilisateur est la plus petite unité de travail. C’est un objectif final, pas une fonctionnalité, exprimé du point de vue de l’utilisateur du logiciel.
• « En tant que [persona], je [veux], [afin de]. »
• Les utilisateurs ne sont pas forcément des utilisateurs finaux externes au sens traditionnel. Ils peuvent aussi être des clients internes ou des collègues.
• Assurez-vous d’avoir clairement défini quand une tâche est TERMINÉE.

Estimation

Crédit : Atlassian

• Chaque membre de l’équipe apporte un regard différent sur le produit et sur le travail nécessaire pour livrer un récit utilisateur.
• Si on laisse une partie de l’équipe produit à l’écart de l’estimation, les estimations sont moins bonnes, le moral baisse parce que des gens clés ne se sentent pas inclus, et la qualité du logiciel en souffre.
• Chaque récit est estimé, généralement en points. Vous POUUUUVEZ aussi utiliser des heures. Pour en savoir plus là-dessus, consultez le guide d’estimation d’Atlassian en lien plus haut.
• Le plus important ici : comparer ce qui a été estimé à ce qui a été livré. C’est comme ça qu’on apprend à estimer plus juste et qu’on donne à l’équipe ce qu’il faut pour réussir.

Conseils de planification

Crédit : Atlassian

• Assurez-vous que l’équipe fixe et comprend l’objectif du sprint et la façon dont le succès sera mesuré.
• N’embarquez pas trop de récits.
• Prévoyez du temps pour l’assurance qualité et le travail qui n’est pas lié aux fonctionnalités.
• N’acceptez pas trop de travail inconnu ou à haut risque. Découpez les récits gros ou très incertains. Bonne règle de base : les récits estimés à plus de 2 jours (ou environ 25 % de la capacité d’une personne pour le sprint) devraient être découpés.
• Si l’équipe exprime des inquiétudes, que ce soit sur la vélocité (la livraison du travail estimé), le travail peu certain ou le travail qu’elle croit plus gros que ce qu’elle a estimé, ne les ignorez pas. Réglez le problème et réajustez au besoin.

Points quotidiens

Le format habituel :

• Durée limitée à 15 minutes
• Hier, j’ai fait : X
• Aujourd’hui, je prévois faire : Y
• Je suis bloqué par : Z

(Si les mêlées ont lieu en fin de journée et non le matin, ce serait plutôt « Aujourd’hui, j’ai fait / Demain, je prévois faire ».)

Beaucoup de gens y voient une façon de responsabiliser l’équipe. On vous suggère de les voir tout simplement comme un moment garanti avec votre équipe.

Revues

Crédit : Atlassian

• Une revue de sprint sert à présenter le travail acharné de toute l’équipe. Les membres de l’équipe se rassemblent autour d’un bureau pour des démos informelles et décrivent le travail qu’ils ont fait pendant cette itération. C’est le moment de poser des questions, d’essayer les nouvelles fonctionnalités et de donner de la rétroaction.

Questions à poser pendant les revues

• Les récits sont-ils bien définis par le responsable de produit, le designer et l’équipe d’ingénierie avant leur mise en œuvre?
• Est-ce que tout le monde comprend et vit les valeurs et la culture d’ingénierie de l’équipe?
• Y a-t-il des définitions et des exigences claires sur la façon dont le travail sera révisé, testé et lancé, pour favoriser un développement agile et durable?
• Quand l’équipe termine un récit, est-ce que beaucoup de bogues font surface? Autrement dit, est-ce que « terminé » veut vraiment dire « terminé »?

Rétrospectives

Les rétros sont une des pièces maîtresses de l’apprentissage continu. Il existe plusieurs versions des questions à poser pendant une séance de rétro d’équipe (ou individuelle); voici nos préférées en ce moment :

• Qu’est-ce qui a bien été?
• Qu’est-ce qui aurait pu mieux aller?
• Qu’avons-nous appris?
• Qu’allons-nous ajuster?

Restez à l’affût : notre prochain article explique comment mener des rétros utiles, dont les améliorations s’additionnent d’un sprint à l’autre, autant pour le rendement que pour le bonheur de l’équipe.