PMSIpilot UI, le thème bootstrap made in PMSIpilot

Chez PMSIpilot, nous développons une multitude d’applications web, que ce soit pour nos clients, ou pour des outils internes. Et pour chaque application, nous sommes confrontés à la problématique du design, de la cohérence par rapport aux autres applications. L’idée d’avoir une base commune s’est donc rapidement imposée.

riad-query

Préconisations

  • Lorsqu’on parle de librairie graphique CSS, on pense souvent à Twitter Bootstrap. Donc pour simplifier l’intégration de nos applications (majoritairement Angular.js) avec les différentes librairies Javascript qui génèrent du code Bootstrap ready, nous avons décidé de développer notre librairie sous forme de thème Bootstrap.
  • Aussi, nos applications doivent avoir la même base, mais une identité unique à chacune des applications à travers les couleurs. Nous avons donc mis en place un système de thème assez simple pour permettre à chaque application de choisir trois couleurs principales.
  • Avec un versionning en semver, et une compilation less effectuée au plus tard (côté application), le workflow de mise à jour du design de nos différentes applications s’est retrouvé grandement amélioré.

Téléchargement
La librairie UI est disponible sur Github et une démo est disponible ici.

Utilisation

Installer la librairie

bower install pmsipilot-ui --save

Inclure les less, et personnaliser son thème

@import 'bower_components/fontawesome/less/font-awesome';
@import 'bower_components/bootstrap/less/bootstrap';
@import 'bower_components/pmsipilot-ui/less/bootstrap';

body {
    .theme-colored(@themeColorOne, @themeColorTwo, @themeColorThree);
}

Agile Barcamp Lyon : Kanban

Je connais la méthode Scrum, pour en pratiquer une partie dans mon équipe, et j’étais intéressée par l’approche Kanban, qui n’est pas itérative avec des sprints isolés comme Scrum, mais qui prend en compte les arrivées en cours de route (les bugs, par exemple) et permet de les intégrer au flux. (Nous traitons ces demandes entrantes dans nos sprints en utilisant la focalisation.) De plus, mon envie de découvrir Kanban a été récemment augmentée, surtout à travers un retour d’expérience, car je suis passée à un travail de maintenance qui peut se faire sans sprint.

Généralités

Kanban signifie étiquette en japonais. C’est une méthode que Toyota a utilisé dans ses usines. Elle consiste à utiliser des caisses étiquetées pour mesurer leur trajet, et ainsi la production. Les étiquettes étant toujours attachées à leur caisse, ce qui permet de tracer leur parcours.

Les principes de Kanban sont de mesurer le Work In Progress (ou en-cours) et de le limiter. En appliquant à un travail informatique, on observe 3 valeurs (et leur évolution) sur notre tableau de bord :

  • le reste à faire
  • l’en-cours
  • le réalisé

On garde à l’esprit que plus on a d’en-cours, moins notre réactivité sur le travail entrant (reste à faire) est bonne.

Principes

Les principes de Kanban sont donc :

  1. limiter les en-cours
  2. produire just-in-time
  3. tiré par la demande

Vous trouverez les principes plus complets sur le site : http://chohmann.free.fr/lean/kanban.htm

Un exemple industriel de Kanban est le Kanban Double Bac. Il s’agit d’avoir, sur une chaîne de montage, un opérateur qui a, pour ses petites pièces (ex: des boulons), 2 bacs de stock. Il se sert dans un seul bac à la fois, par exemple il commence par le bac A, et quand le bac A est vide, il permute avec le bac B (encore plein).
Un logisticien vient alors chercher le bac A vide, le remplace par un bac C plein, et note qu’il a rempli un bac.

Voici comment est décrit le process dans Wikipedia :

Le système Kanban fonctionne entre les postes de production aval et amont :

  • L’opérateur aval entame un conteneur. Il libère alors le kanban de manutention fixé sur le conteneur et le dispose dans une boîte,
  • Le manutentionnaire ramasse le kanban de manutention et va au poste amont,
  • Au poste amont, il enlève le kanban de production du conteneur plein, le met dans une autre boîte et lui substitue le kanban de manutention,
  • Il ramène le conteneur plein avec le kanban de manutention au poste aval,
  • Quand l’opérateur du poste amont a rempli un conteneur, il regarde la boîte de kanbans de production. S’il y a un kanban, il l’enlève, le fixe à un conteneur vide et reprend la production. S’il n’y a pas de kanban, cela veut dire que les en-cours sont suffisants et il attend.

Un exemple de flux de travail en mixant Kanban et Scrum a été donné par Alain, qui vient de la même boîte que Christophe Ney (vous retrouverez la présentation avec des images de ce qui a été mis en place sur Slideshare http://www.slideshare.net/cney/scrum-et-kanban-agile-grenoble-2011).

Ce que j’en ai retenu

On considère alors le sprint comme unité qui passe dans le Kanban. L’exemple utilise 3 lignes de production (qui chacune ont préparation – production – livraison comme phases) :

  • sprints : préparation de sprint, réalisation du sprint, revue de sprint
  • maintenance (TMA), qui peut être de la correction de bug, mais qui peut également être une réunion
  • non-planifié (prioritaire) : date fixe et proche

L’équilibre à trouver est le rapport en l’en-cours et le stock (le reste à faire) : on met du temps à savoir combien il nous en faut en stock et combien on peut en avoir en cours de manière concurrentielle.
Au sein du travail en équipe, les stand-up meeting Kanban sont focalisés sur les tickets plutôt que sur les gens : on fait donc le tour des tickets (des post-it chez nous), plutôt qu’un tour de parole des gens. C’est très intéressant avec une équipe nombreuse.
L’idée avec Kanban est de travailler en continu, en flux tendu. Kanban permet de mesurer la production pour trouver son rythme (ratio entre encours et entrant).

Voilà ce qui est indiqué sur les étiquettes du système mixte Kanban / Scrum :

  •  date de début
  • date de livraison prévue
  • trigramme des personnes capables/préssenties pour la réalisation
  • nom du ticket et détails

Les limites

Les limites de Kanban, citées par Christophe Ney sont :

  • le stock (à faire) est trop important par rapport à l’en-cours qui a atteint sa limite
  • le champ de vision du flux est sur quelques semaines seulement
  • les opérations à date fixe (ex : un site de Noël pour agence web, avec une date de péremption) ne rentrent pas bien dans le système Kanban

De l’utilisation du couple Behat/Sahi sur différents browsers

Différents brothers

Jusqu’à peu, nous utilisions Behat pour sa définition principale : confirmer la stabilité des fonctionnalités de nos applications et leur non régression dans le temps. Une partie de ces fonctionnalités faisant appel à du javascript, nous l’avons tout naturellement couplé à Sahi (la dernière version en date étant la 3.5) et Chrome. Nous avons récemment décidé d’étendre ces tests à d’autres navigateurs afin de nous assurer une compatibilité cross-browsers de notre application.

Et là, c’est le drame : un tsunami d’erreurs. Comme le disait récemment un tavernier près du port de Cherbourg : « ce qui plaît à un navigateur ne plaît pas forcément à un autre ». Nous nous sommes donc plongés dedans et voici donc la liste non exhaustive des écueils auxquels nous avons été confrontés. Et vu qu’à PMSIpilot on n’est pas des requins, on vous met aussi les solutions apportées. [/fin de la minute maritime]

… 

La qualité

La qualité

Un projet est composé de quatre variables :

  • le périmètre fonctionnel (quoi),
  • la qualité (comment),
  • les ressources (qui),
  • le temps (quand).

J’ai volontairement classé ces variables dans l’ordre où il me semble qu’elles devraient être définies. Mais nous ne vivons pas dans le monde des Bisounours et c’est pourquoi la qualité est en général la variable qui sert à laisser de la marge aux autres.

… 

Améliorez votre confort avec Behat

Aujourd’hui je vais vous montrer quelques astuces qui vont peut être sauver votre santé mentale quand vous vous apprêtez à lancer une longue suite de tests avec Behat pour valider votre développement. En vrac on va parler de filtres pour lancer des scénarios spécifiques, de pouvoir lancer vos tests en arrière plan, d’utiliser le système de hooks pour faire des notifications, et même des captures d’écran !

… 

Barcamp sur les méthodes agiles à Lyon le 3 mars 2012

Nous utilisons des méthodes agiles inspirées de SCRUM au sein de nos équipes de travail, et nous aimons améliorer nos connaissances et apprendre. Du coup, nous proposons un Barcamp d’une journée. Nous espérons voir arriver des personnes de l’agglomération lyonnaise et alentours.

Un Bar Camp est une « non-conférence » ouverte qui prend la forme d’ateliers-événements participatifs où le contenu est fourni par les participants qui doivent tous, à un titre ou à un autre, apporter quelque chose au Barcamp, l’objectif est avant tout de partager des idées.

Tous les participants sont invités à parler du Barcamp autant avant leur participation, qu’après, pour rendre compte de leurs échanges.

  1ère règle: Tu parleras du BarCamp.

2ème règle: Tu blogueras à propos du BarCamp.

3ème règle: Si tu veux faire une présentation, tu dois inscrire ton sujet et ton nom dans un slot de présentation.

4ème règle: Des intros de 3 mots seulement.

5ème règle: Autant de présentations à la fois que l’infrastructure le permet.

6ème règle: Pas de présentations réservées à l’avance, pas de touristes.

7ème règle: Les présentations iront tant et aussi longtemps qu’elles le doivent, où jusqu’à ce qu’elles se heurtent à l’heure de début de la présentation suivante.

8ème règle: Si c’est votre première fois au BarCamp, vous DEVEZ présenter. (Bon, on ne va pas vous forcer, mais essayez de trouver quelqu’un avec qui présenter, ou posez des questions et soyez un participant actif.)

par Tantek Çelik, en parodie des Règles de Fight Club.

L’accès se fait via une inscription préalable et est limité à 40 participants, pour des raisons légales. Au delà de 40, vous serez en liste d’attente.

Nous vous attendons samedi 3 mars de 10h à 18h dans les locaux de PMSIpilot, 61 r Sully, Lyon 6ème.

Plus de détails sur la page Barcamp de l’événement.

 

Ressources sur les API REST

Les API REST c’est bien. Mangez-en !

Squashons avec GIT

Dans ce premier article consacré aux astuces GIT, je vais vous parler d’une technique permettant de regrouper un ensemble de commits en un seul.

… 

Gitboard, le tableau de bord des projets Git

Nous travaillons sur plusieurs projets, tous gérés par Git. Il y a certains jours avec beaucoup de commits et d’autres sans.

C’est pourquoi nous avons développé Gitboard, un petit script php qui permet d’avoir rapidement une vue d’ensemble d’un projet Git :

  • le nombre de commit des derniers n jours, n heures et n minutes,
  • le détails des derniers commits,
  • l’écartement des branches locales non mergées,
  • des statistiques simplistes sur les différents commiters.

… 

Mink, Sahi et un gros DOM sont dans un bateau

… le bateau coule !

tl;dr > Voir directement la pull request

Ça fait environ deux semaines que nous utilisons Behat pour élargir notre couverture de tests fonctionnels sur notre application, et je dois dire qu’on est quand même très content, c’est facile, ludique et relativement stable. Pour donner une idée on en est à 30 scénarios, environ 400 steps et une douzaine de comportements persos.

Seulement sur certaines pages très lourdes, on a eu presque aléatoirement quelques problèmes quand on utilisait Mink avec Sahi

…