Télérama et la méthode Agile : les pièges et les bonnes pratiques - Actency Drupagora 2017

Drupagora 2017
Télérama et la méthodologie
Agile:
les pièges et les bonnes
pratiques.

SOMMAIRE
1. PRESENTATION DES INTERVENANTS
2. LE CHOIX DE L’AGILE
3. LE PROJET TÉLÉRAMA SORTIES
4. BATTLE PRODUCT OWNER Vs SCRUM MASTER
5. OBJECTIFS ATTEINTS
6. CONCLUSIONS
Drupagora 2017 – Télérama et la méthodologie Agile - Twitter : @Actency #drupactency 2/12

1. INTERVENANTS
3/12Drupagora 2017 – Télérama et la méthodologie Agile - Twitter : @Actency #drupactency

4/12Drupagora 2017 - Télérama et la méthodologie Agile
Twitter : @Actency #drupactency
Violaine Meneux
Responsable du département Projets / T.M.A.
@Actency
Violaine Meneux est à la tête d’une des équipes de production d’Actency,
composée de 30 Développeurs Drupal, Directeurs techniques et Scrum Master,
partagée entre Paris et Strasbourg.
Elle établit avec pragmatisme les process et les stratégies permettant à son
équipe de réaliser leurs projets en respectant les méthodologies Agile. Elle
apportera son expérience et sa vision sur les avantages et les risques d’appliquer
ce type de méthodologie dans un environnement Drupal et un contexte d’agence.
1. Les intervenants

Giovanni Dacheux
Scrum Master / Chef de projet technique
@Actency
Développeur Drupal puis Scrum Master / Chef de projet technique depuis 3 ans,
Giovanni est en charge de piloter l’équipe technique dédié au projet Télérama
Sorties.
En expert Drupal, il affronte les urgences et les difficultés inhérentes à une
méthodologie Scrum bien respectée. Mais il en connaît également les nombreux
avantages. Proche du terrain, il sait que la théorie ne survit pas à la pratique et il
apportera un témoignage d’application réaliste de la bonne application de la
méthodologie Agile Scrum.
1. Les intervenants

Laurène Chevalier
Product Owner Télérama Sorties / Chef de projet Marketing
@Télérama
Product Owner en charge de la création de Télérama Sorties. Responsable de la
stratégie marketing des produits web et notamment de la gestion de la relation
avec les services Clients, Abonnés et Adhérents dans le cadre du projet Drupal
Télérama Sorties.
Également en relation étroite avec le Scrum Master, Laurène Chevalier est une
pionnière de la méthodologie Agile au sein de Télérama. Elle a ainsi expérimenté
depuis de nombreuses années les bénéfices et les risques liés à ce mode de
gestion, que ce soit en interne ou dans la relation quotidienne avec ses fournisseurs.
Elle vous fera part de sa vision de la méthodologie Agile dans le contexte d’un
projet Drupal chez Télérama.
1. Les intervenants

2. TELERAMA

2. Présentation de la société TÉLÉRAMA
TÉLÉRAMA
● CA de 73,5 M€ (2016)
● Effectif de 160 CDI
● 485 000 abonnés
● Diffusion totale de 520 000 exemplaires
● 400 partenaires (ciné, théâtre…) dont 300 sur la plateforme
● 10 000 000 de visites sur le site telerama.fr (mai 2017)
● 5 000 000 de visites sur l’appli Grille TV (iOS et Androïd - mai
2017)
○ Plus d’une visite sur deux depuis un smartphone

3. ACTENCY

3. Actency – 100% powered by Drupal
ACTENCY
● 80 experts en projets Drupal, dont 50 Développeurs salariés (en France & hors freelances/partenaires)
● 7 agences & bureaux - dont une présence nouvelle au Canada depuis Janvier 2017

4. LE CHOIX DE L’AGILE
(Méthode SCRUM)

4. La méthodologie Agile
Qu’est-ce que la méthode Agile (Scrum) ?
https://www.slideshare.net/rsazima/why-the-lean-startup-changes-everything-37943327

La méthodologie Agile : pourquoi ?
Un constat simple sur les projets
menés en méthodologie “traditionnelle”:
TRADITIONNELLE
➢ 1 tiers des projets “classiques” n’aboutissent pas en
méthodologie classique
Source : The CHAOS Manifesto, The Standish Group, 2012
AGILE
➢ 64% des fonctionnalités “gaspillées”
➢ Seules 7% des fonctionnalités développées
sont “toujours” utilisées
Source : J.Johnson, Keynote speech, XP 2002 Italie
Méthodologie
Traditionnelle VS Agile

Principe de Fonctionnement
Scrum
Master
Product Owner
Product Owner
PRODUCT BACKLOG SPRINT BACKLOG INCRÉMENT
Planification
de sprint
Revue de sprint
rétrospective
SPRINT
2 à 4 semaines
Team

Le choix de la méthodologie Agile pour Télérama?
• Première expérience pour Télérama avec la méthodologie
AGILE
• Accélération du time-to-market pour livrer un produit en phase
de test sur une région française en 2 mois
• Digitalisation du groupe Le MONDE et Télérama en impliquant
l’ensemble des collaborateurs

5. LE PROJET
TÉLÉRAMA SORTIES

5. Le projet TÉLÉRAMA SORTIES
Les challenges du projet : contexte
Place de marché d’offres culturelles réservée aux abonnés

Les challenges du projet : contexte
Place de marché d’offres culturelles réservée aux abonnés
● Création d’une offre numérique forte et complémentaire à
destination des abonnés « papier » de Télérama mais aussi dans
un objectif de conquête
● Création de valeur autour de la marque
● Les cibles de Télérama :
○ Les abonnés
○ Les adhérents (partenaires culturels)

Les attentes métier vis à vis du projet
• L’Offre rencontre sa demande
○ Promotion d’offres proposées par les adhérents
○ Accéder et profiter de ces offres par les abonnés
• Levier d’acquisition autour d’une newsletter personnalisée
Questionnaire
Lancement
Rhône
bêtà-test
Ouverture
nationale
Sprint tech
Design maquettes
Filtres
Retours
Utilisateurs
Amélioration
PASS AMI

Les attentes techniques vis à vis du projet : système de réservation

Les attentes techniques vis à vis du projet : création d’offre ergonomique et facile

Les attentes techniques vis à vis du projet : visibilité d’offre par région

Les attentes techniques vis à vis du projet : approche responsive

6. BATTLE
What the scrum master
thinks I do
What the product owner
thinks I do

5. Battle de Scrum : Scrum Master vs Product Owner

Le Scrum Master :
Un interlocuteur unique ayant une
connaissance complète de Drupal
● Garant du bon suivi de la
méthodologie
● Leader des cérémoniaux Scrum
● Coordonne les équipes de DEV
● Pivot technico-fonctionnel
● Réactif et force de proposition
Le Product Owner :
Un interlocuteur unique ayant la connaissance
complète du produit à réaliser
● Force de proposition
● Organisation afin de suivre un rythme soutenu
● Savoir gérer, prioriser les besoins complexes
demandés par les parties prenantes
● Savoir gérer les frustrations liées aux détection
de bugs et aux fonctionnalités non priorisés
BATTLE DE SCRUM : explication des rôles
Doit rester pédagogue et pragmatique Doit se faire respecter par la confiance

Enjeu #1 :
Produire un Product Backlog
de bonne qualité

Product backlog de Télérama
#1 La difficulté de produire un Product Backlog de bonne qualité
Une User Story (= US)

#1 La difficulté de produire un Product Backlog de bonne qualité
Du point de vue Product Owner
• Exprimer et traduire des besoins
métiers brut et non des solutions
• Prioriser les besoins métiers
• Être précis au niveau des user
stories
Du point de vue Scrum Master
● Comprendre les US et proposer des
solutions adéquates dans la timebox
impartie
● Respecter les standard de Drupal pour
répondre aux besoin (Simplification First)
● Respecter la priorisation métier tout en
restant force de recommandation
“J’attends du SM qu’il me propose des
solutions standards Drupal”
“J’attends du PO que les US soient
précises et qu’il soit ouvert d’esprit”

#1 Exemple : Une seule User Story peut en cacher une multitude
A/ La User Story fourni par le PO
En tant qu'adhérent je souhaite pouvoir consulter un tableau de bord qui regroupe les
informations des sorties administrées par l'adhérent.

#1 Exemple : Une seule User Story peut en cacher une multitude
Attention aux Userstories qui ne sont pas décrites
suffisamment précisément : risque de ne pas tenir le délai

Enjeu #2 :
Livrer un produit sans
régressions

Scrum Master
● J’ai un effet régressif lié à la nature
itérative de la méthodologie (après 18
Sprints)
C’est une limite de la méthodologie Agile
● Facteur aggravant quand il n’y a pas de CIT
● Nécessité de faire des sprints de
rationalisation
Product Owner
● Ne pas perdre de temps à retester toute
la solution
● Éviter les régressions
● Obtenir de la valeur ajoutée pour mes
utilisateurs à chaque Sprint
● Le PO est souvent surchargé par de
multiples clients internes. Pas le temps
de tester, je dois faire confiance
#2 La difficulté d’obtenir un produit sans régression
“J’attends que le Scrum Master
me livre sans bug et sans
régressions”
“J’attends que le PO accepte de
prendre le temps de rationaliser le
code et de mettre en place un CIT”

#2 Exemple : un bug en production sur la réservation

Au bout de .. :
… 18 Sprints
… 12 Mois
… 6 Développeurs
... 150 Commits
… 400 lignes de code
Un fichier de code n’est plus
réalistement maintenable:
il faut rationaliser.

✓ Le système réalise des tests à la
place du client à chaque
modification de code
✓ Le système refuse les
modifications de code
provoquant des régressions
✓ 5 tests = Réductions de 50% de
tickets Anomalies (CHU
Strasbourg)
#2 Une solution efficace : le CIT (Continuous Integration Testing)

Enjeu #3 :
Respecter les cérémoniaux

#3 La difficulté de respecter les cérémoniaux : de quoi parle t-on ?
Scrum meeting Tous les matins la TEAM DEV et éventuellement le Scrum Master se réunissent pour faire le point sur le déroulé de la journée précédente, le déroulé de la journée en cours et
relever les différents points de blocage de l'équipe. Tous les points de blocage doivent être centralisés vers le Scrum Master pour traitement dans les meilleurs délais et
conditions.
Réunion de
planification de
sprint
Dans le cadre du projet Télérama cette cérémonie est réalisée entre le PO et le Scrum Master afin que la TEAM DEV ne soit impliquée uniquement lorsque les User Stories sont
découpés en micro tâche et que le scope des User Stories est validé.
La première itération s’effectue après la démo et permet de découper en tâche, vérifier la conformité des US et clarifier le besoin au mieux. Le PO décide dès lors par priorisation
les User Stories qui devront être traités.
Poker Planning Réunion durant laquelle l'ensemble de la TEAM DEV revoit avec l'aide du Scrum Master les User Stories à intégrer au sprint. Durant cette réunion la TEAM DEV rechiffre l'ensemble
des User Stories à produire et s'assure de la possibilité d’intégrer le périmètre sur la durée du sprint concerné.
Sprint Review Réunion regroupant tous les acteurs du projet et permettant de relever ce qui s'est bien passé sur le sprint et ce qui s'est mal passé. Afin de maintenir ce qui marche et corriger ce
qui ne marche pas. Des plans d'actions peuvent-être établis et validés par l'ensemble des acteurs (amélioration continue).
Démonstration A chaque fin de sprint la TEAM DEV et/ou le Scrum Master rencontrent le PO pour démontrer le fonctionnel développé lors du sprint. Cette démonstration se doit d'être préparée
et de prouver par son déroulement que l'ensemble des éléments des User Stories ont été implémentés et que les tests de recette prévus s'effectuent bien dans la cadre de la
livraison.
Gestion de la relation
PO & TEAM DEV
Au long des sprints le PO et la TEAM DEV s'aident du Scrum Master. Ce dernier a pour mission de faciliter l'avancement du projet et consacre donc du temps et au Directeur de
Produit et à la TEAM DEV. Son but est de maintenir une relation continue pour optimiser au mieux le temps de la TEAM DEV et ainsi maximiser la valorisation du temps de
développement pour le PO. Ainsi, dans le cadre de ce volume de jours, le Scrum Master intervient pour faciliter les échanges (les retraduire ou les vulgariser) afin que l'ensemble
des acteurs du projet soit toujours à jour de l'avancement projet et des actions restantes à réaliser pour atteindre les objectifs du projet.
Code Review Réunion de travail entre tous les Développeurs de la TEAM DEV pour transfert de compétences sur les tickets traités, les méthodes implémentées, etc. Cette réunion garantit la
bonne connaissance globale du code du projet et favorise l'augmentation de la vélocité de l’équipe de développement

● Réactions en chaîne:
○ Impossibilité de terminer les USs scopés
dans le sprint dans la timebox impartie
○ Descopage
○ Incompréhension fonctionnelle au
moment de la démonstration
○ Anomalie
#3 le piège : faire l’impasse sur le sprint planning
● Les causes :
○ TEAM dev indispo
○ Manque de temps
○ Excès de confiance
○ Illusion de maîtrise du
product backlog
Pas de Sprint Planning = Mauvais Chiffrage = Délai non tenu

Product Owner
● Savoir écouter, ne doit pas imposer, doit
être capable de gérer - et de concilier -
des demandes différentes
● Tenir un backlog regroupe les demandes
métier
● Avoir des parties prenantes
représentatives
Scrum Master
● Difficile de rendre disponible tout le
monde aux Sprint planning (poker
planning), Sprint Review et Sprint
Rétrospective en raison de l’aspect
Multi-Client des centres de services.
“J’attends que le PO ait
conscience du temps que cela va lui
prendre et qu’il soit formé pour
être un PO”
“J’attends que la méthodologie soit
strictement appliquée par le SM ”
#3 La difficulté de respecter des cérémoniaux

7. OBJECTIFS ATTEINTS

7. Objectifs atteints
Chiffres clés
• Délai pour obtenir le 1er MVP : 2 mois
• Nombre de sprint : 18
• Durée d’un sprint: 2 semaines
• Nombre de jour de dev : 350j
• Nombre de US : 300
• Nombre d’évolutions / anomalie : 400
• Nombre de lignes de code : 13 000
• Nombre de commit : 3 000, 1300 PR
• Modules contrib : 80
Modules custom : 39

Objectifs atteints

8. CONCLUSIONS

Conclusions : les temps statistiques d’Actency
8. Conclusions
INTITULÉ DE LA REUNION DURÉE THÉORIQUE QUI
Scrum meeting 15mn/Jour DEV+PO+(SM)
Réunion de planification de sprint 30mn/Sprint DEV+PO+SM
Poker Planning ½ journée/Sprint DEV+PO+SM
Sprint Review ½ journée/Sprint DEV+PO+SM
Démonstration ½ heure/Sprint PO+SM+ Parties Prenantes
Gestion de la relation PO & DEV 1,5 Jours/semaine SM
Gestion de la relation SM & DEV 1 Jour/semaine PO
Code Review 2Hr/semaine DEV

● Forcez-vous à respecter tous les cérémoniaux Agile, vous ferez des économies
● Tous les 4 sprints, prévoyez une phase de rationalisation du code
● Dès le départ ou au plus tard à partir de 10 Sprints, installez un CIT
● Formez vos PO et anticipez leur temps de travail
● Constituez une équipe de Parties Prenantes impliquée via le PO
● N’oubliez pas qu’une User Story peut en cacher beaucoup d’autres
Conclusions
8. Conclusions

Notre Happy Day
sera-t-il le vôtre?
HAPPY DAY CONTEST*
Comment participer ?
Rien de plus simple, il vous suffira de :
1. Tourner notre roue « Happy Wheel »
2. Publier sur Twitter votre résultat suivi
@Actency #HB10ans
Et tentez de gagner une trottinette électrique !
Ne manquez pas le tirage au sort « Happy Deal » qui se
déroulera le 30 Juin à 16h, vous serez peut-être l’heureux
vainqueur de notre grand jeu !
*Voir conditions et règlement sur le Stand ou sur le site Actency
http://www.actency.fr/fr/happy-day-contest

50/12
MERCI
En savoir plus,
Visitez notre site, téléchargez nos supports
www.actency.fr
www.twitter.com/actency
www.facebook.com/actency
Notre book de références
http://share.actency.fr/nos_references.pdf
Notre Factsheet Drupal
www.actency.fr/drupal

51
twitter : @actency
QUESTIONS?

MERCI
52
twitter : @drupagora
Drupagora 2017 – Télérama et la méthodologie Agile - Twitter : @Actency #drupactency

Télérama et la méthode Agile : les pièges et les bonnes pratiques - Actency Drupagora 2017

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Télérama et la méthode Agile : les pièges et les bonnes pratiques - Actency Drupagora 2017

Similar to Télérama et la méthode Agile : les pièges et les bonnes pratiques - Actency Drupagora 2017 (20)

More from Actency

More from Actency (13)

Télérama et la méthode Agile : les pièges et les bonnes pratiques - Actency Drupagora 2017