Scrum – Le premier sprint
Cet article est une adaptation en français de l’article Scrum – First Sprint qui présentait en anglais le bilan de mon premier sprint en tant que Scrum Master. J’ai délibérément choisi de conserver le vocabulaire anglais pour les noms de rôles, d’artefacts, … mais les liens pointent bien vers de la documentation en français.
Je suis depuis quelques mois vraiment enthousiaste par rapport à mon travail. J’ai en effet été chargé mi-octobre d’être le Scrum Master d’une équipe de 4 personnes (incluant deux développeurs, Jose et Pepe ainsi que Silvia comme Product Owner).
Scrum, c’est quoi?
En quelques mots, Scrum est une méthodologie Agile dédiée au management de projet. Scrum s’applique principalement à la gestion de projets informatiques mais est également utilisable sur d’autres sortes de projets. L’idée principale derrière Scrum est d’avoir de petites itérations de travail, et avoir un produit délivrable à la fin de chaque itération. Via le Product Owner, le client est vraiment impliqué dans le projet dès le début, il peut donner son feedback sur le produit très souvent et très tôt dans le process.
Il décide des priorités et à chaque itération; tout ceci étant basé sur la fameuse règle des 80/20 (80% des utilisateurs vont utiliser 20% des fonctionnalités, donc ces 20% devraient être développés en priorité).
Les avantages d’une telle méthode comparée à une méthode plus classique (Cycle en V, …) sont nombreux: la flexibilité, les feedbacks sont fréquents et tôts, le scope est priorisé, …
La méthodologie Scrum
Product Owner
Silvia est notre chef de projet, mais pour les besoins de Scrum, elle remplit également le rôle de Product Owner. Notre situation business est un peu particulière et complexe, et il nous est impossible d’impliquer le client et de l’amener à travailler à nos côtés. Donc Silvia a l’incroyable chance (!) d’être la personne chargée de tirer le maximum du client et d’essayer d’en déduire des spécifications et contraintes. Jusqu’à maintenant, çà n’a pas été simple. Le jour qui a suivi le début du premier sprint, le client nous a finalement fourni des screenshots des sites que nous devions redévelopper sur nos plateformes…
L’autre rôle important de Silvia, évidemment, est de décider des priorités de chacune des caractéristiques. Même si à la fin, on est censé avoir développé tout, il est vital de se concentrer tout d’abord sur le plus important et le plus prioritaire, et c’est ce qu’elle nous a aidé à faire en apportant une vision plus orientée business à nos Daily Scrum Meeting.
Scrum master
En tant que Scrum master, je suis responsable de la bonne marche du projet et je dois m’assurer que tous les membres de l’équipe suivent bien le process Scrum et ses artefacts. Je mène les réunions quotidiennes et veille à ce que nos décisions soient en ligne avec les priorités business dictées par le client et/ou le Product Owner. Mon rôle est également d’identifier tous les problèmes et toutes les sources de ralentissements de travail des développeurs et de les solutionner. Je n’ai ici aucun rôle de développement, et je n’ai aucun rôle décisionnaire: les décisions sont prises en équipe et les différentes tâches de développement sont affectées d’un commun accord. Même sans rôle de décision, je me dois d’aider et d’encourager la communication au sein de l’équipe, et je suis également le travail en prenant note de tout et en gardant une trace de tout ce qui est effectué; ce qui me permet également d’avoir une visibilité sur l’avancée du projet et de donner à Silvia une projection sur le futur.
C’est ma première expérience comme Scrum Master, et seulement ma deuxième expérience dans une équipe Scrum. Il y a une semaine, nous avons terminé notre première itération et avons fait une démonstration à Silvia et quelques personnes de la hiérarchie (3 de mes supérieurs dont le directeur de département).
Honnêtemenet, pour nous tous cette première expérience fut vraiment faite dans un contexte très compliqué. N’y voyez là aucune manière de chercher des excuses, mais d’habitude une équipe Scrum est toujours placée dans de bien meilleures conditions:
- même après le début du premier sprint, nous ajoutions toujours de nouvelles tâches et changions le sprint. Les besoins n’étaient pas encore complets, et la plateforme sur laquelle nous développions était nouvelle pour tout le monde, et nous n’avions pas prévu certaines tâches de configuration ou développement
- l’équipe de développemenet n’est formée que de deux personnes, qui n’ont pas la même formation. Ils ne peuvent donc pas se remplacer l’un l’autre, et ils ne travaillent pas aux mêmes heures ni au même endroit.
- on est dispersé aux quatre coins du monde. Jose travaille avec moi à Madrid, Silvia travaille près de San Francisco et Pepe est basé à Mexico.
- nous avions souvent des problèmes de connexion Internet avec Mexico.
Mais nous avons surmonté ces obstacles et obtenu un résultat vraiment agréable – on a même amélioré les composants de bases qui avaient été développé par d’autres régions.
Les principaux problèmes que nous avons eus
Durant ce sprint nous avons eu de nombreux problèmes. Certains problèmes auraient pu être anticipés, mais pour d’autres il n’y a pas grand chose que nous pouvions faire:
- que ce soit pour le front ou le back-end, on était derrière un framework interne pour lequel la documentation était assez légère, de même que les trainings. Heureusement, Jose avait déjà de l’expérience avec ce framework, ce qui notamment aidé Pepe qui sans surprise a eu beaucoup de mal à comprendre et utiliser le framework – comme il est à Mexico, il n’a accès à presque aucun support technique puisque tout le support est à Madrid. Il a d’ailleurs appris rapidement et a même amélioré certains des composants de bases qui avaient été produits depuis Madrid!
- les besoins venaient parfois trop tard et manquaient de clarté
- nous n’avions que deux développeurs, parfois l’un d’entre eux attendait l’autre pour des explications ou pour la mise à disposition d’un bout de code
L’erreur à ne pas faire
Au début du premier Sprint, nous avons décidé de ne pas fixer de date de fin de sprint. Il s’agit de l’un des prédicats de base lorsqu’on débute un Sprint, mais nous pensions que fixer le scope serait suffisant. Grosse erreur. Au bout de plusieurs semaines, nous nous sommes rendus compte que nous n’étions plus axés sur la livraison à une date donnée d’un produit partiellement terminé et en tout cas délivrable tel quel. C’est à ce moment-là qu’on a vraiment commencé à s’inquiéter des priorités et à mettre de côté certaines fonctionnalités – même s’il s’agit d’un travail compliqué.
Malgré tous ces problèmes, nous avons réussi à rafraîchir toute la logique du framework et des composants que nous avions réutilisé depuis d’autres régions. Le front-end, qui n’avait absolument pas été travaillé par d’autres, a été particulièrement chiadé par notre équipe et c’est toujours agréable de voir un produit qui en plus est un tant soit peu utilisable et ergonomique.
Les outils
Dans une équipe Scrum, la meilleure situation est lorsque toute l’équipe est dans la même salle, avec un grand mur ou un grand tableau blanc. Un sprint backlog peut être complètement dessiné sur le mur, ainsi qu’un product backlog. A chaque réunion quotidienne, les fonctionnalités (les post-its) peuvent être physiquement déplacés d’un état à l’autre. Le simple acte de déplacer une fonctionnalité est vraiment un atout important pour la réussite du process.
Malheureusement, du fait de notre situation particulière (4 personnes dispersées sur 3 pays), le tableau blanc aurait été trop compliqué. Nous avons donc dû nous contenter d’un fichier Excel, que j’ai amélioré petit à petit le long du Sprint; et qui contient pour chaque fonctionnalité le temps restant estimé de développement. D’autres informations y apparaissaient, comme la velocité en cours de l’équipe, le temps planifié, …
Nous avons également essayé Pivotal Tracker, mais avons décidé de l’abandonner après avoir trouvé quelques problèmes, notamment pour les estimations des fonctionnalités.
Au sujet de la communication au sein de l’équipe, la plus grande partie se passait par email. Les Scrum Daily meeting avaient lieu à 17h (heure de Madrid), dans une salle de réunion, en utilisant Skype pour les appels audios et Webex pour le partage de bureau. Typiquement, je partageais le backlog Excel et on travaillait directement dessus; et parfois les documents PDF ou les mails qui nous servaient de spécifications étaient également partagés.
Voilà, je pense que j’ai terminé. D’autres Sprint ont eu lieu depuis l’écriture de cet article, je vous en dirais plus. Je suis persuadé qu’en 2011 je reviendrai souvent ici vous parler de Scrum.
Nicolas.
Comments
Leave a Reply
Joel on 10.01.2011
Je suis à la recherche d’un logiciel permettant de réaliser des boards avec post-it en virtuel.
Tu en connais?
Nicolas on 10.01.2011
Le premier qui me vient à l’esprit est IceScrum.
Mais il faut voir, c’est un logiciel que tu veux utiliser uniquement toi, ou bien tous tes compagnos? IceScrum s’installe sur un serveur Tomcat il me semble.
Je pense que maintenant la plupart des logiciels pour Scrum intègre cette fonctionnalité de whiteboard avec post-its virtuels.
http://www.google.es/search?sourceid=chrome&ie=UTF-8&q=scrum+software
Demande à Bruno Sbille, il en connaît un rayon. Ou demande à Claude Aubry sur son twitter (@claudeaubry) mais il te dira surement IceScrum vu qu’il l’a fait lui-même