Première partie : Scrum

Les origines

Tout commence en 2001, à la création du Manifeste agile quand, aux États-Unis, dix-sept spécialistes du développement logiciel se réunissent pour mettre un terme au «  management des années 30  » dans lequel le système des hiérarchies et les processus trop lourds s’avèrent inefficaces dans la gestion des projets informatiques. En réalité, bien avant ce Manifeste, les méthodes agiles existaient déjà à l’instar de Scrum et Extreme Programming (XP) qui datent des années 90. XP a été créé par Kent Beck et ce sont Ken Schwaber et Jeff Sutherland qui ont créé Scrum en 1993 et qui l’ont officiellement présenté dans une conférence deux ans plus tard. Quand Kent Beck crée XP en 1996, il s’inspire des méthodes agiles des années 90 en poussant les limites un peu plus loin. Par exemple, tout ce qui devait être fait « souvent  » doit être fait avec XP en «  continu  » : les tests sont désormais réalisés en continu, c’est-à-dire systématiquement, l’intégration se fait en continu, la vérification du code se fait aussi en continu, la livraison se fait en continu et aujourd’hui...

Scrum

Scrum permet une production plus fréquente puisqu’on produit à chaque sprint quelque chose de présentable et fonctionnel.

Le client final est impliqué très tôt dans le projet puisqu’il peut évaluer à chaque fin de sprint ce qui a été réalisé.

Comme nous allons le voir, Scrum repose sur des concepts très simples. Le projet se déroule par itérations appelées sprints. Ces sprints durent 1, 2, 3 ou 4 semaines. Une fois le choix de la période validé, la durée du sprint ne change plus durant tout le projet. On parle d’itération car les sprints se suivent dans le temps et à chaque sprint on produit un bout de la solution finale du projet. Le produit est ainsi fabriqué de façon incrémentale, sprint après sprint. Le but n’est donc pas de tout réaliser en une seule livraison et d’attendre des mois ou des années pour voir le résultat final, mais de diviser les développements sur ces périodes courtes appelées sprints. C’est seulement au bout de x sprints que le projet est finalisé.

On planifie ce qui devra être produit durant un sprint lors du Sprint Planning. En fait, on se pose la question de savoir quelles fonctionnalités développer sur le sprint en question. Ces fonctionnalités sont classées dans une sorte de panier qu’on nomme le Product Backlog. Ce dernier est donc un contenant alimenté par les fonctionnalités du produit à développer. On ne trouve pas dans ce Product Backlog toutes les fonctionnalités à développer, le Product Backlog n’est pas une Roadmap globale qui donne une vision à long terme. Dans ce Product Backlog, on trouve uniquement les fonctionnalités à développer sur les deux ou trois prochains sprints. Pour une vision plus large, on s’appuie évidemment sur une Roadmap globale.

Au fur et à mesure de l’avancement, on piochera des fonctionnalités de la Roadmap pour les introduire dans le Product Backlog.

Une fois un sprint démarré, chaque jour du sprint on tient une Daily Scrum pour suivre quotidiennement l’avancée des travaux. En fin de sprint, on fait une démonstration à l’utilisateur...