Initiation à l'agilité

Cas pratique : Chez Profideo

Initiation à l'agilité

Pourquoi l'agilité ? (1/2)

Le développement de projet / produit ne fonctionne pas (à 100%)
Quelle que soit l'industrie !
L'agilité ne résout pas tout, mais résorbe certaines anomalies.

Initiation à l'agilité

Pourquoi l'agilité ? (2/2)

Les individus et leurs interactions plus que les processus et les outils
La collaboration avec les clients plus que la négociation contractuelle
Des logiciels opérationnels plus qu’une documentation exhaustive
L’adaptation au changement plus que le suivi d’un plan

Nous reconnaissons la valeur des seconds éléments,
mais privilégions les premiers.
+12 principes

Initiation à l'agilité

Qui ? dans Scrum ?

• Product Owners (P.O.) : (Responsable produit)
  • représente le client
  • tient à jour le backlog (liste des fonctionnalités (User Story : U.S.)
• Scrum Master (S.M.) : (Responsable d'équipes)
  • représente l'équipe
  • lui facilite le travail (respect des pratiques, veille, ...)
• Développeurs :
  • s'engage à produire en qualité/quantité les demandes
  • référent technique

Les différents rituels

Meeting / Réunions

Les différents rituels

Poker planning

• Estimation de la complexité (et non la charge) du travail à venir
• Comment :
  • Le P.O. présente une U.S. ( si besoin assisté par le S.M. ou autres)
  • Chaque développeur a la possibilité de voter pour la valeur suivante : 0, 1, 2, 3, 5, 8, 13, ?, infini
  • Le vote est simultané
  • En cas de différence ou d'incohérence, un débat est lancé
• Prérequis :
  • Tout le monde connait la valeur du 1
  • On évite de faire un lien entre charge et complexité
  • Les stories sont accessibles en lecture auparavant pour faciliter les échanges, s'ils sont nécessaires

Les différents rituels

Lancement de sprints

• Découpe du travail en tâches (estimables en heures)
• Comment :
  • Les développeurs + S.M. se réunissent et divisent une U.S. en plusieurs activités sur des posts-it
  • Le vote est simultané
  • En cas de différence ou d'incohérence, un débat est lancé
  • Facultatif : Une borne peut être prévue
• Prérequis :
  • Tous les développeurs participent
    • à la rédaction+évaluation des posts-it
  • Les questions ne sont pas sans réponses ;)

Les différents rituels

Daily meeting

• Bilan, perspectives, questions de chacuns des acteurs sur le travail
• Comment :
  • L'équipe se réunit autour du tableau
  • Chaque développeur prend la parole (et est le seul à parler)
  • Quand il a terminé, il pose des questions ou passe la parole
• Prérequis :
  • Si une conversation est hors sujet, elle est sortie du meeting
  • La réunion ne dépasse pas 15 minutes par équipe (8 personnes)
  • C'est mieux, si c'est debout

Les différents rituels

Démonstration

• Les développeurs présentent le fruit du sprint - Les clients voient les capacités de l'équipe
• Comment :
  • L'équipe invite les clients (et autres)
  • L'équipe présente chaque demande qui a été développée
    • Exception : modifications très mineures
  • Les personnes de l'équipe passent à tour de rôle
• Pré-requis :
  • L'ordre de passage est déterminé
  • Les fonctionnalités ont été testées en amont
  • Le matin sert aux ajustements (pas de correction)
  • La réunion ne dépasse pas une heure
  • La démonstration ne sert pas de recette

Les différents rituels

Rétrospective

• L'équipe se réunit pour faire le bilan (ce qu'il faut garder vs éviter)
  • On élimine ce qui gène - On garde (améliore) ce qui marche  
• Comment :
  • L'équipe prépare des remarques / critiques pertinentes
  • À tour de rôle, les points sont présentés
    • Un débat est proposé si c'est nécessaire
• Prérequis :
  • Le nombre de remarques est limité
  • Rappeler les points importants du sprint passé
  • Demander aux participants de préparer

Les différents rituels

Dans l'ensemble (version courte)

Les indicateurs et contrôles

BurnUp Charts / Qualité

Les indicateurs

BurnUp Charts

Qui : Développeurs, Product Owners, Scrum Master

Quand : En continu

Quoi : Développements

Comment : Manuellement

Pourquoi : Vérification de l'avancement / retard (au quotidien)

Rouge : Max heures disponibles
Gris : Max heures estimées
Vert : Heures consommées
Bleu : Heures attendues

Note : Le jeudi tout doit être terminé (bleu et vert se croisent)

Les indicateurs

Vélocité globale

Qui : Scrum Master

Quoi : Capacité de travail

Pourquoi : Permettre d'estimation la charge de travail possible

Jaune : Moyenne équipes
Rouge : Moyenne avant 07-2014
Bleu : Capacité courante  équipes

Les indicateurs

Sonar

Qui : Développeurs, Scrum Master

Quand : En continu

Quoi : Développements

Comment : Automatiquement

Pourquoi : Vérification du respect des normes

Les contrôles

Revue de code

Qui : Développeurs, Scrum Master

Quand : Avant recette

Quoi : Développements / Script

Comment : Lecture du code

Pourquoi : Vérification de la logique du code

Les contrôles

Recette(s) / Test(s)

Qui : Développeurs, Product Owners, Clients

Quand : Avant la mise en production ;)

Quoi : Développements, Déploiement, Fonctionnalités

Comment : Automatiquement, Manuellement

Pourquoi : Vérification du besoin

Questions ?

...

Questions ?

Comment savoir si la quantité de travail est suffisante pour l'équipe ?

• Le Product Owner est en relation avec les clients
  • P.O. + Clients => Définition du besoin
  • Les demandes sont priorisées avec la direction
• Le Scrum Master définit un objectif chiffré en début de sprint
  • L'équipe évalue la consommation d'un développement

Questions ?

Comment sont gérées les urgences ?

• Un à deux points sont réservés dans un pot
  • Cette réserve est remplie par défaut par des développements.
    • Rapides (~ 1 journée de développement)
    • Prêts (ne nécessite pas des Q/R trop lourds)
    • Peu prioritaires (La réalisation n'est pas une nécessité pour l'échéance du sprint)
  • Si une urgence arrive en cours de sprint
    • Elle est évaluée (une urgence dépasse rarement deux points de complexité)
    • Insérée dans le pot (+ priorisée)
    • Réalisée / Revue / Testée / ...

Questions ?

Comment sont formalisées les demandes ?

• Les P.O. font l'effort de répondre à l'ensemble des questions.
  • Les réponses sont mises à plat dans un référentiel commun qui est attaché à la demande (#ticketing)

Questions ?

Avec Scrum, il est difficile de donner des dates de fin.

• Les facteurs permettant de donner des dates sur des projets "non-priorisés" sont difficile mais pas impossibles.
• Si tous les acteurs jouent le jeu, et que les priorités sont clairement définies, il n'y a rien d'impossible.

Questions ?

Est-ce qu'il y a des personnes spécialisées dans certaines parties ?

• Oui, mais on essaye de faire tourner un peu les équipes pour :
  • que les connaissances soient partagées
  • pour éviter une ascendance entre développeurs
  • gagner en efficacité globale

Questions ?

Quel est le rôle des autres pôles ?

• Nous vous considérons comme des clients
  • Mais des clients qui sont dans le même bateau que nous
  • On essaye d'avancer tous dans la même direction
    • on minimise les facteurs d'échecs et de perturbations
      • Les données doivent être livrées avant le début des développements, c'est nécessaire pour
        • la rédaction des tests,
        • la compréhension de tous lors des démonstrations
    • on maximise notre compréhension de votre besoin
      • d'où l'intérêt de participer aux phases en amont / aval
      • notamment en recette...

Questions ?

Est-ce que ça marche ?

• Facteurs de réussites
  • Savoir donner des défis (atelier technique, alterner les équipes, ...)
  • Être persévérant : ça ne marche au premier coup
  • Adapter, améliorer les outils, les processus, ...
  • La confiance (intra - inter équipes)
• Facteurs d'échecs
  • Ne pas surveiller la fatigue de l'équipe
  • La réticence