Scrum Day, c'est une journée de conférences spécialement dédiée à
Scrum, cette méthode de travail agile. L'événement était organisé au centre de conférences Microsoft, à Issy-Les-Moulineaux.
Voici le compte-rendu des sessions auxquelles j'ai assisté.
Keynote : Embedding a Scrum Culture, par Harvey Wheaton, membre du bureau de la Scrum Alliance et Studio General Manager à
Supermassive Games
Scrum n'est pas qu'une méthode, c'est une culture et elle s'appuie sur les critères suivants :
- Motiver les personnes de l'équipe
- Leur apporter toute aide dans leurs tâches
- Leur faire confiance
A Supermassive Games, les jeux sont développés en Scrum avec les caractéristiques suivantes :
- Organisation hiérarchique minimale, pas de managers
- Les personnes sont responsabilisées : elles décident de leurs tâches, le temps qu'elles vont prendre..
- Toujours commencer par une maquette
- Enrichir le logiciel en passant d'une faible fidélité à une haute fidélité
- Décomposer le projet en 3 étapes :
- Stages = c'est la maquette (10% du coût total)
- Commit = validation des choix (20% du coût, dernière chance pour changer)
- Alpha = première version
- Le critère d'avancement = logiciel
- Exécuter la rétrospective pour améliorer l'itération suivante (auto-critique...)
L'auteur rappelle que Scrum n'est pas une méthode finie : il ne faut pas hésiter à améliorer les processus qu'elle définit pour la rendre encore plus efficace. Finalement, c'est une très bonne session qui explique bien plus l'existence de Scrum que sa mise en oeuvre.
Session : Mode Forfait et Méthode Scrum, par Bertrand Pinel, Directeur technique à
Ippon Technologies
Il s'agit d'un retour d'expérience sur de nombreux forfaits réalisés en Scrum, sur des projets en technologie Java.
La difficulté du forfait en Scrum est l'intégration de la contrainte du contract, qui est inévitable et nécessite donc des ajustements par rapport à la méthode d'origine.
Plusieurs catégories de forfait ont donc été identifiés et éprouvés par l'auteur, en fonction des exigences et de la nature du client :
- Forfait classique (pas de Scrum) : adapté quand les fonctionnel + budget + délai sont fixes et qu'il n'y a pas besoin d'agilité (refonte d'une application à l'identique...)
- Forfait Scrum pour le secteur public : adapté quand les budget + délai sont fixes et qu'il y a une place pour de l'agilité sur le fonctionnel, celui-ci sera alors révisable en cours de forfait (par remplacement de certaines fonctions pour un effort équivalent)
- Forfait Scrum pour le secteur privé : adapté quand le budget est fixe mais avec de l'agilité sur le fonctionnel + délai; le projet est alors décomposé en plusieurs lots contractuels successifs (de courtes itérations : 3 environ) sur lesquels le client se réengage. A la fin de chaque lot, l'application est exploitable, et à chaque fois plus riche fonctionnellement.
- Forfait Scrum pour POC (Proof Of Concept) : le forfait est décomposée en deux phases: une première qui inclut le périmètre minimum du POC et dont la réalisation est garantie (engagement de résultat), et une deuxième dont le périmètre n'est pas garanti par rapport à l'enveloppe mais avec une volonté de best effort sur la réalisation (engagement de moyen).
Quelques points de conclusion:
- Plus d'itérations, mieux c'est (minimum 6); il est difficile d'exploiter Scrum pour des projets très courts (hors POC)
- Les gens doivent être expérimentés, la techno doit donc être maîtrisée dès le début du forfait : ceci pose une difficulté pour l'intégration des juniors
- Les clients sont satisfaits et observent des résultats plus rapidement qu'avec une méthode classique, ce qui les rassure.
Session : Outillage agile dans un environnement de développement Microsoft, par Christophe Héral et Geoffrey Daniel, consultants (et mes collègues) à
Winwise
Il s'agit d'une présentation de l'outil Team Foundation Server (TFS 2010) et comment l'utiliser dans un contexte de projet conduit en Scrum.
Il existe trois modèles de projets agiles pour TFS :
- MSF Agile v5.0
- Scrum for Team System v3.0
- Scrum v1.0 (nouveauté)
Les modèles Scrum contiennent les éléments de travail propres à Scrum : itération, sprint...
La majorité de ces fonctionnalités a été exposée pendant la session ainsi que la gestion des tests avec Visual Studio Lab Management qui permet notamment de gérer les tests manuels.
En complément de la session, je vous invite à consulter ce post sur les différences entre ces trois modèles.
Session : Le Product Owner "Proxy", Mise en place de l'agilité dans un environnement à forte culture "Cycle en V", par Bertrand Dour
Il s'agit d'un retour d'expérience sur la mise en place d'un projet en Scrum au PMU.
Difficultés : plusieurs représentations métiers à gérer (paris hippiques, paris sportifs, comptes & poker) sans Product Owner (refus des métiers à prendre la casquette !), avec néanmoins l'objectif de réalisation du site web (multi-métier donc).
La mise en place du POP (Product Owner Proxy) a permis d'instaurer une communication entre les métiers et le technique (département web), au-delà d'une classique relation fermée de type client-fournisseur.
- les avantages : l'interlocuteur unique pour l'équipe de développement, les priorités sont consolidées par rapport aux métiers, la planification est cohérente
- les inconvénients : la faible connaissance métier du POP, sa légimité, la complexité du processus
En conclusion, la solution du POP est viable, mais il est important d'étudier d'abord les autres solutions d'une part, et les possibilités de simplification de l'organisation d'autre part. Pour résumer : trouver et prendre le temps de trouver un vrai Product Owner aurait été plus efficace.
Session : Scrum sur un projet court en environnement corporate, par Jonathan Scher, expert Java à
Octo
Contexte client : refonte du Système d'Information en un an dans un grand groupe d'assurance. L'application est très orientée CRUD, donc "simple" à priori. La réalisation a été proposée en Scrum avec une équipe de 4 personnes et des sprint de 1 semaine.
Dans cette session, il s'agit plutôt de l'anatomie d'un échec, ou plus précisément toutes les erreurs à éviter dans cette mise en oeuvre de Scrum :
- Annonce d'une livraison en 2 mois avec une méthode agile (c'est court)
- Démarrage en décembre (oubli des congés)
- Incapacité à avancer en raison d'arrêts maladie (monopole de compétences)
- Refus de la méthode agile en cours de projet (oubli de certains acteurs)
- Oubli d'intégrer certaines contraintes (processus de déploiement et d'exploitation du client)
Les conseils des auteurs pour remédier aux problèmes rencontrés :
- Définir un interlocuteur unique à 100% comme interface avec l'entreprise (le Scrum Master, selon les auteurs)
- Toute personne de l'équipe doit être backup des autres (co-propriété du code)
- Stabilité de l'équipe, bonne connaissance à l'intérieur
- Fonctionnement en binôme senior/junior pour monter en compétences les plus jeunes
Conclusion
Le Scrum Day est une journée riche en présentations et en retours d'expérience : je la conseille à tous ceux qui s'intéressent à Scrum ou aux méthodes agiles en général, et qui envisagent de l'appliquer ou d'en bénéficier sur un projet.
Noter que les sessions ont été enregistrées et que les WebCasts seront disponibles d'ici une semaine.
