Scrum pour les nuls

Scrum est une méthodes dite agile.

En fait c'est une formalisation de pratiques de bon sens utilisées depuis belle lurette par tout chef de projet informatique qui se respecte.

Le vocabulaire :
Scrum = mêlée [en référence au rugby, certainement pour évoqué cette grande confraternité masculine qui caractérise les équipes de développeurs informatiques]
Itération = cycle de 2 à 4 semaines durant lequel un logiciel sera développé. Aussi appelé sprint.
Backlog = ensemble de fonctionnalités à développer durant une itération.
Sprint burn out chart = graphique illustrant le "reste à faire" du projet dans sa durée.

L'équipe :
L'équipe = les développeurs et graphistes.
Scrum master = le chef de projet.
Directeur de produit = responsable fonctionnel.

Les concepts
Les hommes avant les processus... à condition d'avoir la bonne équipe.
Le client collabore... parfois difficile en mode "contrat/forfait".
Adaptation rapide au changement... permet d'avoir des spécifications faibles si tant est que la vision globale du produit est claire.

La pratique
On retrouve les bonnes vieilles recettes des projets : découpés en sous projets à taille humaine (et l'on ressort le ratio d'un chef de projet pour 5 développeurs)
Les étapes :

1. Planification : 4h maximum pendant lesquelles les backlogs sont définies
2. La mêlée quotidienne : 15 minutes maximum où le point est fait du réalisé, du reste à faire et des difficultés.
3. La revue de sprint : fin de l'itération avec son bilan, ses recommandations pour mieux mener les autres itérations.

Le petit truc en plus
Chaque backlog se voit attribuer un nombre de points (avant on appelait cela des points fonctions) en fonction de sa difficulté de développement. A partir de chaque point et de l'expérience on calcule une vitesse de développement -vélocité-.
En comptant les points de tous les backlogs d'une itération on calcule donc le temps de développement d'une itération. On dispose donc d'une mètrique pour valider la bonne exécution d'un projet contrôlé par un reporting quotidien.

Les trucs qui coincent
Il vaut mieux partir avec un projet pour lequel les bases techniques sont en place. En effet le simple développement d'un framework risque de prendre plusieurs itérations.
Les évaluations de la vélocité reposent sur les performances initiales des développeurs, très variables d'un individu à l'autre et d'une phase de projet à une autre. Mieux vaut une équipe mature constituée de développeurs expérimentés.
La dispersion géographique ne facilite pas les mêlées quotidiennes, mieux vaut avoir une bonne liaison internet pour garantir une bonne vidéo conférence.
Le reporting quotidien un peu lourd.

La bibliographie
http://agilemanifesto.org/
http://agilealliance.org/
http://www.scrumalliance.org/
http://fr.wikipedia.org/wiki/Scrum
http://www.meetup.com/frenchsug/
http://www.aubryconseil.com/