Chez PowerGate, nos équipes dédiées développent des applications logicielles en utilisant la méthodologie Agile / Scrum. Scrum est une méthode agile de gestion de projet avec une approche itérative. La méthodologie Scrum gère le processus de développement à travers de nombreuses petites étapes, plutôt que d’essayer de tout planifier à l’avance. Son objectif principal est de maximiser le retour sur investissement du client en créant rapidement des logiciels fonctionnels et en répondant rapidement aux exigences changeantes.
Scrum s’appuie sur le développement itératif. Cela signifie que nous nous concentrons sur le développement d’un produit dans de courts intervalles de temps (généralement de deux à quatre semaines). Une fois chaque intervalle écoulée, la direction du projet peut être ajustée si nécessaire pour s’adapter à toute nouvelle situation ou circonstance. Chaque itération est appelée « sprint » et donne lieu à une fonctionnalité logicielle qui est développée et testée progressivement. Le logiciel peut être déployé ou expédié aux utilisateurs finaux. Les clients peuvent fournir un retour d’expérience sur l’une ou l’ensemble des versions intermédiaires du logiciel. Les clients ont de nombreuses occasions de modifier la direction du projet si l’évolution des circonstances le justifie.
La méthodologie Scrum facilite une approche exploratoire du développement de logiciels. Elle libère nos clients de l’obligation de fournir une documentation complète des besoins dès le départ. L’agilité de Scrum améliore la transparence des projets en fournissant des informations mises à jour régulièrement sur l’état du développement du logiciel. Cela permet de s’assurer qu’aucun problème n’est dissimulé et que toutes les parties prenantes sont informées à tout moment des progrès de l’équipe.
Scrum et l’assurance de qualité
Chez PowerGate, la qualité est bien plus que la mise en place rapide d’une application et de son test avant la livraison. Nous intégrons le travail d’assurance qualité à chaque sprint. Au lieu de nous appuyer sur la pratique défectueuse consistant à effectuer de nombreux cycles de tests et de correction de bugs sur des logiciels déjà mis en œuvre, nous nous efforçons de concevoir et de construire des systèmes comportant moins de bugs dès le départ. Ceci est possible grâce aux tests unitaires automatisés et à l’intégration continue, deux pratiques clés que nous recommandons à tous nos clients pour leurs projets de développement logiciel.
Activités et artefacts de Scrum
À la base, la méthode Scrum est une approche itérative du développement de logiciels. La méthode Scrum divise un grand projet en plusieurs intervalles de temps appelés sprints. Les sprints durent généralement entre une semaine et un mois, avec une moyenne d’environ 14 jours. Au cours de chaque sprint, les développeurs se concentrent sur un ensemble particulier de fonctionnalités, transformant l’idée en réalité par un codage et des tests minutieux.
Chaque sprint peut être ensuite subdivisé en activités plus petites. Chaque sprint débute par une réunion de planification au cours de laquelle les membres de l’équipe identifient les principales priorités et dressent la liste de celles qu’ils peuvent réaliser de manière réaliste dans le backlog de produit.
Tout au long du sprint, des réunions quotidiennes d’une durée maximale de 15 minutes sont organisées. Les membres de l’équipe partagent des informations sur leurs progrès de la veille, leurs plans pour la journée en cours et les obstacles potentiels. Ces réunions permettent d’aligner les efforts des membres de l’équipe et de maintenir le travail de chacun sur la bonne voie.
Lorsque le sprint touche à sa fin, la revue de sprint permet à l’équipe de démontrer ses réalisations. Le Product Owner et/ou les utilisateurs sont invités à voir la nouvelle fonctionnalité et à fournir des commentaires détaillés, qui sont ensuite intégrés dans le prochain backlog de produit.
La rétrospective du sprint a lieu à peu près au même moment. C’est l’occasion pour tous les membres de l’équipe de discuter du processus lui-même, de partager leurs réflexions sur le sprint qui s’achève et de proposer des idées pour rendre le prochain sprint encore plus productif et plus réussi.
Artefacts Scrum
La méthodologie Scrum donne lieu à plusieurs artefacts. Le plus évident est, bien sûr, le produit fini qui est prêt à être partagé avec le client et/ou l’utilisateur final.
Le backlog du produit est un document vivant qui contient une liste complète de toutes les fonctionnalités souhaitées, sujettes à modification en fonction des besoins du client. Le PO hiérarchise la liste des éléments et l’équipe se concentre sur les éléments en suspens les plus prioritaires dans chaque sprint. Les fonctionnalités souhaitées peuvent être listées de différentes manières, mais les équipes de projet rencontrent le plus de succès lorsqu’elles sont exprimées sous forme d’histoires brèves décrivant concrètement l’expérience de l’utilisateur final.
Notez que le backlog de sprint est un sous-ensemble plus petit du backlog de produit. Il répertorie uniquement les caractéristiques et les fonctionnalités sur lesquelles les membres de l’équipe vont se concentrer au cours d’un seul sprint.
Lorsqu’ils s’attaquent à la liste du backlog de sprint, les membres de l’équipe utilisent deux tableaux : le tableau d’avancement du sprint et le tableau d’avancement de la version. Ces documents reflètent la quantité de travail que l’équipe doit encore accomplir et fonctionnent presque comme un tableau de bord, fournissant une représentation visuelle de l’état d’avancement du sprint ou de la version.
Product Owner
Lorsqu’on suit la méthodologie agile Scrum, le PO est la partie prenante clé et un visionnaire ayant le pouvoir de partager cette vision avec les membres de l’équipe. Le backlog du produit est le principal outil du PO pour communiquer sa vision, car il contient une liste des caractéristiques du produit par ordre de priorité de développement.
Le PO doit avoir une bonne compréhension du marché, des concurrents, des tendances et des utilisateurs finaux. Le PO est souvent un utilisateur final principal, mais il peut aussi s’agir d’un membre du développement du produit et/ou du marketing.
Le PO fournit une orientation claire pour motiver l’équipe, mais n’assume pas un rôle de délégant. Les membres de l’équipe sont les mieux placés pour attribuer les tâches de chaque sprint en fonction de leurs compétences et de leur compréhension de la quantité de travail nécessaire au développement d’une fonctionnalité particulière. Le PO élabore la liste des fonctionnalités du backlog de produit et leur attribue des priorités, mais les membres de l’équipe déterminent les fonctionnalités sur lesquelles ils se concentreront au cours de chaque sprint.
Lorsque les membres de l’équipe s’engagent à développer certaines fonctionnalités pendant un sprint, le PO accepte de ne pas modifier les exigences pendant le sprint. Entre les sprints, des ajustements peuvent être effectués. Mais pendant un sprint, la concentration de l’équipe ne doit pas être perturbée.
Scrum Master
Chaque équipe Scrum a un Scrum Master qui guide le processus et aide l’équipe à obtenir des résultats optimaux. Le Scrum Master est un expert de la méthodologie Scrum. Il est capable d’identifier et de supprimer ou d’atténuer les obstacles, de faciliter les réunions et de communiquer clairement avec le PO et les autres parties prenantes.
Le Scrum Master est souvent une personne ayant une formation en gestion de projet, mais ce rôle peut également être rempli par un spécialiste technique. Le Scrum Master n’est pas seulement un coach, mais aussi un protecteur de l’équipe. Si le PO est trop exigeant, le Scrum Master doit le reconnaître et aider les membres de l’équipe à ne pas se surmener. À l’autre extrême, si les membres de l’équipe deviennent léthargiques, le Scrum Master doit également s’en occuper.
Bien que le Scrum Master n’ait aucune autorité réelle sur les autres membres de l’équipe, il est le maître du processus lui-même. Le Scrum Master ne peut pas renvoyer les membres de l’équipe, mais il peut contrôler la durée et la fréquence des sprints. Les meilleurs Scrum Masters maintiennent les membres de l’équipe concentrés sur l’objectif final, mais ils ne font pas de micro-gestion pour tenter de contrôler les performances des membres de l’équipe au cours de chaque sprint.
Le Scrum Master ne peut pas contrôler la façon dont les tâches sont accomplies ou qui les accomplit, et ces limitations de pouvoir peuvent être frustrantes pour ceux qui sont habitués à des rôles plus traditionnels dans la gestion de projet. Le rôle du Scrum Master est stimulant et essentiel au succès de la méthodologie Scrum.
L’équipe
Les équipes Scrum ne sont pas des organisations hiérarchiques. Au contraire, chacun collabore pour mener à bien le travail de développement que l’équipe s’est engagée à réaliser au cours d’un sprint donné. Les individus n’ont pas de rôles assignés, mais travaillent plutôt ensemble pour le bien de tous.
La plupart des équipes Scrum comptent entre cinq et neuf membres, mais cela peut varier. Les projets de plus grande envergure sont réalisés grâce à la pratique de la mise à l’échelle, par exemple en créant des équipes Scrum au sein d’autres équipes Scrum. Lorsqu’elle est correctement structurée, cette mise à l’échelle peut accueillir plus de 1 000 personnes. Au sein de cette structure, chaque équipe envoie une personne à une réunion « Scrum of Scrums » où le travail inter-équipes est coordonné. Ces réunions ont généralement lieu plusieurs fois par semaine, mais pas tous les jours comme les réunions d’équipe.