itération

Adam Smith a inventé la division du travail. Frederick Taylor l’a complétée en divisant le temps de production en une suite de tâches élémentaires, répétées et chronométrées.

Le taylorisme a eu une influence considérable sur l’organisation du travail. On en retrouve des traces, voire plus, dans des types de travaux pour lesquels il n’a pourtant pas été conçu comme ceux de la connaissance et des services.

Le résultat est produit par le travail de l’équipe, à partir du backlog, dans la boucle du sprint. À un backlog unique vont correspondre plusieurs résultats, un par sprint.

À la différence de backlog et de sprint (dans ce contexte), résultat est un mot du langage commun. Cependant quelques précisions sont utiles.

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.

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 :

1. le timing
2. la responsabilité

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.

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 œuvre sans bases solides peut amener à une utilisation dégradée.