cycle de vie du développement logiciel (SDLC). Scrum Model Step by Step
Scrum framework permet d’implémenter une méthodologie de développement Agile. Contrairement au modèle de développement logiciel en cascade, Scrum permet un processus de développement itératif et incrémental. Le projet se divise en plusieurs phases, chacune aboutissant à un produit prêt à l’emploi. A la fin de chaque étape (appelée sprint dans la terminologie Scrum), un produit utilisable est livré à un client., Les commentaires des clients aident à révéler d’éventuels problèmes ou à modifier le plan de développement initial si nécessaire. Si vous souhaitez que votre projet suive strictement les grands principes du Manifeste Agile, vous pouvez utiliser le modèle Scrum et être sûr d’être sur la bonne voie.
Voici les principaux rôles impliqués dans le processus de développement, selon le modèle Scrum:
- Le product owner prend en charge les intérêts de l’utilisateur final;
- Le Scrum master coordonne l’ensemble du processus de développement., Une autre tâche consiste à s’assurer que Scrum est utilisé correctement et à tenir des réunions Scrum régulières;
- L’équipe Scrum développe le produit. Ses tâches principales sont la programmation, l’analyse, les tests, etc.
voyons maintenant les principales étapes du processus de développement de Scrum.
Phases du modèle Scrum
Étape 1. Création de backlog produit
un backlog produit est une liste qui contient des fonctionnalités à implémenter pendant le processus de développement. Il est ordonné par priorité et chaque élément est appelé une histoire utilisateur. Chaque histoire d’utilisateur obtient un identifiant unique., En règle générale , les User stories ont le format suivant: en tant que, je veux le faire . Cette liste ci-dessous montre à quoi ces histoires peuvent ressembler.,ange la durée et la date de début de celles actuelles en utilisant le glisser-déposer afin que je puisse estimer le temps global du projet
outre ces champs obligatoires, les champs facultatifs peuvent être ajoutés en cas de besoin:
- la piste permet de sélectionner tous les User Stories d’un certain type pour changer leur priorité., Peut être utilisé pour augmenter la priorité des user stories qui se rapportent au panneau de configuration, par exemple;
- Les composants constituent une liste de composants qui seront modifiés pendant le travail. Les modules d’une application, tels que l’authentification ou la recherche, par exemple;
- Le demandeur est un client qui souhaite implémenter une fonctionnalité particulière;
- Bug tracking ID contient une liste de bogues détectés qui se rapportent à une histoire utilisateur appropriée.
Étape 2. Planification de Sprint et création de Backlog de Sprint
tout d’abord, vous devez déterminer quelle sera la durée de votre sprint., Un sprint court vous permet de libérer la version de travail d’un produit plus fréquemment. En conséquence, les commentaires des clients seront reçus plus souvent, et tous les bugs et erreurs possibles seront révélés à temps.
comme alternative, vous pouvez préférer une durée de sprint Plus longue. Cela permettra aux développeurs de travailler plus à fond. La durée optimale du sprint est définie comme une moyenne de ces deux options. En règle générale, dans un modèle Scrum, un sprint dure environ 2-4 semaines. Ce qui est plus important à cette phase, c’est l’objectif de Sprint. L’objectif est déterminé pour chaque sprint., Et conformément à cela, le sprint est rempli d’histoires d’utilisateurs. Une autre chose importante est la coopération entre les parties prenantes et les membres de l’équipe. Le product owner détermine l’importance d’une histoire utilisateur appropriée, tandis que L’équipe Scrum définit les coûts de main-d’œuvre appropriés.
Après cela, L’équipe Scrum peut sélectionner les histoires d’utilisateurs les plus importantes dans le Backlog Produit. Ensuite, les membres de l’équipe doivent décider comment ils vont résoudre telle ou telle tâche. En outre, l’équipe peut diviser des histoires d’utilisateurs particulières en plus petites, puis les transformer en une série de tâches., Le backlog Sprint devrait être créé ensuite. Il se compose d’histoires d’utilisateurs qui seront complétées pendant le sprint en cours. La quantité de ces histoires dépend de leur capacité en points d’histoire attribués à chaque histoire au cours de l’étape d’évaluation. L’équipe Scrum devrait être capable de terminer toutes ces histoires à temps.
Étape 3. Travailler sur le Sprint. Réunions Scrum quotidiennes
Après le choix des user stories pour la phase en cours, le processus de développement commence.
pour suivre le processus de travail en cours, un tableau des tâches est couramment utilisé., Il y a généralement de grandes cartes avec les noms des histoires d’utilisateurs particuliers et un paquet de petites notes autocollantes avec une description des tâches uniques qui sont nécessaires pour la mise en œuvre de telle ou telle histoire. Chaque conseil est développé en fonction des spécificités d’un projet. Jetons un coup d’oeil à un petit exemple.
Les cartes peuvent être disposées en fonction de leur importance. Lorsque le travail sur une tâche a été démarré, l’autocollant correspondant est déplacé du champ” à faire « vers celui” en cours »., Lorsque le travail est terminé, l’autocollant peut être déplacé vers le champ « Test”, et une fois la tâche testée avec succès, l’autocollant va dans le champ « terminé”. Un exemple de la façon la Mêlée tableau des tâches peut regarder comme indiqué ci-dessous:
Il est également possible d’utiliser des logiciels spécialisés pour cette tâche.
Par exemple, Atlassian JIRA.
Une autre caractéristique importante de Scrum est les réunions Scrum quotidiennes., L’objectif principal de ces réunions est d’obtenir des informations complètes et véridiques sur l’état actuel du projet et de s’assurer que tous les membres de l’équipe sont sur la même page. Lors des réunions Scrum, chaque membre de l’équipe doit dire ce qu’il a fait pour L’objectif Sprint, quelle tâche sera la prochaine et quels problèmes les membres de l’équipe ont rencontrés pendant le travail.
en outre, un tableau de burndown est un autre outil largement utilisé qui permet de surveiller efficacement les processus quotidiens. Il vous montre combien de tâches restent inachevées., Ce graphique donne la possibilité de contrôler le processus de développement et peut être mis à jour après chaque réunion.
jour après jour, les réunions Scrum contribuent à augmenter la flexibilité du processus de développement. Ils permettent également de comprendre quels changements devraient être apportés.
l’axe des X représente les jours de travail restants, tandis que l’axe des Y affiche le nombre total de points d’histoire pour l’étape en cours. Une fois qu’une tâche nécessitant un certain nombre de points d’histoire est terminée, vous pouvez ajouter un point sur le diagramme pour indiquer la progression actuelle.,
JIRA permet de créer ces graphiques ainsi:
Ce graphique permet de tirer des conclusions au sujet de la vitesse actuelle de travail. En fonction de ces conclusions, le nombre d’user stories pour le prochain sprint peut être modifié.
Il est important de noter que, puisque le résultat idéal de chaque sprint dans un modèle Scrum est un produit fonctionnel, le processus de test du cycle de vie complet est très important. Il existe différentes façons de minimiser les coûts de la période de test. Par exemple, vous pouvez réduire le nombre total d’histoires utilisateur., En conséquence, le nombre de bugs possibles sera minimisé. L’autre façon est d’inclure des ingénieurs QA dans L’équipe Scrum.
lisez aussi pourquoi L’assurance qualité joue un rôle clé dans le développement de Produits Logiciels de haute qualité
Étape 4. Incrément de produit et revue de Sprint
le résultat de chaque sprint dans Scrum est un incrément de produit potentiellement expédiable qui peut être démontré au client. Après chaque itération, l’équipe de développement crée une nouvelle version d’un produit logiciel avec une valeur ajoutée., Lors de L’examen du Sprint, qui est la partie finale de chaque sprint, les résultats globaux peuvent être démontrés et analysés. Sur la base de toutes ces informations, les parties prenantes peuvent prendre une décision sur d’autres changements de projet et planifier le prochain sprint.
Étape 5. Retrospective and Next Sprint Planning
L’objectif principal de Retrospective est de discuter des résultats et de déterminer les moyens d’améliorer le processus de développement à l’étape suivante., Une caractéristique importante est qu’à ce stade, ce sont les processus de travail et d’interaction qui sont discutés afin d’améliorer le travail de L’équipe Scrum dans son ensemble. L’équipe devrait conclure ce qui s’est bien passé pendant le processus de travail et ce qui peut être mieux fait lors de la future itération. Lorsque les voies d’amélioration sont définies, l’équipe peut se concentrer sur la prochaine planification du sprint.
Conclusion
Les principales caractéristiques distinctives de Scrum sont l’agilité et de progrès continu. Il est principalement assuré par une communication permanente et une coopération étroite entre les parties prenantes à chaque étape., L’approche Scrum implique un processus de développement continu itératif et incrémental. L’objectif est d’assurer la possibilité d’augmenter continuellement la valeur du produit et de maintenir la flexibilité dans le choix des priorités pour d’autres itérations.
lorsque le sprint est terminé, le client peut évaluer la fonctionnalité de travail du produit à l’itération en cours et prendre une décision éclairée sur la façon dont le projet devrait évoluer lors des prochains sprints.,
même si, selon le Manifeste Agile, vous devriez préférer un logiciel de travail à une documentation complète, rien n’empêche les développeurs d’utiliser une spécification logicielle requise. SRS est bon pour dire ce qu’un système ou un produit devrait faire. Bien que SRS puisse manquer certains aspects agiles du développement de projet, tels que la collaboration, il peut toujours être un bon outil de planification et de planification.