itération

Rythmer le flux avec des sprints

Rythmer le flux avec des sprints

Chapitre 2 : la première partie du chapitre présente le développement itératif et incrémental. Elle a légèrement évolué dans cette édition. La 2e partie du chapitre a été complètement remaniée.

Le canal du Midi est bien agile

Le canal du Midi est bien agile

Je suis allé vérifier sur place

Laurent dit que le canal du Midi est agile. Malheureusement le canal est au chômage[1] depuis une semaine, ce qui fait que, si j’ai bien vu deux écluses, je n’ai pas vu de bateau. Pas pu vérifier les dires de Laurent. Si je dis que le canal du Midi est bien agile, c’est pour sa construction : Pierre-Paul Riquet a fait preuve d’agilité (à croire qu’il connaissait Scrum). Dans l’excellent article de Wikipedia consacré au canal du Midi, on trouve une description des principes appliqués pour ce projet, réalisé sous Louis XIV !

Un scénario enchaîne des petites histoires

De l'intérêt d'une *big picture*

La technique des “user stories” est très efficace couplée à un développement par itérations. Les stories alimentent le backlog de produit et sont développées pendant l’itération. La tendance est à avoir des stories très petites, ce qui présente des avantages en terme de gestion et de suivi. Mais cela a l’inconvénient de rendre les choses plus difficiles à comprendre. Une story est à replacer dans un contexte plus large pour qu’on voit à quoi elle sert.

Planification de l'itération

La pratique Scrum d'une équipe autonome et responsabilisée rend caducs les aller-retours entre le chef de projet, les membres de l'équipe et le management

Bien avant de passer à Scrum, je faisais du processus itératif. J’ai encadré de nombreux projets qui appliquaient un processus itératif, genre RUP. Comme dans Scrum, il y avait une planification à 2 niveaux : plan grosses mailles pour le projet et plan détaillé pour l’itération. Le concept est le même, mais la façon de préparer le plan diffère, essentiellement sur 2 aspects : le timing la responsabilité Côté timing, avec Scrum c’est simple : le plan de l’itération n se fait au début de l’itération n lors de la réunion prévue pour ça.

Le reste à faire sur une tâche

RAF !

C’était la semaine dernière, au cours du scrum quotidien. Le premier scrum du premier sprint. J’étais le ScrumMaster. Chacun prit la parole à tour de rôle. Quand vint le tour d’Ibrahima, il présenta ce qu’il avait fait depuis la veille, et sur quelles tâches il avait travaillé. La liste des tâches, élaborée au cours de la réunion de planification du sprint était affichée sur le tableau autour duquel nous étions, debout comme il se doit(ça s’appelle aussi standup meeting).

Séparer le bon Scrum de la mêlée écroulée

… en vérifiant qu’on s’appuie sur de bons piliers Comme Scrum est à la mode, beaucoup de monde s’y intéresse et le risque est d’en faire un usage très superficiel. Une lecture rapide d’une présentation de Scrum peut amener à penser, comme je l’entends parfois, que Scrum est déjà plus ou moins appliqué dans les projets. Ceux qui disent : on fait déjà du Scrum sans le savoir. D’un autre côté, une mise en oeuvre sans bases solides peut amener à une utilisation dégradée.

Perturbations pendant le sprint

En principe une équipe ne devrait pas être perturbée pendant un sprint par du travail à faire suite à des évènements qui surviennent pendant le sprint. Pas toujours possible… Quand une équipe Scrum travaille sur un projet qui a déjà produit une release, il arrive que pendant le sprint courant, une anomalie détectée sur la release en production nécessite une correction urgente. Pas possible d’attendre le sprint suivant [1]: il faut faire quelque chose (au moins corriger l’anomalie) pendant le sprint courant.