Le principe est simple : pas gestion de projet mais une gestion de produit (cf cycle de vie objet).
C'est une approche philosophie, un mouvement, un courant, une culture agile des organisations, de sa propre façon de travailler.
A noter que le travail ou la réflexion incrémentale (coeur de l'agilité) est totalement présente dans la petite enfance.
Les enfants travaillent par essais successifs, jusqu'à ce que le résultat produit est celui attendu (Voir aussi les Shadoks ...)
Échec des techniques traditionnelles
L'échec des méthodes traditionnelles, classiques ont permis :
- La migration vers un processus itératif de livraison permanentes, enrichies par cycles
- L'utilisation des outils & doc traditionnels de façon plus souple & dynamique
Innovation dans le suivi de projet par l'utilisation d'outils alternatifs de planification
- Définition des besoins et planification par carte mentale ou gantt simplifié
- Rituels organisationnels et réunions régulières,
Implication du client dans le processus de développement du projet
Cette implication est essentielle. Elle apporte :
- Une communication approfondie et permanente avec le MOA
- Le respect des besoins, le suivi de l'évolution des besoins dans le temps,
- Un cahier des charges dynamique et adaptatif
- Un effort pour revoir l'importance des fonctionnalités en permanence :
- Faire avancer celles qui ont un forte valeur ajoutée ou qui sont faciles a réaliser
- Différer celles qui sont complexes ou ont peu de valeur ajoutée.
Saisir et exploiter les opportunités des changements
- But = augmenter la performance du produit, sa modernité, son adéquation aux besoins
Résultat
- La livraison fonctionnelle est plus rapide, les premiers éléments du projet sont utilisés dès la fin de leur conception,
- Le produit est plus adapté au besoins
Inconvénients
- Aucune date de fin définie,
- Perte de l'objectif et dispersion des équipe, d'où la nécessité d'avoir une ligne directrice et un objectif clair,
- Le coût du projet peut exploser si on ne conserve pas de ligne directrice (la SNCF est revenue en arrière),
Acteurs du projet (méthode Scrum)
Les acteur des projets agiles sont en réalité les mêmes que pour les projets classique, mais ils ne communiquent pas de façon identique.
On rencontre :
- Le Product Owner (=MOA/AMOA)
- Le Scrum Master (+/-= MOE,cdp)
- Project team (équipe projet)
Comme le MOA est impliqué dans le projet, le MOE est moins présent comme acteur et confondu avec le Scrum Master.
Cependant, pour des projets importants, on retrouvera un chef de PO pour une ou plusieurs équipes et un niveau hiérarchique de PO plus pyramidal.
Product Owner (PO)
Maître d'ouvrage, c'est le client, l'expert métier.
Il porte la vision du produit.
Il définit le besoin et liste les fonctionnalités attendues du produit.
Scrum Master (SM)
Il fait partie intégrante de l'équipe de production.
Son rôle est plus celui d'un interlocuteur et d'un gardien de la méthode que d'un chef de projet.
Son rôle est de faire respecter les réunions et rituels, de faciliter la communication interne et externe à l'équipe de production.
- Organise la réalisation de chaque itération
- Améliore la productivité de l'équipe
- Rend compte des besoins pour le fonctionnement de l'équipe.
L'équipe de production
L'équipe de production (work team) produit l'objet livrable du projet.
Elle est multi-compétence et réuni des personnes comme : ingéieurs, architectes, techniciens, testeurs ...
La communication la plus efficace se fait en interne, en face à face et par ajustement mutuels.
(n'en déplaise aux fans de mail, chat, réseaux sociaux ou autres)
Démarche SCRUM globale
Principaux documents de travail et réunions
User stories
Les récits utilisateurs (User stories) Sont l'expression formalisée des besoins des utilisateurs du produit du projet.
Exemples
- En tant qu'utilisateur, je souhaite pouvoir accéder a un service de gestion interne (intranet) grâce à mon navigateur.
- En tant qu'utilisateur, je souhaite pouvoir accéder a mes fichiers (perso et travail) depuis n'importe quel poste de travail.
Backlog
Le backlog est une liste des fonctionalités à réaliser pour le projet.
- Bakclog initial de projet : identifier les besoins
- Backlog de sprint : définir les fonctionalités à réaliser durant le sprint (période de travail productif)
Backlog initial de projet
(Initial planning meeting)
Il sert à identifier les besoins du projet et est contitué durant une phase d'étude classique précédant le début effectif de la réalisation du projet.
Ce backlog peut être remis en question à chaque cycle de production.
Il permet de
- Définir un "Cahier des charges", liste des besoins fonctionnels (à partir des récits utilisateurs : user stories)
- Prioriser les fonctions par enjeux, facilité, investissement
Backlog de sprint
(Sprint planning meeting)
Backlog dont la charge est calculée pour la duré du sprint.
- Réunion de planification des tâches sélectionnées
Sprint : réalisation, itération
(Sprint burndown chart et scrum ou stand off meeting)
Le sprint représente une période de travail ininterrompue de réalisation & tests.
Le suivi est fait avec des indicateurs journaliers sous forme de tableau de progression (brundown chart) sous forme papier (historique et communication) et sous forme d'un tableau mural ou numérique sur lequel des étiquettes représentant les tâches sont déplacées à mesure de l'avancement.
La concertation quotidienne de projet est faite sous forme d'une réunion courte (15' maxi) et debout, la melée (scrum=mèlée) ou stand off meeting.
La stand off meeting est faite devant le tableau de progression sur lequel on déplace des étiquettes pour marquer l'avancement.
Le scrum master va reporter l'avancement sur le tableau de progression (burndown chart)
Exemple de burndown chart
La charge de chaque tâche est définie en points qui représentent à la fois le temps, la difficulté, la nécessité de préparation ou de formation préalable, etc....
Elle est donnée aux tâches par le PO et l'équipe.
Une façon ludique et démocratique de déterminer la charge est d'utiliser le "planning poker" (ou scrum poker) pour choisir une charge consensuelle par tâche.
Poker planning :
- L'intérêt de ce "jeu" est d'éclaircir les zones d'ombre du travail à réaliser en expliquant clairement la démarche de réalisation et la technicité chaque tâche.
- Les cartes sont numérotées selon la suite de Fibonacci afin que les écarts soient représentatifs de l'incertitude de l'estimation de la charge et ainsi parvenir à un consensus plus rapidement.
Charge totale = 77 points. Charge journalière = 25 points.
| Légende : |
|
Tâche réalisée |
|
Tâche à faire |
|
Avance |
|
Retard |
| n° |
Description |
charge |
J1 |
J2 |
J3 |
| A1 |
Créer le serveur Linux Debian de base |
5 |
|
|
|
| A2 |
Configurer le réseau |
3 |
|
|
|
| A3 |
Installer le service web |
1 |
|
|
|
| A4 |
Installer l'application web |
2 |
|
|
|
| A5 |
Tester l'application web |
1 |
|
|
|
| B1 |
Cloner le serveur web complet |
2 |
|
|
|
| B2 |
Créer la réplication Master-Slave |
20 |
|
|
|
| B3 |
Tester la réplication Master-Slave |
8 |
|
|
|
| B4 |
Créer la réplication Master-Master |
13 |
|
|
|
| B5 |
Tester la réplication Master-Master |
5 |
|
|
|
| C1 |
Cloner le serveur debian -> HAProxy |
2 |
|
|
|
| C2 |
Installer l'application HaProxy |
1 |
|
|
|
| C3 |
Configurer l'application HaProxy |
8 |
|
|
|
| C4 |
Tester l'application HaProxy |
1 |
|
|
|
| C5 |
Tester la surveillance HaProxy (module stats) |
5 |
|
|
|
| Total |
77 |
14 |
55 |
71 |
On voit ici que tout n'est pas terminé. Cela signifie que l'équipe est moins performante que prévu et que la charge journalière doit être réduite entre 15 et 20 au lieu de 25.
Il faut améliorer ça rapidement faute de quoi le délai de réalistion risque d'être dépassé.
Exemple de tableau d'avancement
TO DO
B4
Créer la réplication Master-Master
C2
Installer l'application HaProxy
C3
Configurer l'application HaProxy
C4
Tester l'application HaProxy
C5
Tester la surveillance HaProxy (module stats)
B3
Tester la réplication Master-Slave
B5
Tester la réplication Master-Master
Tâches à réaliser
IN PROGRESS
C1
Cloner le serveur debian -> HAProxy
B2
Créer la réplication Master-Slave
DONE
A1
Créer le serveur Linux Debian de base
A3
Installer le service web
A4
Installer l'application web
A5
Tester l'application web
B1
Cloner le serveur web complet
Livraison partielle
A la fin de chaque période itérative de travail, une partie de la solution sera livrée.
C'est l'occasion de faire le bilan du Sprint à l'aide de deux types de réunions :
- Rétrospective : réunion interne pour identifier les problèmes, sans chercher de solution.
- Revue (review) : Demonstration au client, bilan de performance de l'équipe (attention, ce n'est pas un règlement de compte !! On n'est pas à OK Corral)
Phase 1. Identifier les besoins
Qui : Product Owner, teams workers
Quoi : Product Backlog / Sprint backlog
Dans cette phase, les besoins fnaux seront définis par un groupe de travail qui doit être pluridisciplinaire au maximum (Commercial, utilisateur, ingénieur, technicien, comptable, etc.).
Elle détermine les besoins fonctionnels du livrable du projet en réponse à un besoin matériel, organisationnel ou financier.
Besoins fonctionnels : fonctions qui doivent être assurées par le produit du projet.
/ex : permettre la communication interne, proposer un service d'intranet, saisie/modification/suppression et validation des notes de frais, etc. ...
L'expression des besoins se fait sous fore de récit utilisateurs (user stories).
"Récit utilisateur" : user story
Les récits utilisateurs sont rédigés sous forme d'une phrase comme suit :
"En tant que <qui, rôle>, je veux <quoi, objet> afin de <pourquoi, objectif>"
Exemples :
USER STORIES
En tant qu'utilisateur, je veux réserver une machine par internet, afin de le faire depuis n'importe quel poste
En tant qu'administrateur je veux administrer les serveurs à distance afin de le faire de n'importe quel poste
En tant qu'utilisateur, je veux stocker des documents sur un serveur afin que n'importe qui ne puisse pas les détruire/voir,
En tant qu'administrateur je veux centraliser l'administration DHCP afin de le faire sans me déplacer entre les site de production
Gestion de projet agile 11
Analyse des besoins
Exemple besoin (rappels) :
- Nbre & étendue des zones réseau, services, niveau & éléments de sécurité, fonctionnalités, …
- Techno, marques, géométrie des installations contrainte légales, environnementales
- Existant, compétences locales, de l'équipe
- Budget dispo, délais finaux, MOD, public, étendue du service à fournir
- (production, formation, maintenance)…
Product Backlog
QUI : POs uniquement
- Construction d'un tableau des stories initialles
- Évaluation de la charge (pts)
- Planification des tâches sélectionnées pour le sprint (durée limitée – limited timebox)
- Permet de rédiger le premier Sprint backlog et révoir les suivants
- Utlise un tableau de stories
- Peut déboucher sur un diagramme de Gantt
/!\ différence avec dev : il faut (parfois) commander du matériel et la livraison peut prendre du temps.
Donc on pourra utiliser un tableau d'ordonnancement et le planning poker doit en tenir compte.
Phase 2 : Sprint (réalisation & suivi)
Durant le sprint, rien ne doit changer : le backlog ne peut pas être modifié.
Mêlée quotidienne
- Scrum, stand off meeting (mêlée, réunion debout), en début de journée, 15' maxi (c'est pour ça qu'on reste debout ;).
- Burndown chart = graphique des réalisations (décompte du reste)
Les questions de la réunion de 15' sont :
- Qu'est-ce que j'ai fait hier (la dernière fois) ?
- Qu'est-ce que je vais faire aujourd'hui ?
- Quels sont les points bloquant actuellement.
- Ne pas se plaindre des autres, on n'est pas là pour régler les conflits !
- Collecte de l'expérience acquise pour capitaliser
Au fur et à mesure :
A chaque réunion, on révise le tableau d'avancement par le déplacement des étiquettes dans le tableau des stories :
- Todo -> doing -> done (à faire, en cours, fait)
- Alternative (fr) : à faire, analyse, réalisation, tests, fait
Analyse = dessin des plans, formation, etc. …
Phase 3. Livraison itérative
En fin de sprint, on effectue la livraison d'une version partielle et fonctionnelle !
C'est le moment de faire les démonstrations et bilans
- Démonstration au client,
- Présentation des rapports de tests,
- Documentation, formation nécessaire, etc. …
- Rétrospective A chaque fin de sprint
- Tour de table env 30' à 1h/semaine, 2h maxi
Rétrospective
La rétrospective permet d'indiquer points forts/faibles de l'équipe, de l'organisation, etc. …
Elle ne concerne pas : le contenu technique des sprints, l'objet livrable du projet.
Organisation
- Elle commence par une ouverture (15') pour initieer les échanges et briser la glace.
- Elle comporte quelques phases intermédiaires : recueil d'informations, libération des idées, élaboration d'un plan d'action, etc...
- Elle se termine par une conclusion avec un feedback sur le déroulement de la rétrospective.
Durant le coeur de la réunion, on utilise un tableau de 3 à 4 colonnes (encore un !) qui permet de faire le bilan objectivement.
Exemples :
Qu'est-ce qu'on a bien fait
- la gestion des étapes
- Lecture de la documentation fournie
- la rédaction des rapports
Qu'est-ce qu'on a mal fait
- Parfois les rapports sont rédigés sans assez de détails
- La restitution des rapports est parfois en retard
- Le travail est lent à cause des distractions (téléphone)
- La communication avec le client.
Actions à mener pour s'améliorer
- Respecter le backlog avec plus de précision.
- Rédiger les rapports de façon plus pro
(un rapport n'est pas un tuto, ajouter des commentaires pertinents, meilleur vocabulaire).
- Prendre plus de notes écrites durant les réunions.
- Laisser les téléphones dans les sacs et augmenter la concentration productive.
- Augmenter la communication avec le client.