SCRUM est un système de gestion de projet radicalement différent des traditionnel approche peu souple. Ce le process qui essaie de se mettre en place la où je bosse. Comme j’ai bien aller au bout des choses, je me suis offert le bouquin de Ken Schwaber, un des 2 pères de SCRUM, sur le sujet.

D’abord un mot sur le bouquin. Évidemment il est anglais, à mon grand regret il n’existe quasiment pas de ressources de qualité sur le sujet. Mais c’est un anglais très simple. Je le craignais avec un vocabulaire technique sur le management et la gestion de projet, mais pas du tout. Le public visé est large. Il ne s’agit pas a proprement parlé d’un livre miracle qui va vous dire comment implémenter SCRUM dans votre boîte. Le livre s’articule autour d’exemples concrets d’utilisation dans des sociétés. Chaque exemple met l’accent sur un point particulier de la technique, présente les bonnes façon de faire, mais pointe aussi parfois sur les dérives possibles. La construction est claire et progressive et tous les éléments clés de la méthode y sont décortiqués, ses points forts mais aussi certains points faibles. À mon sens ce livre est indispensable à lire par quiconque à rapport avec SCRUM d’une façon ou d’une autre, car il en détaille clairement la mécanique interne. Mais il manque certains détails concret pour satisfaire celui qui voudrait implémenter la technique, d’autres lectures et la discussion/formation avec des gens qui l’applique déjà comme il faut me semble indispensable.

Et maintenant un mot sur SCRUM, le process en lui même. Évidemment, le livre en fait son apologie et le manque de précision sur certains détails me laisse des questions en suspens. Mais ce que j’en vois là est pour moi un très bon système. Grosso modo, l’un des points clés est la communication entre les membres de l’équipe et l’abolition de frontière et ‘domaine reservé’ parfois artificiels et contraignants. SCRUM replace l’Equipe, les gens qui vont réellement faire le boulot, au centre des choses en les impliquant dans l’ensemble du processus décisionnels.

Dans les grandes lignes, le Product Owner (que l’on peut voir comme le client) établit une liste des fonctionnalités qu’il veut voir dans le produit qu’il veut. Cette liste est classée par ordre de priorité, plus un élément est haut dans la liste, plus le client veut voir cette fonctionnalité rapidement. Ensuite, il vient présenter cette liste aux membres de l’équipe et répond à leur question/précision. Ensemble, il est décidé des fonctionnalités qui peuvent être implémenter dans une période de 30 jours, appelée sprint. Une fois les éléments sélectionnés, l’équipe se réuni pour voir comment faire le travail qu’elle s’est engagée à faire en 30jours. Le sprint vient de commencer. A partir de maintenant, la liste des fonctionnalités qui seront développés dans le sprint ne pourra pas bouger, sauf à arrèter le sprint et refaire un tour de table. Tous les jours, l’équipe se réunis pour faire le point, qui à fait quoi, et qui va faire quoi et qui est bloqué. Un point de synchro qui favorise la communication entre les membres de l’équipe ainsi que l’entraide et la motivation. En dehors de cette réunion, l’équipe est libre de s’organiser Tout le process est régi par des règles relativement strictes que le ScrumMaster, sorte de chef d’orchestre du process (du process et dont du développement), se charge de faire respecter par tout le monde : les membres de l’équipe mais aussi le product owner. Il est aussi là pour faire en sorte que l’équipe ne soit pas perturbé par l’environnement extérieur et débloquer toutes les situations matérielles qui pourraient empêcher sa progression.

Bon, c’est un résumé plus que succinct, mais le net regorge d’info sur la méthode. Mais la lecture du bouquin de Schwaber me semble être une référence indispensable.