Cette approche rigide ne laissait que peu de place à des innovations exceptionnelles. Ainsi, le client recevait exactement ce qu’il avait défini au début du projet, de préférence dans un cahier des charges. Un cahier des charges était un long document dans lequel toutes les exigences relatives au produit étaient détaillées. Le problème de cette approche était que les clients ne savaient généralement pas exactement quelles étaient les exigences spécifiques concernant les applications au début. Certaines ne deviennent claires qu’au cours du développement et les exigences existantes peuvent également changer, car on trouve de meilleures solutions ou certaines fonctionnalités ne sont pas réalisables sans compromis.

La révolution est survenue en 2001 avec l’émergence du « Manifeste Agile ». Un groupe de 17 développeurs de logiciels expérimentés et de penseurs innovants s’est réuni dans un chalet de la station de ski de Snowbird dans les montagnes Wasatch de l’Utah pour trouver des alternatives possibles aux processus de développement lourds et axés sur la documentation. Le résultat – le Manifeste pour le développement agile de logiciels – a été révolutionnaire pour l’ensemble du secteur informatique et n’a pas perdu de son importance aujourd’hui. Les participants ont élaboré douze principes de développement agile de logiciels, basés sur quatre valeurs fondamentales :

Manifeste pour le développement agile de logiciels

« Nous découvrons de meilleures façons de développer des logiciels en le faisant nous-mêmes et en aidant les autres à le faire. À travers ce travail, nous en sommes venus à valoriser :

• Les individus et les interactions plutôt que les processus et les outils
• Un logiciel opérationnel plutôt qu’une documentation exhaustive
• La collaboration avec les clients plutôt que la négociation contractuelle
• L’adaptation au changement plutôt que le suivi d’un plan

C’est-à-dire que même si nous reconnaissons la valeur des éléments de droite, nous accordons plus d’importance aux éléments de gauche. »

Méthodes traditionnelles vs Développement agile de logiciels

Selon les méthodes traditionnelles, comme le modèle en cascade par exemple, les projets logiciels sont divisés en phases individuelles qui se suivent chronologiquement et sont idéalement traitées par différentes équipes. Une fois qu’une de ces phases a été parcourue, il est très difficile d’y revenir et d’y apporter des modifications, car l’équipe se trouve déjà dans une autre phase. En raison de cette structure de projet, les problèmes bloquants peuvent rapidement entraîner des goulots d’étranglement et des retards, car l’achèvement d’une phase est une condition préalable au début de la phase suivante.

À la fin d’un projet, il y a une seule version où le produit complet est publié. À ce stade, le client final entre généralement en contact avec le produit pour la première fois, car contrairement à l’approche agile, il n’est pas possible de présenter de nouveaux prototypes de manière itérative. De ce fait, les problèmes éventuels sont souvent découverts beaucoup trop tard, ce qui peut entraîner des coûts plus élevés. Si l’on pouvait montrer de manière itérative de nouveaux prototypes au client, on pourrait réagir très rapidement si des exigences ont été mal comprises et développées.

Les méthodes traditionnelles conviennent aux produits dont les exigences sont clairement définies et structurées dès le départ. En outre, elles ont également leurs points forts pour les produits ayant des exigences non fonctionnelles élevées, telles que la sécurité, les performances ou encore la fiabilité, car on peut les prendre en compte dès le début et ainsi mieux les planifier.

Néanmoins, dans la pratique actuelle, les exigences changent très rapidement en raison des énormes progrès technologiques qui surviennent en peu de temps. Le développement agile de logiciels aide à réagir rapidement à ces exigences changeantes. En conséquence, les projets sont organisés en cycles courts et itératifs, en mettant l’accent sur la communication, la collaboration et le feedback régulier. Cette méthode de travail flexible permet de répondre aux changements (du marché), comme par exemple les nouvelles technologies ou les tendances, et ainsi d’assurer un haut niveau de satisfaction du client. Une méthode agile connue et largement répandue est SCRUM.

Comment se déroule un projet avec SCRUM ?

Le développement logiciel agile selon SCRUM se déroule en phases courtes et répétitives, bien définies, appelées sprints. Au début d’un sprint, les équipes se réunissent pour planifier la phase à venir. La base de cette planification de sprint est le backlog de produit priorisé du Product Owner. Ce backlog de produit se compose généralement d’user stories qui décrivent les exigences du produit. Au sein de l’équipe, les efforts pour ces user stories sont alors estimés. Cela peut se faire, par exemple, en estimant le temps nécessaire ou en utilisant des approches telles que le Planning Poker. Après plusieurs sprints achevés, une équipe dispose d’une vélocité de sprint moyenne. Celle-ci indique combien d’user stories ils accomplissent en moyenne par sprint. Le backlog de sprint est ensuite créé sur la base de la vélocité respective et des estimations d’effort pour les user stories individuelles.

Déroulement du processus selon la méthode SCRUM

Une communication et une collaboration efficaces sont très importantes dans la méthode SCRUM, c’est pourquoi il y a des réunions quotidiennes debout. Ces réunions délibérément courtes, d’environ 15 minutes, servent à une meilleure coordination au sein de l’équipe de développement. Chaque développeur explique brièvement quelles tâches il a accomplies la veille, ce qui est prévu pour la journée et s’il y a des obstacles ou des problèmes qui pourraient le bloquer dans son travail. Si des problèmes surviennent, l’équipe cherche des solutions.

À la fin d’une phase, une démonstration de sprint a lieu. Idéalement, il y a un environnement de test qui représente le mieux possible l’environnement de production. Les membres de l’équipe se démontrent mutuellement et aux parties prenantes les résultats du sprint. Ainsi, l’équipe SCRUM reçoit immédiatement des retours et a la possibilité d’y réagir directement, évitant ainsi des ajustements ultérieurs. Autrement, il pourrait arriver, par exemple, que des exigences soient mal comprises et que du temps précieux soit perdu en raison d’ajustements importants.

En outre, il y a une rétrospective de sprint. Dans cette revue, on réfléchit à ce qui s’est particulièrement bien passé, où étaient les problèmes et quels sont les potentiels d’amélioration pour les prochains sprints.

Quels rôles faut-il pourvoir dans SCRUM ?

Le Product Owner concentre son attention principale sur le produit. Il connaît précisément les exigences et est donc responsable de la priorisation des tâches à venir. Pour ce faire, il développe et gère le backlog de produit, la collection priorisée de toutes les tâches en attente, qui ont été élaborées en collaboration avec le client. Grâce à une étroite collaboration avec l’équipe, il s’assure que tous les éléments du backlog sont compris par chacun. Le Product Owner décide également quand le produit sera livré. Il est recommandé de choisir une fréquence de livraison plus élevée.

Le SCRUM Master est responsable du bon déroulement et de la mise en œuvre du processus SCRUM. Il soutient l’équipe dans l’optimisation du processus en éliminant les obstacles potentiels et en évitant les distractions. Pour ce faire, il fait le lien entre le Product Owner, l’équipe de développement et l’entreprise, et prend en charge la planification des ressources nécessaires pour les sprints respectifs, les réunions debout, les revues de sprint et les rétrospectives de sprint.

Les équipes SCRUM proprement dites se composent des développeurs logiciels opérationnels. Idéalement, elles sont constituées de cinq à sept membres avec différents domaines de compétences qui se complètent. Ils travaillent si possible sur un site commun pour assurer une communication et une collaboration efficaces et travailler ensemble à l’achèvement réussi du projet. Le coaching mutuel réduit le risque de goulots d’étranglement et de retards de livraison qui en résultent.

Où se trouvent les avantages de SCRUM ?

Le plus grand avantage de la méthode réside dans la flexibilité offerte, car il est rare que les exigences d’un produit soient gravées dans le marbre. Les demandes de modification ne sont donc pas perçues comme une perturbation dans SCRUM, mais sont intégrées à la méthode. Grâce à cette approche itérative, les exigences peuvent être continuellement adaptées pour créer le meilleur produit possible.

En se concentrant sur des sprints courts, des jalons sont souvent atteints, ce qui rend le progrès continu du projet plus tangible et augmente ainsi la motivation au sein de l’équipe. Celle-ci est également encouragée par l’auto-organisation et la responsabilité individuelle des membres de l’équipe.

Comme les parties prenantes sont impliquées tout au long du processus de développement et donnent leur feedback, la qualité du produit et la satisfaction des clients augmentent.

Meilleure pratique : SCRUM chez digatus

digatus développe des logiciels selon la méthode agile SCRUM. Différents rôles sont définis au sein de l’équipe, qui assument des tâches définies tout au long du projet. Les éléments clés de la méthode sont les sprints temporellement autonomes, qui durent généralement 1 à 2 semaines chez digatus.

Pour l’estimation des efforts, digatus privilégie la méthode du Planning Poker. Dans cette approche, chaque développeur reçoit un jeu de cartes similaire au système de Fibonacci (1, 2, 3, 5, 8, …). Chaque collaborateur estime individuellement l’effort requis pour chaque récit utilisateur et attribue les cartes en conséquence. Par la suite, les résultats sont comparés. En cas d’écarts significatifs, une discussion au sein de l’équipe s’engage sur l’estimation jusqu’à l’obtention d’un consensus.

Ce carnet de sprint constitue le fondement du développement et des exigences à concrétiser durant cette période. Lors des réunions cycliques de sprint, la planification de la phase suivante est réalisée, ainsi que la rétrospective et la validation de la phase précédente. De cette manière, toutes les parties prenantes sont continuellement informées de l’état d’avancement du développement et veillent conjointement avec l’équipe au respect des objectifs, du calendrier et du budget.