Histoire de l'utilisateur
Les user stories sont un moyen efficace d'énoncer les exigences pour les logiciels en cours de développement. Ces histoires contiennent de brefs conseils au nom de l'utilisateur du logiciel.
Étant donné que dans la méthodologie Scrum, la définition d'objectifs est généralement la prérogative du client ou du propriétaire du logiciel, ils sont considérés comme le principal moyen d'influencer le processus de développement. Chaque User Story a une limitation dans la quantité de texte et la complexité de la présentation. L'histoire est le plus souvent écrite sur une petite feuille, ce qui en soi limite le volume.
Grâce aux user stories, vous pouvez documenter les souhaits du client et répondre rapidement aux demandes du marché.
La User Story doit être considérée comme une mesure simpliste des exigences car elle n'inclut pas de procédure de test d'acceptation. La compilation de la user story doit respecter la procédure d'admission. Cela garantira que la User Story atteint son objectif.
La structure de l'histoire ressemble à ceci : "En tant qu'utilisateur <type d'utilisateur>, je veux effectuer <action> pour obtenir <résultat>" (En tant que propriétaire de produit, je veux ...). Une telle structure est non seulement simple, mais également compréhensible pour tout le monde.
Avantages de l'utilisation des User Stories :
- Les histoires sont petites et faciles à créer.
- Aider toutes les parties prenantes à discuter du travail sur le projet et de son soutien.
- Ne nécessite pas d'entretien constant.
- Pertinent uniquement lorsqu'il est utilisé.
- Améliorer l'interaction avec le client.
- Grâce à eux, vous pouvez diviser le projet en petites étapes.
- Faciliter le travail sur des projets avec des exigences mal comprises.
- Simplifiez l'évaluation des tâches.
Inconvénients des user stories :
- Sans accord préalable, les procédures peuvent rendre difficile son utilisation comme base d'un accord.
- Leur utilisation nécessite un contact étroit avec le client tout au long du projet, ce qui rend parfois le workflow difficile.
- Ils présentent des inconvénients lors de la mise à l'échelle de grands projets.
- Directement lié au niveau professionnel des développeurs.
- Utilisés pour démarrer une discussion, mais ne peuvent pas mettre fin à une discussion, et ne sont pas utilisés pour la documentation du système.
Arriéré
Le backlog produit est les tâches en cours sous forme de liste, compilées par ordre de priorité. La liste est formée sur la base de la feuille de route (feuille de route) du projet et des points qui y sont énoncés. Les tâches les plus importantes sont généralement en haut de la liste. Ceci est nécessaire pour comprendre quel travail doit être fait en premier.
L'équipe de développement choisit la vitesse d'exécution des tâches du backlog indépendamment des souhaits du client, mais en fonction de ses qualifications et de son expérience des sprints précédents. Il est extrêmement indésirable "d'ajuster" les programmeurs. L'équipe elle-même choisit des tâches dans le backlog en fonction de ses propres considérations et capacités. L'exécution se déroule sans interruption (Kanban) ou plusieurs itérations (Scrum).
Deux conditions importantes de l'arriéré
Le cœur d'un backlog de produit se compose d'une feuille de route, de propositions et de conditions d'exécution. Les épopées contiennent des conditions et une User Story. Examinons de près un exemple typique de feuille de route.

La création du site « Teams in Space » est la première proposition de la feuille de route. Il doit être divisé en épopées (dans la figure, elles sont représentées en vert, bleu et turquoise) et une histoire utilisateur pour chaque épopée.

Le client du logiciel forme une liste à partir de plusieurs User Stories. Si nécessaire, il peut modifier l'ordre dans lequel les histoires sont exécutées, de sorte que les développeurs traitent d'abord l'une des épopées les plus importantes (à gauche) ou vérifient le fonctionnement de la réservation de billets à prix réduit. Pour ce faire, vous devez implémenter des histoires à partir d'épopées (à droite). Les deux options peuvent être vues ci-dessous.

Sur la base de quels facteurs le client doit-il prioriser ?
- Pertinence pour les utilisateurs.
- La présence de commentaires.
- Complexité du développement.
- La relation entre les tâches (pour compléter "B", vous devez d'abord faire "A").
Les priorités dans les travaux sont déterminées par le client, mais d'autres parties peuvent exprimer leur opinion à ce sujet. Le succès du backlog dépend, entre autres, des avis des clients et des programmeurs. Ensemble, ils peuvent obtenir de meilleurs résultats et assurer une livraison rapide du produit fini.
Comment conserver un backlog
Si le backlog a déjà été créé, vous devez ensuite le modifier périodiquement au cours de travaux ultérieurs. Le client du logiciel doit s'assurer que le backlog est correctement compilé avant chaque nouvelle planification d'itération. Cela aidera à clarifier les priorités ou à changer quelque chose après l'analyse de la dernière itération. Ajuster le backlog dans Agile est parfois appelé « toilettage » ou « raffinement » ou « maintenance du backlog ».
Si le backlog est déjà relativement important, le client doit regrouper les tâches par exécution à court terme et à long terme. Les affectations à court terme doivent être examinées attentivement avant de leur accorder ce statut. Vous devrez composer une User Story, découvrir toutes les nuances au sein de l'équipe.
Quant aux tâches à long terme, il est hautement souhaitable que les développeurs leur donnent leur appréciation. Cela facilitera la priorisation. Peut-être que quelque chose va changer, mais l'équipe améliorera sa compréhension des tâches et fera le travail plus rapidement.
Le backlog est un élément important entre le client et l'équipe de programmation. Le client peut toujours modifier ses priorités en fonction des commentaires des clients, des prévisions ou de nouvelles exigences.
Il est recommandé d'éviter d'apporter des modifications directement pendant le fonctionnement. Cela a un effet néfaste sur le flux de travail et l'état émotionnel des programmeurs.
Sprint
Un sprint est une courte période pendant laquelle une quantité de travail préalablement convenue doit être effectuée. Les sprints sont basés sur les méthodologies Scrum et Agile. Choisir les bons sprints aide une équipe agile à développer des logiciels de qualité.
« En utilisant Scrum, vous pouvez développer un produit en plusieurs itérations avec une durée claire - des sprints. Cela aide à décomposer les grands projets en tâches plus petites », explique Megan Cook, Jira Lead chez Atlassian.

Comment Scrum planifie et exécute les sprints ?
Selon les auteurs de la méthodologie Scrum, afin de planifier le futur sprint, tout le monde doit se réunir lors d'une réunion séparée. Lors de cet événement, les membres de l'équipe doivent trouver des réponses à deux questions principales : que faut-il faire dans ce sprint et comment le faire au mieux ?
Le client du logiciel, le Scrum master et les programmeurs sont impliqués dans la détermination de la liste des tâches de travail. Le client explique l'objectif du sprint et les tâches du backlog.
Ensuite, l'équipe élabore un plan selon lequel les tâches du sprint seront réalisées. Ce plan, ainsi que les éléments de travail sélectionnés, s'appelle le backlog de sprint. Après la réunion de planification, l'équipe se met au travail. Les développeurs sélectionnent des tâches dans le backlog, à mesure que le travail est terminé, le statut de chaque tâche passe de "En cours" à "Terminé".
Pendant le sprint, l'équipe organise des réunions Scrum quotidiennes (stand-ups) pour discuter des problèmes actuels et des progrès. De telles réunions sont nécessaires pour identifier les difficultés qui peuvent affecter la réalisation du sprint.
Si le sprint est terminé, l'équipe montre les résultats de son travail lors de l'examen des résultats (démo). Chaque participant au projet peut prendre connaissance des résultats. La familiarisation doit être effectuée avant que le code fini ne soit fusionné dans l'environnement de production.
La rétrospective complète le cycle des sprints. Sur celui-ci, l'équipe identifie les domaines qui doivent être améliorés dans un futur sprint.

À quoi faire attention et à ne pas faire
La plupart des jeunes équipes ont du mal à introduire des sprints dans leur flux de travail pour la première fois. Pour éviter les problèmes, nous vous recommandons de consulter la liste des actions nécessitant une attention prioritaire.
Qu'avons nous à faire:
- Vérifiez que l'équipe comprend le but du sprint et comment il réussira. Ceci est nécessaire pour que chacun avance ensemble vers un résultat réussi.
- Vous devez avoir un backlog clair et compréhensible. Si le backlog n'a pas été maintenu correctement, cela peut devenir un problème qui peut endommager le flux de travail.
- Assurez-vous que votre estimation du rythme de travail est correcte, en tenant compte des vacances d'été et d'autres facteurs.
- Participer activement à la planification des sprints. Encouragez les membres de l'équipe à développer le plan pour les histoires, les bogues et les devoirs.
- Refusez les tâches pendant lesquelles les développeurs ne pourront pas résoudre les problèmes de dépendance.
- Une fois le plan approuvé, nommez un employé qui sera responsable de la saisie des données dans le programme de gestion de projet (cartes Jira, etc.).
Ce qu'il faut éviter :
- N'abusez pas d'un grand nombre d'histoires, évaluez sobrement le rythme de travail et n'attribuez pas de tâches qui seront difficiles à réaliser dans un sprint.
- Soyez attentif à la qualité de votre travail. Vérifiez si vous disposez de suffisamment de temps pour le contrôle qualité et la correction des bogues dans le code.
- Assurez-vous que tous les membres de l'équipe comprennent clairement le contenu du sprint. Ne chassez pas la vitesse. Toute l'équipe doit bouger ensemble.
- Ne surchargez pas les développeurs avec du travail supplémentaire. Bientôt un autre sprint.
- Si l'équipe exprime des inquiétudes concernant la charge de travail ou le délai, vous devez tenir compte de son avis. Traiter les problèmes et les corriger si nécessaire.
tableau de mêlée
Le Scrum Board est un outil qui montre comment le travail de l'équipe Scrum est effectué. Vous pouvez afficher des informations sur un tel tableau sur papier, au mur ou sous forme électronique (JIRA, Trello).
Un tableau Scrum comporte au moins trois colonnes : À faire, En cours et Terminé. Voici un exemple de tableau :

Le tableau Scrum contient toutes les informations du backlog, préalablement approuvées pour la planification. En règle générale, les cartes de tâches professionnelles sont épinglées au tableau par priorité de haut en bas. Vous pouvez les diviser en types de travail spécifiques (travail sur le code, la conception et autres).
Une fois qu'une partie du travail est terminée, la carte est déplacée sur le plateau vers la colonne suivante. Pour montrer la visibilité de l'avancement du travail de l'équipe, le "travail restant" par jour sur le Burndown Chart aide.
Vous pouvez également utiliser un tableau à feuilles mobiles. Dessus, les noms des œuvres sont écrits sur des autocollants en papier et fixés au tableau. Dès que le travail est terminé, les autocollants sont déplacés vers une autre colonne.
Tableau de combustion
Le burndown chart montre la quantité de travail effectué et la quantité de travail restant. Il est mis à jour quotidiennement et est disponible pour toutes les parties intéressées. Le graphique est nécessaire pour montrer l'avancement du travail sur le sprint.
Il existe deux types de graphiques :
- Graphique Burndown montrant la progression du travail dans un sprint.
- Burndown chart montrant l'avancement du travail jusqu'à la sortie du produit (les données sont résumées à partir de plusieurs sprints).
Exemple de graphique :

Cet exemple utilise la psychologie : le graphique ne montre pas le nombre de tâches terminées, mais le nombre de tâches restantes (non faites).
Autrement dit, si l'équipe a effectué 90 tâches sur 100, il peut y avoir une fausse impression que tout est prêt. Après tout, passer de 90 à 100 tâches ne change vraiment rien.
Si vous affichez le nombre de tâches restantes, vous ne pouvez pas vous empêcher de remarquer à quel point elles deviennent de moins en moins nombreuses. Cela incite inconsciemment les participants au projet à atteindre l'objectif plus rapidement - il ne devrait pas y avoir de tâches inachevées au tableau.