Pourquoi fonctionner en sprint ?

[Opinion]

Lorsqu’on travaille sur des tâches techniques, qu’il s’agisse des éléments d’une fonctionnalité, de la refactorisation du code, de la correction de bug, etc, ces tâches peuvent avoir une durée variable, clairement indépendante de cette fenêtre de temps que l’on se fixe, et qu’on appelle sprint (ou “itérations”, dans la doc de SAFe).

À partir de là, pourquoi se fixer une durée fixe, pour les sprints ?

Un peu de vocabulaire…

Suivant les organisations, une équipe produit peut inclure plusieurs équipes techniques. Celles-ci seront alors responsable d’un composant technique. Ce composant remplit une fonction précise, dans le produit. Dans le cas de microservices, ce composant aura un lien étroit avec un produit ou une partie du produit.

Un produit adresse une opportunité, et ce en phase avec la stratégie de l’entreprise. Suivant l’organisation de l’entreprise, le produit pourra être découpé en fonction des services qu’il fournit, et chaque service proposera des fonctionnalités à l’utilisateur du produit.

Lorsqu’une fonctionnalité, ou évolution de fonctionnalité arrive entre les mains de l’équipe technique, celle-ci fera l’objet d’une ou plusieurs tâches. Les bugs et refactorisation du code seront également incarnés par des tâches. Toutes ces tâches sont alors rassemblées au sein du backlog de l’équipe.

La notion de sprint est issue du Scrum, qui défini un ensemble d’outils permettant de structurer le travail de l’équipe technique. Notamment, Scrum défini les rituels comme le Daily Stand up prévu pour suivre l’avancement des membres de l’équipe au quotidien, ou les Sprint Retrospectives permettant de faire le point à l’issue d’un sprint. Voir scrum.org pour une présentation plus complète.

Venons-en au fait : pourquoi ?

De base, l’organisation en sprint permet de fournir un découpage, dans le flot d’activité des équipes, mais c’est aussi l’occasion de faire le point.

Qualifier les progrès

La fin de sprint est l’occasion de rassembler tout ce qui a été accompli sur sa durée. L’équipe technique va ainsi produire un livrable, qui pourra faire l’objet de qualification, intégration, etc. Le livrable aura alors été couvert par des tests unitaires, d’intégration, de sécurité, etc.

Il ne sera pas forcément déployé en production : le déploiement devient pertinent à partir du moment où notre livrable contient des corrections de bug ou des fonctionnalités finies et prête à aller entre les mains des clients. Dans les autres cas, notre livrable servira uniquement à l’équipe technique. En effet, les tests lui permettent de s’assurer qu’il ne comporte pas de régression, de faille de sécurité, etc. et surtout qu’il s’interface toujours avec les autres composants.

Revoir les priorités

L’intérêt de l’Agile, est de pouvoir ajuster sa progression en fonction de l’évolution du besoin client (on peut réévaluer les priorités des tâches), mais aussi des contraintes de l’équipe technique. En effet, des cas de figure, problèmes, ou (au contraire) simplification qui n’avaient pas été anticipés ont put être rencontré, au cours du sprint.

Dans ces cas là, le point à la fin du sprint est l’occasion de faire le nettoyage et le tri du backlog des équipes techniques. Ce sera également l’occasion d’introduire de nouveaux sujets produit à soumettre à l’équipe technique.

Guider le découpage des tâches

Les sprints permettent également de fournir un rythme régulier de livraison. On va alors prévoir le découpage des tâches de façon à ce qu’on puisse réguli!èrement déployer en production des fonctionnalités, ou portions de fonctionnalité complète, ou des prototypes, des MVP, etc.

De plus, préparer ses tâches pour un sprint permet de garantir la concentration des membres de l’équipe sur les tâches planifiées, sans se disperser sur les nouvelles demandes clients. À noter cependant que la durée du sprint revêt d’autant plus d’importance que

• s’ils sont trop court, ils cassent l’intérêt de rester concentré, et
• s’ils sont trop long, l’équipe peut se retrouver dans une forme d’effet tunnel, dans la mesure où la fonctionnalité peut diverger des attentes clients.