Voilà bientôt deux ans que Haploid a choisi la méthodologie SCRUM pour l’ensemble de ses projets.
Voici un petit retour d’expérience vu par chacun des rôles clés du SCRUM : Développeur, Testeur, Scrum Master et Product Owner
Mon rôle de Product Owner se résume à comprendre le besoin du client, l’objectif est de refléter au maximum ses attentes et surtout ses ambitions ! Je reçois régulièrement des cahiers des charges de plusieurs dizaines de pages pour une application mobile, après avoir lu les 20 premières pages, vous avez déjà oublié la première fonctionnalité.
Un cahier des charges ne permet pas non plus de pondérer chaque fonctionnalité en fonction de son apport « business », autrement dit quelle fonctionnalité va générer le plus de revenus dans mon application ?
La méthode SCRUM permet d’éclater ce cahier des charges en « user stories » qui permettent d’évaluer la complexité de réalisation et la « business value ». Cette étape est un excellent moyen pour faire comprendre à notre client que toutes les fonctionnalités ne se valent pas et qu’il est capital que les plus « importantes » soient développées en amont.
L’autre avantage du SCRUM est la livraison fréquente du produit, à chaque fin de sprint, notre client est en mesure de tester et valider les « user stories » implémentées. On évite ainsi les mauvaises surprises liées au « tunnel de développement ».
Ces interactions fréquentes apportent de la confiance et permettent de travailler en concertation tout au long du projet. Tous les clients qui ont su s’adapter à cette méthodologie (disponibilité lors des réunions de fin sprint, participations aux daily) ont apprécié cette transparence vis à vis des équipes.
Pour tous nos projets nous utilisons IceScrum : Cet outil s’est révélé le plus efficace pour gérer nos projets avec des membres de l’équipe qui peuvent être en déplacement ou avec le client. Il faut un peu plus de temps pour écrire les stories et les tâches au démarrage mais ce temps est compensé par le confort des graphiques de burn-up et burn-down automatiques !
Être Scrum Master demande de la rigueur, mais une fois qu’on a pris goût au SCRUM, difficile de s’en passer ! Je me surprend même a faire sur des feuilles A4 le fameux tableau « TODO / DOING / DONE » et à y coller des bouts de post-it pour un projet où je suis tout seul dessus !
Les « dailys » permettent de vraiment bien suivre le développement d’une application et surtout, surtout : de ne pas oublier de tâche qui trainent ! un élement de design qui manque, un texte à changer. Voir ensemble les tâches à faire tout les jours et surveiller la courbe du burndown permet de rester concentré, de ne pas relâcher l’effort jusqu’à la livraison finale.
En fin de sprint, la rétrospective permet de prendre du recul et améliorer notre fonctionnement en tant qu’équipe. On analyse les couacs d’organisation et on essaye des solutions au sprint suivant. Plus on fait ce point sérieusement, mieux on travaille ensemble ! rien que ça c’est top !
J’avoue avoir été sceptique sur le SCRUM au début, j’avoue maintenant être fermement convaincu !
Le découpage en fonctionnalités nous permet de réaliser des blocs de l’application, nous obligeant à concevoir l’architecture de l’application au fur et à mesure des développements. Ceci est compliqué lorsqu’on débute sur une plate-forme, mais devient plus simple au fil de l’expérience.
Cependant, le libre choix des technologies utilisées pour le développement de l’application, nous implique d’autant plus dans le projet. De même, le fait que chacun des développeurs de l’équipe s’attribue lui-même les tâches qu’il souhaite réaliser dynamise l’avancement du projet et nous motive.
Les différentes réunions rendent les développements plus efficaces.
En effet, les réunions de début de sprint nous permettent de prendre connaissance des fonctionnalités à développer pour la fin du sprint et de les découper en tâches simples. Les “dailys” nous permettent de revenir sur les développements réalisés par chacun la veille afin de constater l’avancement des tâches et d’identifier les points de blocage afin que l’équipe puisse s’adapter aux compétences de chacun.
De même, les réunions de fin de sprint nous permettent de faire un point sur l’avancée du développement des fonctionnalités du projet et de donner notre ressenti afin d’adapter la charge de travail ou revoir les méthodes de travail pour les prochains sprints. Cette réunion est l’occasion également d’avoir un aperçu de l’application que nous développons et nous motive d’autant plus dans sa réalisation.
Je trouve beaucoup d’avantages à utiliser la méthodologie Scrum dans mes phases de test. D’une part, avec les « dailys », je me sens plus impliqué dans la conception des fonctionnalités et cela me permet de créer de nouveaux angles d’attaques pour déceler les éventuels bugs. D’autre part, mes scénarios et cas de test évoluent tout au long des sprints. Avec ce suivi journalier, je sais quand toutes les tâches de développement sont terminées, je peux donc ajuster mon emploi du temps gagnant ainsi en flexibilité.
Etant intégrées aux sprints, les phases de tests sont aussi plus réactives. Et chaque fonctionnalité étant bien cloisonée, les effets de bord sont plus restreints, limitant ainsi la quantité de tests.
Les tests ont enfin l’importance qu’ils devraient avoir tout le temps : une story n’est pas déclarée finie tant qu’il reste des bugs la concernant !
Aucun commentaire:
Enregistrer un commentaire