Le Sprint est lancé et vous avez identifié avec votre collègue Anastasia les tickets sur lesquels vous allez collaborer. Découvrez maintenant les bonnes pratiques pour coder en mode agile.
Développez en binôme
En bon développeur agile, vous avez décidé de travailler main dans la main avec Anastasia sur le ticket 1 517. Vous allez faire du peer-programming.
Du peer-programming ? C’est la programmation à deux, c’est ça ?
Exactement ! Et c’est plus que recommandé en méthodologie agile, car écrire à deux permet d’obtenir un code de meilleure qualité. C’est également l'occasion pour vous d’apprendre de nouvelles techniques de développement grâce aux développeurs expérimentés et, inversement, de partager vos connaissances auprès de développeurs moins expérimentés. Ainsi, Anastasia vous propose de traiter le ticket en TDD (Test Driven Development, ou développement piloté par les tests, en français).
Euh j’ai pas trop compris là… 🤨
Pas de panique, je vous explique ! Un test ne peut avoir que deux issues : soit il passe, soit il échoue. Imaginons maintenant que vous deviez coder une fonction “bonjour_prenom” qui prend en argument un prénom, et qui doit renvoyer Bonjour {prénom}.
En TDD, vous allez d’abord écrire le test suivant :
function test_bonjour_prenom {
// On récupère ici le retour de notre fonction.
resultat = bonjour_prenom("Henry")
// On vérifie que le résultat de notre fonction
// correspond bien à ce qui est attendu.
assertEqual(resultat, "Bonjour Henry")
}Bien évidemment, votre test va échouer car votre fonction “bonjour_prenom” n’est pas écrite. En revanche, cela vous permet de définir le résultat de votre fonction, et de comprendre rapidement ce que votre fonction doit faire. Le test fournit ainsi une documentation fonctionnelle et simple de votre code. Il ne vous reste plus qu'à écrire la fonction pour le faire valider ! Le développement est donc Test Driven car “piloté par les tests”.
Anastasia vous présente une autre devise de développeur agile : le KISS. KISS signifie “keep it simple and stupid” (“Garde ça simple et stupide”, en français). C’est un principe en développement qui préconise la simplicité dans la conception.
Concrètement, cela consiste à prendre du recul sur son code, et à adopter les réflexes suivants :
toujours se demander si c’est possible de faire plus simple ;
veiller à nommer correctement les variables et les fonctions dans le code.
Après une demi-journée de travail, vous avez finalisé le développement. Mais en regardant le code de plus près, vous vous rendez compte qu’une partie n’est pas très claire. Or, en tant que développeur, vous avez une devise : toujours laisser l’endroit plus propre que vous l’avez trouvé !
Anastasia est d’accord avec vous, cette partie du code porte à confusion. Vous décidez de la réécrire ensemble. C’est ce qu’on appelle le refactoring (ou refactorisation, en français).
Techniquement, cela consiste à mettre en place les bonnes pratiques suivantes :
toujours effectuer un refactoring sur du code testé ;
effectuer des refactorings réguliers et estimer leur temps ;
prendre le temps de bien comprendre la logique et les différentes implications du code avant de commencer le refactoring.
Ces techniques de développement que sont le TDD, le KISS ou le refactoring sont parmi les plus répandues dans le développement agile. Vous en découvrirez d’autres au fur et à mesure de vos expériences !
Communiquez sur vos avancées lors des Daily
Nous sommes jeudi, et vous retrouvez votre équipe à 9 h 30 pour votre réunion quotidienne : Le Daily (également appelé Daily Scrum, ou “mêlée quotidienne”, en français. D’ailleurs le mot “mêlée” illustre bien le principe de cette réunion, qui permet à l'équipe de faire rapidement le point avant d’attaquer le match (ici, votre journée de travail 😇).
L’objectif du Daily est de recueillir des informations sur les avancées et la qualité de la collaboration au sein de l’équipe. Chaque membre prend rapidement la parole à tour de rôle. Avec votre équipe, vous utilisez un tableau Kanban, un support qui permet de visualiser les avancées pour chaque ticket.
Ce tableau est constitué de 5 colonnes :
À faire ;
En cours ;
Bloqué ;
À valider ;
Terminé.
Vous prenez la parole pour présenter les avancées sur le ticket 1 517 lors de votre session de pair programming d’hier. Vous présentez également votre travail en cours, et les difficultés auxquelles vous êtes confrontés. Les membres de l’équipe prennent la parole l’un après l’autre, et à 9 h 45 la salle de réunion est libérée. Vous pouvez attaquer votre journée. 😃
Validez collectivement les développements
Vous avez finalisé la fonctionnalité demandée lors du ticket nº 1 517. Les tests sont passés, votre code est donc prêt à être déployé ! 🥳. Étant donné que vous aviez créé une branche sur GitHub pour traiter ce ticket, le moment est venu de réaliser une Pull Request (ou demande de fusion, en français) pour demander l’autorisation de fusionner votre branche sur la branche principale du projet.
Vous réalisez votre demande de fusion, en précisant bien sur la Pull Request les raisons de cette demande. Vous en profitez pour passer également votre ticket dans la colonne "À valider" du tableau Kanban ! 😉 Puis vous envoyez un message au lead développeur, Jonathan, pour organiser une Code Review.
Le but de cette Code Review (ou revue de code, en français), est de vérifier le code avant de le déployer. Ainsi, vous vous assurez que le code est fonctionnel, et que le produit final fonctionne exactement comme prévu. Étant donné qu’il s’agit d’un code complexe, vous préférez échanger de vive voix avec Jonathan. Ceci dit, vous auriez également pu réaliser ce processus de manière asynchrone. 😉
Jonathan, par exemple, vous propose une méthode alternative pour optimiser votre programme, car celui-ci consomme trop de ressources en l’état. Il vous invite également à renommer certaines fonctions du code qui ne lui semblent pas claires.
Après avoir pris en compte ces remarques, vous soumettez le lien de la Pull Request modifiée à Jonathan et Anastasia, avec qui vous avez travaillé en binôme sur ce ticket. Quelques instants plus tard, vous recevez leur validation technique ! Vous envoyez alors un message à Garance. Elle doit vérifier que le déploiement correspond bien au comportement attendu du logiciel, défini dans les User Stories. Vous avez une réponse en fin d'après-midi : c’est également validé pour elle !
Vous avez donc validé techniquement et fonctionnellement votre premier ticket. Bravo ! 🥳 Vous pouvez merge votre code, placer le ticket 1 517 dans la colonne “Terminé”, et passer au ticket suivant !
Résultat : 3 points en moins pour le Sprint sur le Burndown Chart !😎
Profitez du retour d’expérience de développeurs agiles
Je vous propose de retrouver Benjamin Dasnois et Kassandre Pedro pour découvrir leur expérience à cette étape du Sprint.
En résumé
Le développement agile repose sur la programmation par pairs, qui consiste à développer en binôme.
Plusieurs méthodes de développement agile vous permettront d’obtenir un code lisible et maintenable :
le TDD consiste à développer un programme en commençant par les tests ;
le KISS consiste à développer un code simple et lisible ;
le refactoring consiste à améliorer le code source d’un logiciel en continu.
Le développement agile repose également sur une communication quotidienne grâce au Daily, une réunion d’équipe où chacun évoque ses avancées et les éventuels points bloquants.
Tout développement implémenté doit faire l’objet d’une validation collective :
une validation technique par l'équipe de développement lors de Code Reviews ;
une validation fonctionnelle par le Product Owner.
Vous connaissez maintenant les particularités du développement agile. Après deux semaines de développement, l’heure est venue de faire le bilan du Sprint ! Suivez-moi dans le chapitre suivant pour découvrir comment ! 😃
