On l’a vu lors de l’introduction sur Azure DevOps, l’usine logicielle n’est pas qu’un repository de code. Nous avons vu avec l’article sur Azure DevOps Repos quelques-unes des possibilités sur la gestion du code source avec cet outil. Mais si les avantages de la gestion du code source sont déjà en soi une raison suffisante d’utiliser l’outil, le développement est avant tout là pour répondre à des besoins métier. Et c’est cette partie que l’on va aborder dans cet article sur Azure DevOps Boards : comment répondre aux problématiques de gestion de projet de développement.
Table des matières
Explication en vidéo 2mn ⏱
Les avantages d’Azure DevOps Boards
La gestion de projet
La section « Boards » est la fonctionnalité orientée gestion de projet de la solution Azure DevOps. Tout projet de développement est avant tout, comme son nom l’indique, un projet. Et un projet, ça se gère plus difficilement sans avoir établi un plan. Au même titre que construire un immeuble, c’est plus facile avec un architecte et des ingénieurs en génie civil, un projet de développement se gère mieux avec un outil dédié.
On va le voir un peu plus bas, mais cet outil va répondre à plusieurs besoins, comme la construction du backlog, et permettre le travail en équipe par le fait de faciliter la lecture et l’échange d’informations.
Le travail en équipe
Le travail en équipe est un point important d’un outil de gestion de projet. L’outil doit permettre au chef de projet et/ou au product owner de planifier l’évolution du projet. Mais il doit aussi et surtout permettre de savoir quels sont les points importants à court terme, afin que l’équipe opérationnelle sache à tout moment qu’est-ce qui doit être fait.
L’équipe peut ainsi voir quel est le cap qui est pris, être complètement intégrée au développement et à l’évolution du logiciel. Elle peut aussi discuter au travers de l’outil afin de proposer de nouvelles idées, des ajustements, ou des demandes d’informations complémentaires.
L’avantage d’Azure DevOps Boards : la centralisation des fonctionnalités
L’un des grands avantages de l’outil vis-à-vis de concurrent, c’est la centralisation des fonctionnalités autour de la gestion des projets de développement. Ainsi, tout le savoir qui sera produit et organisé dans « Boards » se retrouvera fortement lié dans la fonctionnalité « Repos » vue précédemment (en suivant par exemple le code lié à une demande, sa pull request, etc.). Mais la liaison se retrouve aussi dans la fonctionnalité « Pipeline ». Nous reviendrons sur les différentes liaisons entre fonctionnalités dans un prochain article.
Créer son backlog sur Azure DevOps Boards
Qu’est-ce qu’un backlog?
Un backlog, c’est une liste de l’ensemble des tâches à faire sur un produit donné. Dans le jargon, on dit qu’un backlog est composé de Work Items qui peuvent être de différents types. On va y retrouver les classiques tasks et bugs, mais aussi d’autres éléments en fonction de la méthodologie projet utilisée.
Un backlog sert avant tout à organiser le travail autour du produit. L’intérêt premier, ça va être de détecter quels sont les travaux à effectuer avec la meilleure valeur ajoutée pour le produit, quels sont les « quick win ». Le backlog répond donc à plusieurs besoins :
- Conserver le savoir, en ayant une trace écrite des idées et des spécifications
- Écrire au mieux les spécifications
- Échanger autour des spécifications (commentaires par exemple)
- Lier les spécifications entre elles (hiérarchisation, blocage, etc.)
Et tout cela passe au travers des work items.
Présentation des Work Items
Les work items donc, ce sont les nombreuses tâches à effectuer sur un produit donner. Mais pas seulement. En fait, cela concerne l’ensemble du « savoir » autour du projet.
Les work items peuvent être de plusieurs types, selon la méthodologie choisie :
- Tasks
- Bugs
- Requirement
- Test case
- User story
- Feature
- Epics
- etc.
Il existe de nombreux types de Work item. Dans un premier temps, gardez simplement en tête que l’idée est de catégoriser l’information afin de mieux la gérer durant le projet. Par exemple, répertorier un bug en tant que tel permet de mettre en place des workflows (avec l’outil de notification, ou Power Automate par exemple) pour lever une alerte dès qu’un nouveau problème survient. Par contre, on ne veut pas forcément alerter toute l’équipe dev / support dès qu’une couleur doit être changée sur un bouton.
Les différents types de gestion de projet
Les différents types de Work items servent donc à catégoriser les éléments de votre projet afin de mieux les priorisés. Il vous est possible d’avoir accès à différents types de Work items :
- Lors de la création de votre projet, plusieurs templates de projet vous sont proposés
- Il est possible de modifier le template que vous utilisez pour en créer un personnalisé
Les templates de Work items qui vous sont proposés sont basés sur des méthodologies de projet très connu. Chacun possède se spécificités, même si la base est commune et que vous pouvez dans tous les cas la personnaliser :
- Basic : le template le plus simple. Vous travaillez principalement autour des tâches. Idéal pour les projets personnels par exemple
- Agile & Scrum : structure de projet classique. De nombreux éléments sont présents pour classer l’information. Le travail s’organise principalement autour des user story, des tasks et des bugs.
- CMMI : le template de projet pour les projets conséquents. Il est très complet et permet de catégoriser finement les différentes informations du projet (change request, risks, …)
Vous pouvez aussi vous référer à l’article de Microsoft sur comment choisir sont workflow pour son projet dans Azure DevOps. Je recommande aussi cet excellent article de Microsoft encore qui permet, de façon très visuelle, de voir les différences entre chaque type de projet.
L’importance d’organiser ses besoins
Un projet, et à fortiori un projet de développement, c’est avant tout réussir à proposer de la valeur à ses utilisateurs. Ne minimisez pas l’importance de cette phase : c’est vraiment la clé qui permettra votre succès ! Voici quelques problématiques auxquelles vous serez confronté :
- S’assurer de ne pas perdre l’information : beaucoup d’idées mon survenir dans le projet. Parfois ce sera une idée dans une réunion dédiée, des fois lancée sur un coin de table. Penser à tout inscrire dans le backlog, avec un maximum d’information pour plus tard. Surtout si cette idée ne sera traitée que dans plusieurs semaines !
- Optimisez vos efforts : on va y revenir dans les sections suivantes, mais il faut garder en tête que la réussite du projet vient en partie de l’optimisation du temps de l’équipe. Comment l’heure / la journée consacrée peut apporter un maximum de valeur au produit? Pour cela, il faudra garder en tête le rapport value / effort de chaque work item.
- Gérer l’urgence : une des difficultés aussi, c’est de ne pas se laisser dépasser. Chaque produit à ses défauts, ses bugs… l’important, c’est de les trouver, de les traiter, mais au bon niveau d’urgence. Tout comme le point au-dessus, la matrice Eisenhower peut être un bon allié !
- Offrir un cap à l’équipe : autant les développeurs que les directeurs, tout le monde a besoin de savoir où on va et comment on y va. Cela permet d’ajuster le cap quand nécessaire, mais surtout cela est un excellent catalyseur pour motiver tout le monde ! L’outil permet d’organiser ces points et de proposer des affichages dédiés, qu’on va voir ci-dessous.
Organiser ses sprints sur Azure DevOps Boards
Organiser les tâches du backlog entre elles
La première chose à faire une fois son backlog construit, c’est de l’organiser. Nous avions vu qu’une des différences entre les différents templates de projets, c’était la parenté entre les éléments. Nous allons nous servir de ça ici. Les exemples seront faits à partir d’un projet Agile.
En plus de la parenté directe, il est possible de mettre en place plusieurs liens entre les différents Work item pour créer le maillage que vous souhaitez dans l’organisation de votre projet. Vous pouvez ainsi définir quels sont les user story nécessaire avant d’en attaquer une en particulier, ou expliquer que ce bug est aussi lié à cette task par exemple.
Prioriser les différentes tâches
Une fois les tâches liées ensemble, il faut pondérer ces dernières afin de savoir quels sont les sujets les plus intéressants à produire. Pour rappel, les sujets à prioriser sont souvent un mélange entre la valeur apportée par la tâche, et sa complexité. Si quelque chose peut être fait rapidement et apporte une valeur importante au produit, alors il faut foncer !
La valeur vient de l’image que va renvoyer votre produit. Par exemple, une fonctionnalité que tous les concurrents ont, ou alors un bug majeur, ça peut faire tâche.. Résoudre le sujet peut avoir une importance majeure !
De l’autre côté, il faut aussi déterminer les efforts qui vont devoir être fournis pour produire une tâche donnée. Nous évoquerons dans un autre article les méthodologies permettant de faire cela. Basiquement, cela va être empirique. Cela proviendra de l’expérience du chef de projet, mais aussi de dialogue avec l’équipe de développement chargé du travail. On parlera notamment de cérémonials tels que le planning poker.
Organiser son travail futur
Une fois les tâches préparées et organisées, Azure DevOps Boards va vous permettre de les organiser dans le temps. Utilisant les méthodologies Agile (ou affiliées), on va parler ici de sprints, des itérations de développement dont la durée est fixée à l’avance et si possible, constante.
Azure DevOps Boards vous permet de gérer votre sprint, et de définir la durée de chacun de ces derniers. Une fois le premier paramétré, l’outil vous pré-remplira les dates des prochains sprints grâce à cette durée présumée fixe. Vous allez pouvoir ensuite utiliser votre backlog afin d’assigner aux sprints correspondants les différents work items.
Voir sa roadmap avec Azure DevOps
Une fois que vous avez défini vos sprints, vous voudrez peut-être avoir une vision plus macro de votre projet. Il est aussi possible que vous souhaitez planifier « grosse maille » les futurs jalons, sans forcement avoir prédéfinit les User Story et leurs planifications.
Pour cela, vous pouvez utiliser l’écran « Delivery Plan ». Cela vous permettra de créer des écrans associés à un type de Work Items, tels que les features ou les epics. Ainsi, vous aurez une vision avec un meilleur recul du plan à suivre sur le long terme.
Suivis du sprint en cours
Vos sprints sont maintenant définis ! Les développeurs vont pouvoir travailler directement via un des écrans principaux de leurs journées : l’écran « sprint ». Il est composé de plusieurs onglets, dont le premier : le Taskboard.
Présentation de la Taskboard
Le Taskboard est un tableau Kanban qui est automatiquement lié au sprint en cours. Vous pouvez néanmoins changer le sprint cible si vous le désirez.
Ce tableau liste les différentes User Story qui ont été sélectionnées afin de pouvoir travailler dessus plus efficacement. L’équipe pourra rapidement les voir, écrire les tasks associées à chacune, y définir le temps prévisionnel pour chacune, puis les faire évoluer sur le tableau Kanban.
Assigner les capacités de l’équipe
Un des points intéressant de l’écran de sprint, en plus de permettre à l’équipe de développement de s’organiser facilement, ça va être de pouvoir sortir des métriques et de piloter plus facilement le projet. Pour cela, un point important va être de paramétrer les capacités de l’équipe, c’est-à-dire leurs temps de travail.
Vous pouvez faire cela depuis l’onglet « capacity ». On y retrouve les membres de votre équipe, et pouvez ajouter d’autres profils au besoin. Vous pourrez définir ici leurs capacités de travail par jour (en heure), le poste qui leur est attribué (développeur, architecte, …) et éventuellement leurs congés.
Cela va permettre à la plateforme Azure DevOps Boards de sortir des métriques que l’on va voir ci-dessous.
Analysez le burndown chart
Une fois votre capacité d’équipe établit, ainsi que les dates de sprint et le backlog, le burdown trend va être établi par Azure DevOps. Il s’agit d’un graphique permettant de visualiser rapidement la capacité de votre équipe à produire les User Story qui auront été chiffrées (avec le planning poker par exemple).
- La ligne verte montre le nombre d’heures maximum que pourra produire votre équipe chaque jour
- La zone en bleu représente le nombre de points d’effort restant à produire. Si cette zone se retrouve au-dessus de la zone verte, l’objectif du sprint ne sera probablement pas rempli et il peut être important d’en informer les équipes métier.
Ces informations vous permettront d’ajuster le projet au fur et à mesure, de calculer une vélocité d’équipe mais aussi d’ajuster le tir et la communication si jamais on voit que se créer un effet tunnel.
L’importance de ne pas faire évoluer le scope (périmètre) d’un sprint
En tant que chef de projet, ou simplement une personne du métier, il peut être très tentant de faire évoluer le périmètre d’un sprint à la volée. Surtout qu’on parle souvent « d’agilité »… Mais même en étant agile, il y a des règles à respecter, et elles ne sont pas là pour rien. Voici quelques exemples de pourquoi un sprint doit être fixe :
- Ajouter des tâches à la volée lors d’un sprint peut décourager l’équipe. Nous leur donnons un cap clair, mais finalement on l’ajuste en cours de route. Cela donne une impression très « brouillon », ce qui est décourageant. Si le cap change trop souvent en cours de route, préférez vous organiser autour de sprint plus court (1 semaine au lieu de 2 par exemple).
- Un changement en cours de route, ça veut dire soit ne pas faire une réunion d’équipe permettant de correctement définir le périmètre et les attentes, soit prendre le risque de faire trop de réunion et avoir des interruptions en plein sprint. Et vous ne voulez ni l’un, ni l’autre.
- Ajuster un sprint à la volée ne permet pas de dégager une vélocité d’équipe, notamment à cause des deux points ci-dessus
Evidemment, il y a toujours des contre-exemples. Mais ces derniers doivent rester réellement exceptionnels ! Seul les « bugs » présente un workflow un peu particulier, car ceux-ci sont souvent capitaux à résoudre. Il est important alors d’avoir un process prenant en charge les bugs en fonction de leurs priorisations, de correctement les prioriser, et/ou d’avoir une équipe support dédiée.
Gagner en visibilité avec les Azure DevOps Boards Queries
Qu’est-ce que sont les queries ?
En principe, vous avez déjà tout ce qu’il vous faut pour organiser votre projet avec Azure DevOps Boards ! Cependant il reste un onglet qu’on a pas abordé : Queries. Et il serait bien dommage de passer à côté !
Queries va vous permettre de créer des requêtes dans la base de données d’objet d’Azure DevOps, en requêtant sur de nombreux champs des différents work items. Vous pourrez ainsi rapidement retrouver les éléments qui vous sont assignés, ceux en retard, etc. Ces requêtes peuvent être personnelles ou partagées avec l’équipe.
Comment fonctionnent les queries ?
Comme on peut le voir sur la capture ci-dessus, une requête est une combinaison de filtre qui sont composés de :
- un champ sur lequel on requête
- un conditionnel (and / or)
- un opérateur (supérieur, inférieur, « not in », « contains », etc.)
- une valeur attendue
Cette requête peut être exécutée avec « Run query » pour voir le résultat, puis enregistrée si elle convient.
Il est aussi possible de grouper les conditions afin de créer des requêtes ayant la forme [(A and B) OR (X and Y)] en regroupant les conditionnels ensemble. On peut faire des groupements sur plusieurs niveaux si nécessaire.
Enfin, il est possible de créer des requêtes permettant d’afficher une parenté avec les éléments.
Pourquoi cette fonctionnalité est centrale pour la gestion de projet ?
La fonctionnalité des requêtes est déjà utile en soi : elle vous permettra de retrouver plus facilement vos work item et de mieux vous organiser. Mais pas seulement !
Les requêtes sont aussi un élément de base permettant de créer des Dashboards (tableaux de bord) permettant de piloter le projet. Vous pourrez ainsi afficher des diagrammes, graphiques ou compteurs qui se basent sur les requêtes que vous avez produites.
L’aspect sécurité dans la gestion de projet
La sécurité est primordiale, et doit être aux centres des considérations d’un projet. Elle doit donc être réfléchie dès le départ, et donc notamment lors de la conception. Prendre en considération cet aspect tout au long de la chaîne de production du logiciel est au centre du concept de DevSecOps. Voici quelques points que vous devez garder en tête lors de l’élaboration et de la quantification de votre backlog.
Secure by design
La sécurité d’un logiciel est avant tout une histoire d’architecture. Quel que soit le type de projet (architecture, réseau, ou développement), la sécurité est toujours plus efficiente lorsqu’on la pense dès le départ. Il est plus simple de sécuriser le bâtiment d’une banque si on pense à la sécurité du coffre avant la construction, plutôt que de tenter d’améliorer la sécurité d’un bâtiment standard existant. Le logiciel, c’est pareil. C’est un des concepts portés par la notion de secure by design.
La réflexion autour d’une architecture sécurisée est donc cruciale. Elle permettra notamment d’être mieux protégé, mais aussi aux développeurs de faire moins d’erreurs et d’oublis. De plus, une architecture claire et correctement définie permet de mieux éviter les erreurs inattention lors des Pull Request comme on a pu voir dans l’article précédent.
Définir les Abuse Cases
Définir les spécifications d’un logiciel, c’est primordial. Mais si on souhaite mettre la sécurité au coeur du process, il va être important de pas seulement réfléchir à comment l’utilisateur peut se servir du logiciel, mais aussi à comment il peut le contourner. C’est ce qu’on appelle les Abuse Cases.
Le concept des Abuse Case, c’est donc de se mettre à la place d’un attaquant ou d’un utilisateur ayant des actions inappropriées qui peuvent conduire à un bug de la plateforme. Le fait de réfléchir à ces différents points à plusieurs avantages :
- Détecter les scénarios qui exposent l’application, afin de mettre en place les sécurités permettant qu’ils ne se produisent pas
- Former l’ensemble de l’équipe à la prise en considération de la sécurité, afin que cela devienne un réflexe
- Former les membres de l’équipe à des scénarios d’attaque (et donc des risques) qu’ils ne connaissaient pas
Ces Abuses Case peuvent servir à couvrir l’ensemble des points de la triade CIA permettant de protéger votre logiciel. Voici un exemple d’abuse cases pour chaque point de la triade :
- Confidentialité : si un utilisateur change l’id dans la request GET ou POST, peut-il accéder aux données d’un autre utilisateur?
- Intégrité : si un utilisateur envoie une requête forgée en tentant de modifier un objet dont il n’a pas les autorisations, y arrive-t-il?
- Disponibilité : si un utilisateur ajoute X éléments dans la plateforme, est-ce que celle-ci se met à ralentir / être indisponible?
La formation
On l’a vu plus haut, les process permettent à l’équipe de se former en apprenant les uns des autres. Mais ça implique aussi que des personnes savent, dès le départ, quelles sont les bonnes pratiques de sécurité !
Il faut donc penser à avoir la formation et la veille technologique au centre de la gestion du projet. Des ateliers doivent être organisés si possible, ainsi que des formations orientées sécurité reconnues telles que la CASE pour les développeurs, ou la CEH plus généraliste.
Azure DevOps Boards : Conclusion
Maintenant que nous avons fait une bonne review de cette section « Azure DevOps Boards », qui sert à vous accompagner sur la gestion de projet, voici mes conclusions :
- Azure DevOps est un bon outil de gestion de projet en liaison avec les développeurs, et excellent si on pense aux liaisons fortes avec la partie code et CI/CD (à traiter dans un futur article)
- Un des exemples d’utilisation puissante est la possibilité de lier le plugin Test & Feedback pour faire des remontées rapides et qualifiées de tâches et de bugs
- Il manque cependant des fonctionnalités centrales, tel que la récupération des demandes utilisateurs, et le suivi (besoin qui peut être complété avec des outils tels que ProductPlan ou UserVoice)
- Il manque aussi d’écran pour facilement pondérer les User Story et feature à forte valeur ajoutée, sur le temps. Les informations sont présentes, mais c’est très compliqué à maintenir dans le temps, et peu utile donc (bien qu’on peut se servir du combo Queries/Dashboard pour pallier légèrement à ce manque)
- Malgré ces défauts, il reste quand même un outil très puissant. Après avoir éprouvé plusieurs solutions telles que la suite Atlassian pendant plusieurs années, ou GitLab, je continue à préférer cette solution notamment par son intégration avec le cloud Azure.
- Il s’intègre pleinement dans une bonne gestion des process DevSecOps
Maintenant que nous avons vu comment gérer notre projet avec Boards et notre code source avec Repos, deux points restent à voir pour parfaire l’utilisation du produit et de notre projet : l’utilisation des pipelines pour l’intégration continue, et celle d’Overview pour rendre l’information projet plus visuelle !