Derrière cette couverture affreuse, il faut le dire, et un titre pas du tout alléchant  se cache un formidable « roman industriel » qui raconte l’histoire d’Alex Rogo directeur d’une usine de la société UniCo. Ce poste était pour lui la promotion tant attendu de sa carrière. Il ne comptait plus les heures et les nuits passés dans son usine à faire fonctionner au mieux sa production,  d’améliorer le rendement de ses machines et de ses salariés. Malgré tous ses efforts son usine est en danger. Le vice-président de la société lui pose un ultimatum : il a 3 mois pour redresser la barre !

Tout les indicateurs qu’il a appris semblent bons, pourtant il n’a l’impression que de gérer quotidiennement des problèmes dans l’urgence pour faire partir au plus vite des commandes dont le retard ne cesse de croitre. A ces retards s’ajoutent des stocks qui n’en finissent plus de grandir et une pression constante du groupe pour réduire toujours plus les coûts.  Lors d’une rencontre avec son ancien professeur de physique à l’université, il découvre dans un échange socratique une nouvelle manière de gérer son entreprise.

La théorie des contraintes

La théorie des contraintes appliquée dans un contexte industriel consiste à identifier les ressources « goulot » et « non-goulot » dans un processus de fabrication d’un produit. Si on considère ce processus comme un flux il devient alors plus facile de les identifier. Un goulot est une ressource dont la capacité de production est inférieur à celles de toutes les autres. Et par conséquent un goulot limite le flux de sortie.

Dans « Le But » le héros fait un parallèle entre le fonctionnement de son usine et une randonné de scout. Un dimanche matin il part en randonné avec son fils scout et tout ses petits amis scout. Le but de la randonné : aller d’un point A à un point B. Ils partent donc de bon train en fil indienne pour avaler les 15 km qu’ils doivent parcourir en une journée. Notre héros calcule qu’avec une moyenne de 3km/h tout le petit groupe devrait arriver à destination dans environ 5h + les pauses éventuelles. Au cours de la promenade Alex remarque que la fil ne cesse de s’étendre malgré le rappel des jeunes gens en tête. Pire il remarque qu’au bout de 2 heures ils n’ont parcouru que 3km au lieu des 6 km prévu. Il remarque aussi très vite le pauvre Herbie, un petit garçon un peu enrobé, qui penne à suivre le groupe.

Ce qu’il découvre au cours de cette randonné est que Herbie est la clé. C’est le lui le goulot, il faut donc limiter le flux à sa capacité et faire tout son possible pour augmenter sa capacité ou alléger le travail du pauvre Herbie.

Dans « Les bronzés font du ski » Josiane Balasko dans le rôle de Nathalie Morin est le goulot, car elle est la moins expérimenté en ski et ses chaussures sont trop grandes.

De manière générale Eliyahu M. Goldratt expose la théorie des contraintes de la manière suivante :

1. Identifier la contrainte (le goulot d’étranglement)
2. Exploiter la contrainte (augmenter son utilisation et son efficience)
3. Subordonner tous les processus au processus contraint
4. Élever la performance de la contrainte (si nécessaire)
5. Recommencer à l’étape 1 si la contrainte a changé

De nouveaux indicateurs

Alex Rogo définit avec plein de bon sens le but de son usine  : gagner de l’argent. Pour évaluer et conduire les améliorations apportées au fonctionnement de son usine il met en place trois indicateurs :

1. Le troughput qui est en quelque sorte le flux de sortie de son usine vendu sur le marché.
2. Le volume de stocks en matière première.
3. Le coût de fonctionnement définit comme le volume d’en-cours plus l’utilisation de la capacité des ressources.

Le but devient alors d’augmenter le troughput tout en réduisant ou limitant le volume des stocks et le coût de fonctionnement.

Lean et le but

Bien que lean ne soit jamais cité dans le livre, il est clair qu’on y retrouve certains aspects :

• la valeur : l’entreprise doit assurer un écoulement sans interruption de la valeur le long de sa chaîne de production (en termes plus triviaux, on fait la « chasse aux stocks »).
• Le kaizen : le processus d’amélioration continue.
• le schéma de production : l’entreprise produit en « tirant » sa production en fonction de la demande et non en « poussant » en fonction des capacités locales de production.

Deux méthodes de management sont confrontés

Bien que la théorie des contraintes soit décrite dans ce livre dans un contexte industrielle, je conseille sa lecture pour s’en inspirer dans un contexte de gestion de projet informatique. En effet cela permet de confronter deux méthodes de management :

• Le management par les objectifs est celui que l’on connait généralement dans une SSII. On définit les objectifs (contrats, cahier des charges, spécifications) et on alloue les ressources nécessaires. Si une contrainte nous empêchent d’atteindre l’objectif fixé on dépensera toute notre énergie pour trouver LA faille (« c’était pas dans les specs ! ») ou alors on essaiera de tricher.
• Le management par les contraintes est celui décrit dans ce livre. On s’attaque directement aux contraintes qui deviennent un moteur d’innovation.

Du même auteur on retrouve « Critical Chain : La Chaîne critique » qui traite de la gestion de projet tel que nous la connaissons.

Enfin pour les plus curieux, vous trouverez une simulation excel de la randonné avec Herbie sur ce site : http://www.theoriedescontraintes.fr/.

Tout y passe : les canvas, les css selectors, les transitions css, la vidéo, le son, la sémantique tout ! C’est vraiment bien expliqué, c’est à lire et à relire et à décortiquer avec firebug.

http://apirocks.com/html5/html5.html

ECO89 a publié il y a un mois un article sur la sortie de livre « FREE! » de Chris Anderson qui présente une nouvelle économie qui consiste à proposer ses services ou produits gratuitement pour mieux vendre ensuite. Ironie, le livre ne sera pas distribué gratuitement en France …

L’article nous en offre un extrait, « les dix principes du raisonnement d’abondance ». Voici 5 de ces principes (les 5 autres m’interesse moins):

1. Si c’est numérique, c’est que cela peut-être gratuit.
2. On ne peut pas concurrencer le gratuit.
3. On achète lorsqu’on est obligé ou lorsque ceci nous simplifie la vie
4. Si cela peut être gratuit, tôt ou tard quelqu’un le proposera gratuitement.
5. Pour vendre avec du gratuit, il est nécessaire des redéfinir son marché.

Après quelques exemples cités dans les commentaires et quelques « Ah bah non on ne peut pas tout proposer gratuitement ! C’est pas possible ! », un lecteur réagit et dit :

Il ne faut pas confondre low cost, gratuit avec de la pub, et gratuit [...]. Le gratuit avec de la pub, comme « 20 minute », ce n’est pas du gratuit. On paye tous les jours le 20 minutes dans les produits que l’on achète tous les jours. 20 minute ce n’est juste qu’un journal pour lier consomateurs et annonceurs, avec quelques informations autour des pubs pour faire croire qu’on lit un journal d’information [...].
Enfin, le vrai gratuit, c’est celui où le produit est gratuit, qu’il n’y a ni pub, ni de marge arrière et où il ne sera pas associer à un tas de service exorbitant [...]. Le plus belle exemple sont les logiciels libres. Les logiciels libres, ne comportent aucune pub, peuvent être modifiés et copiés à volonté. Il n’y a aucun service ou produits associés.

STOP ! Les logiciels libres sont donc des produits distribués gratuitement par de gentils développeurs qui travaillent très dure dans l’unique but d’être gentil. Linux et Apache ont peut-être démarré dans cette esprit. Mais si ces deux projets sont ce qu’ils sont aujourd’hui, c’est bien qu’un portefeuille invisible y met des sous de temps en temps …

Au même titre que le « 20 minutes », l’open source est un investissement. Le quotidien déplace les frais vers ses annonceurs, le  logiciel libre déplace les frais de l’achat des licences vers le service (1). Il est proposé gratuitement mais avec tout « un tas de services exorbitants » (intégration, support, évolution). Qui offre ces services ? La société éditrice ou les sociétés de services spécialistes de cette solution.

Enfin l’entreprise utilisatrice qui investi dans une solution open-source bénéficiera gratuitement des corrections et des évolutions que la communauté apportera.

Notre quotidien :

• Livrer aux équipes de qualification puis au client, les releases de nos équipes de développement,
• Maintenir les différents environnements de qualification et de développements opérationnels

Mais aussi :

• Etre un garant de la cohérence des environnements applicatifs pour les différents acteurs du projet
• Assister dans la mise en oeuvre des différents éléments de l’architecture globale du SI (je pense notamment aux éléments de sécurité)

Et enfin :

• Toujours améliorer nos processus pour fournir à nos « clients » un service efficace, réactif mais aussi constant.

L’organisation globale du projet possède des caractéristiques des méthodes agiles. Je pense aux releases fréquents des équipes de dévelopement (1 fois par semaine en moyenne pour chaque application du SI) et à l’implication du client dans la recette de chaque version qui lui ait livré (1 fois toutes les 2 semaines en moyenne). En revanche le périmètre des fonctionnalités est definit au démarage du projet sous forme de contrat : c’est un projet au forfait. Notre équipe d’intégration maintient en quelque sorte l’infrastructure d’une usine de développement applicatif.

J’ai pu lire sur différents blogs que des méthodes agiles tel que SRUM ne sont pas adaptés aux projets de type TMA (dont le mode de travail est très proche de celui de l’intégration). Or les valeurs supportés par agile, sont des valeurs qui pourrait s’intégrer parfaitement à notre mode et améliorer énormément nos processus :

(de wikipédia)

• L’équipe (« Personnes et interaction plutôt que processus et outils ») : Pour assurer une qualité de service constante il faut que chaque membre de l’équipe entretienne un niveau de compétence uniforme. La communication est primordiale (ce n’est pas nouveau en même temps).
• L’application (« Logiciel fonctionnel plutôt que documentation complète ») : Ça je vais avoir du mal à l’expliquer à mes chefs de projet ! Le problème de la documentation c’est qu’elle devient néfaste si elle n’est pas à jour. Combien de temps perdons-nous à corriger les problèmes survenus lors de l’application d’une documentation obsolète ? S’il faut vérifier la pertinence de la documentation crée par ses collègues, où est l’intérêt de la documentation ?
• La collaboration (« Collaboration avec le client plutôt que négociation de contrat ») : Dans notre cas ce n’est pas LE client mais LES clients : le client du projet, les équipes de développement et de qualification. « Le client doit collaborer avec l’équipe et fournir un feed-back continu sur l’adaptation du logiciel à ses attentes ». Pour nous il faut que chaque acteur se contente de la valeur qu’il percoie dans le service que nous offrons : en gros il faut que tout le monde soit content. Ainsi il est necessaire d’adapter constamment nos services aux besoins de nos clients. Voici un billet sur le concept de la valeur.
• L’acceptation du changement (« Réagir au changement plutôt que suivre un plan ») : Il n’est pas facile de faire accepter les changements aux autres, alors pourquoi ne pas tout mettre en œuvre pour que le changement soit aisé chez nous, et qu’il devienne moteur d’innovation et de satisfaction pour nous et nos clients.

Qu’est ce qui pose problème à l’application de SCRUM dans notre contexte ?

twitter bird

Twitter est un outil efficace pour être spammé suivre en temps réel l’activité de ses amis. Potentiellement ils peuvent tous  devenir témoins de l’actualité. En imaginant avoir beaucoup d’amis, twitter devient un outil de crowdsourcing de l’actualité.

C’est ce qui est arrivé après la tragique fusillade en Allemagne où la rédaction de  France 24 a pu retrouver un témoin gràce à twitter. D’après cet article, les premières infos sur certains événements arrivent de plus en plus souvent sur Twitter avant d’être traitées dans les dépêches d’agences de presse.

Il y a quelques mois j’avais rencontré des personnes de Total Immersion, un éditeur de logiciel spécialisé dans la réalité augmentée. Leurs solutions ne sont pas comparables à ce que vous avez pu voir dans la vidéo précédente, mais elles restent impressionnantes !

Qu’est ce qu’un service RESTful, et plus particulièrement l’architecture REST ?

Plutôt que de répondre à la question, voici une selection d’articles :

• RESTful Web Services
• Pour ne plus être en REST, comprendre cette architecture
• How to create a REST protocol

Mais voilà dans tous ce que j’ai pu lire sur REST, quelquechose m’a manqué… J’ai besoin de toucher les choses, il me fallait voir de plus près la Technique.  Et je ne suis pas le seul, la question revient souvent dans les commtaires de blogs : « Concretement, si je veux que mon site soit en REST, je fais quoi ? ».

C’est ainsi que j’ai commencé mes recherches sur les différents frameworks disponibles en PHP ou en Java. Je me suis arrêté sur le framework Konstrukt en PHP.
En voici les grands principes, retrouvés dans d’autres frameworks comme Restlet en Java :

1. Une uri = un controlleur.

L’uri ou l’url est l’adresse qui identifie ma ressource. Le controlleur est l’objet qui va traiter ma requête. Il vient du pattern MVC. Chacune de mes requêtes, c’est à dire l’uri demandé, est traitée par un contolleur sélectionné en fonction de celle -ci.
Cas pratique 1 : je suis une agence de voyage, et je souhaite que l’on accède à la liste de tous les aéoports par mon site. Je saisis www.monagence.com/aeroports dans la bar d’adresse de mon navigateur et j’obtiens la liste comme demandé. Nommons le controlleur qui traite ma requête « aeroports_list_controller ».
Cas pratique 2 : je suis toujours mon agence de voyage et je souhaite afficher les détails du vol 816 aux départ d’Orly. Je saisis alors l’url www.monagence.com/aeroports/orly/vols/816. Nommons le controlleur « vols_show_controller » qui affiche les détails du vol 816.

Voila pour le premier Principe.

2. Un controlleur possède deux comportements.

Le premier est celui décrit en 1. Le second est un comportement de routeur. En réalité dans le cas pratique 2 ce n’est pas 1 controlleur qui traite ma requête mais 5. Le premier qui entre en jeu est le controlleur racine « root_controller » qui me redirige vers « aeroports_list_controller ». Pourquoi? Car le premier éléments de mon uri est « aeroports ».

De la même manière « aeroports_list_controller » me redirige vers « aeroport_show_controller » pour traiter « orly ». Enfin en passant par « vols_list_controller », j’arrive à « vols_show_controller » qui affiche les détails du vol 816 au départ d’Orly.

3. Un controller connaît le contexte dans lequel il est appelé.

Le controlleur « vols_list_controller » est commun à tous les aéroports. Les données mises à disposition par celui sont fonctions de l’aéroport qui l’appelle.

Enfin il ne reste plus qu’a implémenter dans chaque controlleur les méthodes GET, POST, PUT et DELETE de REST.

Voici avec le framework Konstrukt ce que donne le code d’un controlleur :


class components_aeroports_List extends k_Component {
function map($name) {
return 'components_aeroports_Show';
}
function GET() {
global $aeroports;
$this->document->setTitle("aeroports");
$t = new k_Template("templates/aeroports-list.tpl.php");
return $t->render(
$this,
array(
'aeroports' => $aeroports->all()));
}
}


Nous avons donc une fonction map qui permet de rediriger vers le controller aeroports_Show lorsque il y a un éléments dans l’adresse après « aéroports »,   »orly » par exemple.  Puis on peut remarquer l’implémentation de la méthode GET faisant appel à un template pour afficher la liste des aéroports.

Pour résumer le schéma général de l’implémentation d’une architecture REST peut se faire avec un pattern Chain of Responsibility. Car finalement c’est pratiquement le pattern que je décris ici.

Comprendre comment était implémenté un des frameworks m’a aidé à mieux comprendre REST. Et c’est comme ca que je me suis confronté à la difficulté de concevoir une architecture orienté ressources plutôt qu’une architecture orienté services.

1. La facilité d’installation et de paramétrage. Un simple war à déployer sur un tomcat par exemple. La documentation est très bien faite sur le site.
2. Le telechargement et l’installation de plugin directement sur l’outil.
3. La publication de flux RSS en natif.
4. Parce que c’est amusant

Autre chose vraiment bien avec Hudson, c’est qu’il n’est pas seulement un outil d’integration continue, son extensibilité lui permet d’être outil polyvalent et efficace dans presque toutes les tâches d’integration d’un projet.

Ainsi je peux gérer :

1. le déploiement automatique de mes applications sur mon environnement cible,
2. le passage de patchs sur les bases de données,
3. la planification de routines sur mes serveurs.

Un point négatif tout de même  : les plugins. Et oui c’est à la fois un des points forts d’Hudson et son point faible. Je m’explique : Hudson propose une multitude de plugin pour étendre l’outil. Ces plugins sont développé par vous et  moi. En effet Hudson est un produit open-source. Ainsi on trouve des plugins inachevés (donc bugués) ou encore qui ont l’air fantastiques, mais dont la documentation est quasi-inexistante, donc inutilisables !

Hudson est un produit encore jeune, les première versions datent de 2007, mais il évolue très rapidement (94 releases en 1 an 1/2). Aujourd’hui je vois beaucoup de projet en entreprise l’utiliser, ca mérite d’y jeter un oeil.

Pour bien comprendre ce qu’est l’intégration continue, je conseil cet article « Continuous Integration » par Martin Folwer dont la version original date de 2000.

Les bénéfices d’une telle pratique sont les suivants :
Estimation de charge, correction de bogues et contribution du client/utilisateur :
Dans un processus d’intégration différé (càd une fois que les développements sont terminés ) il est souvent difficile de prédire la charge effective. En effet lors de l’intégration c’est une multitude de bogues qui vont se superposer et en cacher d’autres. Il devient alors difficile d’estimer combien de bogues on aura à corriger et combien de temps mettront ces corrections.
Avec l’intégration continue, si j’introduis un bogue dans mon code, je m’en apercevrais rapidement (voir immédiatemment) et il sera alors plus facile à corriger (car il n’y aura pas ou peu d’accumulation). De plus il n’y a plus besoin d’estimer la charge du processus d’intégration car il fait parti du processus de développement.
Enfin l’intégration continue permet aussi de pouvoir estimer facilement l’état fonctionnel de notre application. En effet le but est d’avoir à tout moment une application déployée qui marche (et dont l’utilisateur pourra faire un retour).

En ce moment je travaille sur un projet utilisant le principe d’intégration continue. Nous utilisons l’outil CruiseControl. Je sais qu’un outil plus performant est récemment sorti, Hudson, mais je ne l’ai pas encore étudié.