Java Bien!

L’utilisation de métaphores est un outil simple et efficace prôné entre autres par les méthodes Agiles.

Une bonne métaphore permet de résumer en quelques mots l’essence d’un système complexe, là où un long discours n’est parfois ni compréhensible ni suffisant.

L’analogie est un principe très proche de la métaphore et l’on confond souvent les deux par facilité.

Le prix de la meilleure métaphore du jour est attribué à… roulement de tambours…

Emmanuel Gaillot, pour cette analogie :

“Wondering what’s the difference between XP and Scrum is the same as wondering what’s the difference between Aikido and Jiu-Jitsu. It does matter, to a certain level, and it really doesn’t if you want to become a practitionner.”

La question “Quelle est la différence entre Scrum et XP ?” est tellement récurrente et l’on tombe si vite dans des détails sans intérêt lorsque l’on tente de répondre à la question. Une bonne métaphore est donc bienvenue.

D’un point de vue plus personnel, elle me rappelle de plus les débats sans fin que l’on pouvait avoir en cours d’école : “C’est qui le plus fort Bruce Lee ou Chuck Norris ?”. Comme quoi l’on reste à jamais de grands enfants…

Number one problem I see with projects trying to implement Scrum is the lack of a Product Backlog.

This is strange because it’s one of the first things you have to do to start a project. I’s also one of the first thing you explain in Scrum : ” You’re going to list features in a Product Backlog and these features will be developped and tested by small increments. ”

How can the Backlog disapear so quickly ? Well it depends on the project. What is sure is that a lack of a Backlog make one thing visible and one thing invisible :

• It becomes visible that the Product Owner didn’t understand his role and job.
• It becomes invisible when the projet is to end because no Product Backlog means no Product Burn Down.

Valtech Training donne régulièrement des formations à la méthode Scrum. Toutes ces formations sont données par des coachs de Valtech qui interviennent sur de nombreux projets pour coacher et mettre en oeuvre Scrum.

La prochaine formation a lieu les 17 et 18 janvier à la Défense.

Au programme de la formation :

Pourquoi l’agilité ?
Comprendre les faiblesses des processus de développement classique
Le manifeste agile
Valeurs et principes des méthodes agiles

Présentation générale de Scrum
Scrum en tant que processus empirique
Fonctionnement des cycles de Scrum

Les rôles dans Scrum
Equipe de développement, Scrum Master et Product Owner
Droits et devoirs de l’équipe

Définir les besoins
Etablir la vision
L’itération zéro
Le Product Backlog

Gérer l’itération
Estimer et planifier l’itération
Construire et suivre l’itération Backlog
L’organisation en Features Teams
La rétrospective d’itération

La gestion de projet agile
Construire et gérer le Release Plan
Organiser l’espace de travail et la communication
La collaboration dans l’équipe

Le cycle de travail journalier
Le Scrum Meeting
Gérer l’affectation des tâches
Le développement piloté par les tests (TDD) et les exigences pilotées par les tests (TDR)

La relation avec le client
Proposer et évaluer les options
Négocier les changements
Evaluer le produit

Aspects avancés
Scrum en équipes multiples
Utilisation des principes Lean dans Scrum

Presque un an que je donne des formations Scrum pour le compte de Valtech Training. Chaque formation, je tente d’améliorer le contenu et la forme afin que les stagiaires puissent mettre en oeuvre dès le lendemain.

Doux rêve du formateur…

Il est clair que deux jours de formation, en dehors de tout contexte projet, ne remplacent pas l’apprentissage, à la dure, sur le terrain. Toutefois, si l’on compare une équipe qui a suivi la formation, à une équipe qui a pris connaissance de Scrum “Just In Time”, l’impact positif de la formation est flagrant.

A condition de passer “les” bons messages. Ou plutôt les messages qui, avec toute ma subjectivité, doivent faire partie de la mallette qu’un stagiaire ramène dans la vraie vie.

Laissez moi partager quelques messages avec vous (les critiques sont les bienvenues) :

1/ Mettre en place Scrum, c’est tenter l’aventure de l’amélioration continue. Sprint après Sprint l’équipe sera plus performante. A une condition : viser haut, être idéaliste.
Je m’explique : Scrum offre un cadre méthodologique difficile à adapter totalement à nos organisations sédimentarisées. Pourtant, l’important est de viser continuellement ce cadre idéal plutôt que de vite s’arrêter en cours de chemin à une mise en oeuvre partielle de Scrum. Le risque est de mettre en place le plus facile et de laisser tomber le plus important.

Je constate par exemple que la rétrospective est souvent vite abandonnée. J’insiste donc en formation sur le fait que si l’on doit ne garder qu’un principe, cela doit être “Inspect and Adapt”, donc les rétrospectives. La dernière heure de la formation prend d’ailleurs la forme d’une rétrospective.

2/ La complexité de la plupart des projets de développement logiciel n’est pas technique. Les problèmes viennent de notre incapacité à travailler de ensemble dans un but commun. Les compromis et les consensus sont pénibles et la transparence de Scrum ne pardonne pas les erreurs individuelles. Il faut transcender cet état de fait si l’on veut s’améliorer. Cela ne se fait pas sans douleur et le binômage, par exemple, est un choc pour presque tout le monde.

En formation, les exercices démontrent que la collaboration en timebox est ultra efficace. L’excellence individuelle est la bienvenue au service d’une équipe.

http://martine.logeek.com/index.php