Continuous Delivery

CONTINUOUS DELIVERY : Délivrer en continue toutes les composantes d’un projet ou d’un produit

L’article précédent « LA GUERRE DES METHODES » mettait en avant un nouveau challenge à relever par les équipes informatiques :Timetomarket1
Or, réussir ce challenge implique, entre autres, la mise en œuvre à toutes étapes de production du projet (produit) de la notion de « FULL COLLABORATIVE CONTINUOUS DELIVERY » c’est-à-dire :Continuousdelivery2La cartographie qui suit, est un exemple (loin d’être exhaustif) de système de livrables et d’indicateurs qu’il conviendrait d’intégrer dans un contexte de « FULL COLLABORATIVE CONTINUOUS DELIVERY »

Think-Phasis3

Build-Phasis4

Run-phasis5

Sachant que tout livrable peut être une entrée d’autres livrables :

  • Les besoins d’une Road Map alimentent le Backlog « Agile »,
  • les Backlog -> les Sprints,
  • les Sprints -> les Gantt projets,
  • Les spécifications -> le référentiel documentaire et les User Stories,
  • Les maquettes -> les templates de pages
  • Les commits -> les branches de versions du référentiel de source,
  • Les branches de versions du référentiel de source -> les Builds,
  • les Builds -> les automates de déploiement,
  • ,

il est alors facile de comprendre que des outils collaboratifs permettant :

  • l’organisation (product process workflow)
  • l’industrialisation
  • l’automatisation

des tâches sont indispensables.

Alors, existe-t-il des solutions ?

Tout d’abord, Le Devops, tendance visant à aligner les équipes de développement et les « ops » – intégrateurs – chargés d’exploiter les applications existantes, a permis de voir l’émergence d’outils d’industrialisation des étapes de CONSTRUCTION, CONTROLE QUALITE et DEPLOIEMENT.

Ensuite, Les institutionnels du génie logiciel (IBM, HP, Oracle, Microsoft, etc.) fournissent des plate-formes collaboratives couvrant les étapes allant de la DOCUMENTATION au TEST.

Enfin, des éditeurs spécialistes et des projets OPEN SOURCE (les deux sont pléthoriques), des acteurs majeurs de la Net Economie (Google, Amazon, etc.) couvrent unitairement ou par partie l’ensemble des différentes étapes, charge à l’équipe « Devops » de les assembler pour constituer une véritable « USINE A PRODUIRE A FLUX TENDU ».

Dans le prochain article, nous verrons s’il est aberrant de faire cohabiter PMO, GANTT et SPRINT.

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.