Scrum améliore la qualité du développement logiciel

07.08.2018

Après avoir mis en œuvre le scrum pour les développeurs Drupal de Droptica, nous avons observé des résultats remarquables en termes de qualité de nos projets. À notre avis, le scrum n'aide pas seulement à maintenir la qualité – il l'impose tout simplement. Comment cela fonctionne-t-il ? Il met l'accent sur les tests le plus tôt possible. Écrire du bon code qui peut être développé devient une nécessité. Il soutient les tests automatiques et l'automatisation du processus de développement. Il réduit les coûts inutiles et augmente la flexibilité commerciale. Vous ne le croyez pas ? Assurez-vous de lire cet article et dites-nous ce que vous en pensez !

Qualité

Si nous demandions à un grand groupe de personnes ce qu'elles associent à la qualité du projet, nous obtiendrions certainement de nombreuses réponses différentes. Personnellement, j'aime le plus la définition de Joseph Phillips, car il croit que « la qualité est le potentiel d'un projet à répondre aux exigences attendues et définies par le client. La qualité est un atout, une valeur et une source de profit tirée de la mise en œuvre correcte du projet. »

Cette déclaration peut être assez générale, mais elle se résume à une chose simple – un logiciel de bonne qualité doit faire exactement ce que le client et l'utilisateur final attendent de lui. Nous pouvons étendre ces définitions et dire qu'un logiciel de qualité ne doit pas non plus faire quoi que ce soit d'inattendu.

Qu'est-ce que le scrum ?

Le Scrum est un moyen itératif et incrémental de mener un projet, basé sur les principes contenus dans le manifeste Agile, à savoir :

Les individus et les interactions plutôt que les processus et les outils.
Le logiciel fonctionnel plutôt que la documentation exhaustive.
La collaboration avec le client plutôt que la négociation contractuelle.
Répondre au changement plutôt que de suivre un plan.

Si vous souhaitez en savoir plus sur le scrum, je vous recommande de lire le Guide Scrum ou de suivre notre blog, car il y aura probablement quelques articles supplémentaires à ce sujet dans un avenir proche.

Comment le scrum aide-t-il à maintenir la qualité ?

Dans le scrum, comme dans d'autres méthodologies agiles, il y a beaucoup d'accent sur la qualité. Mais est-ce que cela aide vraiment à améliorer la qualité ? J'espère que les arguments suivants vous convaincront que c'est le cas.

Les versions fréquentes nécessitent du bon code

À la fin de chaque période, il doit y avoir une version qui peut être déployée et montrée à l'utilisateur final. Imaginez que vous écriviez un code de mauvaise qualité. Après un certain nombre de versions, la dette technologique commence à croître de plus en plus, au point que maintenir une telle architecture deviendra un obstacle au développement ultérieur – vous pouvez être sûr que votre client ne sera pas content de cela. Le modèle scrum vous oblige à écrire un code facile à maintenir et à développer.

Tests dès le début du projet

Dans le scrum, le projet est divisé en sprints (de périodes hebdomadaires à mensuelles au maximum), qui se terminent par la livraison d'un morceau de code fonctionnel. Cela nécessite de tester dès le tout premier sprint et le plus tôt possible afin de pouvoir présenter une solution éprouvée au client. Cela change le rôle du testeur, qui n'est plus un portier qui se tient à la porte finale et rejette les solutions mal conçues. Au lieu de cela, il devient un acteur de l'équipe de développement, qu'il aide à assurer la qualité du projet. Les testeurs cessent d'être un rôle séparé, au lieu de cela, ils font partie d'une équipe unifiée qui poursuit l'objectif final d'un sprint donné avant qu'il ne se termine.

Même lors de la planification du sprint, la perspective des testeurs sur le projet et leur compréhension de la manière dont le système se comportera dans certaines situations peuvent être très utiles.

Une autre solution intéressante pourrait être d'écrire des tests même avant que le code ne soit créé, obligeant les testeurs à réfléchir aux cas d'utilisation et à poser des questions sur ceux que le développeur ne pourrait pas prévoir lors du développement d'une fonctionnalité donnée.

Erreurs moins coûteuses

Dans le modèle commercial traditionnel, l'équipe de développement reçoit une spécification, selon laquelle le projet est développé. Il est facile d'imaginer un cas où une spécification bien préparée est utilisée pour développer un projet qui est entièrement conforme à toutes les exigences listées. Le développement prend six mois et après cela, il est présenté à l'utilisateur final, qui déteste tout ce que les concepteurs ont proposé. On pourrait penser que la qualité du projet livré est excellente puisqu'il était conforme à ce que le client voulait ; cependant, le marché ne s'en souviendra pas comme l'un de vos succès.

Dans le scrum, à la fin de chaque sprint, nous fournissons une fonctionnalité opérationnelle qui – si le client le souhaite – peut être mise en œuvre et montrée à l'utilisateur final. Grâce à cela, si nous allons dans la mauvaise direction, nous perdons au maximum le travail d'un sprint.

Une livraison rapide favorise l'automatisation

D'une part, chaque sprint doit donner lieu à un nouveau fragment d'un site web fonctionnel, et d'autre part, les nouvelles fonctionnalités ne doivent pas casser celles déjà en place. En conséquence, le nombre de choses à tester commence à croître à un rythme tel que sans automatiser le processus, nous devrions augmenter le nombre de personnes qui vérifieraient le site web avant son déploiement. Puisque la responsabilité de la qualité du projet incombe non seulement aux testeurs, mais à toute l'équipe, les développeurs sont plus enclins à aider et à mettre en œuvre un cadre de test.

Communication, communication, communication

Les réunions quotidiennes de l'équipe de développement, y compris les testeurs, soutiennent la communication au sein de l'équipe. Si un bogue est trouvé, toute l'équipe en est informée et peut réagir rapidement.

Dans le scrum, l'équipe ne doit pas seulement communiquer entre elle – il est également nécessaire de parler au représentant du client (Product Owner). Cela est important car l'équipe ne se contente pas de les informer de l'avancement de leur travail, mais obtient également des réponses concernant toute ambiguïté et doute, par exemple sur le fonctionnement d'une fonction spécifique.

Bien sûr, le client parle généralement le langage des affaires, tandis que les développeurs parlent technique, mais notre expérience montre que lors des réunions suivantes, ils commencent à mieux communiquer. Cela élimine les cas où les développeurs doivent deviner comment le système est censé fonctionner et les cas où le client aimerait connaître quelque chose sur l'avancement du travail mais ne sait pas à qui poser la question.

Réagir rapidement et saisir les opportunités

Comme je l'ai mentionné plus tôt, dans les projets agiles (et donc aussi scrum), nous essayons de livrer des versions des projets prêtes à être déployées et montrées à l'utilisateur final aussi souvent que possible. Cela nous permet de tester nos concepts d'affaires plus rapidement que dans les méthodes traditionnelles et de commencer à en récolter les bénéfices plus tôt.
Le même principe s'applique aux changements que le marché nous impose. Puisque notre projet doit être créé de manière à le rendre plus facile à modifier, nous pouvons rapidement adapter notre projet aux nouvelles conditions.

Je pense que les arguments donnés ici sont suffisants pour vous faire réfléchir sur l'opportunité d'essayer un projet scrum pour une fois. Si vous souhaitez en savoir plus sur le scrum, vous devriez certainement consulter nos autres articles sur ce sujet :

Je vous encourage également à suivre notre blog, car ce n'est certainement pas notre dernier article concernant ce sujet.

Je voudrais conclure cet article en citant la devise de la famille Gucci : « La qualité est retenue longtemps après que le prix est oublié ». Cela ne signifie pas que seuls les projets coûteux sont bons – le but est de vous rappeler que si vous ne prenez pas soin de la qualité du projet, vos utilisateurs ne l'oublieront pas de sitôt. Alors, essayons toujours de penser à la bonne qualité dans le contexte de vos projets, et vos clients apprécieront certainement cette approche.