Scrum nous propose une démarche empirique d’amélioration de notre processus de développement logiciel. Ce qui est exprimé par la célèbre formule, devenu le slogan de Scrum : inspect and adapt. Mais cette adaptation ne concerne pas Scrum lui-même. Cette nuance mérite souvent d’être explicitée.
Un article intéressant paru sur l’alliance Scrum. Je voulais souligner notamment la notion de préparation personnelle avant une mêlée quotidienne et les bonnes pratiques pour communiquer son avancement.
Notez la différence entre dire :
Yesterday I worked on the flux capacitor; today I will finish work on the flux capacitor; I have no obstacles.
et :
I worked on the flux capacitor yesterday and realized that one of the design decisions we made as a team last week simply doesn’t work. John, we need to take a look at our architecture sketch and make sure that it still makes sense, especially when considering the upcoming scalability enhancements. Mary, the way I coded the FC will certainly change the way some of the tests should be executed. Why don’t you pair with me after the meeting and I’ll walk you through this? ScrumMaster, I’ve had a difficult time finding the product owner; could you find him for us and brief him on the situation. We need his help.
La première forme a-t-elle une quelconque valeur? Aucune à mon humble avis.
La deuxième forme prend à peine plus de temps. Elle demande cependant une certaine préparation.
Orange a lancé le 15 octobre 2007 un nouveau projet de site Internet avec l’ambition de le mettre en ligne avant la fin de l’année… avec, bien sûr, un ensemble de fonctionnalités assez ambitieux. Grâce à Scrum, le client a pu se concentrer sur les éléments prioritaires et modifier ses choix à mesure que le logiciel se construisait. L’objectif de mise en ligne a été tenu avec un passage en production le 13 décembre, après 5 sprints.
Vu les délais très serrés, nous n’avons consacré qu’une semaine au sprint 0 pour à la fois évaluer le besoin fonctionnel et déterminer les technologies. En tant que ScrumMaster, je souhaitais faire vivre au directeur de produit (Product Owner) l’expérience de l’émergence des fonctionnalités au cours du projet. C’est pourquoi nous avons ‘oublié’ le travail considérable fourni en avance par le client sur l’analyse de son besoin et la conception de son futur service. Cette démarche n’a pas été bien accueillie au début mais lorsqu’il a fallu définir sur quoi l’équipe de développement allait commencer à travailler, il a bien fallu considérer que les 100 pages d’analyse du besoin n’avaient pas toutes la même priorité. Scrum, et de manière plus générale la démarche Agile, était nouvelle pour la plupart des personnes impliquées dans le projet côté client. Pour cela, il a fallu expliquer que l’engagement de l’équipe de développement se faisait sprint par sprint et qu’elle ne s’engagerait pas lors du démarrage du projet à couvrir l’ensemble des fonctionnalités souhaitées en production à la mi-décembre. Le directeur de produit n’en était pas à son premier projet Scrum, et il a su rassurer les inquiets… où assumer seul le risque fonctionnel, selon le point de vue.
Nous sommes alors partis sur un rythme de sprints de 2 semaines pour permettre au directeur de produit de modifier la direction suivie plusieurs fois avant son échéance marketing de mise en production. Un sprint de deux semaines est, en fait, d’une bonne durée pour l’équipe de développement qui parvient assez bien à déterminer les items du carnet du produit (product backlog) qu’elle peut convertir en fonctionnalités pendant le sprint. Plus long, cela devient plus difficile car le potentiel d’incertitudes augmente. Plus court, l’ensemble des items choisis ne permettait pas de livrer un ensemble cohérent de fonctionnalités ni de définir un but à l’itération. De plus, cette capacité d’appréhender sur deux semaines nous a permis de démarrer le premier sprint sans connaître la vélocité de l’équipe. Nous avons par la suite constaté une vélocité moyenne d’environ 50 points, ce qui permettait de faire tinter la sonnette d’alarme lorsque nous étions trop loin de cette valeur lors d’une rencontre de planification.
Vous avez sans doute songé qu’entre le 22 octobre et le 13 décembre, il n’y a pas la place pour 5 sprints de 2 semaines. Effectivement! Nous avons terminé anormalement le sprint 3 et dédié le sprint 5 à la mise en production en ramenant sa taille à une seule semaine.
Côté outils, nous avons utilisé JIRA pour gérer notre carnet du produit et notre carnet du sprint. De plus, le plugiciel GreenHopper nous a permis de générer simplement notre graphique d’avancement du sprint. Cet outil offre une visualisation du travail en cours sous forme de tableau des tâches.
Mon meilleur souvenir (pour l’instant)? La personne du marketing qui, pendant le sprint 0, avait voulu qu’on s’engage à livrer tout ce qui était dans leur dossier d’analyse. Cette personne découvrait les méthodes Agiles, et Scrum a fortiori. Lors de la démonstration du sprint 1, en ayant sous les yeux une application qui tourne, elle a eu une nouvelle idée à laquelle personne n’avait pensé et qui devenait évidente avec l’application sous les yeux. Je crois qu’elle a réalisé ce jour-là l’intérêt des méthodes Agiles et l’absurdité d’un monde dans lequel on essaie de tout prévoir à l’avance.
Le client est très satisfait de cette expérience. La preuve? On continue! Nous sommes repartis pour une série de sprints et une future livraison (livraison 2) du produit au début de l’année prochaine. À suivre…
réf: Orange Business Services – Online Multimedia
En 2006, j’ai été ScrumMaster à la BNP sur un projet de refonte d’une application. Une expérience extraordinaire car la mise en place de Scrum a eu un effet presque immédiat assez inattendu.
Lorsque je suis arrivé sur ce projet, il était mal en point, empêtré dans la validation de documents de spécifications. La MOA ne validait jamais rien ce qui, dans l’organisation d’alors, bloquait l’équipe de développement qui travaillait sur le futur cadre. Le passage à Scrum a tout changé :
Au bout de deux itérations de deux semaines, le directeur de produit (Product Owner) a réalisé que le travail fait depuis un an ne correspondait pas à son besoin. En seulement 1 mois, Scrum a permis au directeur de produit de prendre en main son projet, d’exprimer l’idée qu’il s’en faisait et de guider l’équipe vers des objectifs purement métier. À partir de là l’ambiance s’est rassérénée. L’équipe et le directeur de produit partageaient maintenant une vision commune du projet et pouvait travailler ensemble. Certes, le projet était moins ambitieux mais plus utile pour l’organisation.
Techniquement parlant, nous faisions des itérations de deux semaines avec deux équipes : 7 personnes à Paris et 4 à Pune en Inde. Le Scrum de Scrum a bien fonctionné avec l’offshore.
réf: Banque BNP Paribas