Découvrir SCRUM en 10 minutes

Process-Diagram

Posons rapidement le cadre de SCRUM. C’est une sorte de jeu avec des règles simples.

Qui sont les joueurs ? il y a 3 rôles dans SCRUM :

Product Owner :

  • il est le propriétaire du résultat,
  • il est celui qui a le budget,
  • il définit par ajouts successifs (on parle d’un « product backlog » vivant par opposition à un « cahier des charges » figé) ce qui constitue le périmètre fonctionnel du produit (ce à quoi il répond au niveau métier)
  • il est celui qui sait répondre aux questions : pour qui (qui utilise) ? pourquoi (finalité de la demande) ? quoi (ce qui est attendu) ? Il doit en permanence affiner sa compréhension des besoins du terrain, des utilisateurs, des clients finaux de l’application ; il doit connaître les processus métier, les différents cas possibles, les règles de gestion métier.
  • détermine si une demande métier a de la valeur et si elle en a plus ou moins qu’une autre, définit si elle fait partie des demandes incontournables ou si on pourrait s’en passer (cf méthode MoSCoW) les priorise…

L’équipe SCRUM :

  • C’est une équipe de 3 à 7 membres, comprenant des équipiers polyvalents ayant tous un statut égal dans l’équipe, pouvant affiner une demande (specs), faire des tests (tests unitaires, d’intégration, fonctionnels, de performance), faire du développement…
  • On cherche en général un bon mix entre Juniors et Seniors, avec différentes spécialités d’origine, certains plus expérimentés en architecture, d’autres en industrialisation, d’autres sur le testing, les performances, etc. L’idée est au départ d’avoir une couverture complète des besoins par au moins un équipier et de progressivement mutualiser la compétence afin d’éviter qu’une tâche ne puisse être prise que par un équipier
  • Il n’y a pas de chef d’équipe, de chef de projet en SCRUM, l’équipe est auto-organisée.

Le ScrumMaster :

  • Il est le gardien du temple, de la bonne application du cadre SCRUM (et chez OPEN de sa traduction en Quali-T agile) mais aussi celui qui doit en permanence veiller à garder active la curiosité du début, la recherche de nouveaux gains d’organisation, l’innovation dans les façons de travailler, de s’améliorer en rétrospective… Ce rôle n’est pas son exclusivité, il peut et doit inciter chacun à innover, à entrer personnellement en processus de progression continue et à ce titre de surprendre, innover, être force de proposition…
  • Il est le facilitateur et à ce titre met tout en œuvre pour que l’équipe ait tous les moyens de bien travailler (espace de travail et de communication par affichage mural, ordinateurs, logistique, lieu de réunion, post-its…).
  • Il protège l’équipe des perturbations extérieures, organise le départ / l’accueil d’équipiers, anticipe les absences pour congés de l’équipe comme du PO, il est au service de l’équipe et du PO
  • Il a une posture basse, n’est pas en posture de leadership ce qui tranche avec un profil de chef de projet.

Ces trois rôles ne touchent qu’à l’aspect opérationnel d’un projet qui va de la compréhension de la demande au développement et jusqu’au au processus de livraison. Or, dans une organisation de type SSII,  il y a d’autres activités à mener qui ne sont pas du ressort de ces trois rôles SCRUM :

La gestion contractuelle : ce n’est pas un hasard que SCRUM n’aborde pas ce sujet vu que l’une des 4 valeurs porte sur la relation collaborative plus que sur le respect du contrat. Quoi qu’il en soit, une SSII travaille pour des clients avec des contrats. Il y a souvent des écarts entre le contrat juridique passé entre la SSII et son client (régie, forfait) et le type d’engagement que l’on prend dans un cadre comme SCRUM (engagement). Le mode qui s’approche le plus de SCRUM est la régie forfaitée.

Le pilotage de haut niveau, macro (pas le pilotage opérationnel sur un sprint qui est géré par l’équipe) qui consiste à assurer un certain nombre d’actions dans une société de prestation. Cela va :

  • en avant-vente de la vérification du réalisme du chiffrage et de la faisabilité du projet dans les conditions proposées (avant validation du devis interne technique par la hiérarchie et envoi de l’offre au client)
  • de la récupération de la commande,
  • de l’ouverture des lignes budgétaires pour que l’équipe puisse imputer son temps
  • de la mise en place des outils de pilotage macro dans la relation de pilotage et validation du service fait / obtention des PV permettant la facturation
  • du recrutement initial (puis renforcement, réduction, renouvellement ou démobilisation) de l’équipe et de poser le cadre de travail (agile ou classique)
  • du management de l’équipe : suivi de la motivation, du développement de chaque équipier, de ses souhaits d’apprentissage et d’évolution
  • du suivi du bon avancement des prestations conformément aux prévisions (suivi de la maitrise du projet sur ses différents axes)
  • de la validation des imputations des temps et frais sur les contrats
  • de la gestion des risques du projet
  • de la gestion de crises de toutes natures (internes, client…)
  • de la gestion des décisions prises (les formaliser, veiller à leur mise en œuvre)
  • de la facturation

La gestion financière et les reports internes :

  • CEP (compte d’exploitation projet) et PSM (Point de Situation Mensuel)
  • PPH CDS (point de pilotage hebdomadaire du centre de services) et PPM (point de pilotage mensuel) CDS avec météo projet et suivi de production
  • Gestion du processus de facturation et transmission des éléments à facturer dans le fichier de liaison « Echéancier »

On le voit, ces activités ne sont pas à proprement parler celles d’un PO ni d’un ScrumMaster mais doivent être réalisées ; leur répartition est à opérer entre les acteurs.  Précisions : le PO peut-être le client mais aussi le DP ou le CP… cela dépend du contrat et du niveau d’engagement (moyen / forfait), de la disponibilité du client, de sa présence opérationnelle aux côtés de l’équipe.

Les rôles étant posés grossièrement, découvrons un peu plus SCRUM.

Vocabulaire de base à appréhender :

Estimations en points de complexité : chaque demande métier est évaluée par l’équipe en points de complexité et non en jours hommes. La demande la plus simple vaut 1 point ; une demande deux fois plus complexe vaut 2 point, une trois fois plus complexe 3 points… Cela permet d’éviter de toujours parler en unités de moyens (jh) et de se centrer sur une unité de résultat.

Vélocité : c’est le nom donné à la capacité de production de l’équipe au cours d’une itération moyenne à équipe complète. La vélocité se calcule en points. Par exemple, si au cours des trois dernières itérations, l’équipe a livré 13 points, 12 points puis 14 points, la vélocité de l’équipe est autour de 13 points. C’est un peu comme si pour une usine de fabrication de camions, on disait qu’on peut produire en moyenne 1000 camions par itération d’un mois, mesure beaucoup plus pertinente que d’annoncer une capacité de 1200 hommes jour.
User Story : c’est une histoire utilisateur. Elle doit être formulée de manière à mettre en évidence la valeur métier de la demande : « en tant que » [utilisateur], « je souhaite » [pouvoir consulter le solde de mon compte bancaire sur le site de ma banque] « afin de » [savoir si je suis à découvert, voir la tendance du solde et décider…]. C’est à la fois différent d’une spécification fonctionnelle et d’un use case : la specification est un découpage par fonction et non par processus, la spec est plus centrée sur la solution et une description détaillée de l’IHM, des interfaces, la story est centrée sur la valeur métier.
Product backlog : c’est une liste de userstories mise à jour au fil de l’eau par le PO. Elle tient lieu de cahier des charges mouvant. Contrairement au cahier des charges d’un projet mené de manière traditionnelle qui est figé au moment de la consultation, le backlog est totalement évolutif. Dans un projet agile, les demandes métier arrivent au fil du projet de manière totalement normale et attendue sans que l’on considère cela comme un « changement » par rapport au « plan initial » et que cela se traduise par un avenant. Le « changement » en agile est la norme.

  • Le PO est le propriétaire du produit et donc du product backlog qui en décrit les valeurs métier.
  • Le PO doit saisir les userstories et les prioriser de 1 à n en évaluant la valeur métier de chaque story : en effet, livrant par itérations courtes, on va livrer le logiciel très vite (dès les premières semaines) donc il faut savoir ce qui a le plus de valeur aux yeux du client. Aucun projet classique ne met autant l’analyse de la valeur au centre du système de pilotage.
  • L’équipe doit estimer chaque story en points de complexité.
  • Le PO peut positionner les user-stories sur un « plan de release » c’est-à-dire sur un macro-planning courant sur les prochaines itérations.

Le Sprint Backlog : lorsqu’une story est embarquée dans une itération (aussi appelée Sprint), on la positionne dans le sprint backlog : c’est un tableau mural sur lequel l’équipe communique par des éléments de management visuel en déplaçant des post-its avec un code et une structuration dont elle a défini les principes. L’équipe décompose alors la story en tâches à réaliser estimées en heures pour pouvoir considérer la story comme terminée. Les tâches sont toutes positionnées dans la colonne « à faire» du sprint backlog, et passent ensuite dans la colonne « en cours » puis dans la colonne « terminée ».
La « Définition of Done » ou « Définition de Fini » : l’équipe et le PO doivent se mettre d’accord sur cette définition. Que signifie le fait de dire qu’une tâche ou une user story est « terminée » ? Qu’elle est développée ? Testée (au niveau unitaire, fonctionnel, au niveau des performances) ? Spécifiée (fonctionnellement, techniquement, en termes d’attentes de performance unitaire ou en charge) ? Documentée ? Intégrée (intégration continue) ?

SCRUM est basé sur un rythme régulier

Le cadre SCRUM est un cadre itératif, où chaque itération a la même durée que les autres et où chaque itération est organisée de manière identique avec des « cérémonies » qui sont sanctuarisées. Apparait un rythme, une sorte de groove, avec un cadencement régulier, des cérémonies régulières. Voyons donc à quoi ressemble ce rythme…

Séquences unitaires : l’itération ou le sprint.

  • A chaque projet on définit la durée de l’itération adaptée au projet. Dans la plupart des cas, les équipes choisissent 2 ou 3 semaines. Dans de plus rares cas, moins de 2 semaines ou jusqu’à un mois.
  • Une itération se traduit par l’engagement de l’équipe à embarquer plusieurs demandes du PO dans l’itération et à livrer à l’issue un logiciel opérationnel qui répond aux demandes du PO.
  • La durée est intangible. Le jour prévu, on livre ce qui est prêt. Et s’il manque une demi-journée pour finaliser, on livre ce qui est prêt (contrairement à une approche classique où on décale la livraison d’une demi-journée.
  • L’avantage de cette durée fixe est d’enchainer de nombreuses itération de même durée sur la même techno, le même métier client, le même PO… plus ça va, plus on se comprend, mieux on travaille ensemble, et plus on sait (le client et nous) ce qu’on est capable de délivrer comme valeur de logiciel qui fonctionne dans la durée d’une itération

En début de sprint, le Sprint planning :

  • C’est la cérémonie de début de sprint : PO et équipe parcourent le product backlog priorisé par le PO. L’équipe procède aux estimations manquantes des stories non encore évaluées.
  • L’équipe s’engage ensuite à livrer dans la prochaine itération les stories les plus prioritaires à concurrence du nombre de points qui correspond à la vélocité constatée de l’équipe sur les dernières itérations.
  • Le client peut avoir envie de challenger l’équipe mais il ne peut pas lui faire revoir une estimation si l’équipe après avoir considéré la demande maintient son estimation.
  • Le sprint planning : c’est la première étape en début d’itération qui consiste à s’engager auprès du PO sur une liste de demandes qu’on livrera dans l’itération puis à décomposer chaque demande en différentes tâches à accomplir. La demande métier (user story) est estimée en points de complexité, les tâches sont estimées en heures de travail.

Quotidiennement : le daily stand-up meeting

  • Cette réunion très courte (10 à 15’) se déroule debout, en demi-cercle face aux task boards, à heure fixe avec les équipiers présents ce jour là. On ne décale pas le stand-up pour attendre un retardataire.
  • Dans cette réunion, chacun parle à son tour, dit sur quoi il a travaillé hier, ses éventuelles difficultés et besoins d’aide, et la prochaine tâche qu’il va traiter dans la journée.
  • On ne débat pas, discute pas. Cette réunion doit rester courte car tout le monde étant rassemblé, une réunion trop longue coûterait cher et ferait perdre du temps de production. Elle permet de savoir où on en est, qui fait quoi, et où émergent des difficultés. De là, on peut après le stand-up en comité restreint traiter des points difficiles, pourquoi pas par exemple en pair-programming ou en faisant un focus avec un architecte.

Puis en fin de sprint : deux cérémonies : la démo et la rétro

  • La démo : elle se positionne à la fin du sprint ; elle est orientée produit ; l’équipe présente le produit au client, devant le PO, des utilisateurs… c’est une présentation publique du produit délivré.
  • La rétrospective : elle suit la démo ; c’est un temps d’introspection, orienté sur le processus de fabrication, sur le mode de fonctionnement et d’interaction entre les acteurs, sur les raisons de certains dysfonctionnements de l’équipe.

Voilà pour les bases. Scrum est assez simple et se résume à cela. C’est à la fois un cadre qu’il faut respecter strictement si l’on veut bénéficier de ses apports et de sa sécurité et à la fois un cadre léger (très différents des cadres qualité classiques avec leurs centaines de processus et procédures). Un coach agile de Grenoble (Jef Jagodzinski) dit que « SCRUM permet d’encadrer le chaos ».

Ensuite, de nombreuses questions arrivent lorsqu’on commence à pratiquer. Mais mieux qu’un long discours, laissons chacun pratiquer sur un projet concret et avançons ensemble quand les problématiques seront soulevées.

Pour aller plus loin…

Vous trouverez beaucoup d’informations sur SCRUM (« mêlée » en anglais), sur le net, dans les livres. Voici parmi les milliers de sources quelques clés d’entrée dans l’agilité sur les blogs et dans les livres :

  • Gestion de projet – vers les méthodes agiles de Véronique Messager-Rota (Valtech) : c’est par là que j’ai compris l’agilité… Très bon parallèle avec la vision classique / PMI.

Crédit photo : Braintrust (USA)

Publicités

2 réflexions sur “Découvrir SCRUM en 10 minutes

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s