Les tests dans un modèle agile
Principes de l’agilité
1. Pourquoi l’agilité ?
Le principe du cycle de développement en V, et des cycles de développement traditionnels d’une manière générale, repose sur des activités et étapes séquentielles qui, elles-mêmes, reposent sur l’application de processus stricts et sur la production d’une documentation dense. Sur le plan organisationnel, les équipes projet se donnent le relais à chaque étape et le client ou l’utilisateur final n’est pas impliqué, découvrant ainsi son produit à la fin de sa réalisation, puisque le produit passe par les étapes d’analyse, de conception, de développement et de test pour ensuite être partagé et montré au client.
L’agilité est arrivée pour remédier aux manquements de ces cycles séquentiels en proposant une approche de développement itérative favorisant l’interaction et la communication entre les équipes et dans laquelle le client est intégré dans le dispositif de réalisation. Cela supprime ainsi l’effet tunnel au cours du développement du logiciel dont se plaignent les clients.
Un client non informé est un client inquiet, voire frustré. La découverte du produit à la fin de sa réalisation représente un risque projet et produit majeur. L’approche agile favorise la communication avec le client et sa satisfaction. Le client reste informé de l’avancement de la réalisation de son logiciel et participe à son amélioration tout au long de la phase de construction.
Dans la section suivante, nous détaillerons les valeurs de l’agilité et les principes fondamentaux sur lesquels s’appuie cette approche.
a. Les valeurs du manifeste agile
Le manifeste agile, c’est quoi ?
Revenons quelques années en arrière. En 2001 est né le manifeste agile, à la suite d’une réunion impliquant dix-sept experts en développement logiciel. Fruit de retours d’expérience des participants, il définit les valeurs et principes fondamentaux de l’approche agile. L’objectif étant de capitaliser sur les pratiques positives du cycle de développement...
Stratégie de test en mode agile
1. La gestion des exigences en mode agile
En méthodologie agile, les exigences du logiciel sont organisées selon une structure hiérarchisée, avec un niveau de granularité facilitant leur compréhension par les équipes.
a. User story
Une user story est la plus petite unité livrable dans un backlog. C’est une description simple et concise d’une fonctionnalité ou d’un besoin du point de vue de l’utilisateur. Elle se présente sous la structure et le format suivant :
En tant que [type d’utilisateur] je veux [faire une action] afin de [atteindre un objectif].
Exemple
En tant qu’utilisateur, je veux pouvoir réinitialiser mon mot de passe afin de pouvoir accéder à mon compte en cas de perte ou d’oubli.
Une user story décrit un besoin spécifique. L’utilisateur et son objectif sont au cœur de l’exigence.
Une user story inclut aussi des critères d’acceptation. Ces critères définissent ce qui est requis pour que la user story soit considérée comme validée et acceptée par l’utilisateur.
Exemple
Pour la user story : « En tant qu’utilisateur, je souhaite pouvoir réinitialiser mon mot de passe afin de pouvoir accéder à mon compte en cas de perte ou d’oubli. », les critères d’acceptation pourraient être les suivants :
Présence du lien de réinitialisation :
Le lien « Mot de passe oublié ? » est visible sur l’écran de connexion.
Affichage du formulaire de réinitialisation :
Un clic sur ce lien ouvre un formulaire demandant à l’utilisateur de renseigner son adresse e-mail.
Traitement d’une adresse e-mail existante :
Si l’adresse e-mail fournie correspond à un compte existant, un e-mail contenant un lien de réinitialisation est immédiatement envoyé à l’utilisateur.
Traitement d’une adresse e-mail inconnue :
Si l’adresse n’est pas reconnue, un message s’affiche invitant l’utilisateur à créer un nouveau compte.
Validité du lien :
Le lien de réinitialisation envoyé par e-mail est valide pendant...
Introduction à SAFe
Nous avons vu comment Scrum permet de mettre en place les principes de l’agilité et d’organiser le travail au niveau d’une équipe.
Lorsque l’on parle de SAFe, on ne parle plus d’une équipe agile mais de plusieurs équipes interconnectées.
Le SAFe (Scaled Agile Framework) est donc un modèle de travail agile conçu pour accompagner les grandes entreprises à mettre en œuvre les pratiques agiles de manière coordonnée à l’échelle de l’organisation. Si des cadres de travail comme Scrum sont efficaces pour de petites équipes, leur application à grande échelle engendre des défis. SAFe comble le besoin de coordonner efficacement plusieurs équipes tout en maintenant l’agilité dans les grandes organisations.
SAFe offre la possibilité de :
-
gérer les complexités propres aux grandes structures ;
-
aligner les équipes sur la stratégie d’entreprise ;
-
synchroniser le développement produit avec les priorités métier.
1. Les principes de SAFe
Voici les principes de base de SAFe.
Adopter une approche économique
L’objectif de ce principe consiste à guider chaque décision par son impact sur le budget. Encourager la prise des décisions qui maximisent la valeur tout en minimisant les coûts. En matière de gestion de projets agiles, cela se traduit par des pratiques qui permettent d’atteindre les objectifs sans gaspiller de temps, d’effort ou de budget.
Voici quelques façons d’adopter une approche économique dans un contexte agile :
-
Prioriser les tâches et les user stories selon leur valeur pour le client ou l’entreprise en utilisant la méthode MoSCoW qui permet de définir ce qui est indispensable et ce qui ne l’est pas. Ce qui est indispensable (Must have), souhaitable (should have), optionnel (could have) ou non prioritaire (won’t have).
-
Optimiser les ressources : les ressources peuvent être humaines ou matérielles. Optimiser les ressources humaines consiste à optimiser le temps de travail en affectant les bonnes compétences aux bonnes tâches.
-
Choisir l’outillage approprié est important. L’objectif est d’encourager...
Introduction à l’approche DevOps
1. Définition
Le DevOps est un mot qui paraît complexe au début, mais une fois le concept compris on y voit plus clair.
Il s’agit d’un principe qui repose sur un ensemble de pratiques qui combinent le développement de logiciels (Dev) et les opérations IT (Ops). Il vise à rapprocher les équipes et améliorer la collaboration et la communication, avec comme objectif principal la livraison rapide des applications tout en améliorant la qualité.
Comment le DevOps peut-il aider à livrer des logiciels rapidement, améliorer leur qualité et aider les développeurs dans leur déploiement ? En favorisant la collaboration et l’automatisation. Qui dit automatisation dit outillage.
Voici un cycle DevOps simple :
-
Planifier : les développeurs planifient ce qu’ils vont construire.
-
Coder : les développeurs écrivent le code et le sauvegardent avec des outils comme Git.
-
Construire : automatiser la création de l’application (compilation).
-
Tester : les équipes de développement ou les équipes DevOps exécutent automatiquement des tests pour détecter les anomalies.
-
Relâcher : les développeurs préparent le logiciel pour le déploiement.
-
Déployer :les développeurs installent l’application...