On était au Devfest 2018 – IMT Lille Douai

Le 21 Juin 2018 avait lieu le devfest 2018 à l’IMT Lille Douai. Il s’agit d’une journée de conférences, codelabs autour de sujets technologiques innovants.

Tout démarre par une keynote d’Alexandra Nemery & Sarah Colmon. Elles ont su captiver l’auditoire avec un petit quizz interactif sur le thème des jeux vidéo sur kahoot.it. Elles ont ensuite tenté de faire le lien entre le monde de l’UX et celui des jeux vidéo, en prenant quelques exemples de jeux dont l’ergonomie n’est pas adaptée soit au device, soit aux habitudes des utilisateurs (joueurs). Et si Shigeru Miyamoto, célèbre créateur de Mario et Zelda, était le premier vrai visionnaire de l’UX ?

On a ensuite assisté à une introduction de gRPC par Sébastien FRIESS. Ce framework s’appuie sur le protocole HTTP/2 et utilise Protocol Buffers pour permettre d’échanger des données entre briques applicatives de façon performante. Sébastien nous a présenté le schéma de description des messages (IDL), puis une démo client/serveur. Il a apporté des modifications aux schémas de données à chaud, côté serveur puis côté client, pour démontrer que les échanges n’étaient pas impactés.

Sébastien Pertus nous a présenté les modules dans EcmaScript 6 et nous a également parler de TypeScript. Il a d’abord fait un historique et un focus sur Node.js puis nous a présenté sous forme de démos l’utilisation des modules dans les navigateurs.

Alexis Hassler nous a fait une revue de HTTP/2 et de son support dans les navigateurs, frameworks web, serveurs d’applications… La démo d’Alexis nous a permis de constater l’efficacité du multiplexage (utilisation de la même connexion tcp) de HTTP/2 sur le chargement de plusieurs éléments d’une page web. Il nous a également parler de la compression des headers http et du « server push » qui permet au serveur de pousser des ressources avant même qu’elles soient demandées par le client. On a pu apprendre que le support d’HTTP/2 est assez hétérogène et que l’utilisation du « server push » n’est pas forcément très simple pour le moment et nécessite de vérifier toutes les briques (reverse proxy, …) séparant le client du serveur.

On a vu différentes méthodes pour protéger ses API avec Léo Unbekandt. Les « API tokens » sont parfaits pour débuter rapidement et sont simples mais ne sont pas idéaux dans un écosystème distribué. Oauth 2 permet d’utiliser un vrai standard partagé mais implique beaucoup de complexité et d’appels client/serveur, cela reste néanmoins une excellente méthode pour faire de la délégation d’identité. Les tokens JWT peuvent être une bonne alternative dans le sens où le token peut être directement validé par le serveur sans appel supplémentaire, les jetons étant signés avec une clé privée connue du serveur.

Christophe Furmaniak & Yoan Rousseau, nous ont parlé de monitoring et d’alerting dans des environnements conteneurisés. Ils ont présenté l’outil de monitoring Prometheus dont le principe est de collecter les métriques en mode PULL dont l’un des principaux avantages est que les applications n’ont pas connaissance de l’infrastructure de monitoring, ce qui simplifie la configuration. Les applications ont tout de même la possibilité de venir Pusher des métriques via un composant intermédiaire que Prometheus utilisera pour collecter la donnée. Il nous ont également montré l’utilisation de Grafana qui permet la visualisation et la mise en forme des métriques collectées par Prometheus. Enfin, la problématique de mise en cluster de Prometheus a été rapidement abordée, le projet Thanos a été mentionné pour répondre à ce besoin. Nous pouvons conclure que Prometheus est adapté pour le monitoring mais n’est pas fait pour stocker des logs ou des événements, il n’est pas fait non plus pour tracer les requêtes dans une architecture microservices où il faudra utiliser des outils comme OpenTracing / Zipkin.

Le composant Istio nous a été présenté par David Gageot. Istio permet d’appliquer le pattern « façade » (ou sidecar) à son architecture micro-services au sein d’un environnement Kubernetes : un proxy HTTP Envoy est adossé à chaque micro-service, ce qui permet d’ajouter des traces, de monitorer, sans rien modifier dans son code ou son déploiement. Istio permet également de faire du TLS automatiquement entre les services, de router le traffic plus finement… David nous a fait une démo de canary deployment où un fix a été déployé pour un seul utilisateur en fonction d’une entête HTTP. Puis il a effectué un blue/green deployment, avec un routage d’une partie des requêtes vers la nouvelle version de l’application et une bascule progressive. Malgré l’effet démo subi par le speaker, cette conférence était très intéressante et Istio est vraiment prometteur.

Aurélien Loyer et Nathan Damie nous ont parlé de Javascript et des frameworks Javascript web. On a eu droit à une petite séance de pair-programming en live sur les bindings en Javascript via le « framework » Vanilla 🙂 Le message de fond est de démarrer simplement avec du pur Javascript, bien comprendre et spécifier son (éventuelle) problématique, et ensuite choisir (ou non) un framework qui colle rééllement à cette problématique.

Au niveau de l’organisation, c’était excellent, très bien organisé et fluide. Il y avait toujours de la place à condition d’arriver à l’heure dans l’amphi (quelques uns ont fini sur les marches, des souvenirs de début d’année en fac..) C’est également l’occasion de recroiser de nombreuses têtes rencontrées au détour de missions dans la région 🙂 Les sponsors proposaient de nombreuses animations, baby foot, bornes d’arcade, etc. On regrettera juste des soucis récurrents avec le projecteur de l’amphithéâtre principal qui a occasionné quelques coupures et slides tronqués. Globalement les présentations étaient de qualité avec des speakers au niveau.

On reviendra avec plaisir l’année prochaine !

Alexandre Vandekerkhove et Maxime Decronambourg

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.

QUALIFICATION DES BESOINS : Les 3B

Qualifier les besoins rapidement et efficacement est aujourd’hui un véritable facteur de réussite et de croissance pour les entreprises.

En effet, les technologies évoluant de plus en plus vite, elles permettent :

  • de mettre en œuvre de nouveaux concepts (net économie, objets connectés, digitalisation des entreprises, learning machine, 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 ne sont-ce pas plutôt des BUZZ) 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).
Tout d’abord cadrons le contexte de cet article.

Celui-ci ne s’adresse pas aux créateurs d’entreprise ou de startup. Pour ceux-ci, je pourrai conseiller un ouvrage « Le Manuel du créateur de startup » de Steve Blank et Bob Dorf, qui leur permettra de répondre à leurs interrogations, si ce n’est pas déjà fait.

Il s’agit ici de s’inscrire dans le cadre d’une entreprise du type « Scale Up »  (Une scale up? Une start-up qui a déjà fait du chemin, qui a prouvé la valeur de son business model, trouvé son marché, connaît une croissance forte, a donc maintenant des directions RH, Marketing, Commercial, Financières et nourrit de sérieuses ambitions en termes de déploiement de son modèle sur son territoire ou à l’international.) ou du type « Corporate Collaborative » (Une entreprise organisée à travers de Business Units, de départements, des services, déployée sur différents sites géographiques et ayant la volonté de mettre en place des outils de collaboration).

Pour les premières, le challenge est de garder l’esprit créatif de la startup alors même que l’on ne partage plus le même bureau, voir le même site géographique.

Pour les secondes, il s’agit de profiter de l’esprit créatif de chaque collaborateur (dispersé géographiquement) en évitant l’effet « Boite à idées – Boite à coucou ».

Le cadre étant posé, prenons un exemple :

Je suis dans le département Marketing de mon entreprise dont le business est l’organisation d’événements.

Mon « Community Manager » me signale que les internautes sont de plus en plus friands de solutions de cagnottage pour le paiement de cadeaux d’anniversaire, de mariage, etc.

 

LA BELLE IDEE

N’existe-t-il pas un besoin de mise en place d’un nouveau moyen de paiement du type « Cagnotte » pour mon entreprise ?

A priori, c’est une Belle Idée, non ? Mais est-ce un besoin réellement implémentable dans le contexte de mon entreprise ?

 

UNE BONNE IDEE ?

Les questions auxquelles il faut alors, impérativement, apporter des réponses sont :

  1. Suis-je capable de la décrire ?
    • A minima : En tant que « X » Je souhaite « ….. » Afin de « …. »
    • Au mieux : Les processus métiers qu’elle crée ou modifie
  2. Y-a-il adhésion des autres responsables ?
    • Force de vente
    • Juridique
    • Finance
  3. Existe-t-il des contraintes techniques, légales, financières, etc. ?
  4. Mon entreprise est-elle prête (IT, Organisation, etc.) ?

C’est ici qu’un outil collaboratif trouve sa raison d’être à condition qu’il possède les fonctionnalités suivantes :

  1. Identification, création du besoin (En tant que, Je souhaite, Afin de)
  2. Description du besoin à travers du design de process (au mieux), de mind mapping, mockup, de documents joints
  3. Fonctionnalités de commentaires (échanges, demandes de précision, etc.) sur le besoin
  4. Mise en œuvre de Followers, Vote, Like (fonctions implémentées dans les outils de réseau sociaux)
  5. Historisation des événements ayant eu lieu sur le besoin et tableau de bord de synthèse permettant d’identifier au plus vite l’effet BUZZ (Nombre de commentaires dans le temps, Fluctuation dans le temps de Followers, Like, etc.)

Alors, cet outil existe-t-il ?

Loin de moi l’idée de faire ici une étude exhaustive des outils pouvant répondre à cette question.

Je me contenterai donc de vous citer deux outils faisant partie de mon retour d’expérience sur le sujet :

  1. JIRA – CONFLUENCE et ses PlugIn

    • Identification et création du besoin
      • Création d’un type de demande « NEED » (JIRA CORE)
      • Ajout de quelques données personnalisées (JIRA CORE) :
        • EN TANT QUE : Un champ « Liste » des départements de l’entreprise
        • JE SOUHAITE : Un champ « Texte libre »
        • AFIN DE : Un champ « Label »
      • Description du besoin
        • Mind Mapping : PlugIn « EasyMind »
        • Mockup : PlugIn « Balsamiq Mockup »
        • Process Design : PlugIn « Draw.io »
      • Echanges et précisions
        • Utilisation des fonctionnalités de « Commentaires » associés à chaque demande (JIRA CORE)
      • Contraintes
        • Ajout d’une donnée personnalisée (JIRA CORE) :
          • CONTRAINTES : Un champ « Liste à 2 niveaux » à choix multiple dont le 1er niveau est une liste de contraintes (Juridique, IT, Logistique, Concurrentielle, Conduite du changement, etc.) et le 2ème niveau est une liste de poids (Bloquante, Forte, Surmontable, etc.)
        • Adhésion
          • Utilisation des fonctionnalités de « Observateurs », « Vote » (JIRA CORE)
        • Tableau de bord
          • Utilisation des Gadgets adéquats sur les tableaux de bord (JIRA CORE)
  1. HAPPLIES

    Je vous invite à visiter le site de Happlies pour en découvrir tout le potentiel.

A ce niveau, en un minimum de temps et un maximum de collaboration, j’ai

  • partagé une idée,
  • décrit le(s) besoin(s) correspondant(s)
  • vérifié qu’elle suscitait (ou pas) un intérêt
  • qu’il n’existait pas de contraintes rédhibitoires (ou risques) associées à l’implémentation de celle-ci

Ce travail a été effectué sur notre implémentation d’un nouveau moyen de paiement « CAGNOTTAGE ».

Compte tenu des résultats obtenus (bons vous l’aurez deviné), nous considérons qu’il s’agit d’une BONNE IDEE.

D’ailleurs, n’étant pas le seul à avoir des idées (traduit en besoins), qui peuvent ne pas être toutes bonnes, il n’est pas inutile de leur donner un état et d’utiliser un workflow (présent à la fois dans JIRA et HAPPLIES) pour les « classer » et effectuer des statistiques (Taux de transformation, Durée de transformation, participant à la collaboration, etc.) afin d’améliorer mon processus de détection des bonnes idées :

3B Workflow Partie 2

 

Evidemment, comme toute entreprise « commerciale », la mienne cherche à faire des bénéfices même si elle doit passer par des investissements.

 

DU BUSINESS ?

A ce stade, il est temps de savoir si mon idée (MON BESOIN) est génératrice de profits (BUSINESS, le 3ème B).

Pour cela, j’ai l’habitude d’utiliser une déclinaison du « Business Model Canvas » d’Alexander Osterwalder (Livre « Business Model, nouvelle génération »).

Voici le canvas :

BMC

Les grands principes :

  1. Au centre
  • LE BESOIN
    • Identification
    • Le triptyque « En tant que – Je souhaite – Afin de »
    • Les fonctions à mettre en œuvre pour réaliser le besoins (Si le travail a été bien fait au niveau « BONNE IDEE ? », les échanges, les contraintes ont permis de les identifier).
      Ici, le nombre de fonctionnalités à mettre en œuvre ou à modifier est un 1er indicateur de complexité et d’effort de concrétisation
  1. En haut – A gauche
  • LES COUTS (Je me fais peur)
    • INITIAUX
      • ACHATS : Ce qu’il faut acheter pour commencer
      • ACTIVITES : Les activités de l’entreprise qu’il convient d’activer pour commencer (Souvent, il s’agit de coûts liés à des ressources d’expertise interne à l’entreprise)
    • RECURRENTS
      • Les achats et activités récurrentes (annuels) nécessaire au maintien du besoin dans le temps.

A ce niveau, je commence par identifier les postes.
2ème indicateur : Plus je mets en œuvre d’activités (surtout initialement), plus le projet sera complexe à lancer. Mon entreprise est-elle donc prête pour intégrer le besoin.

Si oui, j’essaie d’estimer les coûts associés à chaque poste.

3ème indicateur : Plus je détaille les postes et coûts, plus je limite le risque de dérapage financier.

  1. En haut – A droite
  • LES REVENUS (je me rassure)
    • OFFRES : Déclinaison en offres du besoin (Abonnement, Support, etc.) et les revenus qu’elles génèrent à l’an 0 et l’an 1.
      4ème indicateur : Tant que je n’ai pas d’offre, cela reste une bonne idée.
    • CIBLES CLIENTS : Déclinaison des cibles clients adressés (Ménagères de moins de 50 ans, Adolescents et jeunes adultes) et les revenus nouveaux ou supplémentaires que le besoin générera.
      5ème indicateur : Tant que je n’ai pas de cible, cela reste une bonne idée.
  • LES CANAUX DE DISTRIBUTION
    • Par quel canal mon besoin sera distribué (Internet, Magasin, Partenaire, Porte à Porte -sic-, etc.)
      6ème indicateur : Pas de canal identifié, cela reste une bonne idée.
  1. Au milieu – A droite
  • CHECK OFFRES – CIBLES CLIENTS
    Je vérifie que ma vision des revenus liés aux « OFFRES » est cohérente avec celle des revenus « CIBLES CLIENTS ».

J’ai souvent eu des surprises à ce niveau et cela m’a évité de me lancer dans des développements non rentables.

7ème indicateur : Inutile de continuer tant que les deux visions ne sont pas alignées.

(NB : On comprend mieux ici que ce modèle est plus adapté aux entreprises du type « Scale Up » et « Corporate » qui sont sensés connaitre leurs coûts, leurs clientèles contrairement aux Start-Up qui sont plutôt en phase de découverte).

  1. Au milieu – A gauche

Une synthèse des coûts : Initiaux & Récurrents

  1. En bas – A gauche
  • La durée de l’amortissement (c’est ici un gros abus de langage, que les DAFs ne me jettent pas la pierre), permettant de calculer les besoins de financement (ici encore, on ne m’en voudra pas pour l’approximation) par année.
  1. En bas – A droite
  • Le calcul de rentabilité sur la durée de l’amortissement.

(Remarque : Le fichier Excel à télécharger ici BMC.xlsx est une déclinaison sans prétention de cette adaptation)

A ce niveau, si le calcul est positif, l’idée (les besoins) est génératrice de BUSINESS.

Si vous êtes encore là, en train de lire et encore suffisamment attentif (et pas las), vous ne manquerez pas de me poser la question suivante « Existe-t-il un outil de ce type ? ».

Pour ma part, je n’en ai pas trouvé de ce type.

Le PlugIn « Comala » pour Confluence, permet de créer des canvas (notamment basés sur le « Business Model Canvas » d’Alexander Osterwalder).

Le site https://canvanizer.com permet créer différents types de canvas et de les partager.

Je suis preneur pour toute suggestion de votre part.

 

Enfin, quant à savoir si l’idée de « Cagnotte » est génératrice de BUSINESS : …
D’ailleurs, ce n’est pas parce qu’une idée n’est pas bonne (ou génératrice de business) à un instant T dans un contexte C, qu’elle ne peut pas le devenir.

A ce propos, j’allais oublier : Complétons notre workflow « NEED » comme ceci, toujours dans l’idée que les informations qu’il fournira, permettront d’améliorer les performances de qualification de besoin dans le futur et éventuellement de revenir sur celle-ci pour la requalifier ultérieurement en gardant la trace des travaux précédents :

EB Workflow Partie 2

En espérant que cet article vous aura été profitable.

La cohabitation PMO, GANTT et SPRINT

Peut-on faire cohabiter PMO (Project Management Office), GANTT et SPRINT ?

 

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). Ces projets sont VERSIONNES pour être DELIVRES à travers des SPRINTS (de 3 semaines à un mois).

L’article « Ending the agile/PMO tug of war » aborde la même problématique.pmo-vs-agile

La question sous-jacente est donc « Comment faire une synchronisation en temps réel ou à la demande de ses différents éléments ? ».

Prenons un cas d’école pour essayer de répondre à cette question :

Une entreprise voulait mettre à disposition de ses utilisateurs des fonctionnalités « QuickWins » a créé une « cellule AGILE » qui -comme son nom l’indique- applique les concepts de l’AGILITE.

Son objectif : Une mise en production de qualité, 1 fois par mois au pire.Agile

Cette « cellule AGILE », adepte du « devops », par ailleurs créative et efficace (Mode « Start Up »), s’est tout de suite outillée en utilisant JIRA AGILE (maintenant JIRA Software) pour la gestion de ses projets et a intégré certains de ses plugIns pour faire de l’intégration continue.

Après quelques explications aux KeyUsers, producteurs des QuickWins, sur ce qu’est une épopée, un récit, un backlog et un sprint, ce qu’ils doivent contenir à minimum, ceux-ci alimentent JIRA avec leurs récits (QuickWins) et les fameux « En tant que – Je souhaite – Afin de ».

Premier planning poker (KeyUsers, Team Leader et Team Dev), premier lancement de Sprint, c’est parti.

Collaboration, daily meeting, entre-aide, recette et ajustements, 3 semaines passent.

Bingo, 1ère mise en production. Un succès.

Les Sprints passent et se ressemblent : les objectifs sont remplis.

Entre temps, bien sûr, la « cellule AGILE » continue l’industrialisation de ses processus de production (Intégration d’un plugIn de gestion des tests, Automatisation des tests de non régression, Dockerisation, etc.) et le scrum master mesure le capacitif de réalisation de son équipe permettant ainsi de définir au mieux le contenu des sprints.

Par ailleurs, les KeyUsers ravis (c’est un cas d’école, je le répète), mettent la pression sur la direction pour élargir l’agilité à autre chose que des QuickWins.

Cette demande est évoquée lors d’un comité de direction.

C’est alors que le DAF signale qu’il n’a pas de visibilité sur les coûts associés aux réalisations de la « cellule Agile », ce qui n’est pas grave quand il s’agit de « QuickWin » (budgété en ON GOING à l’année sur une taille d’équipe constante) mais peut le devenir pour des réalisations de plus grande ampleur.portfolio

Sur ce, le DSI rebondit en mettant en évidence que la taille de l’équipe pouvant fluctuer dans le temps (on est plus dans un cadre de ON GOING), il conviendra d’avoir une visibilité sur les charges de réalisation pour anticiper les besoins en ressources de la cellule.

Les directeurs de départements, quant à eux et unanimement, souhaitent maintenir les arbitrages sur les priorités de réalisation et continuer à avoir une visibilité sur les dépendances de réalisation.Gantt

Tous conviennent que l’idée est belle mais que pour qu’elle soit bonne, il convient de mettre en place un outillage permettant de préserver l’AGILITE mais aussi de planifier (GANTT) et de « coster » (PORTFOLIOS).

Qu’à cela ne tienne, demandons à notre prestataire préféré (encore une fois, c’est un cas d’école), de faire une étude de faisabilité.

Ce dernier mène sa réflexion sur le constat suivant :

Ne remettons pas en cause ce qui fonctionne. La cellule AGILE ayant basé son industrialisation sur JIRA, il faut le préserver à tout prix.

Etudions les plugIn JIRA qui permettent de répondre à la problématique qui m’est posée.

Atlassian (éditeur de JIRA) et les éditeurs de plugIn permettent d’avoir des versions d’évaluation d’un mois, c’est justement ce qu’il me faut se dit le prestataire pour faire une démonstration et la présenter au prochain comité.

Voici des extraits de cette présentation :

Solutions étudiées

JIRA SOFTWARE

BACKLOG & SPRINT

Backlog - Sprint

  • Un Backlog qui reprend l’ensemble des tâches non terminées et non affectées à un sprint
  • Création de 1 à n Sprint

SCRUM – SPRINT ACTIF

 sprint actif

  • Scrum = KANBAN
  • Paramétrage du Workflow des états des demandes par type de demande

BIG PICTURE

GANTT & BASE LINE

Gantt

  • Cross Projet ( 1 programme = 1 à n projets)
  • Synchronisation avec JIRA :
    • Tout changement dans JIRA (Ajout, Modification, Suppression de tâches, etc.) se répercute sur le GANTT
  • Ordonnancement des tâches
    • Au sens WBS è N’impacte pas le ranking du Backlog et des Sprints
  • Déplacement dans le temps et changement des durées des tâches
    • Ne modifie pas la Due Date de JIRA SoftWare
  • Intégration des dépendances entre tâches
    • Fin-Début, Début-Début avec délai en jours
  • Planification automatique ou à la demande
  • Base Line
    • Mémorisation à la demande des dates de début, fin de toutes tâches ou de tâches sélectionnées
  • Gestion de tâches non JIRA Software (Tâches artificielles)

CHEMIN CRITIQUE

chemin critique

  • Représentation des chemins critiques

MATRICE DES RISQUES

Risk Matrix

  • Placement des demandes à risque dans une matrice que l’on peut afficher sous-forme de Gadget dans le tableau de bord

ROAD MAP

Roadmap

  • Représentation d’une road map et des dépendances de réalisation

UTILISATION DES RESSOURCES

Team Occupation

  • Table de représentation des temps passés et planifiés par équipe et ressource

TEMPO FOLIO

COUTS DES RESSOURCES

Cout personnel

  • Gestion des coûts des ressources

PREVISION DES COUTS

Coût prévisionnel

  • Rapport des coûts réalisés, planifiés

RAPPORT DES DEPENSES

Rapport des dépenses

  • Gestion des dépenses (CAPEX – OPEX)
  • Reporting associé

RAPPORT DES COUTS DE DEMANDES

Rapport des coûts des demandes

RAPPORT COMITE DIRECTEUR

Rapport du comité directeur

Migration REDMINE vers JIRA AGILE

Aujourd’hui, notre client utilise deux outils de gestion des demandes (REDMINE – JIRA AGILE) :

  • Redmine
    PROJETS « METIERS »

 

  • JIra Agile
    PROJETS ERP et ECOMMERCE gérés en mode AGILE

 

Celui-ci souhaite vérifier qu’une migration REDMINE vers JIRA AGILE est possible et qu’elle lui permettra de retrouver ses fonctionnalités de reporting orienté KPI (indicateurs de performance).

Il a donc confié à SALTO cette prestation pour laquelle nous avons adopté le phasage suivant :

  • PHASE « MIGRATION REDMINE – JIRA AGILE« 

    1. Migration de 3 projets REDMINE vers JIRA AGILE
    2. Configuration de JIRA AGILE pour minimiser la conduite du changement (Filtres, rapports, vues et écrans similaires à ceux utilisés dans Redmine)
    3. Restitution des résultats
    4. Documentation de la procédure de migration

 

  • PHASE « KPI« 

    1. Intégration de PlugIns JIRA AGILE complémentaires
    2. Paramétrage et configuration pour retrouver les fonctionnalités ISO, notamment au niveau des KPIs
    3. Restitution des résultats
    4. Documentation des PlugIn JIRA AGILE

La suite de cet article se propose de synthétiser les résultats de la phase « MIGRATION », l’autre phase étant trop spécifique au contexte client.

Sachez cependant, que nous avons pu obtenir des résultats équivalents aux reportings Redmine grâce notamment aux plugings « Tempo TimeSheet », « Tempo Planner » et « Tempo Folio ».

MIGRATION

JIRA offre en standard des outils d’importation dont voici la liste :

Importation natives JIRA

On y retrouve notre composant d’importation pour Redmine.

Celle-ci se fait en plusieurs étapes :

Etapes de migration Redmine

  1. La connexion à l’instance de Redmine sur laquelle se trouve les projets à migrer
  2. Le choix des projets Redmine à migrer et le mapping vers les projets JIRA AGILE d’accueil
  3. Le mapping des champs personnalisés de Redmine vers les champs personnalisés JIRA
  4. Les champs à mapper (priorité, statuts, type de ticket)
  5. Pour chaque champ à mapper, l’association avec les valeurs de JIRA (plus exactement aux valeurs configurées pour les projets JIRA sélectionnés)
  6. Le mappage des liens entre les tickets (exemple : Copied à mapper avec Cloned)
  7. Et enfin, le lancement de la migration

On s’aperçoit vite qu’il convient, préalablement à la migration, de créer les projets JIRA AGILE d’accueil et de les configurer de façon à ce que l’on puisse mapper en 1 pour 1 les champs, les valeurs et les liens.

Nous avons donc créé une configuration « Migration RedMine » dans JIRA AGILE (dont chaque projet d’accueil « héritera »), comme par exemple :

  • Les types de demande et le schéma associé
  • Les écrans et les systèmes associés
  • Le WorkFlow et son système
  • Les champs personnalisés et leur système
  • Les droits pour l’intégration des rôles « Redmine » spécifiques (voir ci-après)
  • Etc.

Nous avons par ailleurs du créer :

  • les liens spécifiques
  • les rôles spécifiques

entre autres.

C’est une fois ce travail préparatoire effectué que la migration se fait sans problème.

Remarquons que l’on retrouve les identifiants des tickets Redmine dans le champ JIRA « External issue ID« . Cependant, pour ceux qui ont créé des liens entre les trakers dans les commentaires (#idt tracker) c’est un peu perdu.

Pour ce qui concerne la conduite du changement, JIRA offre tellement de possibilités de paramétrage, qu’elle peut être réduite au strict minimum, cela d’autant plus que

  • l’ergonomie proposée par JIRA est « Up To Date »
  • les TABLEAUX KANBAN, les DASHBOARDs, les WIDGETs

sont de véritables outils de productivité.

Enfin, l’intégration de PlugIn JIRA permet de palier à certains manques de JIRA (versus Redmine, s’entend) :

  • Le Gantt (mais est-ce réellement utile avec l’AGILITE) : Les plugIn sont nombreux quand il ne s’agit que d’un affichage
  • La feuille de temps : TEMPO TIMESHEET est une solution plus que satisfaitante

Pour conclure, l’importation des projets Redmine vers JIRA AGILE est réellement efficace à condition de l’avoir correctement préparée.

Création d’un Plugin JQuery : Input Prefix

Pour les besoins d’un projet, nous avons développé un plugin JQuery permettant d’ajouter un préfixe à valeur fixe dans les balises « Input ».

Il est alors impossible d’effacer, modifier ou couper ce préfixe…

Par contre il est toujours possible d’ajouter du texte après le préfixe, sans autres limitations que celles par défaut !

Plugin JQuery

Le plugin sur Github :

https://github.com/gfruleux/jquery-plugin-input-prefix

Demo sur Jsfiddle :

https://jsfiddle.net/97vuzwba/50/

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.

Symfony 2 : Grande distribution

Pour le compte d’un client de la grande distribution, nous développons « from scratch » une application de gestion grâce au framework Symfony 2.

Une large liste de composants et une communauté très active, entres autres, font de ce framework une valeur sûre pour réussir vos projets.

Pour découvrir les avantages, cas d’usage, et bonnes pratiques de Symfony 2, contactez-nous et parlons PHP !

Symfony 2

Prototypage d’un gestionnaire d’événements REST-JSON : Grande Distribution

Notre client, acteur de la grande distribution, nous a sollicité pour une refonte de son SI. En effet, l’architecture logicielle actuelle ne permet plus de soutenir sa croissance.

Les 3 exigences exprimées par le client :

  1. Un référentiel de données d’entreprise centralisé
  2. Un fonctionnement autonome de ses agences locales : pouvoir faire des réservations et des ventes, même si le référentiel de données d’entreprise centralisé n’est pas accessible
  3. Un point d’accès unique aux données du référentiel par les différentes applications du SI

L’architecture préconisée par SALTO dans ce cadre :

  1. Mise en oeuvre d’un ERP (Apache OfBiz) pour la gestion du référentiel des données d’entreprise (Réponse exigence 1)
  2. Echanges inter applicatif gérés par un gestionnaire d’événements centralisé (basé sur les technologies NodeJS & MongoDB ) :
    • Abonnement des applicatifs du SI aux événements stockés par le gestionnaire d’événements pour synchronisation de leurs données (réponse exigence 2)
    • Mise à jour des données du référentiel centralisé par push d’événements (Création, Mise à jour) vers le gestionnaire de flux (réponse exigence 3)

SALTO a réalisé :

  1. Un prototype du gestionnaire d’événements en NodeJS / MongoDB
  2. Une démonstration de celui-ci à travers la mise en oeuvre de mouvements de stock sur 3 instances d’OfBiz (2 instances mettant à jour les stocks, une instance synchronisant et centralisant les stocks)

La suite :

  1. Centraliser et synchroniser les données B2C
  2. Migrer les données existantes ( ~ 500 000 occurrences) vers l’ERP « Référentiel de données » à travers le gestionnaires d’événements (pour test de montée en charge du gestionnaire d’événements)
  3. Réaliser des IHMs d’administration du gestionnaire d’événements