Le mode de travail traditionnel en cascade utilise une spécification détaillée des exigences pour exprimer l'exigence, et le personnel chargé des exigences est responsable de la recherche des exigences, compile la spécification détaillée des exigences en fonction de la situation de recherche, procède à un examen des exigences, signe et confirme après l'examen et la main à l'équipe R&D pour la conception et le développement. Dans un tel environnement, le document d'exigences est le principal corps de transmission d'informations et également un contrat.
Cependant, les spécifications détaillées des exigences présentent les cinq inconvénients majeurs suivants :
- La transmission d'informations à sens unique est sujette à des erreurs d'interprétation.
- La documentation est tellement formelle qu'on peut la confondre avec quelque chose qui doit être vrai, ne la remettons pas en question, arrêtons de porter des jugements.
- Avec une documentation détaillée, nous n'allons pas faire de va-et-vient à ce sujet, confirmation mutuelle.
- La documentation écrite ne facilite pas le partage des responsabilités en équipe, elle fait office de preuve. Scrum met l'accent sur la responsabilité partagée de l'équipe. Qu'il s'agisse d'un responsable des exigences, d'un développeur ou d'un testeur, l'objectif commun de tous est de comprendre correctement les exigences par la discussion et la collaboration, puis de transformer ces exigences en fonctions dont les clients ont vraiment besoin. , plutôt que la livraison de tâches à sens unique. .
- Il faut beaucoup de temps pour préparer des documents d'exigences détaillés et exprimés avec précision, et si les exigences changent fréquemment, le coût de maintenance est plus élevé.
Agile utilise le Product Backlog pour gérer les exigences. Le Product Backlog est une liste d'exigences triées par leur valeur métier. Les exigences hautement prioritaires se trouvent en haut du Backlog. Le Product Backlog est une liste progressivement détaillée, il comporte 4 caractéristiques principales, appelées DEEP :
- Détaillé Niveau de détail approprié, les exigences de haute priorité sont plus détaillées et les exigences de faible priorité sont plus granulaires
- Emergent émerge, la demande émerge lentement, progressivement détaillée
- Estimation Estimation
- Hiérarchisé/ Ordonné Ordonné selon la valeur commerciale
Dans le backlog du produit, la principale forme d'exigence est la user story. Une user story est une brève description d'une exigence du point de vue de l'utilisateur. Les user stories sont le meilleur moyen de déplacer l'attention de l'équipe de la description et de la rédaction des exigences fonctionnelles vers la discussion des exigences.
Une user story décrit la fonctionnalité souhaitée du point de vue de l'utilisateur. Une bonne user story se compose de trois éléments :
- Rôle : Qui utilisera cette fonction.
- Activité : Quel type de fonction doit être rempli.
- Valeur commerciale : pourquoi cette fonction est nécessaire et quelle valeur apporte cette fonction.
Les user stories sont généralement exprimées au format suivant :
法文：
En tant que <Rôle>, je veux <Activité>, de sorte que la <Valeur commerciale>.
法文：
En tant que <rôle>, je veux que les <activités> facilitent la <valeur commerciale>.
Par exemple : en tant que membre ordinaire d'un site Web, je m'attends à ce qu'après avoir passé une commande, je puisse annuler la commande avant qu'elle ne soit expédiée, ce qui est plus flexible pour moi.
Leangoo est un outil de gestion de développement agile professionnel qui fournit des solutions de gestion de R&D agiles de bout en bout, couvrant la gestion des exigences agiles, la collaboration des tâches, le suivi des progrès, la mesure statistique, etc.
Gestion agile des exigences
Nous pouvons créer un Product Backlog Kanban via l'outil agile Leangoo pour gérer les exigences agiles.
Sur le tableau Kanban agile de Leangoo, nous pouvons personnaliser et créer plusieurs listes, et ajouter des cartes de demande à chaque liste.
Habituellement, nous créons ces listes dans le backlog de produit Kanban : "pool de user stories, user stories à trier, user stories triées, user stories en cours d'implémentation, user stories terminées"
En règle générale, "le regroupement des user stories est terminé" a la priorité la plus élevée et le pool de user stories a la priorité la plus basse. La figure suivante est un exemple de Product Backlog Kanban :
L'icône dans le coin inférieur droit de la carte d'exigences dans la figure ci-dessus représente les points d'histoire de cette carte d'histoire, certaines discussions sur cette histoire et les points clés du test d'acceptation de l'histoire, etc. Les points clés des tests d'acceptation sont reflétés sous la forme d'éléments d'inspection.
En plus de la charge de travail, des commentaires et des éléments de contrôle, nous pouvons également définir des délais, des étiquettes, etc. pour les cartes, et classer ou hiérarchiser les cartes par le biais d'étiquettes. Comme indiqué ci-dessous:
Une fois les user stories ajoutées, l'équipe peut trier les user stories avec une priorité plus élevée. Les éléments de tâche nécessaires pour terminer la user story peuvent être ajoutés aux éléments de vérification de la carte, de sorte qu'une fois la user story suivante planifiée dans le Sprint, elle puisse être facilement désassemblée en cartes de tâche plus petites.
Grâce au flux de liste, laissez l'équipe comprendre intuitivement la priorité et la planification des exigences
Planification des besoins à l'itération Kanban pour l'itération
- Avant le début de l'itération, nous devons planifier les user stories triées et prioritaires dans l'itération Kanban, afin de préparer le contenu qui doit être complété dans l'itération.
- Cliquez sur le bouton "Sprint Planning" et faites glisser les user stories prévues pour "Sprint1" vers le tableau "Sprint1".
Chaque itération a une importante statistique de progression du Sprint - burndown chart.
Le burndown chart est un outil simple et pratique pour suivre la progression de l'équipe dans Scrum. Il peut afficher visuellement la charge de travail restante et l'évolution du temps de travail restant dans l'itération en cours. Généralement, l'équipe utilisera le burndown chart lors du stand quotidien. -up réunion Comprendre la situation actuelle de la vitesse de sprint Sprint.
Leangoo générera automatiquement des graphiques d'avancement des versions en fonction des modifications apportées aux cartes d'histoire.
Cliquez sur le "Menu" sur le côté droit du Kanban et sélectionnez "Statistiques Kanban" pour afficher le graphique burndown, comme illustré dans la figure suivante :
Taux de réalisation par itération
Le taux de réalisation d'itération consiste à comptabiliser la réalisation de chaque itération Kanban dans le projet.
Configurez le cycle Kanban et le graphique burndown, Leangoo comptera automatiquement l'achèvement de chaque itération de Kanban et générera automatiquement des graphiques statistiques visuels, afin que la direction puisse voir la progression de chaque itération en un coup d'œil.
Statistiques pour chaque vitesse d'équipe d'itération
La vélocité de l'équipe est la quantité réelle de travail effectué par l'équipe Scrum dans un sprint (généralement en utilisant des points d'histoire comme unité de vélocité de l'équipe).
Une fois chaque sprint terminé, Leangoo enregistrera automatiquement la charge de travail effectuée dans le sprint en cours et générera automatiquement un tableau statistique visuel du taux d'équipe, afin que l'équipe puisse comprendre et analyser la tendance des changements d'efficacité de l'équipe.
Grâce aux méthodes et statistiques ci-dessus, nous pouvons bien gérer les exigences agiles.
Enfin, rappelons que l'agile privilégie la transparence, il est donc très important de gérer visuellement le product backlog. Si les conditions le permettent, on peut envisager de visualiser le product backlog à travers un grand écran d'affichage. Il serait préférable d'avoir un grand écran tactile. LA TÉLÉ.