Azure Devops : Complet et accessible

Azure Devops, c’est la solution que nous utilisons actuellement. Dans cet article voyons un rapide tour du propriétaire.
Nous nous concentrerons sur la partie “Gestion de projet”.
Tout d’abord, Azure Devops, c’est une solution complète pour gérer vos projets informatiques de la gestion de projet, au code, aux tests, jusqu’au déploiement. Tout ceci de manière simple, complète et efficace.

Je reviendrai certainement plus en détails sur certaines parties dans d’autres articles.

Petit retour en arrière

Il y a quelques années, lors du passage d’une organisation projet classique à une organisation Agile, je me suis posé la question de l’outil.

On est d’accord, ce n’est absolument pas la première question à se poser! Mais malgré tout on y vient assez vite.

Le processus de choix final s’est organisé de la manière suivante :

• Expérimentation au tableau (rien de mieux pour commencer sur les méthodes Agiles,
• Utilisation de Trello : Excellent pour commencer à toucher un Kanban, la base de la base
• Choix de la solution définitive. Nous avions déjà comme outil de gestion de code TFS, pourquoi ne pas aller plus loin avec ?

En 2011, TFS 2010 était par contre loin d’être agréable à utiliser et niveau compréhension du produit, configuration… peut mieux faire.

En 2016, nous avons découvert l’offre cloud, et là, tout était plus simple :

• Outil plutôt agréable
• Possibilité de boucler un cycle Devops (on en était bien loin!)
• Intégration avec notre gestion de code source

Depuis la plateforme évolue constamment (sprints mensuels) et propose une expérience simple, compréhensible et en adéquation complète avec nos besoins.

Retour au présent.

Scrum, Kanban : tout est dedans

Première chose à savoir, Azure Devops intègre tout ce qu’il faut pour ses deux méthodologies. Il est possible pour cela de choisir un modèle pré défini et de commencer (la partie code, pourquoi ne pas démarrer avec GIT?).

Rentrons dans le vif du sujet.

Le board / Backlog : vision globale du projet

C’est dans cette section que l’on peut gérer la globalité de son backlog.

L’on a une vue en mode kanban, personnalisable (couleurs, colonnes, capacité, champs à afficher…). Permet d’avoir une vue globale sur l’avancement du projet en Scrum et de gérer tout simplement son projet si l’on reste sur un mode Kanban.

Une vue sous forme de liste, “backlog”, qui permet d’organiser son backlog, de mapper ses stories entre elles, de créer des hiérarchies (features, epics), de planifier facilement sur un sprint…

Ces vues sont principalement utilisées par le Product Owner (PO) et le proxy PO pour organiser le projet et les sprints. Ce travail est essentiel pour choisir les bonnes directions et avoir la bonne vision sur les stories prioritaires.

Sprint Backlog : suivi opérationnel des sprints

Pour les projets en Scrum essentiellement. Permet de gérer sses sprints

Encore une fois on retrouve une vue graphique et une vue liste :

• Taskboard : C’est la vue la plus utile. Affiche toutes les informations nécessaires pour gérer les tâches à réaliser pour chaque story du sprint.
  L’affichage personnalisable (avancement de chaque tâche), couleurs personnalisables, champs à afficher personnalisable… . De quoi en faire SON tableau.
• La vue liste permet de réorganiser les stories en elles, de faire du classement de changer des informations par lot… . Pratique, mais moins lisible au jour le jour.

Ici, c’est le quotidien de l’équipe en générale et surtout de la dev team. Permet à chacun de gérer son travail.
Pour le PO et le Proxy PO, c’est également une vue permettant de voir le déroulé du sprint.

Remarque importante, sur chaque élément (story, tâche…) il est possible de chatter avec ses collègues. C’est bien fait, interactif mais ne remplace pas le face à face non plus.

Dashboard : Synthèse du projet

Besoin de statistiques, de graphiques, de résumés sur telle ou telle information? C’est ici que ça se passe!

Vous pouvez ici composer une (ou plusieurs d’ailleurs) page avec un système de widgets.

Microsoft en propose beaucoup en standard (Burn down, requêtes de votre choix, membres de l’équipe…) de quoi proposer une espace de synthèse avec les bons indicateurs pour chacun.

Le dashboard n’est certes pas l’espace le plus utilisé par l’équipe, mais il permet de prendre du recul sur l’activité et voir la santé du projet. Beaucoup utilisé par le Proxy PO et le Scrum master chez nous.

Liaison avec le code efficace

Un grand classique pour lequel je ne m’éterniserai pas : il est possible de lier une story, une tâche à son code généré par le dev team.

Permet de garder un historique des travaux et un lien entre la définition du besoin et le réalisé.

La personnalisation, un réel point fort

Ce que j’ai fortement apprécié dans cet outil, c’est le fait de pouvoir en faire SON outil.

Un peu comme une méthodo Agile, il faut respecter le cadre, mais il est possible d’apporter sa touche personnelle, en fonction de son contexte de travail.

Il est ainsi possible de :

• Personnaliser les dashboards,
• Changer les différents statuts
• Modifier les champs à saisir dans une story, une tâches… (et donc d’en ajouter au besoin!)
• Faire des requêtes sur le backlog de manière simple et intuitive
• Modifier les affichages (codes couleurs, champs à afficher ou non…)
• De modifier le comportement global en créer son propre modèle de projet (à partir d’un existant)

https://dsm.cletj.com/wordpress/azure-devops-rendre-son-backlog-intuitif-et-agreable/

BI quand tu nous tiens!

Pour aller plus loin sur les analyses, il est possible de créer des rapports directement en lien avec Azure Devops.

Il faut pour cela créer une Analytic View. Aprés cela via power BI tout est simple.

Nous utilisons Power BI pour produire des rapports consolidés sur tous nos projets. Par exemple des statistiques type “portefeuille de projet” pour notre manager.

Excel is back!

Nous avons l’habitude de dire en interne “Excel c’est le mal!”. Pourquoi parce qu’en entreprise, cela participe beaucoup à l’éclatement des données sur chaque poste de travail. Beau sujet pour un article d’ailleurs!

Dans le cas de Devops, c’est une sacrée force. Avec notre cher ami Excel, il est possible d’ouvrir des requêtes directement préparées dans Devops. Pas mal, mais surtout cela permet d’éditer en masse des stories et autres éléments.

https://dsm.cletj.com/wordpress/utiliser-excel-avec-azure-devops/

Pour le coup, il est facile de changer tout un lot de stories sur un autre sprint, de changer en masse des efforts, des business values, voir même de rajouter facilement des stories. Rapide, facile et puissant.

Wiki : Pourquoi se contenter d’une doc statique?

Le principe du wiki est validé depuis des années. Ici, Devops en propose un intégré pour chaque projet.

Ce wiki est complet et accessible pour les membres de l’équipe. Bien pour stocker la documentation fonctionnelle et technique.

Cependant, nous avons soulevé un point négatif : les informations à intégrer dans le wiki ne doivent pas forcément être partagées que par l’équipe projet. Et là on trouve des limitation sur le partage par exemple au support, à certains utilisateurs… .