• 4 heures
  • Facile

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 30/05/2023

Cernez les enjeux d’une organisation agile

En tant que développeur, vous avez sans doute déjà été confronté à ces problèmes : livrer un produit en retard et/ou non fonctionnel, résoudre des problématiques de développement en cours de route… 😭

En quoi est-ce que l’agilité peut être une solution à ces problèmes ? Qu’est-ce que cela change pour vous concrètement de travailler en mode agile ? C’est ce que je vous propose de découvrir dans ce premier chapitre ! 😃

Découvrez ce qu’est l’agilité

Que ce soit à un entretien d’embauche, sur votre lieu de travail ou encore sur les réseaux sociaux, vous avez dû entendre parler d’agilité. Alors qu’est-ce que c’est, l’agilité ? C’est d’abord un concept né dans les années 2000 (Eh oui, ça remonte !). Tout a commencé à l’occasion d'une réunion rassemblant les “stars” de la programmation logicielle de l'époque.

Une réunion qui rassemble les stars de la programmation logicielle ? 🤩 Mais pourquoi faire ?

Eh bien, pour trouver une solution à plusieurs problématiques rencontrées dans le développement des projets, comme le temps passé à la conception du logiciel, ou encore le manque d’anticipation des problèmes au cours du développement.

Après deux jours intenses de brainstorming et d’écriture de Post-it, le concept d’agilité est né. Il reposait alors sur 4 valeurs qui accordent de l'importance :

  • aux individus et à leurs interactions plutôt qu'aux processus et aux outils ;

  • à un logiciel fonctionnel plutôt qu’à une documentation exhaustive ;

  • à la collaboration avec les clients plutôt qu'à la négociation contractuelle ;

  • à l’adaptation au changement plutôt qu'à l'exécution d’un plan.

Ces 4 règles d’or du manifeste agile sont les fondations des différents cadres de travail et méthodologies utilisés aujourd'hui en agilité. 

Ah bon ? Mais du coup, c'est un peu théorique, l’agilité, non ?

Effectivement, ces 4 règles d’or peuvent vous sembler difficilement applicables en l’état. Mais le concept d’agilité a par la suite été complété par des méthodes visant à mettre en place ces principes. C’est notamment le cas pour le framework (ou modèle, en français) Scrum.

Scrum est un cadre de travail agile. Il permet de générer de la valeur en proposant des solutions adaptatives pour des problèmes complexes.

Ah super, mais c’est quoi ces solutions, concrètement ?

Quelle impatience ! 😉 C’est justement ce que nous allons découvrir ensemble grâce au schéma ci-dessous :

Schéma illustrant les étapes de réalisation d'un Sprint.
Travaillez dans un environnement Scrum en suivant les étapes de réalisation d'un Sprint.

Globalement, travailler dans un environnement Scrum implique de suivre les étapes ci-dessous :

Préparer le Sprint

L’équipe prend d’abord connaissance d’une liste de tâches à réaliser, qu’on appelle le Product Backlog. Cette liste peut contenir des fonctionnalités à ajouter, des bugs à fixer, etc.

Ces tâches (on parle également de tickets) sont ensuite partagées et analysées en équipe. L’objectif est de les redéfinir plus précisément d’un point de vue technique. C’est ce qu’on appelle le Backlog Refinement ou Backlog Grooming.

L’équipe s’engage ensuite sur la réalisation d’un nombre donné de tickets. Ces derniers doivent être traités en un temps donné, qu’on appelle un Sprint. Un Sprint a une durée fixe et peut être compris entre 1 et 4 semaines.

Enfin, les objectifs du Sprint sont définis lors du Sprint Planning, une réunion au cours de laquelle l’équipe définit ensemble un ou plusieurs buts à atteindre à la fin du Sprint.

Réaliser le Sprint

Pendant le Sprint, l'équipe traite l’ensemble des tickets sur lesquels elle s’est engagée. Elle se rassemble quotidiennement lors du Daily (appelé également Daily Scrum). Pendant cette réunion, les membres de l’équipe partagent leurs avancées, les objectifs de la journée et les éventuels points bloquants.

Faire le bilan du Sprint et itérer

À l’issue du Sprint, l’équipe fait le bilan, c’est ce qu’on appelle la Sprint Review. Au cours de cette réunion, l’équipe identifie les points accomplis, le travail restant, et présente le travail aux autres équipes (managers, client et autres parties prenantes). Elle réalise ensuite le bilan humain du Sprint (charge de travail, organisation, communication, etc.), entre membres de l'équipe Scrum, au cours d’une réunion qu’on appelle la Rétrospective, ou Rétro.

Distinguez concrètement développement en cascade et agilité

Alors, quelle est la différence entre un développement agile et un développement en cascade ?

Prenons l’exemple de Greta qui travaille sur un projet de développement web en utilisant une méthodologie en cascade. Dans ce cadre, Greta et son équipe disposent d’un planning fixe pour réaliser les différentes étapes de leur projet :

  • deux mois pour analyser les besoins du projet ;

  • deux mois pour concevoir la maquette ;

  • deux mois pour implémenter le code. 

Illustration de la méthodologie en cascade. De gauche à droite, les différentes étapes du projet se succèdent de manière séquentielle.

Jusque-là tout va bien… Sauf qu’au bout de 4 mois de travail, Greta se rend compte que certaines fonctionnalités n’ont pas été bien définies. La maquette construite par l’équipe n’est donc plus valide, et des modifications doivent être apportées en cours de route. Conséquences : Greta et son équipe vont devoir repasser par l’étape de conception, et le projet sera livré en retard.

La nature séquentielle de la méthodologie en cascade a pour conséquence d’éloigner le développeur des besoins du client jusqu'à la finalisation du produit.

En utilisant un framework agile tel que Scrum, Greta aurait obtenu une version utilisable du produit dès le premier Sprint. Le client aurait alors testé cette première version, et demandé des ajouts ou des modifications qui auraient ensuite été pris en compte pendant le deuxième Sprint.

Le framework Scrum offre donc une plus grande souplesse dans les processus. Il permet de livrer régulièrement des versions utilisables du produit, afin d'avoir un retour des parties prenantes et d'intégrer plus facilement des changements au produit.

Illustration du fonctionnement du framework Scrum. Plusieurs itérations de Sprint et plusieurs livraisons se succèdent.

Appréhendez ce que cela va changer pour vous

Que vous soyez expert en Python, Java, Node.js, ou d’autres langages, vous êtes en mesure de développer techniquement une fonctionnalité dans votre langage de prédilection. Mais devenir un développeur agile demande bien plus que cela. On attend de vous de développer, non pas du code, mais des softs skills !

Des quoi ? 🤨

Des soft skills, ou “savoir-être”, comme par exemple :

  • une bonne capacité relationnelle (et on ne parle pas ici de table SQL 😛) ; 

  • une communication régulière avec le client et/ou les managers. 

Vous aviez l’habitude de coder “dans votre coin” ? Eh bien, dans un contexte agile, vous coderez principalement en binôme !

Coder à deux sur le même code ? Mais ça ne fait pas perdre du temps ?

Au contraire ! Cela permet de partager les connaissances en équipe, et d’avoir une meilleure visibilité sur les différentes parties techniques du projet.

Vous aviez l’habitude de livrer de grosses quantités de code après deux mois de programmation ? Dans un contexte agile, vous devrez effectuer régulièrement des petites livraisons de code implémentable au logiciel.

Mais, plus on envoie du code, plus on prend le risque de changer le comportement du logiciel, non ?

C’est vrai ! C’est pour cette raison que vous devrez toujours tester et vérifier le code à chaque modification, de manière à prévenir toute régression dans le logiciel. C’est ce qu’on appelle de l’intégration continue.

Effectivement, ça fait beaucoup de changements en perspective pour nous, développeurs ! Mais c’est quoi l’objectif, au final ?

Bonne question ! Tout simplement : avoir un produit qui répond aux besoins, qui est utilisable et amélioré par rapport au Sprint précédent.

En résumé

  • L’agilité repose sur 4 principes qui accordent de l'importance :

    • aux individus et à leurs interactions plutôt qu'aux processus et aux outils ;

    • à un logiciel fonctionnel plutôt qu’à une documentation exhaustive ;

    • à la collaboration avec les clients plutôt qu'à la négociation contractuelle ;

    • à l’adaptation au changement plutôt qu'à l'exécution d’un plan.

  • La méthodologie Scrum traduit concrètement les principes d’agilité en proposant une organisation du projet en Sprints.

  • En tant que développeur, vous devez appréhender plusieurs changements en passant à l’agilité :

    • travailler en binôme ;

    • livrer régulièrement des petites parties de code ;

    • intégrer en continu.

Et voilà, vous avez découvert ce qu'est l'agilité ! Suivez-moi dans le chapitre suivant pour découvrir votre équipe. 😃

Exemple de certificat de réussite
Exemple de certificat de réussite