Tests automatisés d’api avec Karate

Dans le cadre de nos projets, nous sommes régulièrement amenés à définir et à développer des API et des services REST.

Nous avons à plusieurs reprises fait le choix d’utiliser Karate pour réaliser des scénarios de tests automatisés sur ce type de projet.

Karate est idéal pour mettre au point rapidement une série de tests représentant des enchaînements d’appels de services REST, de plus il s’intègre parfaitement avec l’ outil d’intégration continue Jenkins.

Nous allons voir comment écrire et organiser des scénarios de tests avec Karate, ainsi que son intégration à Jenkins.

Posons le contexte

Pour illustrer la réalisation de tests automatisés avec Karate, prenons l’exemple d’une api permettant à un client d’acheter des produits et de payer via une de ses cartes de paiements.

Notre api permet donc à nos clients:

1 – de créer un panier

POST /carts

2 – d’ajouter des produits dans le panier

POST /carts/{{cartId}}/items
{
  "itemId": '#(itemId)'
}

3 – de modifier la quantité des produits du panier

PUT /carts/{{id}}/items/{{itemId}}
{
  "quantity": '#(quantity)'
}

4 – de consulter son panier

GET /carts/{{cartId}}

5 – de récupérer ses moyens de paiements

GET /carts/{{cartId}}/wallet

6 – de payer le panier

POST /carts/{{cartId}}/payment?cardId={{cardId}}

Réalisons les scénarios réutilisables

Pensons réutilisabilité et commençons par créer 6 fichiers feature contenant chacun un scénario correspondant à une requête vers notre api.

Pour chaque requête, nous enregistrons le code de retour http et la réponse afin de pouvoir y accéder ultérieurement.

1 – Créer un panier

Fichier: createCart.feature

Feature: API - createCart

  Scenario: create a cart
    When url BASE_URL + '/carts'
    And request {}
    And method post 
    * def statusCode = responseStatus
    * def body = $

Ce scénario effectue une requête http POST sur /carts

2 – Ajouter des produits dans le panier

Fichier: addItemToCart.feature

Feature: API - addItemToCart

  Scenario: add an item to a cart
    When url BASE_URL + '/carts/' + cartId + '/items'
    And request
    """
    {
      "itemId": '#(itemId)'
    }
    """
    And method post
    * def statusCode = responseStatus
    * def body = $

Ce scénario effectue une requête http POST sur /carts/{{cartId}}/items

Il a deux paramètres:

  • cartId: identifiant du panier
  • itemId: identifiant du produit à ajouter au panier

3 – Modifier la quantité des produits du panier

Fichier: updateCartQuantity.feature

Feature: API - updateCartQuantity

  Scenario: update cart item quantity
    When url BASE_URL + '/carts/' + cartId + '/items/' + itemId
    And request
    """
    {
      "quantity": '#(quantity)'
    }
    """
    And method put
    * def statusCode = responseStatus
    * def body = $

Ce scénario effectue une requête http PUT sur /carts/{{id}}/items/{{itemId}}

Il a trois paramètres:

  • cartId: identifiant du panier
  • itemId: identifiant du produit à mettre à jour
  • quantity: nouvelle quantité pour le produit à mettre à jour

4 – Consulter son panier

Fichier: retrieveCart.feature

Feature: API - retrieveCart

  Scenario: retrieve a cart
    When url BASE_URL + '/carts/' + cartId
    And request {}
    And method get
    * def statusCode = responseStatus
    * def body = $

Ce scénario effectue une requête http GET sur /carts/{{cartId}}

Il a un paramètre

  • cartId: identifiant du panier

5 – Récupérer ses moyens de paiements

Fichier: getWallet.feature

Feature: API - getWallet

  Scenario: get wallet
    When url BASE_URL + '/carts/' + cartId + '/wallet'
    And request {}
    And method get
    * def statusCode = responseStatus
    * def body = $

Ce scénario effectue une requête http GET sur la ressource /carts/{{cartId}}/wallet

Il a un paramètre

  • cartId: identifiant du panier

6 – Payer le panier

Fichier: postPayment.feature

Feature: API - postPayment

  Scenario: Pay a cart
    When url BASE_URL + '/carts/' + cartId + '/payment'
    And param cardId = cardId
    And request {}
    And method post
    * def statusCode = responseStatus
    * def body = $

Ce scénario effectue une requête http POST sur /carts/{{cartId}}/payment

Il a deux paramètres

  • cartId: identifiant du panier
  • cardId: identifiant de la carte de paiement

Réalisons les scénarios de tests

Commençons par créer un nouveau fichier « feature » avec un block « Background » permettant de rejouer des instructions avant chaque scénario. Ici les instructions du block « Background » correspondent à la création d’un panier. Nous utilisons l’instruction call pour réutiliser les scénarios précédemment créés. Afin que l’identifiant du panier soit visible dans tous les scénarios, nous l’enregistons dans une variable cartId.

Feature: API

  Background:
    When def createCartResult = call read(createCart)
    Then match createCartResult.statusCode == 200
    * def cartId = createCartResult.body.id

Ajoutons un scénario qui vérifie simplement la bonne création d’un panier. La création du panier est effectuée dans le block Background, il est donc inutile de répéter cette opération dans le scénario.

  Scenario: Create a cart
    Then match createCartResult.body.status == 'IN_PROGRESS'
    And match createCartResult.body.items == []

Ajoutons un scénario qui teste la consultation d’un panier. Un nouveau panier est créé avant l’exécution du scénario grâce aux instructions du block Background

  Scenario: Retrieve a cart
    When def r = call read(retrieveCart)
    Then match r.statusCode == 200
    And match r.body.status == 'IN_PROGRESS'

Ajoutons un scénario qui vérifie l’ajout d’un article dans un panier.

  Scenario: add an item
    When def r = call read(addItemToCart) { itemId: 'XXX' }
    Then match r.statusCode == 200
    And match r.body.status == 'IN_PROGRESS'
    And match r.body.items[0].itemId == 'XXX'

Ajoutons un scénario qui ajoute un article au panier et vérifie la mise à jour de la quantité

  Scenario: add an item and update its quantity
    When def addItemToCartResult = call read(addItemToCart) { itemId: 'XXX' }
    Then match addItemToCartResult.statusCode == 200

    When def r = call read(updateCartQuantity) { itemId: '#(addItemToCartResult.body.items[0].itemId)', quantity: 3 }   
    Then match r.statusCode == 200
    And match r.body.status == 'IN_PROGRESS'
    And match r.body.items[0].quantity == 3

Ajoutons un dernier scénario qui ajoute un produit dans un panier, récupère une carte de paiement, utilise cette carte pour payer, vérifie l’état du panier et la création d’un ticket.

  Scenario: Pay a cart with a card
    # add an item to cart
    When def addItemToCartResult = call read(addItemToCart) { itemId: 'XXX' }
    Then match addItemToCartResult.statusCode == 200

    # retrieve a card
    When def getWalletResult = call read(getWallet)
    Then match getWalletResult.statusCode == 200
    * def cardId = getWalletResult.items[0].id

    # pay
    When def r = call read(postPayment) { cardId: '#(cardId)' }
    Then match r.statusCode == 200
    And match r.body.status == 'PAYMENT'
    And match r.body.payment == 
    """
    {
      "id": '#string',
      "creationDate": '#string',
      "status": "SUCCESS"
    """

    # check status FINISHED and ticket is available
    When def r = call read(retrieveCart)
    Then match r.statusCode == 200
    And match r.body.status == 'FINISHED'
    And match r.body.ticket == { ticketNumber: '#string', creationDate: '#string' }

Intégration avec Jenkins

Le plugin Cucumber Reports permet d’intégrer facilement nos scénarios Karate à Jenkins.

En utilisant un jenkins pipeline, il suffit d’ajouter dans son Jenkinsfile après son build:

cucumber fileIncludePattern: '**/target/surefire-reports/*.json'

Jenkins construira un reporting comme illustré ci-dessous:

karate-report1
karate-report2

Conclusion

Karate est un outil très efficace pour tester des api et des services rest.

Sa faculté à s’interfacer avec du code java et javascript est très utile pour ajouter des scripts et interagir avec d’autres outils comme Selenium Webdriver.

Enfin Karate reposant sur Cucumber, nous pouvons profiter des plugins Cucumber pour une intégration avec Jenkins.

Méthode Agile

Méthode AGILE – Retours d’expériences

Voici maintenant plus de 5 ans que SALTO Consulting gère des projets implémentant la méthode AGILE.
Ceux-ci sont de

  • nature (Création d’un nouveau produit, Maintenance d’un produit existant, Intégration de progiciel, etc.),
  • taille (de 100j à plus de 3000j),
  • durée (de 3 mois à 3 ans),
  • domaine fonctionnel (ECommerce, Mise en place d’un back-office Magasin, Mise en oeuvre des processus de ventes et d’achat, etc.)

différents.
Il n’en demeure pas moins que la mise en oeuvre complète ou partielle des éléments ‘clés’ suivants conditionne la réussite de ceux-ci  :

 

1. Des rôles indispensables

A minima, un projet utilisant la méthode AGILE doit intégrer et IDENTIFIER les 3 rôles suivants :

  • Product Owner (PO) : Alimente le Backlog en UserStory – Il est le représentant du fonctionnel
  • Scrum Master : Récolte et analyse les données des sprints passés : Capacitif => Dimensionnement cohérent des sprints
  • Team Member : Il s’agit des membres de l’équipe chargés de la réalisation des UserStory.

Ce que l’on néglige parfois, c’est celui de Scrum Master.
C’est pourtant lui qui permet de reprendre les données ‘historiques’ des sprints, de les analyser (prendre du recul) et d’en tirer des éléments d’amélioration ‘objectifs’ (non discutables) du processus ‘AGILE’ mis en place.
Il contribue ainsi à

  • l’amélioration des processus de réalisation
  • la mise à disposition de chacun de données ‘objectives’
    • Capacitif d’équipe,
    • Rapprochement Story Point et Charges de travail,
    • Cause de blocage, de rupture dans la chaîne de fabrication,
    • Etc.
  • la mise en place d’une relation de confiance entre le fonctionnel et l’équipe AGILE.

 

2. Des rôles parfois nécessaires

En plus des rôles précédemment décrits, il peut s’avérer nécessaire de les compléter avec les 2 rôles suivants (qui ne sont pas des rôles de la méthode AGILE) :

  • Team Leader (ou Leader Technique) :
    Même si les choix de conception, revues de code, déploiements, veille techno etc. sont censés être totalement partagés dans l’équipe de développement, il n’en demeure pas moins que dans certains cas (équipe jeune, environnement technique nouveau), l’intégration d’un Team Leader (plus exactement leader technique) peut s’avérer nécessaire. Il faudra alors s’assurer qu’à terme, tous les membres de l’équipe aient un certain niveau d’autonomie au sein du projet (augmentation de la productivité).
  • DevOps :
    Affecter un rôle de ‘DevOps’ (lien entre le développement, la pré-production et la production) à l’un des membres de l’équipe (ce n’est pas son seul rôle dans le projet) permet d’assurer la ‘fluidité’ des mises en production des réalisations, notamment quand le niveau de maturité de l’outillage ‘DevOps’ (Intégration continue, orchestrateurs de containers, déploiement automatisé, etc.) n’est pas encore suffisant.
    Sans se vouloir exhaustif, la liste qui suit présente les principales problématiques à mettre en oeuvre :

    • Réalisation des jeux de données (sur la base des tests ‘QA’), éventuellement bouchonnés
    • Description du contenu de la livraison (Release Notes),
    • Ecriture des scripts (procédures) à passer lors de la mise en production
    • Mise en oeuvre et maintenance évolutive d’une plate-forme d’intégration continue automatisée (Build, Tests de non régression, Audit de code, Tests de performance, déploiement, etc.)
    • Vérification de la réalisation des pré-requis ‘techniques’ réalisés par des équipes tierces (BDD, VM, Dockerisation, APIs, Batch, etc.)
    • Planification des MEPP et MEP avec l’équipe Production
    • Participation à la MEP (GO – NO GO ‘technique’ de la mise en production – Vérification des résultats de l’intégration continue automatisée ou pas)
    • Faire le bilan de la MEP et de proposer des actions d’amélioration

 

3. Relation de confiance entre le fonctionnel et l’équipe AGILE

Il va sans dire qu’une relation de confiance entre le fonctionnel et l’équipe de réalisation (qu’elle soit méthode AGILE ou pas) est un élément clé de la réussite d’un projet.
Elle évite toute perte de temps à négocier et à se justifier.
Cette relation de confiance se traduit notamment par les éléments suivants :

  • Le fonctionnel (représenté par le PO) ne remet pas en question (négocie pas) les ‘Story Point‘ (charges) fournis par l’équipe (ou son Team Manager).
  • Le Scrum Master s’engage à fournir un capacitif de réalisation (en story point ou charge) de l’équipe à jour au PO et à lui donner toutes les explications nécessaires
  • Le fonctionnel (représenté par le PO) se base sur le capacitif de l’équipe pour construire les sprints
  • L’équipe AGILE s’engage à réaliser le contenu du Sprint et à fournir un contenu de qualité.

 

4. Mise en place d’un Release Plan donnant de la visibilité sur les réalisations à venir

Même si le contenu des sprints est susceptible d’évoluer (c’est le principe même de l’agilité), il est indispensable d’avoir une visibilité sur les réalisations à intégrer sur 2 à 3 mois à venir, à travers un Release Plan (ou Road Map).
Celui-ci doit permettre de :

  • Anticiper la création des UserStory, de les prioriser et de les documenter
  • Organiser des Workshop entre les Team Members (éventuellement représentés par le Team Leader) et le PO pour lever les manques ou les ambiguïtés qui peuvent subsister au niveau de la documentation des UserStory,
  • Planifier la réalisation des pré-requis (réaliser par des équipes tierces) à la réalisation d’une UserStory (APIs, Maquettes HTML-CSS, Contenus médias, etc.)
  • Faire une macro évaluation des UserStory (sous forme de story point ou de charge),
  • Prioriser les réalisation (ranking du Backlog),
  • Alimenter (encore une fois, même s’il est susceptible de changer) le contenu des 3 ou 4 prochains sprints,

Ce Release Plan est vivant. Il peut être revu, ajusté autant de fois qu’il est nécessaire. Il s’agit bien d’anticiper au delà du sprint à venir et de ne pas tout découvrir au dernier moment.
Par contre, il convient de prendre garde à rester sur un périmètre fixe (défini à l’initialisation du sprint) pour le sprint actif (sauf bug critique, incident de production).

 

5. Les Tests – Incontournables

Rappelons ici que méthode AGILE ou pas, ils sont indispensables.
Ils peuvent être classés en 4 grandes catégories :

  • Les tests unitaires : L’équipe de développement est en charge de leurs réalisations.
    Des outils existent pour la plupart des technologies permettant de les ‘prototyper’ et de vérifier en vérifier la complétude en niveau du code (taux de couverture).
  • Les tests fonctionnels : La MOE (à travers son PO ou sa MOA) les réalisent.
    Idéalement, chaque User Story doit avoir son test fonctionnel ‘écrit’ que l’on doit pouvoir lui associer (pièce jointe à la User Story, lien, sous-tâche, etc.). Ils doivent par ailleurs pouvoir être (re)passés n’importe quand (au niveau du sprint actif une fois la UserStory développée ou ultérieurement pour vérifier les non-régressions) afin de vérifier que le produit est (toujours) conforme aux exigences fonctionnelles.
  • Les tests de non-régressions : Il s’agit d’une sélection ‘pertinente’ (fonctionnalités intégrées dans les processus ‘auto-route’, image de marque, réglementation, etc.) de tests fonctionnels à rejouer à chaque nouvelle livraison.
    Dans la plupart des projets, ils sont réellement effectués s’ils ont été automatisés et intégrés dans une chaîne d’intégration continue ou s’il existe une équipe QA sur le projet dont l’une des missions est de les jouer.
    Ils s’avèrent pourtant primordiaux dans le cadre de la méthode AGILE, les mises en production étant de fait fréquentes augmentant sensiblement les risques de régression.
  • Les tests techniques : Ils consistent à vérifier que le produit répond toujours aux exigences de performance et de stabilité.

 

6. Préparation des sprints

Le but de la préparation d’un sprint est qu’au moment du lancement du sprint, il n’y ai plus de question à se poser sur celui-ci et que l’équipe DEVOPS puisse s’engager en toute ‘sérénité’ sur la MEP de celui-ci dans les temps et la qualité requise.
Théoriquement, au moins si la road map a été réalisée et mise à jour, il ne doit plus y avoir de point fonctionnel à revoir.
Il s’agit donc pour le Team Leader et le PO d’adapter le contenu du sprint en fonction des événements récents de la vie du projet à savoir :

  • intégrer les correctifs ‘non bloquants’ restants du sprint précédent
  • découper éventuellement des UserStory pour que chaque userStory du sprint ait un poids équivalent en terme de ‘StoryPoint’ (ou charge).
    Chaque membre d’équipe est alors amené à réaliser le même nombre de UserStory et les commits sont réguliers.
    La mesure d’avancement est alors plus fiable et facile (un comptage du nombre de UserStory réalisées peut suffire)
  • ré-intégrer dans le sprint les UserStory qui n’ont pas pu être réalisées lors du sprint précédent (ce qui doit être exceptionnel si la roadmap a bien été définie et mise à jour)
  • vérifier la réalisation des pré-requis tiers pour chaque UserStory du sprint en cours de préparation
  • prendre en compte le capacitif ‘actuel’ de l’équipe (congés, absence, dimensionnement, intégration de nouvelles ressources, etc.)

Le ‘goal‘ du sprint est alors clairement défini et l’équipe peut se focaliser et s’engager sur sa seule réalisation

 

7. Organiser les Sprints

Sans aller jusqu’à reproduire le Cycle en ‘V’, il apparaît profitable d’organiser les sprints avec les étapes suivantes :

  • Lancement du sprint (1/2j) : PO (ou le Team Leader) lance le sprint avec son équipe par une revue des user story intégrées à celui-ci. Chacun sait ce qu’il y a à faire et ce qu’il peut faire
  • Réalisation (2 semaines minimum) : Au fil des réalisations, l’équipe réalise les UserStory dans l’ordre des propriétés (Ranking du sprint). Elle effectue les tests unitaires et intégre les user story au fil de leur réalisation.
  • Tests : A chaque user story intégrée, le PO (ou sa MOA), passe les tests fonctionnels et identifie d’éventuelles anomalies qu’il priorise et surtout classe comme bloquant ou pas. Dans le cas d’une anomalie bloquante, l’équipe la corrige lors du sprint.
  • Préparation de la MEP (1/2j) : Une fois le GO MEP donné par le PO, l’équipe documente la MEP (Release Notes, procédures et scripts spécifiques, etc.).

 

8. Workflow de réalisation simple et efficace

La mise en place de workflow d’état des UserStory permet d’avoir une vision claire de l’état d’avancement du sprint (surtout si l’on utilise les KANBAN).
Cependant, une tendance forte est de multiplier les ‘états’. Or, la vraie question à se poser est de savoir si un état représente bien une étape d’avancement dans le processus de développement d’une UserStory.
En tout état de cause, les états ‘utiles’ et ‘systèmatiques’ rencontrés sont :

  • Open : La UserStory est ouverte
  • In progress : La UserStory est en cours de développement
  • Ready to test : La UserStory est développée et prête à être testée
  • Done : La UserStory est développée et les tests fonctionnels la concernant ont été passés avec succés. Elle est donc prête à être buildée pour mise en pré-production ou production.
  • Blocked : La UserStory est bloquée (manque de spécifications, en attente d’une autre UserStory, en attente d’un pré-requis, etc.)

L’avantage de ces états est qu’ils sont également applicables pour les anomalies, en effet, il suffit de remplacer, dans ce qui précéde, ‘UserStory’ par ‘Anomalie’ et ‘développée’ par ‘corrigée’ . Dans le cas du ‘Blocked’ les causes peuvent être un manque de description de l’erreur, du contexte dans lequel elle s’est produite (Scénario de test – Etape du test – Jeux d’essai, etc.).

Il existe souvent les états ‘Validated’, ‘Refused’ qui sont plutôt des informations (pourquoi ne pas utiliser alors une étiquette). En effet, le fait de retrouver une User Story (ou Anomalie) dans un sprint suppose qu’elle a été validée (enfin, il faut l’espérer) et si elle est refusée, elle restera dans le backlog et donc ne sera pas visible dans le Kanban (scrum) du sprint.

Toujours est-il que la définition d’un état peut avantageusement être complétée par des critères mesurables d’atteinte de l’état (ex : Done : Taux de couverture des tests de 90% – Respect des normes de développement – Taux de performance atteinte sur l’environnement de pré-production – Présence d’une documentation technique – etc.).

 

9. Polyvalence des équipes

En dehors du fait que cela permet de palier aux absences des membres de l’équipe, cela permet aussi à chacun de faire le travail de l’autre et donc de s’apercevoir des contraintes qui pèsent sur ses tâches et de mieux comprendre les exigences qu’il peut avoir (Ne fais pas à autrui ce que tu n’aimerais que l’on te fasse).
La mise en oeuvre typique de cette notion est la revue de code : L’équipe de développement fait des revues régulières sur les codes de ses collègues permettant non seulement de partager la connaissance des réalisations des autres (limitation du cloisonnement et échanges sur les bonnes pratiques) mais aussi des réduire le nombre d’anomalies.

 

10. Outils collaboratifs

Enfin, la méthode AGILE permettant de réaliser des versions de produits sur des cycles courts et de pouvoir faire évoluer les besoins à la demande (Time to market),

  • partager en permanence les informations sur
    • le stock des UserStory et des anomalies (BACKLOG)
    • le contenu des sprints à venir (ROAD MAP)
    • l’état d’avancement des UserStory (et des anomalies) du sprint actif (KANBAN)
    • les procédures à appliquer (WIKI),
    • les questions et les réponses apportées (FAQ),
    • les trucs et astuces (HOW TO),
  • échanger en live sur une problématique (CHAT),
  • décider sans avoir besoin de se réunir au même endroit (CallConf, WebConf)

sont des besoins ‘quotidiens’ nécessitant donc la mise à disposition des équipes des outils communs ‘collaboratifs’, l’idéal étant d’avoir un seul outil couvrant l’ensemble de ces problématiques d’échange et de partage.

Gestion de projet : La guerre des méthodes

Gestion de projetA travers plus de 20 ans de gestion de projet, j’ai eu l’occasion d’utiliser différentes méthodes de conduite de projets, celles-ci ayant eu des durées de vie pour le moins disparates.

Pour les principales, citons :

  • Le bon vieux « Cycle en V», récemment transformé en « Mini Cycle V » afin de produire des résultats sur des durées plus courtes (1 à 2 mois)
  • Le feu RUP (Rational Unified Process), les IBMistes et les adaptes d’UML se reconnaîtront
  • L’ Extreme Programming et son utilisation parfois abusive du type « On ne spécifie rien, tout est dans le code »
  • Le collaboratif AGILE avec ses sprints (Point d’effort, Capacitif delivery) , ses tableaux magiques (Kanban et Scrum), ses daily meetings et planning poker

Nombreuses sont les discussions qui les mettent en opposition.

Actuellement, une bataille rangée oppose les adaptes du « Cycle en V » (qualifiés de « Old School » par les autres) et ceux de l’« AGILILTE » (qualifiés de « génération Y ou Z » -zappeur- par les premiers).IT_fight

Pour ma part, je n’en ai trouvé aucune mauvaise dans l’absolu à condition de les utiliser dans le bon contexte.
Sans vouloir verser dans la caricature et loin de moi l’idée d’être universel et exhaustif, voici des exemples d’utilisation rationnelle d’une méthode par rapport à un contexte :

  • « Cycle en V » : Projets réglementaires, institutionnels, intégration de progiciel
  • RUP : Projets de refonte basée sur du spécifique et/ou sur l’intégration de briques logicielles
  • Extreme Programming : Projets événementiels (durée de vie limitée dans le temps)
  • AGILE et « Mini Cycle V » : Projets « Time to Market », QuickWins

Quoiqu’il en soit, un projet reste un projet et quelle que soit la méthode utilisée :

  • On spécifie des besoins
  • On les valide et les intègre dans des versions
  • On réalise les composants de l’application dans une version
  • On déploie sur les environnements de recette les versions
  • On teste les versions
  • On déploie sur les environnements de pré-production puis de production.

et cela, en RESPECTANT 4 FONDAMENTAUX :

  • Le niveau de qualité défini
  • Les exigences fonctionnelles et techniques
  • Les délais
  • Les coûts

Chaque méthode a apporté ses pierres à l’édifice « GENIE LOGICIEL », à travers les concepts qu’elle met en œuvre, comme par exemple et pour ne citer que les plus représentatifs :

  • « Cycle en V» : Ordonnancement des tâches (WBS) et planification (GANTT)
  • RUP: Conception graphique (UML et ses diagrammes)
  • Extreme Programming: Intégration continue
  • AGILITE: Sprint, KANBAN-SCRUM Board et surtout outils collaboratifs

Time to marketUne guerre existe bien, mais pas au niveau des méthodes.

C’est contre le TEMPS que l’on se bat aujourd’hui (le fameux TIME TO MARKET).

Le VERITABLE DEFI A RELEVER est bien de PRODUIRE à FLUX TENDU des COMPOSANTS LOGICIELS RESPECTANT LES 4 FONDAMENTAUX, et peu importe la méthode.

Plus précisément, il s’agit bien de FOURNIR EN TEMPS REEEL (ou à la demande) à l’ensemble des ACTEURS DU PROJET les éléments qui leur permettent de prendre les bonnes décisions au bon moment et de produire ses livrables sans rupture au plus vite.

En conclusion : L’utilisation combinatoire des concepts de chacune des méthodes n’est-elle pas une des armes à utiliser pour gagner cette guerre ?

 

Ainsi, pour nos prochains articles, nous aborderons les sujets suivants :

  • Est-il aberrant de faire cohabiter PMO (Project Management Organization), GANTT et SPRINT ?

En fait, la problématique qui m’est posée est de plus en plus la suivante :

Les COMITES DE DIRECTION élaborent des ROAD MAP sur la base de BESOINS (valorisés en coûts estimés et bénéfices attendus) qui se déclinent en PROJETS (PMO) que les DIRECTEURS DE DEPARTEMENT planifient en fonction des ressources et des contraintes externes (GANTT) qui sont VERSIONNES pour être DELIVRES à travers des SPRINTS (de 3 semaines à un mois).
La question sous-jacente est donc « Comment faire une synchronisation en temps réel ou à la demande de ses différents éléments ? ». L’article présentera un cas d’école et l’utilisation de JIRA et de certains de ses PlugIn.

  • CONTINUOUS DELIVERY : Délivrer en continu tous les composants d’un projet ou d’un produit

Tout le monde a entendu parler du mouvement « devops » et de son corolaire, l’intégration continue.
Pour simplifier, il s’agit d’outiller, d’industrialiser voire d’automatiser les étapes de CONTRUCTION, d’ASSURANCE QUALITE (fonctionnelle et technique), de DEPLOIEMENT des composants d’une version logiciel sur les environnements de Recette, préproduction, production.
Dans cet article, j’élargirai le champ du CONTINUOUS à toutes les étapes d’un projet (GESTION PROJET – DOCUMENTATION – TESTS DE NON REGRESSION – TESTS FONCTIONNELS – TESTS TECHNIQUES) pour aboutir à la notion de CONTINUOUS DELIVERY.

  • QUALIFICATION DES BESOINS : Les 3B

Les technologies évoluent de plus en plus vite qui permettent :

  • de mettre en œuvre de nouveaux concepts (net économie, objets connectés, digitalisation des entreprises, etc.)
  • d’améliorer sensiblement des besoins existants (distribution omni canal, fidélisation multi support, etc.)
  • d’architecturer son SI en mode services

Les idées ne manquent pas mais si elles sont BELLES, sont-elles BONNES et me permettront-elles de générer du BUSINESS (les 3B) ?
Tout l’enjeu est d’avoir au plus vite les réponses pour prendre les bonnes décisions (l’éternel TIME TO MARKET).
Cet article se proposera de décrire les outils qui permettent de répondre à cette problématique.

  • I HAVE A DREAM : L’outil de gestion de projet idéal

Un projet évolue suivant les trois phases principales qui suivent :

  • PREPARATION (THINK) :
    Il s’agit principalement d’une phase de gestion des besoins (Identification – Qualification 3B – Costing et Budget – Priorisation – Validation et enfin Inscription dans un projet)
  • CONSTRUCTION (BUILD)
    Il s’agit ici de délivrer des versions de produits (concrétisation des besoins) à travers la réalisation de tâches de conception, de développement, de test, de déploiement, etc.
  • MAINTENANCE (RUN)
    Il s’agit de corriger (Bug) et d’ajuster (petites évolutions ou QuickWins) les composants logiciels au fil des incidents de production et des demandes « urgentes » (sic).

Je me suis surpris à rêver d’un logiciel qui traite de ses 3 phases tout en implémentant le meilleur des différentes méthodes (WBS et GANTT du cycle en V, SPRINT-KANBAN-SCRUM de l’AGILILITE, Conception graphique du RUP, Intégration Continue de l’Extreme Programming) le tout dans un contexte « full collaboratif ».
Cet article essaiera de retranscrire mon rêve et de voir si une réalisation existante s’en approche.

Agile Tour Lille 2015 (Partie 2/2)

Retour sur la 1ère partie…

Suite de l’article : Agile Tour Lille 2015, partie 2

Pour rappel, voici les conférences que j’ai suivies cette année :

  1. Des lean startups dans l’administration !? – par Pierre Pezziardi
  2. Si le TDD est mort, alors pratiquons une autopsie – Par Bruno Boucard et Thomas Pierrain
  3. Construire plus vite en apprenant plus vite – Retour d’expérience du Monde.fr – Par Ismaël Héry
  4. Ratez vos revues de code en 5 leçons ! – Par Michel Domenjoud
  5. L’estimation, un formidable outil de discussion, même pour les projets #NoEstimates – Par Sébastien Delest
  6. Le Kanban expliqué par Bison futé – Par Cyrille Deruel
  7. Alliés contre les défauts – pourquoi et comment nous relisons ensemble le code que nous produisons – Par Julien Jakubowski et Antoine Blancke
  8. Intégration continue, DevOps et après ? – Par Laurent Tardif

5. L’estimation, un formidable outil de discussion, même pour les projets #NoEstimates – Par Sébastien Delest

Sebastien Delest est venu nous présenter le mouvement #NoEstimates. Aujourd’hui, nous avons besoin d’estimer pour décider et gérer un projet, une équipe. La difficulté est qu’estimer l’imprévu peut s’avérer.. complexe. On utilise généralement le coté reproductible des choses pour avoir une idée du temps nécessaire. Seulement on ne fait pas tout le temps la même chose, qui plus est dans le même contexte. Par ailleurs on a souvent tendance à être trop optimiste.

Sébastien nous propose donc d’éviter l’estimation, ou au moins de minimiser son importance. Pour cela il nous propose quelques alternatives :

  • On ne peut se fier à une estimation pour des décisions importantes. Il vaut mieux prendre des décisions mineures et pouvoir changer d’orientation, s’adapter.
  • Il faut garder le point de vue sur la vision, l’objectif est d’utiliser le maximum de feedbacks sur des cycles courts pour prioriser les besoins.
  • Engager moins d’argent et donc moins de temps, en faisant un point d’avancement chaque semaine, par exemple, pour savoir si on continue ou si on prend la bonne direction.

Toutefois, l’estimation a également des vertus : elle permet par exemple via le planning poker de discuter du besoin et de partager la vision de celui-ci. Et donc de mieux le comprendre et soulever les premières inconnues. Il en est de même pour la rédaction des User Stories et des Scénarios BDD qui permettent de décomposer le besoin et encore une fois d’avoir une meilleure vision des détails. Sur ces points, l’orateur insiste sur l’intérêt d’avoir des interlocuteurs variés afin d’augmenter les points de vue et d’enrichir les échanges.

On peut également se poser la question de la valeur ajoutée d’une demande. Générerait-elle plus de chiffre ? Est-ce nécessaire pour améliorer la maintenabilité et donc mieux supporter les évolutions à venir ou simplement la qualité du support ? Pour cela, on peut utiliser une Story-map qui permet de prioriser les fonctionnalités par valeur ajoutée et/ou effort nécessaire.

Comme toujours il n’y a pas de solution miracle, mais des bonnes pratiques peuvent limiter les impacts. Ainsi si un client change d’avis et souhaite revenir en arrière, faire des cycles courts et avoir un retour au plus vite permet de réduire les pertes. De même, dans le cas d’engagement au forfait, il vaut mieux privilégier la confiance et s’engager sur l’effort plutôt que sur le contenu.

Dans tous les cas, le travail d’estimation doit être pris comme une opportunité d’échanges sur le besoin et les priorités plutôt que comme une simple opération comptable.

6. Le Kanban expliqué par Bison futé – Par Cyrille Deruel

Voilà une présentation très dynamique et diablement pertinente ! Cyrille est Delivery Manager chez Octo, il ne travaille aucunement pour bison futé, en revanche il a eu une soudaine conviction un jour de bouchons sur la route des vacances. Il a remarqué de nombreuse similitudes entre la gestion du trafic routier et celle ses projets informatiques. Voilà l’origine de sa présentation.

Cyrille nous propose donc d’améliorer les 5 pratiques de notre kanban en appliquant les solutions correspondantes à ce que fait Bison Futé pour mieux gérer le trafic routier.

1. Visualiser le flux de travail

Pour éviter la frustration des clients engendrée par le manque de vision des délais, on peut indiquer sur le kanban une estimation du temps restant avant la mise en production d’une fonctionnalité, comme le fait Bison Futé avec ses panneaux à affichage variable estimant le temps restant pour atteindre une destination. Ce n’est pas un engagement, on ne peut prévoir l’imprévu. Par contre on peut supposer au vu du rythme actuel que si la fonctionnalité est en phase de test par exemple, il lui reste X jours pour arriver en production.

De même on peut préciser le nombre de personnes travaillant actuellement sur tel ou tel pan applicatif. Ainsi on a conscience qu’un sujet dans un domaine avancera plus ou moins vite en fonction de l’énergie actuellement allouée sur ce domaine.

2. Limiter le WIP (Work In Progress)

C’est un classique, le multi-tâches c’est le mal, et accumuler un ensemble de tâches en cours est le meilleur moyen de se noyer. C’est là qu’intervient le WIP. Pour respecter ce nombre de tâches pouvant être traitées en parallèle, on bloque ce nombre. Comme un feu rouge devant une autoroute, vous êtes ainsi certain que la route sera fluide et optimale. De manière plus radicale, on peut imaginer une circulation alternée. Si les Product Owners ne sont pas en mesure de prioriser les tâches, on peut les choisir aléatoirement. C’est à éviter autant que possible, mais ça débloque le problème. Un concept intéressant est également celui de la fourrière. Si chaque jour une tâche n’avance par car un élément externe est bloquant, on peut mettre cette tâche en fourrière, ne plus s’en préoccuper et ainsi libérer l’équipe d’un point sur lequel elle ne peut rien faire.

3. (Mesurer et) gérer le flux

Concernant le trafic routier, il y a plusieurs options : on peut réserver une voie au taxi pour qu’il puisse aller plus vite en cas de bouchon, ponctuellement utiliser une voie d’arrêt d’urgence pour augmenter le flux ou encore limiter la vitesse globale pour augmenter la vitesse de croisière. (Réduire la vitesse de 10km/h sur le périphérique parisien à augmenté de 18% la vitesse moyenne !)

Pour notre kanban, comme pour le reste d’ailleurs, le meilleur moyen de décider est d’abord de mesurer. Il faut régulièrement s’adapter et expérimenter. Tester une nouvelle manière de gérer, et si au bout d’un mois le résultat n’est pas concluant, on refait comme avant. Par ailleurs, en période de congés, quand une partie de l’équipe est absente, on absorbe forcément moins d’activité que si tout le monde était présent.

4. Rendre explicites les règles des processus

Il est essentiel de définir les règles à suivre, de réaliser des checklists pour vérifier que l’on s’y tienne et de les adapter au fil du temps et notamment de l’expérience. Ainsi en cas de problème, on peut en identifier les causes et faire évoluer le process pour ne plus reproduire l’erreur. La checklist permet d’éviter les habitudes qui trop vite nous font oublier certains points et donc reproduire des erreurs.

Ici aussi en mesurant la « quantité de problèmes »qu’on a sur les différents sujets, on est plus à même d’identifier et corriger le problème en amont.

5. S’améliorer collaborativement

Il faut dés le début avoir conscience et prendre en compte les contraintes externes. Un éco-pont a permis d’éviter des accidents avec des sangliers sur la route. Vérifier que le ciblage de nos utilisateurs est compatible avec le règlement de la CNIL évite de s’en rendre compte une fois en production. Il faut aussi, comme le télépéage, automatiser tout ce qui peut l’être, comme le déploiement sur un environnement de tests, par exemple.

Cyrille ajoute à cela l’importance d’avoir une bonne salle de pause et des événements en dehors du travail. Cela améliore la qualité des échanges et simplifie la communication.

Il faut aussi prendre conscience que le changement peut prendre du temps : 40 ans après le lancement de la ceinture de sécurité, 21% des tués dans les accidents de la route ne la portaient pas…

Je vous invite à parcourir les slides qui sont assez évocateurs :

 

 

7. Alliés contre les défauts – pourquoi et comment nous relisons ensemble le code que nous produisons ? – Par Julien Jakubowski et Antoine Blancke

Voila une nouvelle présentation sur la revue de code, plutôt orientée sur le retour d’expérience des équipes au Web Center d’Axa.

Julien et Antoine commencent par nous expliquer qu’au début, la revue de code était plutôt faite par un expert dans l’équipe et parfois en pair-programming. Cependant le résultat était peu concluant car le retour d’expérience était peu diffusé et l’expert avait trop de code à relire. Ils ont donc opté pour une revue de code faite par l’ensemble de l’équipe. De premier abord, cela semble particulièrement coûteux, à raison de 3 réunion d’une heure par semaine pour tout le monde d’un coup. Dans les faits, le coût est de 5% du budget de développement du projet.

Il y a deux choses qui permettent d’accepter ce coût :

  • La première est d’optimiser au maximum l’efficacité de la revue de code. Pour cela, il ont établi des rôles qu’il est impératif de respecter : un time-keeper, un modérateur, un scribe, 3 lecteurs et bien sur l’auteur initial du code qui explique ce qu’il a produit. Chaque rôle permet d’équilibrer la réunion et de s’assurer de son efficacité.
  • La deuxième chose est de relativiser ce coût par rapport au autre coût d’un projet. Des statistiques donnent un R.O.I de 4 pour 1 (4h de debug pour 1h de revue) avec un budget dédié à la correction de bugs au départ de 43% du budget du projet. Pour finalement descendre à 5% du budget lorsque la revue de code est utilisée.

D’autres avantages de la revue de code sont aussi la communication autour du code, la mise en place d’une propriété collective du code qui devient donc plus facile à maintenir, et enfin la facilité d’apprentissage pour les nouveaux arrivants qui intègrent plus facilement les standards et la compréhension du projet.

S’il est difficile au début de faire des revues de code, par peur de montrer son code ou de faire des remarques peu pertinentes, ou simplement par la pression du projet. Avec du travail, notamment sur la communication : ne pas critiquer le code mais faire référence au standard, reformuler ses phrases pour ne pas accuser (tu …) mais plutôt partir d’une hypothèse (je pense que …). Et le respect des rôles (time-keeper, modérateur), la pratique de la revue de code s’avère très efficace et améliore notablement la communication, même avant les revues !

En conclusion, s’ils ne devaient garder qu’une chose sur leurs gestions de projet, ils garderaient la revue de code !

Les slides de la présentation sont disponibles ici :

 

8. Intégration continue, DevOps et après ? – Par Laurent Tardif

« Prédire » l’avenir est difficile : En 1994 par exemple, le rapport Thery ne croyait pas en l’avenir d’internet… Toutefois Laurent commence par présenter un chiffre intéressant : d’après une étude Gartner, en 2016 Devops va passer d’un marché de niche à une réelle stratégie pour 25% des entreprises. Le ton est donné.

Ensuite, il réalise un rapide état des lieux de ce qui existe : l’émergence des principes sur l’agilité, les outils d’intégration continue qui permettent déjà de rapprocher le développement des tests. Tout cela permet d’améliorer la qualité du code, sa robustesse et son processus de livraison.

Ensuite nous voyons une définition de ce qu’est DevOps – la fusion du dev, des tests, et des ops :

  • D’un point de vue technique, c’est principalement de l’automatisation, des processus de tests, de la livraison, etc.
  • D’un point de vue du business, c’est une approche qui croit en l’expérimentation, à l’échec rapide, au produit viable minimal et une décision prise sur des chiffres.

Puis on passe en revue rapidement pléthore de domaines couverts par devops ainsi que les principaux outils associés :

On constate à nouveau qu’il est très important de mesurer, via du monitoring, la gestion du feedback utilisateur. C’est là clé pour prendre les bonnes décisions.

Puis Laurent fait un rapide bilan de ce que l’on a aujourd’hui : un forte tendance vers les produits Open Source, les clouds privés et/ou publics, les technologies autour des containers (Docker) et micro-services, et enfin le machine learning, aujourd’hui avec Mahout et Spark et demain certainement avec Flint.

On apprend que les solutions de cloud privé sont en recul, notamment du fait de leur coût et leur complexité, au contraire de l’IoT et la sécurité qui sont en forte croissance. Un nouveau courant cherche à décentraliser les puissances de calcul pour les apporter jusque dans les téléphones mobiles (via des containers). Cela permettrait d’amoindrir les coûts et d’améliorer le service, par exemple en cas de coupure réseau.

Enfin comme piste de réflexion pour le buffet de clôture, Laurent imagine qu’après l’association des Devs et des Ops, la prochaine génération associera les Devs et le Marketing.

Les slides de la présentation sont disponibles ici :

Tout cela n’aurait pas eu lieu sans l’association Nord Agile et de leurs sponsors, un grand merci à eux !

Et bien sûr merci à Salto Consulting de m’avoir permis de participer à cette journée !

Par Matthieu Fernandes

Jenkins : Usine d’intégration et de déploiement continue

Salto Consulting a mis en place pour un de ses clients une usine d’intégration et de déploiement continue avec Jenkins.

Jenkins

Jenkins

Jenkins est un outil open source d’intégration continue, fork de l’outil Hudson.
Écrit en Java, Jenkins fonctionne dans un conteneur de servlets tel qu’Apache Tomcat ou en mode autonome avec son propre serveur Web embarqué.
C’est un outil que les équipes de Salto Consulting mettent en place régulièrement dans le cadre de leurs projets.

Dans le cadre de cette réalisation, elles se sont appuyées sur l’utilisation des deux plugins Jenkins suivant:

Build Flow Plugin
Ce plugin permet d’orchestrer les différents jobs Jenkins liés à un projet grâce à la notion de workflow qu’il implémente.
La construction de chaînes d’exécution complexes de jobs et la définition des règles associées en est grandement facilitée.
Il a été ainsi possible de construire une chaîne d’exécution composée des jobs de build, de déploiement, de tests d’intégration et de tests de charge.
Ces jobs sont déclenchés les uns à la suite des autres et des conditions peuvent être configurées (Exemple: le job précédent doit avoir un statut d’exécution en succès pour continuer la chaîne).

Build Graph View Plugin

Ce plugin permet de visualiser l’exécution des workflows sous la forme d’un graphe et d’accéder rapidement à la console d’exécution de chaque job Jenkins.

Jenkins Build Graph