Développer en méthode agile : fonctionnel plus vite, sans stress

CodeKing t’emmène aujourd’hui en terre inconnue pour de nombreux professionnels du web, y compris à des positions managériales : la gestion de projet. Plus précisément, on voulait t’en dire plus sur la méthode agile, une approche à contre-courant des méthodes traditionnelles, largement utilisée dans le développement. Son ambition ? Développer des produits numériques plus performants, plus rapidement, et avec moins de stress. Comment ? En se libérant des carcans de l’ingénierie et replaçant l’humain au cœur du processus. Rien que ça.

On a attisé ta curiosité ? Parfait, bienvenue dans l’agilité !

Qu’est-ce qu’une méthode agile ?

Pour faire très simple, une méthode agile est qualifiée de telle lorsqu’elle correspond à une certaine approche, un certain état d’esprit. C’est d’ailleurs pour cela que l’on parle plus volontiers de méthodes agiles, au pluriel. L’agilité est multiple et englobe donc tout un ensemble de méthodes. Et puisque le maître mot est la flexibilité, chacun est libre de prendre ce qui lui convient dans les méthodes agiles les plus courantes, quitte à créer sa propre méthode ou une version hybride mêlant agilité et gestion de projet classique (ce bon vieux cycle en V par exemple).

Une méthode agile peut donc être tout et n’importe quoi ? Non, bien sûr que non. Bien qu’ouvertes, les méthodes agiles ont toutes quelques points communs, définis dans un document rédigé en 2001 par 17 professionnels du développement : le Manifeste Agile, également connu sous son nom complet de Manifeste pour le développement Agile de logiciels. Il liste notamment 4 valeurs et 12 principes, fondateurs de l’agilité.

Le Manifeste agile affiche donc pour ambition première de « mieux développer des logiciels par la pratique ». Ils privilégient pour cela certains aspects de la gestion de projet par rapport à d’autres :

  • Les individus et leurs interactions (par rapport aux processus et outils)
  • L’opérationnalité logicielle (au détriment potentiel d’une documentation complète)
  • La relation client/développeur (plus qu’un contrat)
  • La flexibilité (en opposition au suivi strict d’un cahier des charges)

Qu’est-ce qu’un développeur agile ?

Mêlée de rugby ou scrum : mêmes valeurs
En développement agile comme en rugby, ensemble, on va plus haut

OK, ça a l’air chouette tout ça. Mais, concrètement, on fait ça comment et comment est-ce que l’on devient un développeur agile ?

La première différence entre un développeur agile et ce bon vieux dev des années 2000 réside dans le fait que le développeur agile est un acteur du succès d’un projet donné. Et là tu te dis « évidemment, puisqu’il écrit au moins une partie de l’algorithme ». On s’explique. Dans de nombreux cas, le développeur du passé reçoit un cahier des charges à suivre à la lettre. Bonjour les contraintes et la tonne de papier à déchiffrer ! Au contraire, le développeur agile travaille sur la base d’une liste de fonctionnalités. À lui de s’impliquer, proposer des solutions, communiquer avec le reste de l’équipe, et rendre l’information accessible à tous. Tu l’as compris : le développeur agile est son propre chef de projet !

Ensuite, le développeur agile est multitâche. Loin du nerd qui parle le Python mieux que le français, il n’est plus limité au seul code. En plus de sa casquette de programmeur, il participe également à l’estimation du temps, au contrôle qualité, à la documentation et pas mal d’autres fonctions qui garantissent le succès du projet et une communication fluide entre les membres de l’équipe, mais aussi avec le client final.

Sprint, product owner, backlog : le vocabulaire de l’agilité

Les méthodes agiles se veulent simples à comprendre et à implémenter. Bonne nouvelle : elles le sont. Pour autant, elles s’avèrent parfois complexes à appréhender en conditions professionnelles réelles. Il faut dire qu’elles s’accompagnent d’un jargon très start up nation qui peut en décourager plus d’un.

On reprend les principaux termes de l’agilité que tu retrouveras un peu partout sur le web pour peu que le sujet t’intéresse.

Principales méthodes agiles

  • Scrum : en plus d’être l’une des méthodes agiles les plus réputées, Scrum signifie également « mêlée », un terme emprunté au rugby qui appuie sur la collaboration humaine de l’approche. Le scrum est ensuite décliné à toutes les sauces (voir scrum master, scrum team et scrum meeting un peu plus bas).
  • Kanban : méthode agile basée sur une gestion visuelle des tâches.
  • XP (ou eXtreme Programming) : une  méthode agile plébiscitée en génie logiciel poussant à l’extrême des principes de programmation simples.

Fonctions de l’agilité

  • Dev Team : on commence par le terme qui te concerne sans doute le plus puisque la dev team représente l’équipe de développement.
  • Product owner : le délégué de classe. C’est lui qui représente l’équipe auprès du client. Il est en plus responsable du product backlog et de la priorisation des tâches en cours de projet.
  • Scrum master : le chef de projet en méthode agile. Avec un nom plus cool.
  • Scrum team : l’équipe au complet (dev team + product owner + product master).

Étapes et éléments de développement du projet

  • User story : ou, en bon français, « récit utilisateur ». Une user story décrit tout simplement une attente de l’utilisateur par rapport au produit.
  • Product backlog : ensemble, les user stories décrivent les fonctionnalités à intégrer au produit, et donc au développement. Une fois priorisées, elles constituent le product backlog, une liste de besoins auxquels le produit doit répondre.
  • Sprint : le sprint est l’unité de mesure d’un projet développé en méthode agile. Un sprint correspond à une phase courte de développement (une « itération »). Généralement limité à quelques semaines (1 à 4 en moyenne), chaque sprint donne naissance à un MVP.
  • Minimum Viable Product (MVP) : un produit ne disposant pas encore forcément de toutes les fonctionnalités prévues, mais utilisable en tant que tel.
  • Scrum meeting : la fameuse mêlée. Il s’agit d’une courte réunion quotidienne prenant place chaque jour en période de sprint. Généralement limitée à 15 minutes, elle a souvent lieu debout et donne l’occasion à chaque membre de l’équipe de dire brièvement où il en est, ce qu’il compte faire de sa journée et d’informer de potentiels éléments bloquants pour le projet.
  • Sprint review : la réunion de fin de sprint permettant de présenter les nouvelles fonctionnalités et obtenir des retours.
  • Sprint retrospective : la réunion des équipes internes permettant de faire le point sur le dernier sprint et tirer des conclusions qui faciliteront l’avancée des prochains sprints et projets.