Point Clés
Bill et Bob partagent une histoire captivante. Bill, attaché aux méthodes traditionnelles, représente un conservateur, tandis que Bob incarne un moderniste, toujours en quête d’expérimentation et de nouvelles approches. La renommée société de jeux vidéo, Namco, fait appel à l’expertise conjointe de ces deux individus. Explorez l’agilité en plongeant dans l’histoire de Bill et Bob afin de comprendre comment chacun a abordé ce projet.
Le “one-man-show” de la gestion du projet par Bill et les leçons apprises
Bill le Conservateur
Lire l’histoire jusqu’à la fin en naviguant à gauche et à droite
Les gars à Namco® contactent Bill
Il travaille dans une entreprise de développement logiciel réputée : RaftingSoftware
Bill, comme chef de projet
S’engage sur un contenu, à livrer à une certaine date, et dispose donc d’un certain budget.
Bill analyse le travail qui doit être fait
Ensuite il va voir l’équipe et lui distribue les tâches.
Chacun travaille sur sa partie et uniquement sur celle-ci.
Après 2 mois
L’équipe dit qu’elle est dans les délais, mais rien n’est fini encore…
Comme l’échéance approche, l’équipe commence à perdre confiance…
Une grille infinie
Les gars de Namco viennent d’avoir une grande idée : une grille infinie…
Ce n’était pas prévu au Cahier des charges
Bill commence à négocier…
La fin approche
Il est temps de mettre un petit peu la pression sur l’équipe… Allez les gars, on peut y arriver !
Quand même
Pas suffisant… les soirées sont longues…
Au final
On fournit quand même ce qui était demandé… pourtant le client n’est pas content
Bill est satisfait
Il a respecté les délais, le budget, le contenu demandé… le projet est un succès !
Voici comment Bill voit le projet
Quel est le problème ?
La demande a été respectée au final.
Qu’est-ce qui n’a pas marché avec la méthodologie de Bill:
- Le client n’est pas satisfait
- L’équipe n’avait pas la parole et l’équipe a subi
- La demande a été fixée au départ et n’a pas évolué
- Les changements ont été durement négociés
- Bill a décidé seul du travail des équipiers
- L’équipe a travaillé à partir d’informations filtrées par Bill
- Le risque de retard n’a pu être identifié que très tard
- L’équipe a fait des heures sup et des membres démissionent
- L’équipe a pris des raccourcis pour finir à temps
Progression vers une agilité accrue avec Bob
2ème tentative
Mais pour Namco® l’argent n’est pas vraiment la question, ils ont envie d’essayer un autre fournisseur…
BoB le moderniste
Lire l’histoire jusqu’à la fin en naviguant à gauche et à droite
Ils contactent Bob de ACTic
Le «product backlog»
Ensemble Bob et les gars de Namco® écrivent des «user stories», toutes ces stories forment le «product backlog»
Et il demande aux gars de Namco® de lister les stories par priorité
L’équipe elle-même estime l’effort pour réaliser ces stories, Bob et les gars de Namco® sont uniquement là pour répondre à leurs questions… ©
A partir des user stories estimées, on prend les top priorités à hauteur de la contrainte donnée par l’équipe
Quand l’équipe pense qu’une story est «finie» le client peut la voir, l’essayer et donner son feedback
Le client a une autre idée, PacMan peut se téléporter quand il mange un fruit magique
Aucun problème, Bob ajoute la user story dans le backlog, elle sera prise dans la prochaine itération
A la fin de l’itération, l’équipe fait une démo de ce qui a été «fini» pendant l’itération
Puis ils se retrouvent dans une rétrospective pour voir ce qui a bien marché et ce qu’il faudrait améliorer
Et on repart pour une nouvelle itération à partir des top priorités suivantes
Quand ils arrivent à la date finale de remise du projet, il reste encore quelques stories dans le backlog mais le client est ravi par le produit
Le Projet vu par Bob
Les clés du succès du projet avec l’équipe de Bob
D'accord mais
Comment ont ils fait ça chez ACTic ?
Au début
Ensemble avec Bob ils ont défini une Vision du produit
C’est une histoire… pour un utilisateur
En tant que <rôle>
Je souhaite <faire une action>
De façon à <obtenir un gain>
A partir de ces user stories, ils ont constitués un product backlog
Ensuite ils l’ont ordonné selon l’importance des gains obtenus avec chaque story
Et ensuite ?
Bob a demandé à l’équipe d’estimer l’effort pour réaliser chaque story
Bob a demandé à l’équipe d’estimer l’effort en utilisant des «story points»
L’équipe a affecté les story points en utilisant le «planning poker»
On a ensuite demandé à l’équipe d’estimer sa «vélocité»
Combien pouvez vous en manger en 1 minute ?
A partir de la vélocité, Bob demande au client de proposer le contenu d’itération
L’équipe accepte de s’engager à tout livrer en fin d’itération
Et maintenant ?
Ils ont créé un tableau des tâches
En regardant le travail à faire pour chaque story
Chaque matin l’équipe se réunissait devant le tableau des taches pour un « stand-up »
Certains travaillaient en binôme
Ils organisaient aussi des revues de code
Et enfin…
A la fin de l’itération, l’équipe faisait une démo de tout ce qui avait été «fini» pendant l’itération
Le client «acceptait» toutes les stories «finies»
Definition of Done
Et toutes les stories «finies» pouvaient partir en production
Go Live
Après la démo Bob animait une rétrospective pour améliorer la façon de travailler
Fêter
…et itérer
…jusqu’à ce qu’il n’y ait plus de budget
…ou avant si le client est satisfait
A la toute dernière itération, la dernière démo …
Et fêter !
Bob ne pilotait pas le projet, il facilitait le travail en commun
Il était Scrum Master
Mais ça veut dire quoi vraiment « être Agile » ?
Des valeurs et des principes
- Les individus et les interactions plutôt que des procédures et outils
- Un logiciel qui fonctionne plutôt qu’une documentation abondante
- La collaboration avec le client plutôt que la négociation du contrat
- L’accueil du changement plutôt que le respect du plan
Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.
Les bénéfices de l’agiltié
Les bénéfices
Définition de l’agilité
LA CAPACITÉ D’UNE ORGANISATION À CRÉER DE LA VALEUR ETÀ RAVIR SON CLIENT, TOUTEN FAVORISANT ET EN S’ADAPTANT -À TEMPS- AUX CHANGEMENTS DE SON ENVIRONNEMENT
(GROSJEAN, 2011)
Le rôle du Scrum Master
+Veille au respect des valeurs et des principes Scrum
+Elimine les obstacles
+Assure que l’équipe Scrum est complètement fonctionnelle et productive
+Permet à l’équipe d’organiser son travail
Coache l’équipe et le Product Owner
+Assure l’étroite coopération entre tous les membres de l’équipe
+Protège l’équipe des perturbations extérieures
Le rôle de l’équipe Scrum
+Crée l’incrément produit
+Auto-organisée, responsabilisée et autonome
+Taille: 3 – 9
+Cross-fonctionnelle – toutes les compétences nécessaires pour fournir un incrément de produit doivent être présentes
+Sélectionne les exigences à réaliser dans un Sprint et s’engage sur l’objectif du Sprint
+Responsable de la réalisation de cet engagement
+Démontre le nouvel incrément de produit à la fin du Sprint
Le rôle du product owner
Autorité : Propriétaire du Produit
- Définir la vision du produit.
- Responsable de la communication :
- Participer à la définition de la stratégie de communication vers les utilisateurs
- Organiser une boucle de feedback utilisateur en amont des projets
- Communiquer sur le Produit et mettre en avant les équipes
- Prioriser les Stories
Connaissance : Propriétaire du Product Backlog et Validateur des User Stories
-
Connaissances du métier et du fonctionnel
-
Responsable du ROI du produit
-
Gérer le Product Backlog : initialiser, suivre, et améliorer.
-
Définir et écrire les User Stories avec les “utilisateurs”
-
Valider les livraisons des Stories
Disponibilité : Membre de l’équipe à part entière
Etre disponible pour les utilisateurs, le métier et les équipes de développement de manière quotidienne
Le déroulement du Sprint
Sprint Planning – (4-8H)
Objectifs:
-
- Définir le but du sprint
- Définition du périmètre du sprint
- Identification des tâches techniques et leurs estimations
Participants : Scrum Master, Développeurs, Expert technique, Product Owner Proxy, Product Owner (si nécessaire)
Daily Scrum Meeting – 15min
Chaque matin, devant le tableau d’avancement
Objectifs:
-
- Evaluer l’avancement du travail
- Identifier les obstacles nuisant à la progression
- Garder l’équipe concentrée sur l’objectif du sprint
Participants: Développeurs, Product Owner Proxy, Scrum Master, Product Owner
Sprint Rétrospective – 2h
Objectifs:
-
- Collecter les informations relatives à l’organisation et au processus
- Définir un plan d’actions concis à mettre en place dès le prochain sprint
Participants: Développeurs, Product Owner Proxy, Scrum Master, Test Manager, Product Owner (Occasionnellement)
Sprint Review – 2h
Objectifs:
-
- Démontrer l’incrément de produit réalisé
- Evaluer les résultats du sprint et recueillir les feedbacks
- Mettre à jour le plan de release
Participants: Equipe Scrum étendue aux parties prenantes du projet
Les rituels scrum
L’agilité à distance
+Sprint 0 très Co localisé
Fédération des équipes, alignement sur la vision et la méthode, définition de l’organisation
+Outillage robuste
JIRA Agile, Outillage standard adapté, vision conférence, webcams, …
+Transparence et visibilité
Indicateurs, outils, visio, …
+Binôme Product Owner et Product Owner Proxy
Travail quotidien, répartition de la prise de décision, testing partagé au fil de l’eau
+Déplacements réguliers
Forte présence sur le sprint 0, présence régulière pendant les sprints, …
0 commentaires