agile scrum terminology
Ceci est un guide complet pour toute la terminologie Agile / Scrum importante et est un glossaire tout en un des concepts Agile et Scrum:
Comme nous le savons tous, Agile n'a pas besoin d'être présenté. Il s'agit d'un cadre de développement logiciel utilisé partout dans le monde.
Cet article est un guide complet de tous les concepts Agile / Scrum que vous devez avoir à portée de main.
Ce que vous apprendrez:
- Manifeste Agile
- Qu'est-ce que Scrum?
- Piliers de Scrum
- Équipe Scrum
- Rôles dans Scrum
- Cérémonies de mêlée
- Principes de base de l'estimation agile
- Artefacts Scrum
- Définition de terminé
- Raffinement du carnet de commandes (toilettage)
- Comparaison rapide avec la cascade
- Backlog produit
- Construire une équipe Scrum
- Conclusion
- lecture recommandée
Manifeste Agile
La méthodologie Agile est basée sur le Manifeste Agile. Pour plus d'informations sur le manifeste, consultez Manifeste pour le développement logiciel agile .
Les principaux enseignements du manifeste agile peuvent être abrégés à :
- La communication de personne à personne est efficace pour la liaison de processus.
- Le produit de travail est meilleur que la documentation conventionnelle étape par étape.
- L'implication des clients / propriétaires d'entreprise est essentielle, tout comme les boucles de rétroaction continues.
- Les changements sont inévitables. Par conséquent, les équipes doivent les accueillir et les accueillir.
Vous verrez que, même si le processus agile fait ces déclarations, il ne fournit pas les étapes concrètes exactes pour y parvenir. Il accorde une liberté et une autonomie complètes aux équipes pour faire de leur mieux.
Au fil du temps, le freestyle a évolué vers des pratiques courantes. Dont le plus connu est Scrum.
Commençons nos définitions par là.
Qu'est-ce que Scrum?
Scrum est un modèle de développement développé par Ken Schwaber et Jeff Sutherland et est utilisé depuis les années 1990.
Le travail est divisé en exigences plus petites (histoires, épopées et tâches) et des équipes soudées créent et livrent en petites tranches. Des commentaires sont fréquemment recherchés et des améliorations sont apportées au produit sous la forme de versions courtes et fréquentes.
Piliers de Scrum
Les piliers de Scrum sont expliqués ci-dessous en détail:
- Transparence : Les équipes sont conscientes de ce qui se passe et sont ouvertes au partage et à l'entraide. La communication circule librement via le stand up quotidien et les interactions informelles de personne à personne.
- Inspection : Des inspections fréquentes et religieuses du travail sont la clé du succès de Scrum. Les équipes peuvent identifier, diagnostiquer, dépanner, réparer et se remettre sur les rails d'une manière simple et fiable.
- Adaptation : Scrum ne suppose pas que ce qu'ils font est juste. Il existe des points de contrôle périodiques sous la forme de Planification de sprint, mêlée quotidienne, revue de sprint / réunions rétrospectives où l'équipe peut revoir et s'adapter.
Équipe Scrum
Équipes Scrum sont généralement petits (5 à 9) et sont généralement de nature interfonctionnelle. Ils comprennent un Scrum Master , développeur, testeur (il est courant de désigner tous les membres de l'équipe agile comme des développeurs, quel que soit leur domaine de travail).
D'autres membres de l'équipe technique et surtout, le propriétaire ou le sponsor du produit. Agile place tous ses paris sur son équipe. Une équipe A auto-organisée est donc essentielle et presque une condition préalable à une mise en œuvre agile réussie.
Rôles dans Scrum
Voici les différents rôles dans Scrum:
- Propriétaire du produit: Un propriétaire de produit est propriétaire du backlog. Il est responsable du produit et de la forme qu'il prend. Maintenir le carnet de commandes du produit, avoir une vision globale du produit et conduire les objectifs de l’équipe vers celui-ci sont les principales responsabilités d’un propriétaire de produit.
- Équipe de développement: L'équipe de développement n'a pas de rôles confinés. On attend d'eux qu'ils travaillent de manière interfonctionnelle et choisissent la meilleure approche pour atteindre l'objectif.
- Scrum Master: C’est le travail du Scrum Master de s’assurer que la mêlée est mise en œuvre de la bonne manière. Le Scrum Master est également appelé le Chef de service pour toute l'équipe.
Cérémonies de mêlée
Agile s'appuie sur quelques habitudes pour rester sur la bonne voie et réussir.
Certains d'entre eux sont mentionnés ci-dessous:
# 1) Réunion de mêlée quotidienne: Il s'agit d'une courte rencontre typique de 15 minutes où chaque membre de l'équipe parle des points suivants:
- Qu'est-ce qui a été fait hier?
- Qu'est-ce qui est prévu pour aujourd'hui?
- Y a-t-il des obstacles en cours de route?
Ce format de réunion est très efficace pour comprendre quel travail est terminé, ce qui reste et comment l'équipe peut s'entraider si nécessaire.
Scrum Master facilite cette réunion, mais ce n'est pas au profit du Scrum Master ou d'un endroit pour récupérer le statut. C'est une opportunité pour l'équipe d'interagir et de se blottir ensemble avant de se séparer pour conquérir les tâches de la journée.
# 2) Sprint : Un Sprint est une itération temporelle (souvent 3 semaines une fois mais peut être plus ou moins longue). Il s'agit d'un processus répétitif qui peut être considéré comme une explosion de développement et de livraison.
# 3) Planification de sprint: Le but de la planification de sprint est de planifier comment transformer un ensemble d'histoires de backlog de produit en un incrément du produit livrable.
Le format global peut être comme une situation en deux parties.
- Première moitié - L'équipe sélectionne les éléments qu'elle s'engage à terminer.
- Deuxième partie - Le Product Owner est disponible pour des questions.
L'équipe décide de la manière de le construire. Ainsi, les tâches sont créées et affectées en conséquence, ce qui Backlog de sprint.
# 4) Revue / Démo de Sprint : Après un sprint, l'équipe et les parties prenantes se rencontrent, afin que le travail réalisé puisse être présenté.
Les tâches terminées sont comparées aux éléments planifiés et la fonctionnalité qui n'a pas été implémentée est omise. La durée de cette réunion ne dépasse pas 4 heures.
# 5) Rétrospective Sprint: Cette rencontre est facilitée par le Scrum Master et toute l'équipe y compris le PO y participe.
L'équipe discute du récent Sprint en mettant l'accent sur les idées d'amélioration des processus et détermine les changements qui pourraient être apportés pour rendre le prochain Sprint plus productif.
En temps normal, cette réunion ne dure pas plus de 2 heures.
=> Lecture recommandée - Réunions rétrospectives agiles
Principes de base de l'estimation agile
Voici les principes de base de l'estimation agile:
Contributions
- Backlog de produit et backlog de sprint.
- Données historiques, estimations précédentes pour des tâches similaires avec des valeurs d'effort réel dépensées.
Estimation Participants
- Les membres de l'équipe connaissent l'application.
- Les membres de l'équipe qui comprennent l'intégration de l'application avec d'autres systèmes.
- Représentation de diverses compétences requises pour l'achèvement du projet.
- Représentants de l'équipe de construction, de déploiement et d'assurance qualité.
Définition à Epic / Feature / Idea
- Ce sont des user stories volumineuses, généralement trop volumineuses pour être implémentées en une seule itération.
- Idée / Épopée -> Histoires -> Tâches (une idée peut avoir plusieurs histoires. Une histoire peut avoir plusieurs tâches. L'étendue de l'histoire est limitée à un Sprint. Toutes les tâches doivent être fermées pour terminer l'histoire)
# 1) Technique d'estimation des points d'histoire: Le point d'histoire est un nombre qui indique à l'équipe à quel point l'histoire est complexe.
Dans la plupart des cas, la série Fibonacci ou la taille de T-shirt est utilisée. Habituellement, un point d’histoire équivaut à une journée de travail d’une personne.
Cependant, le ratio est révisé après chaque itération sur la base des données réelles du temps moyen nécessaire pour terminer une unité d'une tâche.
Les étapes impliquées comprennent:
- Divisez les très grandes exigences en petites tâches.
- Choisissez une équipe d'au moins 2 estimateurs, le Scrum Master , Le Product Owner et les autres peuvent participer.
- Chaque estimateur attribue en privé ses points d'histoire à une user story (tâche) et la publie.
- Les points d'histoire pour l'exigence sont attribués par les estimateurs en fonction de leur connaissance antérieure de la taille d'une tâche similaire.
- On s'attend à ce que les estimations diffèrent légèrement.
- Si les estimations diffèrent considérablement, les estimateurs élevés et faibles expliquent leurs estimations.
- Après cela, un autre cycle d'estimation est effectué par tous les estimateurs, suivant le même processus jusqu'à ce qu'ils convergent tous vers le même nombre.
# 2) Planification du poker: Cette technique intéressante et amusante est expliquée ici: Comment simplifier le processus d'estimation agile avec Planning Poker
Noter :Il existe de nombreuses autres techniques d'estimation agile, mais ce sont les deux plus importantes.
Artefacts Scrum
Les artefacts Scrum les plus importants sont le Backlog Produit et le Backlog Sprint . Ce sont ceux qui aident à surveiller les objectifs globaux du sprint.
# 1) Backlog produit:
- Une liste ordonnée des «exigences» qui est maintenue pour un produit / projet.
- Une liste peut contenir des bogues et des éléments non fonctionnels.
- Le Product Owner est responsable de la définition des priorités dans le PBL.
- Le Product Owner est responsable de la gestion du Product Backlog.
# 2) Backlog de sprint:
- Liste de tâches (également appelée élément Backlog) pour le Sprint.
- Équipe Scrum est responsable de leur entretien.
- Pendant le sprint, les membres de l'équipe doivent mettre à jour le backlog de sprint dès que de nouvelles informations sont disponibles.
- Dans le cas où l'un des éléments est laissé incomplet ou partiellement complet, selon la définition de la mêlée standard, ces éléments sont remis dans le Backlog de produit.
# 3) Tableau de combustion:
quel est le meilleur logiciel d'accès à distance
- Il s'agit d'un graphique affiché publiquement montrant le travail terminé et restant dans le sprint.
- Affiche le travail réel effectué par jour.
- Maintenu par le Scrum Master sur une base quotidienne.
- Il existe deux types de 'Release Burn-down charts' et 'Sprint Burn-down charts'.
Définition de terminé
Définition de terminé est différent pour différentes équipes de mêlée. En termes simples, DoD est un moyen de savoir quand l'équipe atteindra l'objectif via les outils disponibles. C'est le contrat entre le PO et l'équipe.
DoD satisfait signifie que toutes les histoires de l'arriéré sont développées en fonction des exigences de la partie prenante. Les histoires peuvent être non techniques ou avoir plusieurs tâches.
Raffinement du carnet de commandes (toilettage)
Amélioration du backlog n'est pas une pratique de base de Scrum mais a été adoptée comme moyen de gérer la qualité des éléments du backlog entrant dans un sprint.
Il s'agit d'un effort continu pour examiner les éléments du backlog produit et vérifier s'ils sont correctement hiérarchisés et préparés de manière à les rendre clairs et exécutables pour les équipes une fois qu'elles entrent dans les sprints via l'activité de planification de sprint.
Comparaison rapide avec la cascade
Paramètres | Agile | Cascade |
---|---|---|
Satisfaction du client | Les clients sont satisfaits grâce à une livraison rapide | La livraison est en retard et les clients ne sont pas sûrs |
Livraison de logiciels de travail | Livraisons fréquentes | Un tous les quelques mois |
Modifications tardives | Peut être porté rapidement au printemps prochain | Difficile à mettre en œuvre |
la communication | Communication quotidienne | Rencontre d'examen avec le chef de projet |
Dépendance | Communication et coopération étroites entre les gens d'affaires et les développeurs - Testeurs. | Le chef de projet pilote le projet |
Backlog produit
Au fur et à mesure que nous progressons, les PBI sont créés et ils sont PROFONDS:
- RÉ- Assez détaillé
- EST- Emergenc est
- EST- Estimé
- P- Priorité
Et ils sont plus détaillés pour l'équipe.
Les choses auxquelles un Scrum Master devrait s'adapter:
- Supprimer les obstacles
- Faciliter
- Mentorat et enseignement
- encadrement
Ce sont les tâches qu'un Scrum Master devrait se produire lorsque le Scrum est nouvellement implémenté. Mais au fur et à mesure que le temps passe et que l'équipe s'habitue à Scrum (devient auto-organisée), le Scrum Master a une tâche à accomplir, c'est-à-dire «OBSERVER».
Construire une équipe Scrum
Tout en constituant une équipe, le Scrum Master pourrait faire face aux défis suivants: formation, prise d'assaut, normalisation et exécution.
- Formant- Où il n'y a pas de relations dans une équipe.
- Assaut- Où les frontières entre les membres de l'équipe deviendraient légères.
- Normalisation- Quand il y a une bonne relation établie dans l'équipe.
- Exécution- C'est la dernière étape où il n'y a que du travail d'équipe.
Comme nous pouvons le voir, la dernière étape est celle où l'équipe travaille vraiment en tant que Équipe Scrum . Mais pendant cette transformation, s'il y a une perturbation à un stade quelconque, cela ramène l'équipe au début.
Conclusion
Nous espérons que ce tutoriel a brièvement expliqué tous les Terminologie Agile et Scrum . Veuillez vous référer à cette série de tutoriels Guide complet de la méthodologie Agile pour plus de détails sur les concepts Agile / Scrum.
Bonne agilité!
lecture recommandée
- Quiz Agile Scrum en ligne: Testez vos connaissances sur Agile Scrum
- Equipes Scrum auto-suffisantes: comment créer une équipe auto-suffisante?
- Kanban vs Scrum vs Agile: une comparaison détaillée pour trouver les différences
- Comment fournir des fonctionnalités logicielles de grande valeur dans un court laps de temps à l'aide du processus Agile Scrum
- Manifeste Agile: Comprendre les valeurs et principes Agile
- Méthodologie Agile: Guide du débutant sur la méthode Agile et Scrum
- Tutoriel SAFe Agile: Qu'est-ce que Scaled Agile Framework
- Rôles et responsabilités de l'équipe Scrum: Scrum Master et Product Owner