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 est un cadre de travail agile qui permet, dans vos projets, 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. Un sprint est tout simplement une période d’une durée de 1, 2, 3 ou 4 semaines. Une fois le choix de la durée du sprint défini, tous les sprints auront la même durée et elle ne changera plus durant tout le projet. On parle d’itération car les sprints se suivent dans le temps de façon continue. À chaque sprint on devra produire un bout de la solution finale du projet. Le produit à développer 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 sera finalisé.

On planifie ce qui devra être réalisé durant un sprint lors du Sprint Planning. En fait, durant cette cérémonie, 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 de tout le travail à faire. Dans ce Product Backlog, on trouve uniquement les fonctionnalités à développer sur les deux ou trois prochains sprints. Pour une vision plus large, les managers s’appuient évidemment sur une Roadmap globale mais, les équipes Scrum travaillent avec le Backlog.

Au fur et à mesure de l’avancement, c’est-à-dire, au fur et à mesure des sprints, les responsables de chaque équipe Scrum iront piocher les nouvelles fonctionnalités à développer dans la Roadmap globale pour les introduire, chacun, dans leur propre Product Backlog....