Agile & SCRUM

Back to Basics

 

From meetup hosted by OpenSka on 20/04/2017

Qu'est ce que l'Agile ?

  • N'est pas une méthode de travail
  • Culture avant tout
  • Transformation pas toujours facile
  • Pas seulement pour les IT, l'entreprise est agile

Iterative

  • Itération courtes
  • Contrairement au cycle en V, Waterfall

Iteration                    Vs                    Waterfall

Incrémental

  • Le produit s'améliore constamment
  • Changement d'une fonctionnalité rapide

Adaptative

  • Adapter la méthode au concept

L'équipe

  • Les individus et leurs interaction plus que le processus et les outils
     

La collaboration

  • La collaboration avec les clients, plus qu'une documentation exhaustive
  • Créer une interaction avec le client, il ne faut pas s'isoler
     

L'application

  • Des logiciels opérationnels, plus qu'une documentation exhaustive
  • Le produit est le plus important
     

L'acceptation au changement

  • L'adaptation au changement, plus que le suivi d'un plan
  • Accepter que l'on peut faire des erreurs, et que des parties développés seront jetés
     

Qu'est ce que le SCRUM ?

Cadre légér

  • Les sprints et leur événements
  • Les 3 rôles clés

Les 3 piliers du SCRUM

1. La transparence

Board Mural
 

  • Visible pour tous
  • Utilisation de Post-it fixé avec une bande de scotch
  • Sert de support pour le Daily Scrum

Avancement de l'ensemble de la team

 

  • Etat des taches de travail
  • Avatar de chaque membre sur la tâche

 

Post-it pour infos clé

 

  • Le logiciel lié (JIRA ou TRELLO) donne les détails

La transparence Review

  • Présenter le travail réalisé en fin de sprint
  • Indiquer la suite
  • Contenu du prochain Sprint
  • Parler d'évolution possibles
  • Rassurer le corps management

2. L'inspection

Daily Scrum

  • Lever d'éventuelle alertes
  • Problèmes pour les devs
  • Alerte planning par le Product Owner

Burndown Chart

  • Outil complémentaire
  • Permet d'anticiper le retard
  • Graphe qui doit au fur et à mesure aller de 100 vers 0 avec ligne représentant la courbe idéale

L'inspection: retrospective

"On n'améliore pas tout d'un coup, mais étape par étape et tout le temps"

Humeur de l'équipe

  • Anticiper un risque sur la productivité
  • Connaitre la santé de l'équipe

Amélioration continue

  • Trouver des axes d'amélioration

  • Améliorer => remotiver les troupes

3. L'adaptation

Méthodes adaptés

  • Trop de perturbation
  • Mise en place d'un kanban en plus du Scrum pour les bugs :
    https://fr.atlassian.com/agile/kanban
  • Impediment Backlog
  • Beaucoup de petit projets = sprint de 2 semaines

S'adapter au contexte

  • Un peu de Lean Startup

  • http://www.lean-startup.net/

  • Respecter les piliers mais rendre la méthode flexible

Les rôles indispensables

1. Le Product Owner

Propriétaire du backlog

  • Choisit l'ordre des demandes
  • Respecte la capacité de développement
  • Rappelle les objectifs
  • Invite les clients à voir le produit

  • Crée le besoin avec le client

Ecrit les user-stories

  • Assure leur compréhension de tous
  • Peut arrêter un Sprint en Cours
  • Assiste au Daily Scrum mais ne participe pas

Un user-story ??

Demande fonctionnel écrit sous un format particulier

Exemple :

  1. En tant que [persona]
  2. Je souhaite [souhait]
  3. Afin de [but]

Exemple de User Stories

2. Le Scrum Master

Coach

  • Gardien de la bonne pratique
  • Formateur
  • Choisit les itérations
  • Propose le temps des itérations

Facilite la vie

  • Facilite l'extérieur à s'adapter au Scrum

  • Ecarte les perturbations

  • Médecin de l'équipe

Animateur des rituels

  • N'est pas le chef de projet attitré
  • Permet de bien fixer les règles SCRUM
  • Ne fait pas de Dev
  • Profil très humain, parle avec les devs

=> permet de rendre les devs plus productifs

Rôle important mais mal jugé

  • Entreprises ont du mal à voir l’intérêt du Scrum master
  • Le confonde souvent avec le Chef de Projet, le manager ou un développeur

3. La Dev-team - 3 à 9 personnes

Responsabilité

  • Qualité du code

  • Pluridisciplinaire

  • Auto-organisé

  • En charge des décisions techniques

Essentiel

  • Instruction venant que du Product Owner
  • Travaille sur un seul Backlog

  • Chacun choisit ses user-stories en fonction de ses affinités et ses envies

Les Artefacts

Product Backlog

  • Ensemble de demandes fonctionnelles
  • Scrum-master arbitre si besoin

User Story

  • Définir en équipe le "Definition of Done" (pour la qualité)
  • https://www.agilealliance.org/definition-done-user-stories/

Sprint Backlog

User-story prise en charge dans un Sprint

Refactoring ou bug ne doivent pas être lié à des user-stories

1. Le Sprint

Daily Scrum

  • Product Owner présent mais ne participe pas
  • Scrum Master arbitre si besoin (ex: temps de parole dépassé)
  • Réunion de 15 min max
  • Chacun dit ce qu'il a fait hier
  • Ce qu'il va faire aujourd'hui
  • Peut remonter une alerte

Processus à suivre

  1. Le Product Owner propose des user-stories (US)
  2. L'équipe invalide les US non comprises ou incomplètes
  3. L'équipe note le point d'effort des US (en j/H ou en complexité)
  4. Un Sprint dure de 2 à 4 semaines

Estimer en complexité

  • Pas de temps de dev en j/H car ne sont jamais réellement respecté
  • Mouvement de "No Estimate", pas de j/H, on avance et le produit avancera tout seul
  • Le "Poker Planning" est souvent utilisé pour la complexité ou la Suite de Fibonacci

L'esprit Planning

  1. Proposition d'un Sprint Planning par le Product Owner
  2. Transformation des US par l'équipe en tâche technique
  3. Rappel de l'objectif du Sprint par le PO
  4. PO démarre le sprint

2. Le Sprint Review

Présentation du travail réalisé

  • A l'équipe
  • Au product Owner
  • Au clients invité par le PO

Discussion ouverte

  • Travaux envisagés dans les prochains Sprint
  • Axe d'améliorations

3. La Retrospective

Amélioration continue

  • Inspection en équipe du Sprint terminé
  • Evolution future
  • Déduire des axes d'amélioration

Santé de l'équipe

  • Le Scrum Master s'en inquiète
  • Détermine la santé de l'équipe (ex: sous forme d'atelier)
  • Dure de 1 à 3h en fermeture de Scrum

Au delà du SCRUM

Scrum bien

Scrum Agile mieux

Le ScrumBan

  • Mélange du Scrum et Kanban
  • Reprends Les itérations, piliers et Rôle du Scrum
  • La souplesse du kanban
  • Très adapté pour tous les métiers

Le MVP

  • MVP = minimum viable product
  • Savoir pivoter d'approche (ne pas persister sur une idée qui ne fonctionne pas)
  • Le client a la base du produit
  • Faire des mesures comprises par tous

Exemple avec un Burger

  • MVP = Pain / Steak / Pain
  • Le MVP plait ? Si oui, on pense au produit
  • Product => Pain / Salade / Fromage / Tomate / Oignon / Steak / Pain

MVP

Product

D'autres organisation que Scrum

  • Le Nexus
  • Le LeSS (Large Scale Scrum)
  • Le modèle de Spotify pour l'agilité à grande échelle

Note : Spotify a testé des tas d'organisation Agile et de modèle de santé de l'équipe,

Etudes sur Spotify

  • http://www.frenchweb.fr/comment-spotify-revolutionne-le-management-avec-plus-dautonomie/234578
  • http://ayeba.fr/2013/06/spotify-est-agile-a-grande-echelle/
  • Vidéo très intéressante (part 1 & 2) :
    https://vimeo.com/85490944
    https://vimeo.com/94950270

D'autres Liens

  • https://www.lesechos.fr/09/12/2016/LesEchos/22336-131-ECH_la-methode-agile--une-promesse-et-un-defi-a-la-fois.htm
  • http://www.agiliste.fr/introduction-methodes-agiles/
  • http://www.agiliste.fr/guide-de-demarrage-scrum/
  • http://www.thierry-pigot.fr/scrum-en-moins-de-10-minutes/

Merci ;)

CR meetup Agile

By Kevin JHappy

CR meetup Agile

From meetup hosted by OpenSka on 20/04/2017

  • 360