Deux semaines, un objectif clair, une demo a la fin. Voici le deroulement d’un sprint SAP vu de l’interieur, du point de vue du consultant qui livre.
L’essentiel
- Un sprint est une periode courte et fixe, souvent deux semaines, avec un lot de sujets a livrer.
- Il commence par une planification et se termine par une demo et une retrospective.
- Sur SAP, le sprint doit tenir compte des dependances entre modules et des transports.
- Le vrai enjeu du consultant : s’engager sur du realiste, pas sur ce qui fait plaisir au client.
Un sprint SAP, c’est quoi concretement
Un sprint est une unite de travail issue des methodes agiles. C’est une periode courte et fixe, en general deux semaines, pendant laquelle l’equipe s’engage a livrer un ensemble de sujets definis. A la fin, on montre ce qui est fait. Sur un projet SAP, le sprint sert a decouper une charge enorme en tranches maitrisables.
Le sujet a traiter s’appelle souvent une user story : une demande formulee du point de vue du metier. Par exemple « en tant qu’acheteur, je veux bloquer une commande au-dela d’un certain montant ». Le consultant traduit cette demande en parametrage ou en developpement, puis la teste avant la demo.
Le rythme d’un sprint, jour apres jour
Le sprint suit toujours la meme mecanique, quel que soit le projet.
- La planification : au debut, l’equipe choisit les sujets du sprint et estime la charge. C’est la que le consultant s’engage.
- Le point quotidien (daily) : quinze minutes pour dire ou on en est et ce qui bloque.
- La realisation : parametrage, tests unitaires, coordination avec les autres modules.
- La demo : a la fin, on montre au metier ce qui fonctionne reellement, pas des promesses.
- La retrospective : l’equipe regarde ce qui a bien ou mal marche, pour s’ameliorer.
Réflexe consultant
Au daily, annonce un blocage des qu’il apparait, pas la veille de la demo. Un sprint agile fonctionne sur la transparence rapide. Un point cache le lundi devient une crise le vendredi.
Ce qui rend un sprint SAP particulier
SAP n’est pas un logiciel isole. Une user story cote ventes touche souvent la finance et le stock. Un sprint SAP doit donc gerer les dependances entre modules. On ne peut pas toujours livrer un sujet seul : il faut parfois attendre qu’un autre consultant ait parametre sa partie.
Autre specificite : les transports. Chaque modification part d’un environnement de developpement et doit remonter vers la recette pour etre testee. Ce circuit prend du temps et doit etre planifie dans le sprint. Oublier ce delai, c’est promettre une demo qu’on ne pourra pas montrer.
À éviter en mission
S’engager sur trop de sujets pour faire bonne impression a la planification. Un sprint rate detruit plus de confiance qu’un sprint modeste mais tenu. Promets peu, livre sur.
Vu en mission
Le sujet parametre est pret, mais le transport n’est pas remonte en recette a temps. La demo tombe a plat, non par manque de travail, mais par manque d’anticipation du circuit technique. Le delai de transport se planifie comme le reste.
Ton plan d’action pour reussir un sprint
- A la planification, estime ta charge en incluant les tests et le temps de transport.
- Decoupe chaque user story en taches concretes et verifiables.
- Identifie tes dependances avec les autres modules des le premier jour.
- Signale tout blocage au daily, sans attendre.
- Prepare ta demo en avance : un scenario qui tourne vaut mieux qu’un discours.
Tu veux etre a l’aise dans un projet SAP agile ?
Savoir s’engager juste, gerer les dependances et tenir ses demos rassure les clients. C’est ce que l’on travaille dans le programme AZ Premium.
Le document ci-dessous approfondit le deroulement d’un sprint SAP et te sert de support a conserver.
Telecharger : dans la peau d’un consultant SAP, le deroulement d’un sprint SAP