Gestion de Projet

Les méthodes Agile partent du principe que spécifier et planifier dans les détails l’intégralité d’un système avant de l’implémenter (approche prédictive) est contre-productif.

Les méthodes Agile reposent sur 4 valeurs et 12 principes

Valeurs Agile

  • Les individus et leurs interactions plus que les processus et les outils.
  • Un système qui fonctionne plus qu’une documentation exhaustive.
  • La collaboration avec les clients plus que la négociation contractuelle.
  • L’adaptation au changement plus que le suivi d’un plan.

Principes Agile

  • Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
  • Accueillez positivement les changements de besoins, même tard dans le projet. Les processus agiles exploitent le changement pour donner un avantage compétitif au client.
  • Livrez fréquemment un système opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
  • Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
  • Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
  • La méthode la plus simple et la plus efficace pour transmettre de l’information à l’équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.
  • Un système opérationnel est la principale mesure d’avancement.
  • Les processus agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.
  • Une attention continue à l’excellence technique et à une bonne conception renforce l’agilité.
  • La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
  • Les meilleures architectures, spécifications et conceptions émergent d’équipes auto organisées.
  • À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.

Les méthodes Scrum, Kanban et ScrumBan sont, actuellement,  les trois principaux modes d’accompagnement dans les projets IT.

Scrum est une méthodologie Agile. Elle vise à satisfaire au mieux le besoin du « Product Owner » en l’impliquant aux différentes phases du projet. Celui-ci est responsable du « Product Backlog » (liste priorisée des « Users Stories »). Lors du « Sprint Planning », le « Product Owner », « le Scrum Master » et la « Team » définissent le « Sprint Backlog » que la « Team » s’engage à réaliser au cours du « Sprint ». Au quotidien, le « Scrum Master » se réunit avec la « Team » pour le « Daily Scrum », et la « Burn Down Chart » est mise à jour. La « Team » conclut le « Sprint » par une « Demo » du travail réalisé, puis une « Sprint Review ».

Comme on peut le constater dans ce bref résumé, la méthode Scrum est très codifiée avec des rôles, des réunions et des artefacts. La méthode Kanban (« étiquette » en japonais), issue à l’origine de la méthode mise en place chez Toyota, est fondée sur l’idée qu’il ne sert à rien de commencer ce qu’on ne pourra pas terminer. On va faire en sorte que chaque activité maximise le temps passé à ajouter de la valeur au produit tout en diminuant ou supprimant les activités n’apportant pas de valeur.

La méthode Kanban n’a pas de règles imposées mais cinq pratiques conseillées :

  • Visualiser les éléments de travail et les processus
  • Limiter le travail en cours
  • Gérer le flux de travail par la capacité disponible
  • Rendre explicite les règles de gestion du processus
  • S’améliorer de façon collective

Contrairement aux autres méthodes où la force d’avancement va de l’amont vers l’aval (on produit d’abord les éléments puis on teste ce que l’on a produit quitte à produire des files d’attente chez les testeurs) on utilise ici le « flux tiré », c’est la demande du client ou la disponibilité d’une capacité aval qui va déclencher la mise en route du travail amont. On ne va pas développer de nouvelles fonctionnalités si l’équipe de test en fin de projet est saturée et ne peut plus accepter de nouvelles fonctionnalités à tester.

A l’origine, la méthode ScrumBan a été créé dans le but de faciliter la transition des équipes Scrum vers les concepts Lean (un ensemble de pratiques qui permettent de développer les compétences des personnes) et Kanban. Combinant les meilleures pratiques de Scrum et Kanban, ScrumBan est devenu un choix majeur. C’est un excellent mélange de la nature normative de Scrum et de la méthode d’amélioration des processus de Kanban. Cette combinaison permet à une équipe d’améliorer continuellement les processus.

Scrumban se caractérise par les particularités suivantes :

  • On retrouve la « Team » et les rôles considérés comme nécessaires
  • Le « Daily Scrum Meeting » est préconisé pour être certain de rester focalisé sur les objectifs et pour revoir les tâches
  • Les « Reviews » et « Restrospective Meeting » peuvent être faits, si nécessaire, pour l’amélioration continue et le partage de connaissance
  • Il n’y a pas de notion de « Sprint », le « WorkFlow » est comme en Kanban, mais avec des limites
  • L’estimation des tâches peut être faite pour avoir une vision de la charge totale prévisionnelle
  • Les membres de l’équipe peuvent être spécialisés
  • Les changements peuvent être pris en compte immédiatement dans la To-Do liste ou en échange d’une autre tâche, sans attendre la fin d’une notion de « Sprint » qui n’existe pas
  • Le « Backlog » est constitué de tâches de toutes tailles, même si leur émission découle d’une « User Story »
  • La priorisation des tâches reste nécessaire et conseillée

Une « Vision » décrit, de façon macroscopique, les objectifs à atteindre et la ligne directrice du projet. Un « Theme » est un objectif de haut niveau qui peut très bien se trouver transversal à plusieurs projets ou produits. Un « Epic » est un groupe de « User Stories ». Un « Epic » ne peut pas être traité en tant que tel, il pourrait être vu comme une grosse « User Story » qui nécessite d’être découpée pour être prise en compte. Lorsque la « User Story » est en phase de passer en réalisation, elle doit être découpée en « Tasks » pour que les personnes techniques travaillent concrètement sur les éléments à réaliser.

La rédaction d’une « User Story » se fait en trois étapes incrémentales appelées les 3C (Card, Conversation and Confirmation).

Ces étapes assurent :

  • Une description du besoin
  • Une négociation en vue d’une définition du besoin
  • Une définition des critères d’acceptabilité

Bien qu’elle puisse être Fonctionnelle, Technique ou Corrective, une « User Story » Fonctionnelle doit être privilégiée et exprimer un point de vue utilisateur plutôt qu’un point de vue système ou technique. Ce point de vue est guidé par la réponse à ces trois questions :

  • Qui a fait la demande ou qui bénéficie de la demande ? (rôle utilisateur)
  • Quelle est la demande ? (besoin)
  • Quelle valeur métier découle de la réalisation de ce besoin ? (valeur métier)

La description d’une « User Story » suit un gabarit utilisable dans la plupart des cas :

  • En tant que (qui, rôle, persona, user type)
  • Je veux (quoi, fonctionnalité, tâche, action)
  • Afin de (pourquoi, valeur ajoutée, résultat)

Une « User Story » raconte une histoire compréhensible par tous, mais elle ne peut souvent pas être réalisée en tant que telle. Celle-ci doit s’accompagner d’une liste de règles métier et de l’ensemble des descriptions permettant de définir les tâches à accomplir.

Il convient de s’assurer que chaque « User Story » répond aux critères du modèle INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable).

  • I : Une « Story » dépendante d’une ou plusieurs autres « Stories » ne sera pas testable et ne pourra pas être validée tant que les autres n’auront pas été faites, ce qui fait porter un risque sur la capacité de l’équipe à pouvoir réaliser rapidement un incrément démontrable.
  • N : Une « Story » doit pouvoir être négociable afin de garantir à l’équipe la capacité de livrer les fonctionnalités répondant le plus aux attentes et permettant également de respecter le « Time to market ».
  • V : Une « Story » n’ayant pas de valeur business pour le métier n’apporte aucune plus-value au produit.
  • E : L’estimation d’une « Story » est importante, car elle permet à l’équipe d’identifier l’effort à fournir et de garantir une granularité cohérente entre les « User Stories », aidant à une meilleure mesure de la prédictibilité.
  • S : Une « Story » trop grosse en effort et en taille met en risque sa réalisation dans un délai court et sa compréhension par l’équipe.
  • T : Une « Story » ne possédant pas l’ensemble des cas de tests à passer pour la valider ne pourra être développée et validée en garantissant être en adéquation avec le besoin exprimé.

Lors des négociations autour d’une « User Story », il faut également évoquer les critères d’acceptabilité d’une « User Story » (Acceptance Criteria). C’est la définition des tests qui permettra de déterminer qu’une tâche appartenant à une « User Story » peut être considérée comme « Done ». La définition de « Done » est un élément primordial pour passer une tâche dans la dernière colonne du « Board ».

Les tests TDD (Test Driven Development) sont centrés sur les tests unitaires, généralement automatisés, placés sous la responsabilité technique de l’équipe. L’idée consiste à écrire le test avant de réaliser la tâche et non l’inverse.

Le cycle préconisé pour utiliser un TDD comporte cinq étapes :

  1. Écrire un test
  2. Vérifier qu’il échoue (car la configuration qu’il teste n’existe pas), afin de vérifier que le test est valide
  3. Écrire juste la configuration suffisante pour passer le test
  4. Vérifier que le test passe
  5. Puis améliorer la configuration, c’est-à-dire l’améliorer tout en gardant les mêmes fonctionnalités

Les tests d’acceptation ATDD (Acceptance Test Driven Development) sont des tests orientés client, qui renvoie à l’utilisateur la responsabilité de définir les critères de contrôle.

L’utilisation du concept de « Behaviour Driven Development » (BDD) intègre certains concepts de TDD. C’est un langage métier qui permet de compléter la « User Story » en décrivant des comportements sous forme de tests auto-suffisants en langage Gherkin (Given / When / Then).

Le gabarit communément utilisé sur les BDD est le suivant :

  • Étant donné (description du contexte)
  • Lorsque (l’action)
  • Alors (le résultat)

BDD se concentre sur l’aspect comportemental du système contrairement à TDD qui se concentre sur l’aspect de mise en œuvre du système. ATDD se concentre sur le recueil des exigences dans les tests d’acceptation et les utilise pour piloter le développement du système qui fait ce pour quoi il est conçu. BDD est axé sur le client tandis qu’ATDD se penche vers le côté équipe de déploiement, comme le fait TDD. Cela permet une collaboration beaucoup plus facile avec les parties prenantes non-techniques, que TDD. Les outils et les techniques TDD sont généralement de nature beaucoup plus technique. BDD donne une meilleure compréhension de ce que le système devrait faire du point de vue du concepteur et du client. TDD permet une bonne et robuste conception, même si les tests peuvent être très loin des exigences des utilisateurs. BDD est un moyen d’assurer la cohérence entre les exigences et les tests des concepteurs.

L’automatisation des tests est un élément clé de l’application d’une méthode Agile dans le cadre d’une Infrastructure IT. Le domaine de l’Automation » bien connu maintenant dans le monde du système (OpenStack, Puppet, Chef, Ansible, Git…) est applicable en tout ou partie aux infrastructures réseaux.

La gestion de la priorisation des « User Stories » peut être effectuée facilement à l’aide de l’outil MoSCoW :

  • Must : identifie ce qui est indispensable pour que le système soit opérationnel, indépendamment de tout confort.
  • Should : identifie ce qu’il faudrait vraiment avoir pour que le système soit utilisable dans de bonnes conditions.
  • Could : Introduit un confort d’utilisation pour faciliter l’expérience des utilisateurs finaux.
  • Won’t : identifie des options qui seraient sympathiques, mais que, lucidement, on n’aura pas le temps/budget de réaliser.
Exemple de correspondance
Must P3
Should P2
Could P1
Won’t P0

En Agilité, il existe deux types d’appréciation d’une « User Story » : la complexité et la valeur. La complexité adresse la difficulté, le temps de réalisation et le risque liés à un scénario pour l’équipe. A risques égaux, un scénario très complexe, mais qui requiert peu de temps pour être effectué pourrait avoir le même nombre de points qu’un scénario simple, mais qui serait long à réaliser, car c’est l’effort total devant être déployé pour terminer le scénario qui est évalué et non un seul de ces aspects.

Communément, on utilise un jeu de cartes composé de la suite de Fibonacci pour évaluer la complexité en faisant une partie de « Planning Poker » (pratique issue de la méthode « eXtrem Programming » et qui est une dérivation de la technique « Wideband Delphi ») afin d’attribuer des « Story Points ». La suite de Fibonacci (mathématicien italien) est une suite d’entiers dans laquelle chaque terme est la somme des deux termes qui le précèdent. Elle commence généralement par 0 et 1, avec comme premiers termes : 0, 1, 1, 2, 3, 5, 8, 13, etc. Cette suite est fortement liée au nombre d’or, φ (phi ≈ 1,61803398). En effet, le rapport de deux nombres consécutifs de la suite est alternativement supérieur et inférieur au nombre d’or : [latex]\frac{1+\sqrt{5}}{2}[/latex]

Certains utilisent d’autres méthodes d’évaluation comme une suite standard de nombres ou encore les grandeurs de tee-shirt (XS, S, M, L, XL, XXL). L’important, c’est que cela parle à l’équipe et qu’elle se sente à l’aise avec la méthode utilisée.

Les « Story Points » sont utilisés pour les « User Story » et uniquement pour la planification relative d’un « Sprint » et donc le calcul de la vélocité. Cette mesure est approximative et il est souhaitable qu’elle le reste. Il ne s’agit pas ici de traiter de la charge en heures ou en jours, ça n’aurait aucun sens d’autant plus que ce serait certainement faux. Les heures sont utilisées pour quantifier le temps qu’il faut par tâches. Ce sont deux mesures complémentaires mais qui ne sont pas utilisées par les mêmes personnes et pas pour les même raisons.

La valeur métier d’une « User Story » peut être difficile à estimer. On peut considérer que sa valeur est proportionnelle aux nombre de parties prenantes ou « Stakeholders » qui la demandent. On peut également estimer sa valeur en termes de risque de ne pas faire. Cette dernière s’applique souvent pour les cas qui découlent d’obligations réglementaires, mais on peut l’étendre à n’importe quel type de « User Story ». La notion de valeur est souvent rapprochée de la notion de priorité lorsqu’on ne sait pas donner un chiffre à cette valeur.

La définition de la limite du travail en cours (Work In Progress) se déterminera et s’affinera en fonction de la taille de la « Team », de son expérience et de sa montée en charge sur le projet. Il convient de s’inspirer du concept DevOps qui cherche à fusionner les équipes de développement et d’exploitation, ayant des objectifs différents pour ne pas dire antinomiques, au sein d’une même équipe. L’objectif est d’améliorer l’efficacité en faisant communiquer les équipes de conception et les équipes opérationnelles tout en mutualisant leurs compétences.

La méthode ScrumBan utilise les indicateurs proposés par Kanban, tels que le « Cycle Time » (temps nécessaire à la réalisation d’une tâche, de la phase d’initialisation à la phase de tests inclue) et le « Lead Time » (mesure du temps total de passage d’une tâche dans le « Board », de son entrée – « Backlog » – à sa sortie – « Done » -).

La mise en place d’un outil informatique de gestion du « Board » facilite la vision des tâches à accomplir, de l’état actuel du travail en cours et présente automatiquement des indicateurs en fonction des éléments saisis pour chaque tâche. KanBoard est un exemple d’outil Open Source auto-hébergeable.

L’utilisation d’une méthode Agile ne recommande pas l’absence de documentation, mais le juste niveau nécessaire à la bonne compréhension du besoin. La mise en place d’un Wiki est une approche permettant de tenir une documentation centralisée, toujours à jour et partagée de tous les membres du projet.

Story Mapping
Story Mapping

Licence

Partagez ce livre