Scrum - Méthodes agiles

Je viens de passer 6 jours consécutifs chez des clients pour les former aux méthodes agiles. 3 clients différents : un ministère, une SSII spécialisée dans les nouvelles technologies de taille petite-moyenne et une grande entreprise avec un SI conséquent.
Pour le ministère et la grande entreprise, la formation était synchronisée avec le démarrage d'un projet, ou plus précisément avec le début de l'application de la méthode agile sur le projet. Juste après la formation commençait le sprint zéro.

J'ai modifié récemment mes supports de cours en mettant plus en avant la notion de pratique. La formation présente une vingtaine de pratiques usuelles du développement agile. On y trouve des pratiques venant explicitement de Scrum, d'autres venant de XP et des pratiques implicites de Scrum et de l'agilité. Je les présente -évidemment- de manière séquentielle. D'abord celles qui sont nécessaires lors du sprint 0, ensuite celles qu'on met en oeuvre dans les itérations.

Les pratiques couvrent les différentes activités (disciplines) du développement : gestion de projet, analyse, conception, codage et test. Certaines sont indispensables pour un développement agile, d'autres sont optionnelles.

Dans la version courte de la formation (un jour), je présente les pratiques dans leur usage courant. Dans la version plus longue, destinée aux personnes qui démarrent sur un projet, les pratiques sont adaptées au contexte du projet et de l'organisation, et leur application est faite (ou simulée) sur le projet lui-même, par des ateliers de travail en groupe. On consomme de la note collante...

Avant de commencer le premier sprint, il y a une période de temps utilisée à préparer ce qui est nécessaire au lancement des sprints dans de bonnes conditions. Jusqu'à récemment, je désignais cette période sous le nom de phase, pour la distinguer de la phase des sprints. Je disais simplement phase de préparation et c'est que j'ai utilisé dans le plugin Scrum pour EPF.
J'utilise maintenant, pour suivre la tendance, le terme sprint 0 pour désigner cette période. C'est la mode, il y a même un article dans InfoQ sur le sujet.
Sprint 0, c'est trompeur, parce que n'est pas un sprint : sa durée est variable, les tâches qu'on y fait sont spécifiques de cette phase, il n'y a pas le cérémonial habituel des sprints, on ne produit pas une version potentiellement utilisable à la fin, on ne mesure pas de vélocité...
Les travaux spécifiquement agiles qu'on y fait, c'est élaborer le backlog initial et planifier la release. Pour cela on y mettra en œuvre des pratiques comme la vision du produit, la priorisation du backlog, l'identification des risques, la décomposition en user stories, l'estimation en points, la définition de fini et de la durée des itérations, le planning de la release, la formation de l'équipe, l'organisation de l'espace de travail.
Les autres travaux à faire dépendent en fait de l'état du projet au moment du lancement de ce sprint 0. Par exemple, s'il n'y a pas d'architecture définie, il faudra probablement y travailler ; mais si l'architecture est déjà connue et stable ce ne sera pas nécessaire.

...plutôt que training Scrum ?

Lire la suite -->

Je conseille aux organisations de développement d'éviter le multitâches en faisant en sorte qu'une personne soit affectée dans la mesure du possible à plein temps sur un projet.
Ce n'est pas un conseil que je peux appliquer moi-même sur mes activités : je travaille sur plusieurs projets en même temps. En général j'arrive quand même à consacrer une journée ou une demi-journée à un seul sujet. Mais en ce moment particulièrement j'ai à changer de contexte très souvent pour passer d'un projet à un autre.

En une journée, j'aurai fait 2 heures de cours à la fac sur la définition agile de produit(vision, features, priorité, backlog, stories), répondu à une interview d'un journaliste de 01 Informatique sur les contrats au forfait avec les méthodes agiles, participé à la réunion du comité d'organisation toulousain de l'Agile Tour, suivie d'une autre réunion portant sur la création d'un consortium pour le développement du projet IceScrum. En fin d'après-midi, j'ai une conférence Skype avec Philippe Kruchten pour préparer notre intervention du 16 octobre sur l'Agilité en situation.
Je vais également préparer une présentation que je fais demain au service méthodes d'un groupe pharmaceutique ainsi qu'une nouvelle mission dans un Ministère qui démarre jeudi, pour laquelle je dois prendre connaissance du contexte (oui oui, c'est pour de l'Agilité, dans un Ministère).
Ecrire ce billet sur le blog, c'est une façon de faciliter les changements de contexte.

Enchaîner les sprints, ça fatigue. Martine l'a clairement fait savoir lors de la dernière rétrospective^[1] : elle veut des jours de récupération entre les sprints. Elle aime bien Scrum, elle apprécie le principe des sprints, mais elle a besoin de souffler.

C'est normal si on se réfère à l'objet de la métaphore, on ne peut pas sprinter pendant toute la durée de la course de fond que constitue une release. Ce n'est pas moi qui vais dire le contraire : même si je ne cours plus beaucoup, j'ai pas mal couru en longue distance. J'ai encore le souvenir des entrainements en fractionné : par exemple une série de 10 fois 200m avec 30 secondes de récupération entre chaque.

Parmi toutes les équipes que j'ai suivies depuis 3 ans, la plupart se contentent d'un week-end avant de repartir sur un nouveau sprint : la revue et la rétrospective se font le vendredi et le prochain sprint démarre le lundi qui suit par la réunion de planification.

D'autres consacrent un jour entre chaque sprint à des activités hors projet; une équipe a instauré un bug day intercalaire.

J'ai aussi connu des équipes qui choisissaient de s'arrêter une semaine tous les 3 ou 4 sprints.

Et puis certaines enchainent directement : fin de sprint le mardi, début du sprint suivant le mercredi matin.

A chacun son rythme.

J'ai fait ce matin mon premier cours aux étudiants de Master1 à l'IUP ISI. Le module Agile est au programme, comme l'année dernière. 50 heures de cours, TD ou TP, plus l'application sur les projets qui durent 6 mois.

Cet enseignement fait partie de l'ingénierie du logiciel, qui comprend aussi un module plus classique de 30 heures. L'IUP ISI est spécialisé dans le développement et le génie logiciel est déjà abordé en L3. Il est donc approfondi en M1 avec ce gros volet sur les méthodes agiles.

Cette année, suite à la rétrospective sur les projets de l'an dernier, nous allons insister sur les tests agiles : plus de pratique sur le TDD. Le programme :

• les racines de l'Agilité, les différentes méthodes agiles
• la définition de produit, la gestion agile des exigences et les tests client
• la technique des histoires d'utilisateur
• l'estimation agile (story points, planning poker)
• la planification agile et le reporting
• les réunions et le travail en équipe (Scrum)
• la maîtrise des risques
• XP, les pratiques d'ingénierie
• le pilotage par les tests (TDD)
• la modélisation agile
• le développement de logiciel libre

Les cours de l'après-midi du 16 octobre ont été neutralisés pour que les étudiants puissent assister à la conférence de l'Agile tour.

Des utilisateurs brimés depuis longtemps pas les DSI découvrent que l'agilité peut accueillir et même favoriser les changements, ce qui les amène à penser qu'ils peuvent tout changer tout le temps.
Des managers se disent qu'avec l'agilité, il sera plus facile de demander de traiter une urgence ou du travail supplémentaire non prévu à leurs équipes de développement.

Ben non. L'agilité favorise le changement, mais ne le rend pas gratuit ni permanent. Si la demande de changement venue d'un utilisateur est la bienvenue, sa prise en compte passe par une gestion des priorités dans le backlog. Et une équipe qui travaille pendant un sprint ne doit pas être perturbée.

Certains auteurs ne facilitent pas les choses. Par exemple, le livre Balancing agility and discipline fait croire que que l'agilité s'oppose à la discipline. J'affirme pourtant que les projets que je coache seraient moins disciplinés (en gros plus bordéliques) si on n'y appliquait pas l'agilité.

Après avoir entendu Rachel, c'est la salutation que je vais adopter pour commencer une réunion. Ca fait plus Scrum que bonjour à tous.
Je commence ce matin. Bonjour équipe !

Un indice : ça commence par un I

Lire la suite -->

Les entreprises utilisent fréquemment des progiciels pour des applications de leur système d'information. J'ai noté qu'elles considéraient ce type de développement comme bien adapté à une approche agile. Certes un progiciel facilite la livraison de versions à un rythme rapide, mais cela ne suffit pas pour être agile...

Lire la suite -->

Un oeil dans le rétroviseur

Lire la suite -->

Une définition de l'agilité

Lire la suite -->