Gestion de projet en mode agile

Le développement logiciel

Le développement d’un logiciel a toujours été une tâche complexe impliquant de nombreuses personnes issues de différents métiers :

De nombreuses méthodes ont été créées pour organiser les différentes tâches à réaliser pour mener à bien un projet.

La méthode de gestion de projet waterfall, ou « en cascade »

Une des plus anciennes méthode de gestion de projet informatique. Elle consiste à passer par une liste d’étapes prédéfinies de façon séquentielle.

waterfall

Avantages de la gestion de projet en cascade

Inconvénients de la gestion de projet en cascade

Variation sur le projet en cascade : le cycle en V

Le cycle en V est devenu un standard de l'industrie du développement de logiciel et de la gestion de projet depuis les années 1980. Chaque étape montante vérifie le travail d’une étape descendante.

cycle en v

Variation sur le projet en cascade : le cycle semi-itératif

On conserve le cycle en V dans sa partie descendante (création de spécification) par contre la partie montante (codage et test) est réalisée en plusieurs étapes (itérations). On ne va pas livrer le logiciel complet mais on va découper les livraisons en différentes releases.

Les méthodes agiles

La lourdeur qu’implique les méthodes en cascade ne donnait pas de résultat satisfaisant au niveau de la qualité du logiciel.

Trop de logiciels en retard et qui ne correspondaient plus au besoin du client.

Les méthodes agiles permettent de s’adapter plus facilement au besoin du client même si un changement intervient en cours de développement.

Un groupe de personnalités du monde de l’informatique a défini ce que doit être une méthode agile.

Ils ont écrit un manifeste.

Extrait du manifeste :

Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. Ces expériences nous ont amenés à valoriser :

Avantages de travailler en mode agile

Désavantage des méthode agiles

Les différentes méthodes agiles

A partir des concepts très simples du manifeste certaines personnes ont développé des méthodes pour construire une façon de travailler « agile ».

Les méthodes sont toutes différentes. Elles définissent un cadre plus contraint que le manifeste agile.

Les principales méthodes

Scrum

Scrum (mêlée) est certainement la méthode agile la plus populaire, elle a été créée en 1993. C’est une méthode itérative pour construire des logiciels complexes.

Scrum définit une méthode simple pour travailler en mode agile.

Les principes fondamentaux de Scrum

Le processus Scrum commence par la définition du backlog de produit. Il définit toutes les fonctionnalités du système à développer.

A partir de ce backlog de produit l’équipe va choisir les fonctionnalités à développer pendant un sprint Un sprint est une période de 2 à 4 semaines pendant laquelle l’équipe va développer les nouvelles fonctionnalités.

Les fonctionnalités à développer sont classées dans un document le backlog de sprint

A la fin du sprint une revue est effectuée avec les membres de l’équipe pour améliorer le processus.

scrum

Chaque sprint commence par une réunion de planification appelée Sprint planning. A l’issue de cette réunion, l’ensemble de l’équipe connaît et comprend l’objectif du Sprint et chaque besoin, qui doit être adressé dans le Sprint, est décomposé en tâches.

Durant le sprint, chaque membre de l’équipe prend une et une seule tâche dans le pool de tâches les plus prioritaires et effectue celle-ci.

A heure fixe, un Daily Scrum (mêlée quotidienne) est effectué.

En fin de Sprint, les besoins réalisés durant le Sprint sont montrés à travers l’utilisation du logiciel pendant une démonstration.

Les principaux rôles

Le product owner (PO)

Le Scrum master

Les membres de l’équipe

L’équipe est auto-gérée, il n’y a pas de manager, ni de chef de projet dans une équipe Scrum.

Les membres de l’équipe s’assignent eux-mêmes les tâches à réaliser.

Il ne doit pas avoir de spécialistes. Tout le monde doit pouvoir intervenir sur toutes les tâches.

Il n’y a pas de notion de junior/senior. Chaque membre de l’équipe a la même importance.

Le backlog de produit

Le backlog de produit est constitué de toutes les tâches à réaliser pour le projet. Avec Scrum il y a trois niveaux de tâches : les epics qui contiennent des user stories qui elles-mêmes contiennent des tasks.

La plupart du temps le backlog de produit contient les user stories et les tasks sont définies par les développeurs.

Les « user story » ont souvent un formalisme particulier. Par exemple:

En tant que <type d'utilisateur> , je souhaite <objectif> pour pouvoir <avantage visé>.

Exemple : En tant qu’administrateur je peux ajouter un nouvel adhérent à une association.

La grille des critères INVEST permet de juger de la qualité d'une User Story.

Exemple de user story:

Epic: En tant qu’enseignant je peux noter les élèves pour construire le bulletin de notes
User story 1: En tant qu’enseignant je souhaite créer un devoir pour noter les étudiants d’une classe.
User story 2: En tant qu’enseignant je souhaite ajouter des notes à chaque étudiant de la classe pour un devoir.

Les récits utilisateurs ne font pas partie du Scrum framework.

Les users stories doivent être indépendantes, elles ne doivent pas être liées entre elles.

Les users stories ne doivent décrire que des taches fonctionnelles en rapport avec le client.

Si l’équipe technique veut décomposer la user story pour décrire les aspects techniques elle doit créer des tâches. Les tâches sont facultatives.

Les users stories : acceptance criteria

Chaque user story doit être accompagné de critères d’acceptance.

Les critères d’acceptance permettent de créer les tests qui vont faire passer la user story à l’état « terminé ». Les tests peuvent être manuels ou automatisés.

User story 1: En tant qu’enseignant je souhaite créer un devoir pour noter les étudiants d’une classe.
Critères d’acceptance : Un bouton « devoir » est présent sur la page principale. Une zone de saisie permet la saisie du nom du devoir. Un bouton « ajouter » crée le nouveau devoir.

La matrice Given-When-Then issue du BDD est un format recommandé pour le test fonctionnel d'une User Story:

(Given) (Etant donné) un contexte,

(When) (Lorsque) l'utilisateur effectue certaines actions,

(Then) (Alors) on doit pouvoir constater telles conséquences

Cette trame pour écrire les tests peut être intéressante pour avoir le même langage entre le différents intervenants.

Etant donné que je suis connecté en tant qu’enseignant.

Quand je clique sur le bouton « devoir »

Alors une fenêtre apparait avec une zone de saisie pour saisir le titre du devoir et un bouton « OK »

Le backlog de produit

Le backlog de produit contient les users stories et les critères d’acceptance mais il contient aussi d’autres champs : la priorité et l’estimation. La priorité définit le niveau d’importance, les tâches les plus importantes doivent être réalisées en premier. On peut utiliser Excel pour construire le backlog de produit.

backlog de produit

Estimation d’une user story

Pour chaque user story on doit estimer l’effort avec des « story point » .

On ne donne pas d’estimation en heure des story points mais on utilise d’autres échelles. La taille des vêtements ou une pseudo suite de Fibonacci.

Les story points notent l'effort relatif du travail selon la suite de Fibonacci : 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100. On utilise la suite de Fibonacci pour éviter de trop rentrer dans le détail des estimations.

Le planning poker

Le Product Owner n’est pas capable d’estimer l’effort pour chaque tâche. C’est l’équipe entière qui va donner une estimation pendant la réunion de préparation du sprint.

  1. Le modérateur lit la description de l’histoire utilisateur (« user story ») ou fonctionnalité que l’équipe doit estimer. Le product owner peut fournir des clarifications sur la fonctionnalité. Chaque membre de l’équipe est doté d’un jeu de cartes.
  2. Chaque membre de l’équipe choisit une carte dans son jeu qui correspond à son estimation initiale de l’effort de développement. Chaque membre de l’équipe pose sa carte à l’envers sur la table pour ne pas influencer les autres.
  3. Quand toutes les évaluations sont sur la table, les cartes sont retournées.

poker planning

Réunion de début de sprint

Au début de chaque sprint une réunion est organisée avec tous les membres de l’équipe pour décider des fonctionnalités à développer pendant le sprint.

Le Product Owner indique les fonctionnalités qu’il veut développer, ce sont les user stories avec la plus haute importance, l’équipe dit ce qu’il est possible de faire. Le Product Owner décrit les fonctionnalités clairement et un dialogue s’installe avec l’équipe.

Un planning poker peut être organisé s’il n’y a pas d’accord sur les estimations des tâches.

A la fin de la réunion le backlog de sprint est créé. La réunion ne doit pas durer plus de 8 heures pour un Sprint d’un mois !

Estimation de la vélocité

Avec le planning poker on a estimé la durée de chaque tâche avec des story points. Reste à déterminer le nombre de points que l’équipe est capable de réaliser pendant un sprint.

Seule l’expérience permet de définir le nombre de points que l’équipe peut réaliser pendant un sprint. C’est la vélocité de l’équipe.

Le meeting quotidien (daily meeting)

Chacun répond à 3 questions :

Pendant le sprint

Une fois le sprint lancé l’équipe ne doit plus être dérangé et ne doit plus accepter de nouvelles tâches ou des modifications dans le backlog de sprint.

Tous les jours les membres de l’équipe participent au daily meeting.

Chaque membre choisit une des user story qu’il veut réaliser.

Après la réalisation de la user story il met à jour le Scrum board.

Le sprint peut être annulé si les objectifs à atteindre ne sont plus pertinents.

Le scrum board

Chaque user story du backlog de sprint est recopié sur un tableau mural. Les colonnes ne sont pas définies par Scrum. On peut ajouter toutes les colonnes qui semblent nécessaires.

scrum board

Sprint Burndown chart

Pour s’assurer que l’avancement du projet est correct pendant le Sprint on peut créer un Sprint Burndown Chart. Sur l’axe-X on met le nombre de jours du sprint. Sur l’axe Y on indique les story points. A chaque fois qu’une user story est complétée on ajuste le graphique.

burndown chart

On peut utiliser Excel pour générer le graphique. Le graphique permet de calculer la vélocité de l’équipe. on pourra ainsi ajuster le nombre de user stories à réaliser durant le prochain sprint.

burndown chart excel

Sprint Review

Le sprint aboutit à la création d’un logiciel exécutable. On peut donc organiser une démonstration où toutes les fonctionnalités sont montrées au client.

But: Montrer et discuter des nouvelles fonctionnalités

Présence :toute l’équipe, le client, le PO et le Scrum Master, membres d'autres équipes

Rétrospective de sprint

A la fin de chaque sprint une réunion est organisée pour faire le point sur le sprint qui vient de se terminer.

Objectif : améliorer le prochain sprint.

Contenu : cette réunion s’intéresse au comportement de l’équipe et à ce qui peut être amélioré plutôt qu’au produit en lui-même.

Présence : toute l’équipe

1ère partie : ce qui a fonctionné

2ème partie : ce qui n’a pas fonctionné

Les releases

Chaque user story doit être fonctionnelle.

Chaque sprint aboutit à la création d’un exécutable.

L’exécutable de fin de sprint n’aboutit pas forcément à un logiciel complet qui peut être envoyé au client. Une release aboutit à la création d’un logiciel pouvant être livré au client.

Une release regroupe plusieurs sprints.

release scrum

Risques liés à Scrum

Une autre méthode agile : Kanban

Kanban est un mot japonais qui veut dire « carte ». La méthode Kanban a été inventée par Toyota pour ses usines de voitures dans les années 50.

Le principe de Kanban est plus simple que Scrum car il ne préconise qu’un seul outil : le tableau Kanban.

Le tableau Kanban est très proche du tableau Scrum.

Un tableau kanban classique comporte un workflow en trois étapes : « à faire », « en cours » et « terminé » (on peut ajouter d’autres colonnes).

board kanban

Les spécificités de Kanban

scrum vs kanban

Avantages/inconvénients Kanban

Les outils

Les tableaux et les graphiques peuvent être réalisés en version papier ou en version informatique avec des outils simples comme Excel ou Trello.

Le manifeste Agile préconise : « Les individus et leurs interactions plus que les processus et les outils ».

Ils existent néanmoins une multitude de sociétés qui proposent des outils pour gérer les backlogs, les scrums boards, les bugs…

Travailler en mode agile pour le développeur

Scrum et Kanban ne s’intéressent pas à la partie technique de réalisation du logiciel.

Une autre méthode agile : eXtreme Programming

La méthode XP pour eXtreme Programming accorde beaucoup plus d’importance à l’aspect programmation que les autres méthodes qui sont surtout concentrées sur l’aspect gestion de projet. Les principes restent les mêmes que pour Scrum.

extreme programming 1

extreme programming 2

XP s’intéresse beaucoup plus à la façon de coder que les autres méthodes. Les règles sont strictes.

Programmer en mode agile

Travailler en mode agile implique de sortir un grand nombre de versions dans un minimum de temps. Tout ceci ne peut se faire sans une automatisation des processus.

Cela a un effet sur la façon de travailler du programmeur.

Le rôle du programmeur en mode agile

Les tests unitaires

Un test unitaire est méthode qui provoque l’exécution d’une autre méthode et qui analyse le résultat. Les caractéristiques d’un test unitaire sont les suivantes:

Il existe de multiples frameworks pour chaque langage pour effectuer des tests unitaires : Junit, xUnit, phpUnit, mocha, Jasmine…

Les tests fonctionnels

Les tests fonctionnels aussi appelés tests d’acceptance permettent de tester la fonctionnalité dans son ensemble. Ils permettent de s’assurer que les critères d’acceptance sont bien respectés.

Ils peuvent être effectués à la main mais la tendance est à l’automatisation de ces tests.

Pour le web on peut utiliser des outils comme Selenium, PhantomJS…

Utilisation de selenium IDE

Selenium IDE est un outil disponible seulement sur Firefox pour tester l’aspect fonctionnel des sites web.

selenium

Un outil pour créer des tests automatisés

Le principe est de travailler en BDD (Behaviour Driven Development). Chaque user story a des critères d’acceptance décrits avec Gherkin. Un outil comme Cucumber va permettre de d’automatiser les tests écrits en langage simple. https://cucumber.io/

Exemple d'utilisation de Cucumber avec Selenium

    @Given("^that seleniumhq.org is available$")
    public void that_seleniumhq_org_is_available() throws Throwable {
        seleniumHQPage = new SeleniumHQ(driver);
    }

    @When("^I read the documentation about page objects$")
    public void I_read_the_documentation_about_page_objects() throws Throwable {
        seleniumHQPage.goToDocumentationPage();
        documentationPage = new Documentation(driver);
        actualPageTitle = driver.getTitle();
    }

    @Then("^I should see the title \"([^\"]*)\"$")
    public void I_should_see_the_title(String expectedTitle) throws Throwable {
        assertEquals(expectedTitle, actualPageTitle);
                }

L’intégration continue

Le but de l’intégration continue est d’automatiser les différentes étapes du développement jusqu’à la mise en production.

Le but est de construire le logiciel automatiquement.

Le code est archivé par le développeur sur une repository central, le logiciel est construit par un serveur de build puis les tests sont lancés. Des emails sont envoyés automatiquement pour indiquer le résultat des tests.

Le déploiement continu

Le déploiement continu est la suite logique de l’intégration continue.

Le déploiement continu prend le logiciel et le place automatiquement sur le serveur de production avec le minimum d’interventions humaines.

Les outils pour faire du déploiement continu

Il y a 6 grandes phases pour mettre en place un déploiement continu.

Conclusion

Les méthodes agiles sont difficiles à mettre en place au sein des entreprises. On reste souvent avec le couple chef de projet/manager. Difficile de modifier les habitudes. Au niveau des équipes on reste aussi dans le classique, l’équipe qui s’occupe des spécifications, les développeurs, les testeurs…

Beaucoup d’entreprises essayent de tordre Scrum pour l’adapter à leur architecture et à leurs outils. On ajoute alors un Tableau Scrum et des réunions quotidiennes à une structure classique de management. On utilise le gestionnaire de bugs pour gérer les user stories.

Le problème vient de la facilité et en même temps du manque de flexibilité des concepts Scrum. On peut comprendre Scrum en 2 heures mais l’application dans un véritable projet est difficile. Il est à noter qu’il y a d’ailleurs très peu d’exemples complets disponibles sur Internet.

La difficulté de Scrum est dans les détails.

Que faire de son équipe de test ?

Que faire des bugs trouvés par d’autres équipes sur une ancienne release ?

La volonté des entreprises est clairement de passer en mode « agile » c’est-à-dire de sortir des versions plus rapidement et en adéquation avec les besoins du client.

La démarche qu’implique Scrum est néanmoins difficile à mettre en place.

On reste souvent au niveau de l’entreprise sur des rapports hiérarchiques plutôt que sur des rapports de collaboration. En février 2018 sur le site monster.fr on peut trouver les offres suivantes :

Nous recherchons, dans le cadre de nos besoins clients, des profils Scrum Master ou Chef de Projet maîtrisant la méthodologie Scrum.

Le terme « chef de projet » reste beaucoup plus valorisant que PO ou Scrum Master.