Analyse de la méthodologie agile mise en place chez OpenClassrooms.

1. MÉTHODOLOGIE DE
GESTION DES TÂCHES
DANS LES PROJETS WEB
Etude de cas chez OpenClassrooms

2. QUI SUIS-JE ?
Romain Kuzniak
@RomainKuzniak
CTO

3. OPENCLASSROOMS
Offre de formation sur la transformation
digitale et les nouvelles technologies
Ouvert à tous, du débutant à l’expert, de
l’étudiant au professionnel en passant par les
personnes en reconversion

4. OPENCLASSROOMS
1000 cours et MOOC
1,5 million de membres
3 millions de visiteurs uniques par mois
15 à 20 millions de pages vues par mois
Première plateforme de digital learning
d’Europe

5. POURQUOI EST-CE IMPORTANT ?

6. Ratio de rendement de 1:100 entre deux
organisations
Influe sur les conditions de travail de tous
Elément compétitif pour l’entreprise (ex.:
Ford, Toyota …)

7. OBJECTIFS

8. PRODUIRE DE LA VALEUR

9. PRODUIRE DE LA VALEUR
Valeur business
Valeur métier
Valeur utilisateur

10. PRODUIRE DE LA VALEUR
Définir ce qu’est la valeur
Définir ses KPIs (Key Performance Indicator)
Pouvoir mesurer la valeur
Mettre en place les outils pour pouvoir mesurer ses
KPIs
Mettre en place des outils pour pouvoir simuler
l’évolution des KPIs (A/B testing …)

11. PRISE DE CONSCIENCE COLLECTIVE
DE CE QU’EST LA VALEUR

12. RÉUSSIR PAR L’AGILITÉ

13. Y A T IL EU UNE VIE AVANT L’AGILITÉ ?

14. La bonne fonctionnalité
Pour les bonnes personnes
Au bon moment

15. AGILE MANIFESTO
Privilégier :
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

16. PROCESSUS
Itératif
Incrémental
Adaptatif

17. PROCESSUS
Pour les fonctionnalités
Pour les processus

18. L’AGILITÉ CHEZ
OPENCLASSROOMS
Culture d’OpenClassrooms
Dans tous les métiers

19. CYCLE DE VIE D’UNE TÂCHE CHEZ
OPENCLASSROOMS

20. -Pablo Neruda
« La vérité, c’est qu’il n’y a pas de vérité. »

21. Notre vérité n’est pas votre vérité
Notre vérité du jour n’est pas celle d’hier
Ni celle de demain

22. Processus agile
Sprint de deux semaines

23. QU’EST-CE QU’UNE TÂCHE ?
Une fonctionnalité
La correction d’un bug
Une tâche technique

24. QU’EST-CE QU’UNE TÂCHE ?
Description
KPIs impactées et gain attendu
Durée estimée

25. ÉTATS D’UNE TÂCHE

26. CYCLE DE VIE DE LA TÂCHE
Todo
In
Progress
To
Review
To
Verify
Verified Done

27. TODO
Tâche à réaliser durant le sprint
Classement avec notion d’importance
(valeur / temps estimé)

28. IN PROGRESS
Tâche en cours
Désormais le seul objectif est de la mettre à
Done
Eviter de cumuler
Amélioration continue de la productivité
(Boyscout Rule)

29. TO REVIEW
Validation technique
Participe à la montée en compétence de
l’équipe
pour le reviewé
pour le reviewer

30. TO VERIFY
En attente de validation fonctionnelle
Déploiement sur un environnement de Stage

31. VERIFIED
Validée fonctionnellement
Prête à être mise en production

32. DONE
En production

33. CYCLE DE VIE DE LA TÂCHE
Todo
In
Progress
To
Review
To
Verify
Verified Done

34. POUVOIR FAIRE LE PROCESSUS DE
BOUT EN BOUT EN UNE JOURNÉE

35. PROCESSUS AFFÉRENTS
Intégration continue
TDD
Builds automatiques
100% de coverage sur les règles métiers
Déploiement continu
Mise en production plusieurs fois par jour

36. RITUELS

37. Draft Rétro
Planning
Time
DSM DSM DSM DSM DSM DSM DSM DSM DSM DSM
1st week 2nd week

38. DAILY STAND UP
Objectif :
Maintenir l’équipe informée des avancées
de chacun
Pouvoir détecter des blocages
Valoriser le travail

39. DAILY STAND UP
Comment :
Tous les matins à heure fixe
Permet à l’équipe de s’organiser
Aligne un minimum les horaires
Retard = une croix, trois croix = le petit déjeuner pour toute l’équipe
Eviter que cela dure trop longtemps
Debout
Si des discussions commencent, il faut les traiter après le Stand Up
Durée fixe (9 minutes max)

40. LA DRAFT
Objectif :
Sélectionner les tâches à mettre dans le
prochain sprint
Comment :
Rapport : KPIs impactées / Durée de réalisation
le plus élevée

41. PLANNING TIME
Objectif :
Mesurer la durée d’une tâche
Avoir des tâches prêtes à être traitées
Comment :
Meeting une fois par sprint
Estimation de toutes les tâches (y compris Backlog)

42. PLANNING TIME
Règles :
Une tâche de plus de deux jours doit être re-découpée
facilite le développement, la revue de code, la validation et le
déploiement
Demander les informations manquantes
Meeting pénible :
Aller à l’essentiel
Rendre « fun » (gâteau …)

43. RÉTRO
Objectif :
Amélioration continue de la productivité
Amélioration continue des processus
Appropriation des processus par l’équipe

44. RÉTRO
Comment :
Meeting une fois à la fin du sprint
Analyse des actions prises précédemment
Retour sous forme de jeu
Points positifs
Points négatifs
Questions?
Etablissement des actions à prendre pour le prochain Sprint
Rapport envoyé à l’équipe Tech

45. SPREAD THE WORD
Objectif :
Maintenir les autres équipes à jour dans la connaissance du
produit
Comment :
Communication au fil des mises en production sur les tâches
majeures
Meeting entre les différents pôles à la fin du sprint
Rapport envoyé à toute l’équipe

46. POINTS IMPORTANTS

47. POINTS IMPORTANTS
Privilégier la valeur
Culture du Done
Appropriation des processus par l’équipe
Tâches inférieures à 2 jours
Agilité + clean code = DYNAMITE
Plus nous avançons, plus nous allons vite

48. BIBLIOGRAPHIE

49. Extreme Programming Explained: Embrace Change, Kent Beck, (Addison-Wesley,
1999)
The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create
Radically Successful Businesses, Eric Ries, (Crown Business, 2011)
Agile Software Development with Scrum, Ken Schwaber, Mike Beedle, (Prentice Hall,
2002)
Agile Software Management with Scrum, Ken Schwaber, (Microsoft Press, 2004)
Toyota Production System: Beyond Large-Scale Production, Taiichi Ohno, (Productivity
Press, 1988)
Agile Management for Software Engineering: Applying the Theory of Constraints for
Business Results, David Anderson (Prentice Hall, 2003)
Lean Software Development: An Agile Toolkit, Mary Poppendieck, Tom Poppendieck,
(Addison-Wesley Professional, 2003)
Crystal Clear : A Human-Powered Methodology for Small Teams, Alistair Cockburn,
(Addison-Wesley, 2004)
Agile Manifesto

50. MERCI