Publicité

Symposium scrum

16 Dec 2015
Publicité

Contenu connexe

Publicité

Symposium scrum

  1. SCRUM et méthodes agiles
  2. SCRUM et méthodes agiles
  3. SCRUM et méthodes agiles 1. Philosophie 2. Les rôles 3. Les items 4. Déroulement d’un projet agile 5. Outils de suivi de projets agiles 6. Les outils de support 7. Problèmes fréquents et solutions 8. Encore plus d’agilité
  4. Le manifeste agile ● Rédigé en Février 2001 ● Issu d’une réunion entre 17 experts du développement logiciel ● Défini le noyau commun aux différentes méthodes agiles ● Composé de 4 valeurs et 12 principes
  5. Les 4 valeurs ● Les individus et leurs interactions plus que les processus et les outils ● Du logiciel qui fonctionne 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.
  6. Les 12 principes (1) ● Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. ● Accueillez positivement les changements de besoins, même tard dans le projet. Les processus agiles exploitent le changement pour donner un avantage compétitif au client. ● Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts. ● Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet. ● Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites- leur confiance pour atteindre les objectifs fixés. ● La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face. ● Un logiciel opérationnel est la principale mesure d’avancement.
  7. Les 12 principes (2) ● Les processus agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant. ● Une attention continue à l'excellence technique et à une bonne conception renforce l’agilité. ● La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle. ● Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées. ● À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.
  8. Les fondamentaux ● Développement itératif et incrémental ● Autonomie des ressources ● Implication de l’utilisateur final (client) dans l’équipe projet ● Equipe projet avec pouvoir de décision ● Recherche continue d’amélioration
  9. Les avantages attendus ● Suppression de l’effet tunnel ● Concentration des efforts sur la valeur métier ● Réactivité et acceptation du changement ● Amélioration de la productivité ● Amélioration du Time To Market ● Meilleure satisfaction des équipes ● Amélioration de la qualité
  10. SCRUM et méthodes agiles 1. Philosophie 2. Les rôles 3. Les items 4. Déroulement d’un projet agile 5. Outils de suivi de projets agiles 6. Les outils de support 7. Problèmes fréquents et solutions 8. Encore plus d’agilité
  11. Product owner ● Fait partie intégrante de l’équipe ● Représente les clients et les utilisateurs ● Est responsable de l’aspect fonctionnel du projet ● Défini et explique les User story (fonctionnalités) ● Priorise les User story ● Est responsable du Backlog produit ● Valide ce qui est réalisé
  12. ScrumMaster ● Est responsable de la compréhension et de l’application de la méthode ● Joue un rôle de facilitateur ● Elimine les obstacles pouvant nuire à l’efficacité de l’équipe ● Protège l’équipe des perturbations
  13. Equipe de développement ● Est autonome ● Implémente les besoins exprimé par le PO ● Contient toutes les compétences nécessaire à la réalisation d’un sprint ● Veille à la cohérence de l’architecture logicielle
  14. Organisation ScrumMaster PO Utilisateurs stakeholders Equipe Scrum
  15. SCRUM et méthodes agiles 1. Philosophie 2. Les rôles 3. Les items 4. Déroulement d’un projet agile 5. Outils de suivi de projets agiles 6. Les outils de support 7. Problèmes fréquents et solutions 8. Encore plus d’agilité
  16. User story ● Traduit une fonctionnalité du produit ● Se présente sous la forme “En tant que <rôle> je souhaite <action> afin de <objectif> ● Comprend les conditions d’acceptation (Si <précondition>, lorsque <événement>, alors <résultat>) ● Est pondérée par la valeur métier apportée ● Est initialisée avec des points d’effort
  17. User story ● Il existe 4 types de User stories : ○ la Story fonctionnelle (apporte de la valeur) ○ la Story technique (apporte de la valeur) ○ le bug fix (rétablit la valeur perdue) ○ le refactoring (rétablit la valeur perdue) ● Doit être INVEST (Indépendante, Négociable, Valorisable, Estimable, Small, Testable
  18. Backlog produit ● Est une liste ordonnée de toutes les User stories du produit ● Est la source unique d’exigence portant sur le produit ● Est dynamique, il évolue en fonction de l’environnement du produit ● Est trié par valeur métier (on implémente la plus haute valeur métier d’ abord)
  19. Backlog de sprint ● Définit un but pour le sprint ● Contient toutes les User stories à implémenter dans un sprint ● Les User stories sont découpées en tâches ● Les tâches sont estimées en heure (pas toujours) ● Dans l’idéal, une tâche ne devrait pas excéder une journée de travail ● Il définit également la “notion de fini” qui doit être partagée par l’équipe
  20. Articulation des backlogs Backlog produit Backlog Sprint User story #2 Tache 1 User Story #1 User story #2 User story #3 User Story #1 User story #2 User story #2 Tache 2 User story #2 Tache 3 User story #1 Tache 1 User story #1 Tache 2 Tâches
  21. Radiateur d’information ● Chaque post-it représente une tâche du sprint ● Les colonnes représentent les différents états ● Le but du sprint et les indicateurs sont affichés ● Le plan d’action relatif au sprint en cours est affiché ● Il est mis à jour durant le Scrum meeting Attention aux femmes de ménage et aux Post-it qui se décollent Il est recommandé de le prendre en photo tous les jours
  22. Radiateur d’information A FAIRE A FINIR FINI User story #1 User story #2 User story #3 Tâche 3 Tâche 4 Tâche 2Tâche 1 Tâche 5 User story #4 Tâche 1 Tâche 2 Tâche 1 Tâche 2 Tâche 3 Tâche 4 Tâche 1 Tâche 2 Tâche 3 BUT : Implémenter la création d’un client Définition de prêt Définition de fini Plan d’action 1 1 1 1 1
  23. SCRUM et méthodes agiles 1. Philosophie 2. Les rôles 3. Les items 4. Déroulement d’un projet agile 5. Outils de suivi de projets agiles 6. Les outils de support 7. Problèmes fréquents et solutions 8. Encore plus d’agilité
  24. Schéma général
  25. Sprint 0 ● Initialisation du projet agile ● Préparation du backlog (estimation, priorisation, …) ● Installation de l’infrastructure ● Installation de l’équipe ● Présentation du produit à l’équipe (contexte, enjeux, …)
  26. Réunion de planification de sprint ● Toute l’équipe doit être présente ● Le PO doit avoir préparé les User stories les plus prioritaires ● Sélection des User stories à implémenter dans le sprint à venir ● Affinage de l’estimation des User stories en point d’effort ● Décomposition des User stories en tâches ● Estimation des tâches en heure ● Préparation du backlog de sprint et du radiateur
  27. Sprint ● Limité dans le temps (time boxing) ● Durée de 1 à 4 semaines ● Le résultat doit être démontrable ● Le backlog de sprint ne peut être modifié durant le sprint ● Les sprints s’enchaînent sans intérruption ● Doit avoir un but. L’engagement de l’équipe porte sur ce but
  28. Scrum meeting ● Toute l’équipe doit être présente ● 15 minutes maximum ● Articulé autour de 3 question : ○ Qu’ai-je fais la veille ○ Que vais-je faire aujourd’hui ○ Quels problèmes j’ai rencontré
  29. Revue de sprint ● Toute l’équipe doit être présente ainsi que les stakeholders concernés ● 4H maximum ● Le Product owner présente le produit du sprint aux utilisateurs ● C’est aussi l’occasion d’échanger avec les parties prenantes du projet (collecte de feedback) ● Le backlog produit est ensuite mis à jour
  30. Rétrospective de sprint ● Toute l’équipe doit être présente ● Dédiée à l'amélioration continue ● L’équipe étudie les résultats des précédents plans d’action ● L’équipe analyse ce qui a bien fonctionné durant le sprint, ce qui n’a pas fonctionné et ce qui peut être amélioré ● A l’issue de cette réunion, un plan d’action est défini pour application durant le sprint suivant
  31. SCRUM et méthodes agiles 1. Philosophie 2. Les rôles 3. Les items 4. Déroulement d’un projet agile 5. Outils de suivi de projets agiles 6. Les outils de support 7. Les points clé pour réussir son projet agile 8. Encore plus d’agilité
  32. Les indicateurs (1) ● La vélocité : représente le nombre de points d’efforts qu’une équipe peut absorber en un sprint ● Le temps de cycle : mesure, pour chaque type de tâche, le temps moyen de réalisation (permet de détecter l’accumulation de dette technique) ● Le diagramme de flux cumulé
  33. Les indicateurs (2) Jours Tâches Temps de cycle WIP Diagramme de flux cumulés
  34. Les indicateurs (3) ● Le burndown chart : représente le RAF théorique (en points d’effort) par rapport au RAF réel
  35. Les indicateurs (4) ● Le Niko-Niko : mesure l’état d’esprit et l’enthousiasme de l’équipe : ● Les indicateurs standards de qualité (code, anomalies, …) :) :| :(
  36. SCRUM et méthodes agiles 1. Philosophie 2. Les rôles 3. Les items 4. Déroulement d’un projet agile 5. Outils de suivi de projets agiles 6. Les outils de support 7. Problèmes fréquents et solutions 8. Encore plus d’agilité
  37. Outils de support ● Intégration continue ● Contrôle de qualité (sonar) ● Automatisation des test (techniques et fonctionnels) ○ Le patrimoine de tests automatisés est déroulé régulièrement afin de vérifier la non régression ● Outils de travail collaboratif
  38. SCRUM et méthodes agiles 1. Philosophie 2. Les rôles 3. Les items 4. Déroulement d’un projet agile 5. Outils de suivi de projets agiles 6. Les outils de support 7. Problèmes fréquents et solutions 8. Encore plus d’agilité
  39. Problèmes fréquents (1) ● Accumulation de dette technique ○ Les développeurs doivent être confirmés ○ Utilisation de standards reconnu ○ Utilisation de composants réutilisables ○ Référentiel de solutions ○ Sprint de refactoring réguliers
  40. Problèmes fréquents (2) ● Manque de disponibilité du PO ○ Anticipation et fractionnement des revues de planification de sprint ○ Essayer de tendre les flux pour fluidifier le processus ○ Evangélisation sur la méthode agile (ScrumMaster) ● Chaîne de décision trop longue ○ Implication des stakeholders ○ Mise à disposition d’un bac à sable
  41. Problèmes fréquents (3) ● Backlog trop fourni ○ Création d’une roadmap produit et plan de release ○ Un Backlog produit correspondant à une release = 50 User stories ● User stories mal détaillées ou mal comprises ○ Le ScrumMaster doit s’assurer que les User stories sont bien comprises de l’équipe avant le sprint ○ Anticipation et fractionnement des revues de planification de sprint
  42. Problèmes fréquents (4) ● Réunion trop longues et pas assez productives ○ Se tenir à l’ordre du jour de chaque réunion (organiser des réunions séparées pour traiter d'éventuels problèmes) ○ Si les estimations sont trop chronophages, les User stories ne sont pas claires ● Goulots d’étranglement ○ Limiter le nombre de tâches en cours par état
  43. Problèmes fréquents (5) ● Problèmes de qualité ○ Adoption de normes partagées (architecture, codage) ○ Pour quelques sprints, fixer le but sur des questions de qualité ○ Responsabiliser les développeurs ● Mini cycle en V sur un sprint ○ Découper les User stories de manière verticale et non en couches ○ Bien définir la notion de fini ○ Limiter le nombre de tâches en parallèle par développeur
  44. Scrum best practices ● Laisser les développeurs choisir leurs tâches (volontariat) ● Garder un rythme soutenable sur le long terme (ne pas dépasser 80% de la vélocité maximale de l’équipe) ● Coder les tests avant la fonctionnalité ● Multiplier les POC pour les problèmes ardus afin de minimiser les risques techniques (simple design for complex problems) ● Travailler le collective ownership : chaque développeur est co-résponsable de la totalité du code
  45. Scrum best practices (2) ● Limiter autant que possible le multi-tâche (cf jeu du prénom)
  46. Scrum best practices (2) ● Être TOUJOURS transparent vis à vis de tous les acteurs ● Intégrer au minimum à chaque fin de sprint (éviter l’intégration big bang qui prend un sprint) ● INNOVER. L’amélioration continue ne s’arrête pas à l’adoption de bonnes pratiques, il faut tester, mesurer, vérifier
  47. SCRUM et méthodes agiles 1. Philosophie 2. Les rôles 3. Les items 4. Déroulement d’un projet agile 5. Outils de suivi de projets agiles 6. Les outils de support 7. Problèmes fréquents et solutions 8. Encore plus d’agilité
  48. Méthodes hybrides ● Garder les fondamentaux agiles ● Intégrer d’autres méthodologies en fonction de l’environnement et de la maturité de l’équipe ● Permet de gagner en productivité ou de respecter des normes d’entreprise (CMMI, TOGAF, ITIL, ISO, ...) ● Le changement est progressif et incrémental. ● L’impact de chaque pratique introduite est mesuré lors de la rétrospective
  49. ScrumBan => agilité + ● Introduit des pratiques Kanban à Scrum ● Permet de passer à un modèle en flux tiré ● Introduit la notion de limitation des travaux en cours par état (WIP) ● Permet de traiter les urgences plus rapidement ● Diminuer la complexité doit rester un objectif
  50. ScrumBan => agilité + A FAIRE A FINIR FINI priorité Tâche 1 Tâche 3 urgence Tâche 2 Limite WIP = 4 Tâche 5 Tâche 4 Limite WIP = 2 Tâche 8 Tâche 10 Tâche 9 Tâche 11 Tâche 6 Tâche 7
  51. ScrumBan => agilité + ● Démonstration par la théorie des files d’attente (loi de Little) : ○ WIP = Vélocité * Temps de cycle moyen ○ Temps de cycle moyen = WIP / Vélocité ● Pour réduire le temps de cycle (Time To Market), il faut donc diminuer le WIP ou augmenter la vélocité ● Pour régler la limite de WIP : ○ WIP Max = Temps de cycle moyen souhaité * vélocité
  52. Scrum et Lean => agilité ++ ● Principes Lean ○ Se focaliser sur la qualité (favoriser l’automatisation des tâches récurrentes, TDD, ...) et sur le time to Market ○ Se concentrer sur la valeur créée ○ Éliminer les gaspillages (Muda) ○ Intégrer le Knowledge Management ○ Prendre des décisions le plus tard possible ○ Optimiser la chaîne de valeur en permanence (Kaizen) kaizen : Amélioration continue kai : Changement zen : meilleur
  53. Scrum et Lean => agilité ++ ● Exemple de modélisation de la chaîne de valeur Demande d’ évolution Création d’une User story Attente de formalisation Ajout au backlog produit 2 jours Attente de fin de sprint 5 jours Ajout au backlog sprint Attente prise en compte tâche 3 jours Implémentation Attente de fin de sprint 4 jours Livraison Attente de déploiement 2 jours Mise en prod 0,5 jour 0,5 jour 0,5 jour 3 jour 1 jour 1 jour temps à valeur ajoutée (6,5 jours) temps total (22,5) = 29 %Taux de Rendement Global =
  54. Scrum et Lean => agilité ++ ● Les 7 sources de gaspillage appliquées à l’ingénierie logicielle : Attente Attente de réponse/décision, libération des ressources Transports/transferts Communication inefficace, manque de partage de l’information Processus excessif Compétences inadéquates, fonctionnalités inutiles, documentation excessive Stock Goulot d'étranglement, variabilité excessive, capacité saturée, multitâche Mouvement Manque d’accès direct à des ressources, chasse à l’information Non qualité Bugs, réinvention, pas d’appropriation collective du code, manque de standardisation Surproduction Manque d’automatisation, mauvaise priorisation
  55. Scrum et Lean => agilité ++ ● Trouver et éliminer les causes de gaspillage ○ Diagramme de causes à effet ■ 5 axes : les 5 M ○ Diagramme de Pareto ■ 20% des causes produisent 80% des effets
  56. Scrum et Lean => agilité ++ ● Estimation et planification ○ De plus en plus considéré comme une tâche sans valeur ajoutée( mouvement #noEstimate) ○ Traditionnellement basée sur des approximations ■ Règle du *2 + 10% ○ Souvent source de conflit entre le PO et le reste de l’équipe ○ De moins en moins fiable au fil du temps (cumul de dérives) ○ Reste nécessaire dans beaucoup de projets
  57. Scrum et Lean => agilité ++ Tâches +/- 2σ = 95% +/- 3σ = 99,7% Tempsdecycle
  58. Scrum et Lean => agilité ++ ● Placer le processus sous contrôle statistique ● Se baser sur des faits mesurés ● Améliorer la prédictibilité du processus ● La prévision s’améliore avec le temps ● Permet de détecter les anomalies dans le processus au plus tôt
  59. Scrum et Lean => agilité ++ ● Production en flux tendus (tendance à privilégier le flux continu par rapport aux sprints) ● Elimination des tâches sans valeur ajoutée ● Passe en mode processus contrôlé ● Facilite le travail entre équipe très spécialisées ● Augmente le feedback via une mise en place systématique de boucle ● Capitalise sur les connaissances acquises ● Gain de productivité de 20 à 40 % (étude McKinsey)
  60. Résultat
  61. Questions / réponses
  62. The end
Publicité