L’Agile Tour Nantes (en images) 3/3

Troisième volet de mon retour sur l’agile Nantes (les parties 1 et 2 sont là et ), voici le programme de l’après-midi

Le paradigme de l’ingénieur dans un imaginaire ubiquitaire

Cette keynote originale nous était présentée par des membres de la compagnie “La Machine” qui, de projets en projets, construit des mécaniques savantes en faisant collaborer ensemble de multiples corps de métier en les faisant interagir en permanence, à l’image de ce que nous faisons dans nos projets agiles, par opposition à l’entreprise traditionelle où règne le “product lifecycke management”.

Le fil conducteur de l’entreprise ne sont pas les projets, mais une vision d’ensemble insufflée par son créateur et directeur artistique François Delarozière : l’imaginaire !

Les machines, comme des êtres vivants passent par 3 phases:

  • La prototype. la machine est assemblée pour en faire fonctionner les différentes parties … avant d’être désassemblée pour être finie, traitée, peinte, etc…
  • L’adolescence. La machine est utilisée dans des manifestations et des spectacles, manipulée et montée par des membres de la compagnie.
  • L’autonomie (le machine de ville). la machine est revue afin de respecter les normes lui permettant d’être accessible par le public.
atnantes2012-lamachine02

A la base de l’entreprise, il y a un meneur, François Delarozière que nous avons déjà nommé. C’est lui qui initie les différents projets. Et au départ de chacun d’entre eux il y a une histoire qui inspire dessins et mises en mouvements.

Une fois le concept posé et les premières idées arrêtées, il y a des réunions avec les différents corps de métier. L’équipe de réalisation est une équipe intégrée regroupant tous les corps de métier : Ingénieurs structure, mécaniciens, hydrauliciens, menuisiers, soudeurs, etc… Il y a une transparence totale sur les travail effectué par les différents membres. On ne parle plus de stand-up quotidien mais de boucles de feedback en continu, toute la journée.

Cet esprit d’équipe est résumé de manière humoristique “on collabore et on travail vraiment en équipe : on ne finit jamais complètement nos tâches, on en laisse pour les autres !”. Pourquoi un ingénieur structure devrait-il donner des précisions sur la réalisation d’une soudure ? Le soudeur connait son travail, mieux même que l’ingénieur ! Il saura poser des questions d’il a besoin de précisions. De toute manière à quoi bon spécifier les détails ? Ce que l’on fera au final sera différent !

L’équipe n’est pas seulement collaborative, elle est aussi plurielle et pluridisciplinaire : ceux qui conçoivente et construisent les machines seront aussi ceux qui les manipuleront et les monteront. Tous ! Comme le disent si bien les membres de la compagnie “on n’a pas vraiment le choix” !

Chaque réalisation de La machine est quelque chose de différent, un nouveau challenge, dont on ne sait pas au départ comment il sera adressé ! Mais tout ceci se réalise plus facilement quand on travaille tous ensemble, dans le même bureau.

PO et culture Agile: potion magique du succès de l’entreprise !

Frédéric Dufau-Joel nous a proposé une session une session au format original : le fish bowl. Frédéric a fait disposer les chaises en cercle, en disposant un petit cercle intérieur de 5 chaises dans lequel il s’est installé. L’un des chaises devant rester vide (la plupart du temps) les autres sont prêtes à acceuillir les personnes déirant poursuivre le débat en posant une question à Frédéric. Quand la dernière chaise est occupée, la personne la plus ancienne dans le cercle doit rendre sa place.

Bref, au lieu d’éliminer du “bottleneck”, on va plutôt en créer afin de réguler le débat. C’est une application du WIP du Kanban, si on veut bien …

atnantes2012-dufau-joel02

Le principal, pour ne pas dire le plus surprenant, c’est que ça marche !

Revenons au thème de la session, c’est à dire le PO en tant que potion magique. Frédéric nous a fait partagé son retour sur l’imporatnce du PO dans le succès des projets au sein de son entreprise. Il identifie plusieurs facteurs de succès.

Les PO viennent des métiers. Cette transition d’un rôle opérationnel vers ce rôle de PO est valorisé et est même un templin pour leur carrière !

Le casting est important. Tout le monde n’a pas le profil pour être PO. La connaissance méier ne suffit pas, car le PO est un agent de changement qui doit aussi travailler très près des utilisateurs. De plus, le formation de binômes sénior / junior aide à la parformance sur les projets, ainsi qu’à la continuité.

Une logique d’amélioration. Frédéric ne parle plus de projets informatiques. Ce sont des projets d’entreprise, des projets d’amélioration. Encore une fois, les PO sont des agents du changements.

Un dernier point que j’ai noté en outre : A la question sur la mesure sur le ROI des projets, Fréderic a dit qu’il n’en faisait aucun, à part le sourire des utilisateurs et des décideurs ! Une belle forme de conclusion.

Apologie du mur

La présentation d’Axel était certainement un peu légère, et j’avoue n’y avoir rien appris. Mais elle était fort bien présentée avec entrain et humour : une touche de légèreté et de différence que j’ai apprécié à cette heure de la journée. En fait je n’ai pas regretté mon choix, ce que je dis plutôt rarement, peut-être même jamais lorsque je pense ne rien apprendre !

atnantes2012-axel04

Mais revenons sur cette présentation. Elle s’appuie sur 3 histoires vécues présentées de manière vivante et avec humour.

La première histoire est celle d’une équipe s’enlisant dans sa stratégie de test. C’est le prix “pas de bol”. Ca arrive, et ça arrivera encore. Elle s’en est sortie en trouvant finalement le bon outil de test fonctionnel.

La seconde histoire est celle d’une équipe présentant une vélocité affichée n’ayant rien à voir avec la vélocité réelle. Une belle illustration de Death March avec son cortège de conséquences habituelles : bugs, pataches, baisse de la qualité et burn out. C’est le prix “mérité”. Pour s’en sortir, il a fallu un retour aux sources sur la qualité et la définition of done … et essuyer la date pendant un petit moment.

La troisième histoire démarre par un Product Owner fort zélé arrivant avec un backlog simplifié… de 4 items ! C’est le prix “inattendu”. Il a fallu reculer le démarrage du projet afin de pouvoir retravailler le backlog avec l’équipe afin qu’il ait une granularité présentant des items appréhendables.

Quelles leçons retirer de ces histoires ?

D’abord que les murs en gestion de projet prédictive sont dangereux. Ils peuvent même signer la mort du projet.

En mode agile, on a comme premier reflexe de cacher tout autant ces murs que l’on voit parfois arriver et qui font peur. C’est une réminiscence de l’ancien mode. Pourtant ils nous apprenent des choses. C’est même eux qui forment la plus grande part de notre apprentissage. On doit leur faire face et en sortir les enseignements lors des rétrospectives.

Pour résumer, en 4 points :

  • N’ayons pas peur des murs !
  • De toute façon, on va s’en prendre !
  • Evitons quand même les gros murs, ne soyons pas kamikazes !
  • Sachons les écouter et affichons (sur des murs physiques cette fois).

Des mots, des maux ? Démo !

Je n’avais pas encore eu l’occasion d’assister à la présentation de ma collègue Caroline Damour et ex-collègue Emilie Franchomme. C’est maintenant chose faite. Mieux encore, elles m’ont donné l’opportunité pour cette “dernière” d’apporter ma modeste contribution. J’y reviendrais.

atnantes2012-demo02

L’originalité de cette présentation était de reposer entièrement sur un appel à témoignage auprès de la communauté ! D’une part cela témoigne d’une attitude humble de la part de Caroline et d’Emilie, et je dois dire que ce n’est pas le trait marquant de notre communauté (au sein de laquelle je m’inclus) ! Cela nous donne aussi un indicateur fiable sur la façon dont la chose est appréhendée par différentes équipes.

Le premier point qui remonte est : Synecdoque ou comment prendre une partie pour un tout ! On devrait en effet parler de “revue de Sprint” et non de de “démo”, celle-ci n’étant qu’une partie de la revue.

Le second point concerne les facteurs de réussite:

  • Ca se prépare
  • Avoir une check-list pour ne rien oublier
  • Raconter une histoire pour captiver le public

Un aspect stressant qui semble réccurent : éviter la honte devant les clients !

Le point qui m’a le plus interpellé est la dualité démontrer / valider !

Ce “pattern” semble réccurent et source de problèmes et de tensions:

  • Cela créer un mur lors des démos (pardon, des revues de Sprint). En effet, on se retrouve plus en climat de client / fournisseurs, voir juge / jugé qu’en situation de collaboration. Chacun s’apprêtant à défendre son camp.
  • Cela exacerbe le problème du “scope creep”, où les utilisateurs vont s’evertuer à trouver insuffisant le périmètre montrer afin d’en avoir “toujours plus”.
  • Cela sape le rôle du PO qui doit être celui qui valide.

Bref, tout cela laisse bien moins de place à la collaboration !

Un dernier point que j’ai noté (mais ce n’était pas le seul de la présentation, vous n’aviez qu’à venir) : la célébration. C’est très américain, mais pourquoi pas ? Toutefois ce ne doit pas être le but recherché.

Et puis, c’était mon tour !

Caroline et Emilie m’ont proposé d’introduire un nouvel opus de ma saga “en finir avec”. J’avais choisi de faire court, pour ne pas canibaliser la présentation. Trop court et trop léger peut-être, je n’ai pas été très satisfait de moi. Je vais essayer de vous résumer la chose.

La démo, c’est reporter en fin de sprint la revue d’éléments que l’on a fini en cours de sprint ! Alors pourquoi ne pas faire plutôt des “micro démos” qui concluraient chaque story, plutôt que de constituer du stock en cours de sprint ? Voilà du moins la colonne vertébrale de mon propos. Je le reprendrais plus tard de manière plus travaillé et plus détaillé dans un post ici même. Stay tuned !

J’avais déjà posté la présentation de caroline et d’Emilie. Elle est accessible ici.

Partir … revenir ?

Déjà 18h30, notre train est à 20h00 et je serais chez moi à près de 23h00. Il est temps de rentrer (ouais, le campus, il est quand même un peu dans la cambrousse). le temps d’un dernier échange avec les suspects habituels, direction le bus.

atnantes2012-retour02

Une belle journée avec des sessions donnat matière à réflexion. Mes deux “keepers” de la journée, en plus d’une foule de petites choses, d’idées et de rencontres.

  • La session de Tremeur Balbous sur l’immunothérapie au changement. Le premier changement à opérer est en nous et il faut se rendre prêts à l’opérer.
  • Le PO “potion magique”. Le Product Owner est un vrai facteur de réussite, mais pas n’importe comment, pas simplement en collant une étiquette au revers de son veston. Il doit d’abord et avant tout être un agent du changement et non un scribe !
  • Mélanger présentation et validation lors d’une démo, c’est pas une idée de génie.

Alors c’est vrai, Nantes ce n’est pas à proprement parler à côté. Pourquoi aller là-bas alors que l’Agile Tour Paris est à 200 mètres de mon lieu de travail ? Pour les rencontres, tout d’abord. la communauté Parisienne, je commence à connaître. L’ambiance est un peu différente des rendez-vous de la capitale où l’on a peut-être plus tendance à pavaner, même malgré nous… Et puis j’avais rencontré quelques personnes de la communauté Nantaise lors de l’Agile Games France. Il me tardait de les revoir à nouveau. Bon allez j’avoue, c’est la raison principale.

Il est un peu tôt pour affirmer que je serais là l’an prochain. Mais cela me tente bien…

Note de lecture : Pro Wicket, par Karthik Gurumurthy

Note : 6 ; Une bonne surprise : globalement clair et pédagogique

Le monde Java s’étoffe décidément de nombre de frameworks open-source aussi surprenants qu’inventifs. Ils constituent, à mon avis, bien plus l’avenir de la plateforme Java Enterprise que l’approche normative que pousse Sun contre vents et marées. Bien sûr, il y a aussi un phénomène de mode sur tous ces frameworks open-source, les nouveaux poussant les anciens. Wicket est l’un des nouveaux venus et vient concourir dans la catégorie pourtant déjà surpeuplée des frameworks de présentation Web !  Mission accomplie, pourtant, car la qualité de ce framework et son approche « disruptive » (une approche mixte xhtml / Java, mais pilotée par le Java) car basée sur des ressources non managées et stateful, en ont rapidement fait un produit populaire. Il a d’ailleurs été accueilli au sein de la communauté Apache.

Tout framework majeur finit par avoir son livre. Dans le cas présent, il n’en existe (ou existait, devrais-je dire) qu’un, celui-ci. Autant dire que je craignais le pire, car le premier livre sur une technologie est pratiquement toujours un ratage total, l’auteur se focalisant plus sur la mise sur le marché que sur la qualités du texte. Apress fait hélas partie des éditeurs soutenant cette approche. A la lecture de ce livre, je dois m’avouer soulagé et agréablement surpris.

Le point fort du livre est sans conteste son approche pédagogique : le framework est introduit progressivement, en commençant par un exemple simple et fonctionnel. Chaque étape, chaque nouvelle fonctionnalité est introduite dans l’étape précédente par la mise en évidence de la lacune de fonctionnalité correspondante. Les exemples sont nombreux et occupent une part importante du texte (pas loin de 40% du texte), mais ils sont hélas souvent émaillés de petites erreurs qui heureusement ne gênent pas leur compréhension.

L’ouvrage est divisé en 9 chapitres, ceux-ci sont donc relativement gros, car le texte compte près de 300 pages, sans les annexes. Le premier chapitre est globalement l’équivalent d’un « hello world » assez étoffé. En réalité, on pourrait déjà écrire et déployer des applications Wicket assez simples à la fin des 33 pages de ce chapitre ! C’est tout dire…

Le chapitre 2 couvre un aspect plus spécifique du framework : les éléments de validation et de conversion. Chemin faisant, nous explorons quelques éléments plus avancés tels que la gestion des propriétés ou les listeners de vues.

Le chapitre 3 est sans aucun doute le plus consistent et le plus important du livre. D’abord par ses 60 pages, ensuite car il couvre complètement une petite étude de cas permettant d’explorer les aspects les plus importants du framework. Vous pouvez facilement vous arrêter à la fin de ce chapitre pour écrire votre première application Wicket et reprendre les aspects plus avancés ultérieurement.

Le chapitre 4, couvrant la structuration des pages est à mon avis le moins réussi et le moins clair. J’avoue avoir décroché assez rapidement.

Un des sujets à la mode est l’intégration de Wicket avec Spring, même si il s’agit là du mariage du veau et du cochon tant ces frameworks sont différents dans leur approche. Le chapitre 5 couvre très clairement le « comment » de ce module d’intégration, mais aussi (bien que plus succinctement) les intégrations Tapestry, Hibernate ou JPA.

Le chapitre 6 reprends là ou le chapitre 2 s’était arrêté pour couvrir l’internationalisation. Utile mais pas passionnant.

Le chapitre 7 couvre le développement de composants Wicket personnalisés. Une section à lire seulement après avoir pris un peu de bouteille avec Wicket.

Ajax est un sujet à la mode, le chapitre 8 n’évite pas le sujet car il lui est consacré, mais le sujet reste traité un peu rapidement ici. On a toutefois assez d’éléments pour démarre avec les composants Ajax de Wicket.

Le dernier chapitre couvre deux sujets qui ne sont pas mineurs : comment tester unitairement nos pages et formulaires Wicket, et ce qu’il y a de neuf dans Wicket 2.0.

En bref, voici un livre pour débuter en tout confort avec Wicket. Cela a été un bon achat… à l’époque. Un petit rafraichissement avec la dernière version du framework et tout serait parfait !

pro-wicket

Référence complète : Pro Wicket – Karthik Gurumurthy – Apress 2006 – ISBN : 1-59059-722-2 ; EAN : 978-1-59059-722-4

Pro Wicket


http://www.goodreads.com/book/add_to_books_widget_frame/1590597222?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

L’Agile Tour Nantes (en images) 2/3

Je poursuis ma restitution de l’Agile Tour Nantes commencée il y a peu.

J’ai 2 jours pour obtenir une vision partagée avec 15 utilisateurs pour mon projet agile !

Pierrick Thibault et Edwige Champin du groupe Atlantic nous racontent comment ils ont opéré le lancement d’un projet en mode semi-agile adoptant une approche “full agile” pour son lancement !

Pourtant les choses se présentaient difficilement : ce projet transverse au groupe impliquait plusieurs sociétés, avec 15 utilisateurs impliqués dans le lancement, issus de sociétés et de fonctions différentes. Qui plus est, la société vient d’assez loin, avec du cycle en V et une méthode “maison” … mais toutefois une pratique Lean au niveau de la production : Atlantic Production System, le pendant du TPS de Toyota !

Le début de la présentation est un peu long, avec la présentation du contexte “groupe Atlantic”. L’opportunité pour nous de savoir que le cycle en V bien que fonctionnant correctement chez Atlantic, présente quand même des lacunes (cycles trop longs fonctions inutiles) que la société souhaite adresser. Le temps aussi pour nous de découvrir le projet Metis dont il sera question.

atnantes2012-pierrick03

Alors voilà, le projet n’est pas encore commencé que déjà des obstacles sont là et bien là !

  • Le projet est déjà estimé !
  • On démarre sur un cahier des charges existant.
  • Des activités au format habituel
  • Un grand nombre de participants pour ce lancement : 15 personnes !

Aussi quelques points auxquels il faut prêter attention:

  • Le partage des pratiques métier: les personnes impliquées tiennent en effet des fonctions très diverses.
  • Se détacher de l’existant.
  • Ne pas transformer ce lancement en “lettre au père noel”.
  • Faire en sorte que les participants soient acteurs (pas facile quand on est si nombreux) !
  • Eviter le jargon agile.

Il est maintenant temps de rentrer dans le dur !

atnantes2012-pierrick02

Ces 2 jours ont été découpés en 3 phases:

  • Ouvrir
  • Explorer
  • Converger

Ouvrir

Pour ouvrir, c’est le format World Café qui a été privilégiée. En quelques points:

  • Des tables de 4 / 5 personnes
  • Des rounds de 15 minutes entre lesquels les participants changent de table.
  • Un hôte qui fait le lien au niveau de chaque table, entre les rounds.

3 rounds de 15 minutes ont permi de déveloper la reflexion autour de “comment optimiser mon organisation au jour le joursur la gestion des dépenses projet”. Ce thème étant reformulé pour le 3 ème round. Une restitution par thèmes cloturant cette première phase.

Explorer

Cette exploration s’est faite en 2 temps:

  • D’abord la définition des “persona” qui serviront à l’expression des besoins.
  • Puis un atelier Story Map pour faire émerger les besoins.

Converger

C’est un atelier de priorisation des stories qui a conclut ces 2 jours. Une priorisation “en silence” vu le nombre des participants, qui a quand même permis en 3 passes de ventiler de manière équilibrée les stories selon 3 niveaux de priorité.

Bref, une présentation intéressante, d’abord parcequ’elle m’a permi de découvrir le World Café que je ne connaissais pas, et parce que le thème du lancement de projet est rarement traité en retour d’expérience, surtout à cette échelle et dans ce type de contexte.

Immunothérapie pour le changement

Je suis resté pour suivre la session de Tremeur Balbous, dans la continuité de sa keynote. L’immunothérapie pour le changement est directement issu des travaux de Robert Kegan et Lisa Laskow Lahey que l’on retrouve aussi dans l’ouvrage éponyme. Ces auteurs, enseignants à Cambridge ont développé une approche de coaching qu’ils supportent aussi au sein de leur société Minds at work, nottament par le biais d’une certification. Eh oui : business, business…

La théorie

Elle s’appuie sur 3 éléments :

  • Les niveaux de développements
  • Les typoes d’apprentissage
  • Les filtres

Les niveaux de développement

Si le développement chez l’enfant est une matière qui, à défaut d’être complètement maîtrisée, commence à être comprise, il n’en va pas de même du développement chez l’adulte. Tremeur nous présente les 3 niveaux de développement identifiés dans cette approche

  1. Socialized minds : ce sont les joueurs d’équipe. La perception des autres compte. Mais ces personnes tendent à comprendre ce qu’ils veulent entendre.
  2. Self authoring minds : Ces personnes sont guidées par leur propre agenda. On y retrouve beaucoup de managers. Etonnant de voir cela décrit comme un stade au-dessus du précédant. Peut-être parce que ces personnes ont sû se sevrer de l’approbation des autres…
  3. Self transforming minds : ce sont les personnes qui apprennent à apprendre, qui capable d’entendre et d’intégrer les différents éléments qui leur sont soumis.

En gros, plus une personne est haut dans son développement, meilleurs sont les résultats qu’elle obtiendra.

Les types d’apprentissage

Il y en a deux:

  • Les apprentissages techniques : ils nous permettent d’apprendre le “quoi”.
  • Les apprentissages adaptatifs : ils vont nous permettre de créer de nouveaux savoirs, de développer de nouvelles capacité. C’est le travail sur nous-même. C’est ce que Tremeur apelle développer notre capacité à faire des liens.

Les filtres : ils rendent subjective notre perception de la réalité.

Le diagnotique de l’immunité

L’approche de Minds at work s’appuie sur un template en 4 parties

  • L’objectif : c’est ce que nous voulons changer dans notre comportement. Nous ne sommes pas nécessairement les mieux placés pour en juger, d’ailleurs. Pourquoi ne pas demander aux autres ce qu’ils pensent que nous devrions changer en nous ?
  • Ce que je ne fais pas (ou plus) par rapport à cet objectif
  • Quels sont mes engagements cachés qui vont à l’encontre de l’atteinte de mes objectifs.
  • Quels sont les postulats fondamentaux qui me guident.

Le travail sur cette “carte” se fait de manière itérative, mais chaque point sert de point de départ au point suivant. C’est en sorte une analyse causale que nous devons faire en nous-même…

Pour illustrer son propos, Tremeur n’a pas hésiter à montrer la carte qu’il avait construit pour lui-même ! Chapeau l’artiste, il fan avoir du courage pour se découvrir ainsi ! L’aspect auquel il faut porter attention lors de la construction de la carte, c’est que les points mis en évidence doivent s’appuyer sur des comportements identifiés et non des ressentis. Il s’agit d’objectiver les éléments, toujours la question des filtres…

Cette démarche a pour but de nous faire prendre conscience de nos immunités, à l’image des 4 stades de la connaissance :

  1. Inconsciemment immunisé
  2. Consciemment immunisé
  3. Consciemment désensibilisé
  4. Inconsciemment désensibilisé

La dernière étape est de travailler sur notre système immunitaire (mais c’est déjà bientôt la fin de la session). Il y a 3 axesChange prevention system

  • Feeling system
  • Knowing system

J’ai zappé pas mal d’éléments, mais je ne vais pas refaire la présentation de Tremeur. Je n’y arriverais pas, je la met plutôt en liens. Je ne suis pas un super-fan des techniques de coaching, mais cette présentation est un de mes “keepers” de la journée.

Revue de code et publications continue

Après la pause déjeuner, c’était la demi-heure “lightning talk”. Bon là, il va me falloir être un peu honnête : je passais en seconde partie et je suis un peu du genre stressé … bref, je n’ai pris aucune note sur la présentation d’Arthur Lutz qui précédait la mienne. C’est fort dommage car cet exemple d’intégration d’outillage mérite le détour. mais vous avez la présentation ci-dessous : have fun !

En finir avec…

Ouais voilà, c’est mon tour ! Quelques personnes quittent la salle, mais une vague tout à fait honorable s’y engouffre. Ce n’est pas salle comble pour moi, mais pas très loin en fait ! Je ne vais pas vous asséner cette présentation à nouveau, la voici en lien en attendant l’article si j’ai le courage de l’écrire…

Voilà pour cette seconde partie de mon retour sur cette riche journée. Tellement riche qu’il va me falloir un troisième opus si toi, courageux lecteur, je ne t’ai pas encore dégouté !

Notre galaxie à 9 Giga Pixels

Il s’agit d’une vue agrégée de multiples prises de vues de la partie centrale de notre galaxie, soit 84 millions d’étoiles.

Je vous recommande le lien vers la vue zoomée figurant sur cette page. Cette vue reste un peu décevante eut égard à la taille annoncée de cette fresque. Si vous avez 25 Giga octets d’espace disque et un écran vraiment, vraiment très grand vous pouvez télécharger la vue originale dans un format compatible Photoshop.

Notre galaxie à 9 Giga Pixels

L’Agile Tour Nantes (en images) 1/3

Soirée entre amis

Pour nous l’Agile Tour Nantes a commencé le 14 : rendez-vous étais pris avec quelques membres d’Agile Nantes. Le lieu était fixé : La bar restaurant établi dans les anciens anciens locaux des biscuiteries Lu. Je sais désormais que LU signifie “Lefèvre Utile”. Le lieu est vaste en espace et en hauteur et garde les stigmates de l’ère industrielle. Il me rappelle un peu les squats Berlinois. J’aime bien.

atnantes2012-soiree04

Arrivé vers 19h00 avec Caroline et Emilie (qui animeront la session “Des mots, des maux ? Démo !”) nous rejoignons Frédéric, Cécilia, Cécile et Pierrick. Une agréable soirée entre passionnés qui ont plaisir à se revoir.

Wake up !

J’avais pris l’option “hôtel en cambrousse mais pas loin de la conf’”, donc j’arrive à pied ! L’école des Mines de Nantes est franchement loin de la ville, mais au moins, il y a de la place. En témoigne l’accueil dans le hall d’entrée.

atnantes2012-accueil01

Assez ri, il est temps de se rendre à la session d’ouverture, guidé par Alvin Berthelot dit “Le Policier” (mais seulement par moi).

atnantes2012-alvin

L’avantage d’être accueilli dans une école, c’est que les amphi sont bien fait pour donner de la visibilité sur la scène. Et on est pas non plus obligé de prendre nos notes sur nos genoux !

Ah, les bancs de la fac ! Me voilà revenu de 30 ans en arrière…

atnantes2012-public01

Ouverture

Pierrick Thibault donne le tempo pour lancer cet Agile Tour Nantes : il sera sur le thème du jeu ! Et on applaudit bien fort la sympathique équipe d’Agile Nantes qui a rendu cette journée possible.

atnantes2012-ouverture04

Keynote

La keynote du matin était assurée par Tremeur Balbous, Breton éxilé au Quebec et aussi créateur de la communauté agile Nantaise. Le titre de cet opus d’ouverture était simplement : On est agile !

atnantes2012-tremeur01

Le passage à l’agilité nous a évité d’aller dans le mur, alors que la gestion de projet classique nous y menait tout droit ! Evité ? Non ! Nous avons juste retardé le moment d’aller dans le mur. Et ce malgré l’agilité.

Tout d’abord, quels sont les bénéfices attendus de l’agilité ? Les enquêtes montrent au premier plan les critères suivants : Time to market, gestion des priorités, gestion du changement, respect des budgets. Des critères tels que le plaisir des équipes arrivent loin.

Quels sont les bénéfices obtenus ? Ils sont différents, avec le plaisir des équipes arrivant assez haut !

Tremeur nous assène son message : le passage à l’agilité n’est pas essentiellement un changement d’organisation, mais une philosophie qui nécessite un changement de perspective. Les causes d’échec ne sont pas exogènes, mais endogènes. Elles sont à chercher en nous (ce que l’on verra dans la session suivante : immunothérapie au changement).

“Change en toi ce que tu veux changer dans le monde” – Ghandi

Il faut donc commencer par travailler sur nous, changer nous-même, apprendre à nous connaître. Il faut investir sur nous-même, par exemple en suivant les conseils de Matt Cutts en essayant quelque chose de nouveau pendant 30 jours.

Ainsi se résume le message d’introduction de Tremeur:

  • Si on reste focalisé sur les pratiques, on va dans le mur.
  • Si on travaille sur nous-même, nous réussirons.
http://fr.slideshare.net/slideshow/embed_code/15206868

Voilà pour aujourd’hui. A bientôt pour la seconde partie !

En finir avec … (le lightning talk)

Voici le support de mon lightning talk “en finir avec …” tel que je l’ai présenté l’Agile Tour Nantes 2012. C’est une présentation courte, de moins de 15 minutes.

Teaser de la présentation

L’agilité est en pleine expansion. Nombreux sont les projets, nombreuses sont les sociétés qui l’adopte ! Nous devons nous féliciter de cet engouement, et pourtant …

Pourtant cette adoption croissante n’est qu’apparence dans certains cas. Dans plus en plus de cas, même. Si Scrum est aujourd’hui l’approche qui fédère le plus, les quelques idées centrales de la méthode sont de plus en plus souvent dévoyées. Il en va de même d’autres pratiques agiles.

Ah ! Vous faites du Scrum, je vois que vous avez un P.O. et un Scrum Master. Vous n’avez plus de cahier des charges mais des User Stories, donc tout va bien.

Cocher la liste des pratiques agiles en repeignant plus ou moins les vieilles pratiques ne convient pas, il faut en finir avec cela !

Dans cette courte session, je vous propose de faire la peau à 3 pratiques : la Roadmap, le Product Owner et les User Stories. Mais vais-je vraiment les assasiner ? Pour le savoir il vous faudra assister à ce lightning talk !

Quelques rappels sur “en finir avec”

Cette série comprend aujourd’hui une présentation générale du principe de cette série ainsi que 3 posts:
Elle compte désormais la présente présentation, et une partie de la présentation de Caroline Damour et Emilie Franchomme à laquelle j’ai participé (du moins pour “la dernière”).
Viendront cette présentation sous forme d’articles, d’autres posts (certains sont en préparation, soyez patients) et peut-être une saison 2 ?

Note de lecture : Liferay Portal Administrator’s Guide 2nd édition, par Richard Sevoz Jr

Note : 3 ; Quand on a vraiment besoin, on n’a pas forcément le loisir d’être difficile sur la forme…

La première chose que l’on découvre quand on prend ce livre en main, c’est qu’on n’a pas envie de lire ! Le format n’est pas pratique (trop grand pour un format poche, mais trop petit pour une lecture confortable), le papier est de qualité très médiocre, la mise en page est lamentable, la qualité des illustrations inexistante et même la typographie n’est pas en reste avec ce charmant carnage.

La bête fait 255 pages hors annexes (celles-ci sont anecdotiques) sur seulement 6 chapitres. Des chapitres assez longs en moyenne, donc.

En parcourant le chapitre 2 « initial setup », on s’aperçois toutefois de certaines choses : d’abord il est vrai que les copies d’écran sont franchement trop nombreuses, même si certaines sont utiles (elles ont souvent des indications comme des parties cerclées, au lieu d’être brutes comme c’est trop souvent le cas). Cela explique la longueur inhabituelle de 89 pages pour ce chapitre. Mais les informations sont claires et précises et des recettes d’installation numérotées permettent de venir à bout de difficultés dont on sait qu’elles prennent du temps sinon. A propos de l’installation, la liste des serveurs d’application pour lesquels est fourni une explication est tout simplement impressionnante.

Le chapitre 3 « configuration » est quand même plus court, avec ses 44 pages. Mais il a un petit goût de tutorial un peu cheap dans sa première partie. Le genre où l’on apprend rien. La partie dédiée à la configuration LDAP rattrape un peu le coup.

La configuration avancée, vous savez celle où l’on parle des « ext » est traitée au chapitre 4. C’est le plus long du livre et de loin, avec ses 90 pages ! Les très complexes fichiers de propriétés sont passés en revue, mais souvent avec des explications franchement sibyllines. La recherche et l’exploitation des informations de ce chapitre sont l’affaire de gens motivés et acharnés … et qui en ont vraiment le besoin. Abandonnez l’idée d’en faire une lecture linéaire. Seule la section dédiée à l’installation des plugins nous offre un oasis d’une relative fraicheur.

Le chapitre 5 « enterprise configuration » nous expose en un peu moins de 30 pages les possibilités de déploiement de Liferay en mode « solid rock » : clustering, cache distribué, déploiement à chaud, etc… sont les sujets qui y sont traités. Le chapitre a le mérite de développer un peu ses explications.

Le dernier chapitre « maintaining a Liferay Portal » parle backup, logging, procédures d’upgrades sur une dizaine de pages.

Voilà un texte auquel on ne s’attaque pas pour le plaisir. Si certains chapitres présentent des procédures d’exploitation claires, l’ensemble de la prose est très sèche et peut surtout être utilisée comme référence. Mais même là, ce n’est pas du grand confort.

Un tel ouvrage se doit de rester à jour par rapport aux nouvelles versions de Liferay. Une troisième édition de cet ouvrage y répond.

liferay-portal-admin-2nd

Référence complète : Liferay Portal Administrator’s Guide 2nd édition – Richard Sevoz Jr – Liferay Press 2008

Liferay Administrator's Guide


http://www.goodreads.com/book/add_to_books_widget_frame/0615196489?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on