Planification de mise en œuvre et reporting avec Microsoft Azure DevOps

Dans la dernière partie de notre série Azure DevOps, nous avons mis en place le projet « Seamless Mobility » et nous avons décrit les exigences en termes d'epics et de fonctionnalités. Cet article se concentre sur l'affinement des exigences sous forme de « user stories » et de tâches. L'objectif est de planifier et de réaliser un sprint avec l'aide d'Azure DevOps. Nous nous concentrerons également sur la communication et la collaboration au sein de l'équipe.

Comme le backlog contient déjà des epics et des fonctionnalités, les détails peuvent être décrits sous forme d'histoires d'utilisateurs. Ces "user stories" sont devenus la norme pour décrire les besoins du point de vue de l'utilisateur. Ils suivent le modèle "En tant que <rôle> je veux <cible>, de sorte que <avantage>. 

Dans la vue du backlog, l'ordre des epics et des fonctionnalités ainsi que le statut peuvent être utilisés pour identifier les éléments actuellement prioritaires. Les user stories sont maintenant dérivées pour les éléments les plus prioritaires.

Jetons un coup d'œil à la rubrique "Basic app development", qui contient deux user stories. Une autre histoire liée à cette fonctionnalité pourrait être sur la connexion de l'utilisateur :

Il a été prouvé qu'il était utile d'établir des critères de qualité pour la formulation des user stories au sein de l'équipe, la "Definition of Ready" (DoR). Par exemple, une user story est Ready for Sprint si :

• elle contient une description
• les critères d'acceptation ont été décrits
• la priorité a été fixée
• il y a une estimation dans Story Points
• toutes les tâches ont été définies.

En outre, les critères INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) peuvent être utilisés pour définir le DoR.

Les tâches sont utilisées pour décomposer les user stories en étapes réalisables afin de pouvoir les attribuer plus tard à des membres d'équipe pour la mise en œuvre. Pour les histoires qui sont traitées pendant toute la durée de l'itération, les tâches fournissent un moyen utile de suivre les progrès en continu. Rien n'est plus traître qu'une user story "presque" terminée, qui n'a le statut "En cours" que pour un sprint entier, sans autres étapes intermédiaires mesurables. Une décomposition en tâches est présentée ci-dessous à titre d'exemple - Azure DevOps est capable de cartographier clairement la hiérarchie :

Après avoir décrit et évalué les user stories et les tâches, il faut définir la portée du prochain sprint. Azure DevOps offre des fonctions de glisser-déposer et résume la somme des points (effort planifié), le nombre de « user stories » (ici 2) et de tâches (ici 3) par sprint. La capacité d'une équipe résulte de la somme des points mis en œuvre lors des itérations précédentes. Azure DevOps enregistre cette vitesse, c'est-à-dire le nombre de story points par sprint, en arrière-plan et ajuste cette valeur après chaque nouveau sprint.

Il en résulte une recommandation de points d'histoire réalisables pour le prochain sprint - qui peuvent être affichés dans Azure DevOps. Sur la base des prévisions, vous pouvez ajuster la planification et faire passer une histoire à l'itération suivante ou ajouter une histoire au sprint actuellement planifié si la capacité est encore disponible.

Après avoir défini la portée de l'itération, le sprint peut être lancé. Dans la vue du sprint, il est maintenant possible de consulter les user stories prévues et, si elles sont disponibles, les tâches peuvent être éditées individuellement. Pendant le sprint, le tableau du sprint constitue la vue d'ensemble sur la progression et les activités en cours de l'équipe. Le sprint board est un support utile pour les réunions de stand-up quotidiennes, au cours desquelles chaque membre de l'équipe fait un bref rapport sur son avancement depuis le dernier stand-up, les plans jusqu'au prochain stand-up ainsi que les obstacles éventuels et se met d'accord avec l'équipe.

La progression actuelle du sprint peut être facilement visualisée à l'aide des rapports « burndown » intégrés. Différentes options sont possibles - par exemple, le travail restant peut être affiché au niveau de l'histoire ou de la tâche :

En plus du Burndown Chart, qui peut être consulté directement dans la vue d'ensemble du sprint, Azure DevOps offre également un moyen très flexible d'intégrer des tableaux de bord et des rapports supplémentaires. En utilisant une grille, différents widgets peuvent être ajoutés et configurés par glisser-déposer pour répondre aux différentes exigences en matière de rapports.

Au cœur de la collaboration agile se trouve la collaboration d'équipe. Grâce aux fonctions de commentaire pour chaque work item, les discussions importantes peuvent être stockées directement dans le work item dans Azure DevOps. Cela permet aux membres de l'équipe, même absents, de se tenir au courant des points convenus à tout moment et de documenter/expliquer les modifications apportées aux tâches ou aux user stories.

De nombreuses équipes utilisent désormais Microsoft Teams comme plateforme pour les réunions virtuelles, les téléconférences, le stockage de fichiers et le chat. MS Teams est un complément idéal à Azure DevOps en tant que solution centrale de communication et de collaboration. Grâce à l'intégration d'Azure DevOps, les work items peuvent être créés directement dans MS Teams dans Azure DevOps ou référencés au cours des discussions.

Le projet Seamless Mobility utilise également Teams pour les échanges quotidiens. Grâce à l'intégration de Teams et des tableaux Azure, les informations relatives aux tâches peuvent facilement être intégrées dans la conversation.

Après la définition du scope et la création d'une feuille de route, on passe à la planification détaillée des user stories et à leur mise en œuvre par itérations. Azure DevOps fournit une base complète pour la planification et l'exécution des sprints, soutenue par des rapports standard tels que le Burndown Report. L'intégration d'Azure DevOps et de Microsoft Teams permet aux équipes d'utiliser leurs canaux de communication habituels et de les combiner de manière transparente avec Azure DevOps.

Dans notre prochain article, nous aborderons plus en détail les déploiements et les tests avant de nous intéresser aux aspects pratiques de revues et de rétrospectives de sprint.