Qu’est-ce qu’Azure Boards ?
Azure Boards est un outil dans Azure DevOps conçu pour aider les équipes à planifier le travail qu’elles doivent effectuer. L’équipe de Tailspin va utiliser cet outil pour avoir une idée plus précise du travail qu’elle doit effectuer et la manière de le classer par ordre de priorité.
Mara a créé son propre projet dans Azure Boards en utilisant le processus De base. Le projet liste les problèmes dans le processus de build qui ont été identifiés par Andy et elle-même. Mara réunit toute l’équipe pour faire une démonstration rapide.
Mara : Bonjour tout le monde. J’ai configuré Azure Boards et je voudrais vous montrer certains éléments de travail que j’ai créés.
Andy : Qu’est-ce qu’un élément de travail ?
Mara : Les éléments de travail nous aident à planifier et gérer un projet. Un élément de travail permet d’effectuer le suivi de tous les types d’activités. Cela peut être une tâche à faire, un bogue à corriger ou tout autre problème. Nous pouvons attribuer ces éléments aux membres de l’équipe et suivre leur progression.
Laissez-moi vous montrer un exemple ; cela sera peut-être plus parlant. Vous voyez ici Azure Boards avec le processus De base :
Amita : Expliquez-nous en quoi consiste le processus De base. Y a-t-il d’autres options ?
Mara : Il existe quatre processus parmi lesquels choisir. Nous avons le choix entre :
- Integration Capability Maturity Model (CMMI) : Ce processus est destiné aux grandes organisations. Je ne l’ai pas utilisé car il est plutôt compliqué.
- Scrum : Scrum dépend d’un Scrum Master qui dirige l’équipe Scrum. Le Scrum Master s’assure que tout le monde comprend bien la théorie, les pratiques et les règles du Scrum. Je n’ai pas non plus choisi ce processus, car nous n’avons pas de Scrum Master en interne, qui est généralement une personne ayant reçu une formation et une certification.
- Agile : Cela semblait le choix évident, car je parle toujours d’Agile. Cependant, ce processus nécessiterait de prendre en compte quelques points supplémentaires par rapport à l’option la plus simple.
- De base : Comme son nom l’indique, c’est le processus de base. Il est simple, mais il nous suffit pour commencer à planifier efficacement dès maintenant. C’est pourquoi j’ai choisi cette option. Le workflow De base est relativement simple. Vous faites passer le travail de À faire à En cours d’exécution, puis à Terminé.
Amita : OK, commençons par celui-ci. Nous pourrons plus tard changer de processus, non ?
Mara : Oui ! Donc, nous allons sélectionner quelques éléments de travail que nous pensons pouvoir corriger dans les prochaines semaines.
Andy a déjà identifié ces problèmes, mais le reste de l’équipe a des questions.
Tim : Il s’agit majoritairement de problèmes de développement. Mais puisque nous parlons de ce sujet, d’autres équipes ont évoqué des problèmes de vulnérabilités du code, et je dois leur démontrer que notre code est sécurisé. Existe-t-il un moyen d’ajouter ce problème ?
Mara : Je suis consciente que la liste n’est pas exhaustive. Les problèmes listés dans le tableau sont ceux dont j’ai parlé avec Andy récemment. Certains de ces problèmes doivent même être divisés en plusieurs tâches plus petites. Je comprends vos inquiétudes à propos des vulnérabilités du code. Andy, qu’en pensez-vous ?
Andy : Actuellement, sortir une build est difficile. Commençons par quelques problèmes généraux. J’aime l’idée d’avoir un emplacement central où nous pourrons effectuer le suivi de tous les problèmes rencontrés. Nous pourrons ajouter des problèmes au backlog et les classer ensuite par priorité de traitement.
Mara : Avant d’ajouter des problèmes, j’ai besoin de connaître un peu mieux le travail de chaque personne.
Chaque membre de l’équipe explique aux autres ce sur quoi il travaille et les problèmes qu’il rencontre. Dans le cadre d’une activité de brainstorming, tout le monde colle des notes sur un tableau blanc. Le tableau blanc est vite couvert de notes.
À la fin, l’équipe sélectionne sept problèmes principaux. Andy se porte volontaire pour ajouter des tâches dans Azure Boards, pendant que les autres regardent. Voici à quoi ressemble le tableau :
Amita : Cela en fait des problèmes ! Comment allons-nous réussir à tous les corriger ?
Mara : Nous ne sommes pas obligés de tous les corriger immédiatement. Pour l’instant, nous avons identifié un backlog, ou une liste de travail à partir de laquelle nous pouvons effectuer une extraction. La planification du travail consiste à déterminer ce qui est le plus urgent ou important.
Après discussion, l’équipe décide de traiter les trois problèmes que Mara avait proposés au départ :
- Stabiliser le serveur de build
- Créer un workflow basé sur Git
- Créer des tests unitaires
Mara : Ces problèmes semblent les plus simples à résoudre, et ils concernent certains défis que nous avons eu à relever récemment. Nous devons maintenant créer un projet, une équipe et un sprint. Après quoi, nous pourrons décider qui fait quoi.
Tim : Qu’est-ce qu’un sprint ?
Mara : Bonne question. Un sprint est le délai imparti pour effectuer les tâches planifiées. Les sprints nous aident à rester concentrer sur l’objectif. À la fin, nous pouvons organiser une brève réunion rétrospective pour échanger sur le travail accompli. Après cela, nous pouvons planifier le sprint suivant.
Tout le monde semble nerveux.
Mara : Nous avons encore beaucoup à apprendre. Un sprint dure généralement de deux à quatre semaines. Par exemple, voyons comment un sprint se déroule sur deux semaines. Il s’agit principalement de tâches qu’Andy et moi pouvons entreprendre. Nous vous présenterons notre progression au fur et à mesure. Nous trouverons ensuite des moyens d’inclure tout le monde dans le processus.
Mara et l’équipe ont pris un bon départ. Vous allez ensuite créer le projet, l’équipe et certaines tâches dans Azure Boards.