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

Continuous Documentation – Une pratique saine

continuous-documentation

Souvent perçue comme une corvée, la documentation est dans la plupart des cas délaissée. Au mieux elle est reportée en fin de projet, au pire elle finit à la trappe. Les raisons de cette perdition sont souvent le manque de temps ou de budget. En fin de course, il est difficile de négocier une rallonge pour rédiger de la documentation.

Pourtant, l’utilité de celle-ci fait souvent l’unanimité. Elle est un facteur clef pour le maintien en condition opérationnelle (MCO), sur l’intégration de l’application au sein du SI ou encore facilite la prise en main du projet par une nouvelle recrue.

Par ailleurs, celle-ci fait partie des bonnes pratiques de la méthodologie Agile. En effet, les préceptes de la méthodologie agile recommande d’arriver à un état livrable de votre application à la fin de chaque sprint, alors pourquoi ne pas l’y inclure?

Les bénéfices

Une documentation disponible à chaque fin de sprint/jalon

La rédaction au-fur-et-à-mesure vous garantie d’avoir une documentation synchronisée avec l’évolution de votre application. Vous éviterez ainsi l’écueil d’une application sans documentation en fin de projet, et de ne plus disposer de moyens – temps et/ou budget – pour la réaliser. De plus à la fin de chaque sprint, votre application est dans un état livrable. Elle contiendra, à minima, d’un guide de l’utilisateur, d’une notice d’installation ou d’un manuel d’exploitation. Bref, votre application prend l’air d’un produit fini et délivrable à un client.

Une documentation précise

D’autre part, vous vous rappellerez plus aisément des points les plus importants en rédigeant leurs documentations dans un délai assez court après leurs réalisations. En conséquence, votre documentation en sera d’autant plus précise.

Une documentation pour chaque version de l’application

Enfin, cette synchronisation du code et de la documentation les met dans un cycle de vie identique. Code source et documentation évoluent ensemble, et pourquoi pas versionnée ensemble. Vous disposez, alors, d’une documentation adéquate en fonction de chacune des versions de votre application. Ainsi, par exemple, la dernière version de la documentation décrit les nouveaux paramètres d’une fonctionnalité, la précédente ceux devenus obsolètes mais encore valable pour la version antérieure (tout est bien dans le meilleur des mondes).

Les écueils

Documenter au moment opportun

Les exigences sont susceptibles d’évoluer tout au long du projet, vous obligeant à retravailler la documentation pour refléter ces changements. Aussi, il est préférable de ne pas documenter trop vite ou trop souvent. Mieux vaut attendre un état stable du produit. Vous éviterez ainsi de perdre du temps et de l’argent à retravailler la documentation.

Une documentation concise et adaptée aux besoins du produit

Il n’est pas nécessaire de tout documenter. La documentation n’a pas vocation à remplacer un cahier des charges ou des spécifications techniques. Bien souvent il sera préférable d’y trouver le manuel d’utilisation (accompagné d’exemples), un guide d’intégration, la description des API, etc. De plus, mieux vaut ne pas trop en faire. La rédaction doit rester rapide et concise.

Dans un prochain article, je vous présenterai un exemple de mise en oeuvre d’une « Continuous Documentation ».

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/

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

 

Jhipster : le générateur Spring Boot + AngularJS


JhipsterJhipster
est un générateur Yeoman qui permet de créer des projets Spring Boot / AngularJS. Créé par Julien Dubois, il permet d’utiliser un back-end efficace (Spring) parfaitement adapté à AngularJS, pour satisfaire les équipes qui ont des grandes exigences de time-to-market !

Dans le cadre d’un projet de cartes cadeaux, Salto Consulting a réalisé l’ensemble de l’architecture, du développement et de l’intégration Salesforce, pour un client de la grande distribution.

Si vous souhaitez découvrir Jhipster à travers un retour d’expérience, nous organiserons un Dojo avant l’été, contactez-nous pour y assister !

Rencontrez-nous : les événements IT de l’été 2016 à Lille

Venez nous rencontrer durant cet été 2016, nous serons présents sur différents événements IT :

1er Juin: Tour de France Digitale @Euratechnologies

2 Juin: Atlassian Tour @Euratechnologies

3 Juin: Euratech Days @BlancheMaille

5&6 Juillet: Summer Days @Euratechnologies

Et d’autres événements à venir…

Lille_Euratechnologies_small

France Digitale

Le Tour de France digitale, c’est le rendez-vous des futures startups de la frenchtech ! Les meilleures startups ont besoin des meilleurs développeurs, nous venons à leur rencontre ce 1er juin à Euratechnologies ! Inscrivez-vous, c’est gratuit : https://www.eventbrite.fr/e/billets-tour-de-france-digitale-a-lille-1-juin-23985354842

 

Atlassian Tour

Jeudi 2 Juin se tiendra le rendez-vous français des débutants, experts, et tous ceux qui souhaitent découvrir JIRA et ses outils (Confluence, Bitbucket…) Nous mettons régulièrement en place JIRA pour nos clients PME et grands groupes, nous serons donc présents pour discuter de vos questions et vos projets autour des produits Atlassian.

 

Euratech Days

Les EuratechDays auront lieu à BlancheMaille (Roubaix) vendredi 3 Juinhttp://www.eventbrite.fr/e/billets-euratechdays-blanchemaille-25168155631

Découvrez l’histoire et l’écosystèmes de BlancheMaille et de ses startups !

 

Euratech Days Summer

Les 5&6 Juillet à Euratechnologies : plus d’informations à venir !

 

 

Retour sur la soirée GitHub au ChtiJUG du 9 décembre 2015

Ce Mercredi 9 décembre à l’Université Lille 1 à Villeneuve d’Ascq se tenait un Ch’ti JUG qui avait pour thème : Comment GitHub build GitHub.GitHub

Alain Helaili (@AlainHelaili) travaille chez GitHub et nous a présenté l’entreprise et montré en partie quelle était leur façon de travailler et les outils qu’ils utilisent.

Il a commencé par nous apprendre l’histoire originale de l’entreprise : des associés en Californie qui voulaient développer une super idée. Pour améliorer leurs conditions de travail, il ont créé une application autour du gestionnaire de source git. Puis ils l’ont partagé, jusqu’au jour où une entreprise a voulu l’utiliser. Il a donc fallu créer la société : GitHub, pour pouvoir vendre et trouver un prix. A ce moment là, DropBox proposait du stockage pour 7$/mois… le prix était trouvé.

Le contexte aussi est intéressant : les associés, même à coté, discutent par chat. Et le leitmotiv est que tout doit avoir une URL pour exister. Ainsi le travail est plus facilement collaboratif et asynchrone : pratique quand on travail sur plusieurs « time zone », surtout quand on sait que l’entreprise de près de 500 salariés est répartie un peu partout dans le monde ! Par ailleurs, l’une des valeurs fondamentales de GitHub est que tout soit le plus simple possible, quitte à omettre des fonctionnalités ou les retravailler jusqu’à ce que l’utilisation en devienne une évidence.

Alain nous a ensuite montré comment fonctionnait l’organisation du développement dans la société. Notamment via l’utilisation des issues et pull request. Ce qui transparaît le plus était pour moi :

  • L’absence d’e-mail au profit de création d’issue ou pull request afin de rendre visible les décisions et qu’elles soient de fait toujours documentées.
  • L’outillage devops notamment avec hubot le robot avec qui on discute par chat et qui se charge de déployer en production, faire des opérations de maintenance etc.
  • Le workflow de développement qui contient les phases classique de TU, TI, TNR etc et qui se termine par un test… en production, plutôt que d’imaginer des scénarios de montées en charge qui resteront toujours éloignés de la réalité. La phase finale consiste à déployer en production pendant un laps de temps défini, d’en mesurer les impacts puis de retirer la fonctionnalité le temps de valider qu’il n’y ait pas eu de mauvais impact. Et ce n’est qu’une fois cette validation en production faite que le développement est mis sur la branche principale : master. Ainsi la branche master ne correspond pas forcément à ce qu’il y a actuellement en production, mais elle est le socle de base, fiable pour la production.

Enfin l’application GitHub nous a été aussi présenté comme hautement personnalisable via les hooks et les nombreuses apis disponibles. On a notamment cité :

  • Review Ninja : la gestion des pull request par SAP
  • Gitcolony : également sur les pull request avec notamment la possibilité de les gérer cross-repos
  • Zenhub : qui permet de visualiser les évolutions en cours sous la forme d’un kanban
  • et plus globalement tous les addons disponibles avec GitHub

N’hésitez pas à consulter leur blog http://githubengineering.com pour en découvrir plus encore.

Le seul point négatif à mon sens de cette conférence était la salle dont l’écran était un peu petit et le micro qui coupait de temps en temps. Par contre on peut souligner le super accueil des étudiants de Lille 1 !

Merci à Alain, à l’équipe du Ch’ti JUG (enfin surtout Cyril cette fois-ci ;)) et aux étudiants de Lille 1 !

Matthieu Fernandes

Global day of code retreat

Ce samedi 14 novembre, à l’initiative de Jérémie et de l’association Nord Agile, se déroulait dans nos locaux l’édition Lilloise du Global day of code retreat.

Le GDCR est une journée mondiale durant laquelle des développeurs se réunissent pour améliorer ensemble leurs skills.
Cette année, plus de 140 événements ont été organisés à travers le monde : http://globalday.coderetreat.org/timeline-2015.html

Pourquoi un Code Retreat ?

Beaucoup de développeurs, pendant leurs études ou durant leur vie professionnelle, apprennent des langages de programmation / frameworks / outils.
Mais il n’y a pas ou peu de choses pour apprendre pas à bien coder. Combien de personnes ont déjà suivi une formation « Améliorer la qualité / maintenabilité de son code » ? Pourtant cela coûte cher ! (1)

Le principe du code retreat, c’est justement d’essayer de lever la tête, sortir de son quotidien pour travailler ça.

Comment ça fonctionne ?

Tout au long de la journée, des binômes travaillent par sessions de 45 minutes sur l’implémentation d’un jeu : Le Jeu de la vie.
A l’issue de la session, on efface le code et une rétrospective est menée pour partager les expériences et trouvailles de chacun.
Puis changement de binôme et on recommence avec des contraintes différentes : interdiction de parler, mode ping-pong, pas le droit d’utiliser de « IF », …

Quels enseignements ?

Certains seront sceptiques quant à l’apport réel d’une telle journée et pourtant… sortir de sa zone de confort, ça incite sacrément à la remise en question et à l’ouverture d’esprit !

Code Retreat en action !

Code Retreat en action !

Cette journée, c’est comme vivre plein de petites revues de code en accéléré, avec une mise en pratique immédiate.
Changer de binôme tout le temps permet aussi de découvrir d’autres langages de développement, IDE, méthodes de travail.

Pour aller plus loin : software craftmanship

KPI : 100% de gens satisfaits !

(1) http://www.nist.gov/director/planning/upload/report02-3.pdf – The Economic Impacts of Inadequate Infrastructure for Software Testing