Aujourd'hui, dans un monde où la digitalisation est de plus en plus présente, les utilisateurs veulent un résultat rapide et sont impatients de pouvoir manipuler leur produit.
C'est la raison pour laquelle les méthodes agiles permettent d'organiser un projet en plusieurs sprints et phases dans le but de pouvoir montrer rapidement le MVP (minimum viable product), et ensuite garder un contact régulier avec le client pour pouvoir discuter autour de démos, prendre note des nouvelles demandes et modifications,...
Contrairement à la méthode classique (ou waterfall), nous n'avons plus besoin d'attendre une analyse fonctionnelle stricte et complète avant d'entamer la phase de développement.
Même si le backend n'est pas encore définitif, l'équipe de développement peut malgré tout montrer un résultat concret aux différents clients et intervenants du projet.
Lorsque nous travaillons en mode agile, nous sommes dans le même bateau ! Les membres de l'équipe de développement choisiront la meilleure solution technique en accord avec les connaissances de chacun.
Par la suite, ils décideront ensemble de retravailler certaines parties du code, ils partageront également leur difficultés et donneront une estimation de temps pour chaque feature.
Si vous aimez être un team player en aidant les autres collègues et en donnant des remarques constructives alors vous êtes au bon endroit !
Grâce au dashboard de tickets, nous pouvons écrire les détails de chaque feature et les assigner aux membres de l'équipe. Un ticket doit contenir les détails de la demande ainsi qu'un wireframe qui déterminera les labels, le placement des éléments, le flow, le résultat attendu,...
Le plus important est de rendre l'information aussi claire que possible pour l'équipe de développement et ainsi leur permettre de se concentrer sur le code sans devoir courir dans tous les sens.
Le project manager, quant à lui, pourra vérifier le statut de chaque ticket (in progress, pending, blocked, done,...) et préparer les demandes supplémentaires du client pour le sprint suivant.
Il n'y a rien de plus stressant pour un développeur que d'être interrompu au milieu de son code surtout lorsqu'il s'agit de changements ayant un impact sur le flow initial.
Si tel est le cas, on attend le prochain sprint pour mettre ce changement en backlog et le communiquer lors des prochaines réunions.
C'est la raison pour laquelle nous organisons des réunions le matin afin de préparer la journée et de centraliser la communication et ainsi laisser les développeurs travailler dans une atmosphère calme durant la journée (ce qui permet d'éviter de la frustration sur le long terme).