Catégorie : Compte-rendu

Retours sur Agile France 2013, 1ère partie (en images)

Le par addinquydans Compte-renduLaisser un commentaire

J’avais fait l’impasse sur l’édition 2012, je suis revenu pour l’édition 2013. Cette année encore Agile France promettait un programme attrayant : promesse tenue ! Le “take away” de ces 2 jours de conférences ne rentre guère dans mon sac à dos, c’est un semi-remorque qu’il va me falloir. Une fois de plus, je vais vous distiller cela en plusieurs parties.

Place à l’action, ou plus précisément à la première session de la journée.

agileFrance2013-01Keynote02

Peter Stevens : From Value to Values

Why management has to change and how IT is inspiring the solution

Nous étions quelques un à avoir eu l’occasion de croiser Peter Stevens lors d’une Scrum Beer il y a environ 2 ans. Cette fois, il nous faisait la keynote de la conférence et venait nous parler du Stoos Network. J’avais une première fois évoqué ce mouvement à l’annonce du Stoos Connect, puis plus récemment pour parler du Stoos Satellite Paris.

C’est bien du Stoos Network dont Peter Stevens est venu nous parler. Selon lui, le monde se divise en 2 types de sociétés:

  • Celles qui enchantent leurs clients.
  • Les autres.

Vu comme ça, c’est un peu simpliste. Creusons un peu. Aujourd’hui, les compagnies ayant un fort “focus client” sont celles qui gagnent de l’argent. Car il n’a jamais été aussi facile de changer de fournisseur ou de service. Votre service de téléphonie ne vous plait plus, résiliez-le dès aujourd’hui pour prendre un nouveau plan ! Il y a 30 ans, Peter Stevens nous confiait qu’en Suisse, un abonnement téléphonique nécessitait un dépot de garantie équivalent à un demi-mois de salaire ! Nous avons donc changé de logique :

  • Autrefois : “you take what we make”.
  • Aujourd’hui : “I choose what I want”.

Pour autant, ce changement de polarité ne s’est pas accompagné d’un changement de paradigme dans la logique de l’entreprise.

agileFrance2013-01Keynote03

L’entreprise moderne continue de choisir son cap en fonction des dividendes qu’elle peut reverser à ses actionnaires. C’est une logique qui n’est en fait pas celle permettant d’obtenir les meilleurs résultats car elle part du mauvais point.

Pour enchanter le client, il faut augmenter la vitesse de réactivité, faire grandir la capacité d’innovation. L’économie d’aujourd’hui est une économie de la créativité. Toutes choses que le mode de fonctionnement “commande / contrôle” hérité du Taylorisme et du Fordisme ne permettent pas.

Il doit y avoir une meilleure façon de faire, c’est le constat que différents courants de pensée du réseau Stoos (radical management, tribal leadership, beyond budgeting, management 3.0, etc…). Et elle s’inspire de l’agilité.

Pour Peter Stevens, l’élément le plus important du manisfeste agile se situe en haut de celui-ci :

We are uncovering better ways of developing software by doing it and helping others do it.

Stoos Network est un “mouvement de mouvements” qui promeut l’entreprise non comme une structure pyramidale, mais comme un réseau “apprenant” de personnes, dont les managers seraient les servants.

Aujourd’hui, l’agilité dans les projets informatiques est confrontée à une frustration de par les conflits qui l’opposent à un management classique. Stoos est la continuité de ce mouvement vers l’organisation de l’entreprise.

Je n’ai pas trouvé la présentation de Peter Stevens, mais un support qui s’en approche de très près.

J’ai été un peu déçu par cette keynote. Bien que quelques exemples (visibles sur les supports) aient pu nous donner à réfléchir, elle est pas mal resté dans les généralités.

Géry Derbier : Le leader en tant qu’hôte

J’avais suivi de loin l’intérêt de Géry pour le host leadership, mais sans m’y intéresser plus avant, car on ne peut pas être partout, n’est-ce pas ? Mais Géry étant mon futur collègue, j’essaie de le pister un peu…

Déjà, ça commence par le coincer en face de mon objectif !

agileFrance2013-02Gery01

Cette session était en fait un atelier participatif. On parle toujours du “servant leadership” par opposition au “leader command & control”. Certes, mais comment cela peut-il se matérialiser ? Il y a-t-il des parallèles avec de choses que nous connaissons qui pourraient nous aider ?

Il se trouve que oui !

Que se passe-t-il quand nous participons à une fête que nous jugeons réussie, que fait l’hôte pour rendre cela possible ? C’est à ce travail de reflexion que nous a invité Gery aujourd’hui. Par petits groupes, nous avons cherché à décortiquer les ingrédients d’une fête réussie

agileFrance2013-02Gery03

Une reflexion pas très facile à mener en un temps limité. Je vous livre en vrac les points qui sont remontés :

  • Favoriser l’émergence, laisser de la liberté pour permettre la créativité.
  • Avoir une (des) réactions en chaine. A l’image de ce qui se passe quand on commence à danser.
  • Créer le lien entre les personnes. C’est vrai surtout quand nombre d’entre elles ne se connaissent pas. C’est moins le cas dans des réunions de famille.
  • Le pouvoir de l’invitation. On ne vient pas sous la contrainte, c’est un acte volontaire.
  • Donner la permission, ou comme le dira Olivier Pezziardi “pas faire chier les gens”.
  • Ne pas chercher à obtenir un résultat. On créé les conditions, le résultat vient en second.

Mais est-il possible de considérer un projet de la même manière ? Sommes-nous invités à nous joindre à un projet ? J’aurais tendance à répondre “oui”. En fait, cela se passe beaucoup dans la tête: nous sommes invités si nous avons envie de nous sentir l’être. Mais c’est juste un avis personnel. Je vous invite à lire le white paper accessible sur le site host leadership.

Cyrille Martraire : Code legacy : Faire évoluer ou réécrire ?

Cyrille est un adepte fervent du DDD et un membre actif de la communaute du software craftmnship. Aujourd’hui il vient évoquer avec nous les stratégies de travail sur le code hérité (legacy code). Cette présentation s’appuie sur un projet mené chez Sungard autour d’un système d’asset management. Nous parlons ici d’une application vieille de 20 ans lourde de 20 millions de lignes de code avec des procédures stockées, des EJB2, etc…

agileFrance2013-03Martraire02

Mais qu’appelle-t-on “code legacy” ? Pour Michael Feathers, du code hérité n’a pas de tests. Si l’on se calque sur cette définition, du code hérité n’a pas besoin d’être vieux pour être considéré ainsi !

Alors, faire évoluer ou récrire ?

Il faut regarder les choses avec lucidité: espérer que tout soit “beau” un jour est illusoire. Ca n’arrive pas !

Le postulat de départ est donc : on garde tout ! Mais pour faire évoluer en gardant l’existant, il faut se munir de tests, d’une manière ou d’une autre. Comment faire ?

Je vous présente le “Software Testing Ice-Cream Antipattern” ! On commence par le haut: si on a rien, on fait des tests manuels. Puis on essaie d’automatiser les tests par l’IHM. Dès que le découpage en couches devient à peu près présentable, on passe à des tests d’intégration pour tester les API. Enfin quand le niveau de découplage interne le permet (le plus souvent jamais) on met en place des tests unitaires !

softwaretestingicecreamconeantipattern

Bien sûr, c’est très coûteux, et l’orateur évalue le différentiel de vélocité de 1 à 4 par rapport à du code neuf écrit en TDD.

Et s’il faut réécrire, doit-on réécrire ?

Pas toujours. C’est la fameuse question du “make vs buy”. Si le processus métier habillé avec le logiciel est un différenciateur de l’entreprise, alors il faut faire ! Comment se différencier en pratiquant la même chose que les autres ? Si ce n’est pas différenciateur, alors il faut essayer d’acheter. Oui, mais le logiciel sur étagère ne corresponds pas exactement à ce que je fais … N’essayez pas d’adapter, même si l’éditeur dit que l’on peut, même si de nombreuses société qui sont prêtes à vous vendre du conseil disent que l’on peut (et qu’elles peuvent vous “aider”). Ou alors, faites-le à minima, faites votre possible pour plutôt adapter vos processus au logiciel. De toute façon, ce ne sont pas eux qui vous rendent différenciant, ce sont des centres de coût.

Visualiser

Il est bien rare que l’on doivent intervenir partout en même temps dans du code hérité. En fait cela concerne le plus souvent un volet précis de l’application : une phase de traitement, de nouveaux instruments financiers, etc…

La première étape que nous propose Cyrille est de visualiser le flux métier. A l’image de ce que l’on montre lorsque l’on construit une story map (là c’est moi). Il s’agit de donner de la structure. Sur celle-ci s’appuient des fonctions secondaires et des concepts. C’est le travail péparatoire qui va nous permettre de passer à la suite. Ce que Martin Fowler appelle l’Asset Capture.

A partir de là, il va falloir identifier le ou les assets concernés par l’évolution.

Comment intervenir

Quand on part d’un legacy à priori inconnu, il y a une démarche logique pour aborder la bête :

  1. Lire la documentation
  2. Interroger les anciens qui la connaisse peu ou prou.
  3. Utiliser l’application.
  4. Lire le code.
  5. S’essayer dessus en fixant des bugs.

Le principe de base des évolutions, est de ne pas essayer de faire plusieurs choses en même temps. Il faut y aller prudemment, s’insérer dans l’existant même si on n’aime pas ce que l’on voit. Des conseils souvent prodigué dans les Reengineering Patterns.

Comment s’organiser

Comment pensez-vous procéder : en opérant une réécriture iso-fonctionnelle ? Sachez-le, personne ne paie pour cela.

Une réécriture s’accompagne toujours d’une certaine dose d’évolutions. Oubliez l’idée d’une équipe refonte constituée de pur techos, il va falloir une vrai équipe projet regroupant des compétences diversifiées (analystes, testeurs, etc…).

Maintenant il faut se mettre au boulot !

Strangler application

Le pattern préféré de Cyrille est le Strangler Application Pattern, lui aussi décrit par Martin Fowler. Comme son nom l’indique, ce pattern consiste à “étrangler” progressivement l’application existante en envoyant les traitements qui ont été réécrits vers la nouvelle application. Le point faible étant ce dispatching qui doit alors exister dans l’ancienne application, nécessitant un refactoring pas nécessairement négligeable… Les deux points clés de l’approche sont:

  • Le décomissionement des concepts : on travaille concept par concept, et on switch complètement l’un d’entre-eux quand il est prêt dans la nouvelle application. C’est donc mieux quand les concepts sont assez atomiques.
  • Le “feature toggle” qui doit permettre le basculement vers la nouvelle application. Attention, parfois cela se passe mal, il est alors souhaitable dans ce cas de pouvoir revenir en arrière.

Bubble context

Le développement de nouveaux concepts s’opère dans une “bulle” isolée des adhérences avec l’existant, du moins autant que faire se peut. C’est l’Autonomous Bubble Context décrit par Eric Evans.

Isolé du monde legacy, le développement s’opère comme un nouveau développement, en TDD & BDD. Entre l’ancien et le nouveau monde, une Anti-Corruption Layer isolée vers le haut par une API et par le base par une SPI, opère comme un sas entre les deux environnements.

Quelques points clés à ne pas oublier :

  • Se faciliter la vie en ayant un certin niveau de mapping avant l’existant. On pense surtout ici au mapping avec la base de données.
  • Décréter le “freeze” de l’existant : toute évolution doit s’opérer dans une Bubble Context. On touche seulement à l’existant pour opérer des renvois vers la bubble context.
  • Ne pas oublier qu’une bulle n’a qu’un temps. Avec le passage du temps, elle-même deviendra du legacy à son tour un jour.

Pour résumer la stratégie de réécriture, l’orateur nous résume la chose :

Réécriture = Frontières clairement définies + stratégie d’étranglement + intégration minimale.

Je n’ai pas exactement le support que Cyrille a utilisé, mais un très proche. Le voici 

Lectures recommandées

Essentiellement 3 ouvrages à connaitre. Ils sont tous sur mes étagères mais n’ont pas encore fait l’objet d’une note de lecture publiée :

Vous pouvez également lire l’excellent retour de Vincent Uribe sur cette session, sur le blog Soat.

Break !

Le début de matinée a déjà été bien rempli. Il est temps de faire une pause. C’est une occasion pour reprendre contact avec les uns et les autres. On est là aussi pour ça.

agileFrance2013-04BreakJeudiMatin02

C’est aussi la pause pour la publication de mon retour d’Agile France. Nous sommes agiles, on va faire tout ça de manière itérative, que diable ! Rendez-vous bientôt pour la suite de mes périgrinations agilistes.

Déjeuner Stoos Paris de Mai

Le par addinquydans Compte-renduLaisser un commentaire

J’avais évoqué il y a peu le Stoos Satellite Paris. Je dois l’avouer, nous n’avons pas fait preuve de l’assiduité dont nous avions l’intention au départ.

StoosParisMai-Dejeuner2

Se voir le temps d’un déjeuner était une bonne façon de reprendre le ryhme, même sans agenda bien défini …

Ca devient presque une habitude, mais on a aussi parlé de Lean Startup et de Lean Startup Machine auquel Oana va participer en tant qu’animatrice.

La mauvaise nouvelle, c’est que je suis reparti avec une nouvelle référence à lire : Liberté & Cie d’Isaac Getz ! Ca devient dramatique …

Comme on n’avait pas d’agenda, les discussions furent décousues … et émergentes !

Transformation et rupture du contrat social

Comme à chaque fois qu’il est parmi nous, Julien nous a asséné une réalité qui est le fruit de son expérience : les transformations organisationnelles radicales n’arrivent qu’après qu’il y ait eu rupture du contrat social ! L’entreprise cherche à renaitre, mais la confiance est perdue, les employés sous le choc.

C’est donc bien la présence d’un danger mortel qui est le facteur déclencheur. Pourquoi amorcer un changement radical si les contraintes sur l’entreprise ne l’exigent pas ? Bien sûr, cela complique d’autant le travail de transformation :

  • Comment repartir de l’avant ?
  • Comment construire un projet pour l’entreprise dans ce contexte ?
  • Comment changer les personnes quand la confiance est rompue ?
  • Comment mettre l’entreprise et ses hommes en situation de regarder vers l’avenir quand le passé récent nous étreint ?

Nous n’avons répondu à aucune de ces questions. Mais Julien nous a bien remis les pieds sur terre : les dynamiques de changement n’arrivent QUE dans les situations les plus difficiles.

ScrumBeer de Mai, bientôt l’été

Le par addinquydans Compte-renduLaisser un commentaire

L’été approche, on reprends un peu de rythme après notre ScrumDay. Notre Grand Organisateur des ScrumBeers AKA Arnaud nous avait convié à cette nouvelle rencontre informelle.

ScrumBeerMai-YannickAnne1

Comme d’habitude, pas d’agenda. Beaucoup d’inscrits, peu de présents (6 sur 17), mais c’est sans importance. Deux étudiants, Charles et Marie, s’étaient joints à nous. Une occasion de voir si nous savons mettre nos propos à la portée des non initiés. Nous sommes parfois moins accessibles que nous le pensons !

ScrumBeerMai-CharlesMarie

Notre idée originale était de faire un peu de teasing en attendant le ScrumBoat. Celui-ci a été reporté depuis. Tant pis ! Mais nous avons évoqué l’apport des innovation games comme élément disruptif, des difficultés liées au changement. Marouane nous a apporté un éclairage original sur les différences culturelles et la façon dont elles impactent la façon dont est perçu le changement.

ScrumBeerMai-Marouane2

Bref, la ScrumBeer, c’est de la balle !

ScrumBeerMai-ArnaudMoi

On me fait parfois remarquer que je ne suis jamais sur les photos. Ce n’est pas encore complètement réussi pour cette fois-ci. Mais bon, l’auto-portrait à bout de bras, ce n’est pas si simple.

Je ferais mieux pour la prochaine ScrumBeer … en Juin ?

Stoos Satellite Paris : qui sommes-nous ?

Le par addinquydans Compte-renduLaisser un commentaire

Au commencement…

Eh bien au commencement, il y a eu l’annonce de la conférence Stoos Connect à Amsterdam. Bien sûr, le Stoos Network existait avant cela, sans pour autant pouvoir revendiquer une longue histoire. Mais sur l’hexagone, il n’y avait rien d’organisé.

Afin de bénéficier de la conférence, Oana Juncu et Yannick Grenzinger ont pris l’initiative de rechercher un lieu nous permettant d’assiter à la conférence en livestream. Ce qui fut fait à La Cantine.

Autant le dire, nous n’étions pas nombreux. D’ailleurs nous ne le sommes toujours pas et ce n’est pas non plus notre but premier. Le livestream était assez médiocre, les interventions de qualité inégales, mais nous avons vécu nos meilleurs moments … pendant les pauses ! Pour les curieux, vous trouverez un compte-rendu (par votre serviteur) des différentes interventions ici (première partie), ici (seconde partie), ici (troisième partie) et enfin ici (dernière partie).

Bref, nous sommes sortis de là avec des sentiments mitigés à propos de ce premier Stoos Connect, mais avec l’envie de continuer ensemble pour voir où cela pourrait nous mener. Personnellement, j’ai bien aimé le groupe, ce fut vraiment la bonne surprise de cette rencontre et ce sentiment semble partagé.

Donc oui, nous allons essayer de faire quelque chose.

Au fait, oui : qui sommes-nous ?

Notre première action a été de créer une communauté Google Plus que nous avons pompeusement nommée : Stoos Paris. Dans le vocable du Stoos Network, chaque émanation locale s’appelle un “satellite”. Nous sommes donc le Stoos satellite in Paris !

Aujourd’hui la page de la communauté Google Plus est notre point de rencontre. Il n’y a pas d’association, pas de site web dédié, etc… Nous n’en avons pas l’usage aujourd’hui. Nous verrons plus tard si le besoin s’en fait sentir…

Puis nous avons eu notre première (et aujourd’hui unique) rencontre. C’était le 5 Février.

stoos-2013Fev-groupe02

Quand je vous disais que nous n’étions pas nombreux…

Pas d’agenda compliqué pour cette première rencontre, mais le désir de répondre au “pourquoi”, “quoi” et “comment” de ce Stoos Satellite Paris. Nous avions aussi fait une vidéo, mais elle a hélas disparu avec le matériel ayant servi à la prise de vue…

Nous nous étions aussi fixé comme objectif de nous rencontrer à interval de 3 semaines ou 1 mois, ce que nous ne sommes pas parvenus à faire jusqu’à présent.

Prochaine étape

Nous n’avons pas abdiqué ! Nous allons de nouveau nous rencontrer courant Mai et voir quelles actions nous pouvons entreprendre.

Rencontre avec Manfred Mack

Le par addinquydans Compte-renduLaisser un commentaire

Damné RER C !

Je prévois mon trajet, je prends une avance raisonnable, et ce foutu train n’arrive qu’après m’avoir fait attendre 30 minutes. Damnation !

Cette rencontre avec Manfred Mack est un déjeuné-rencontre comme Christine Koehler en organise régulièrement. La dernière était en Février, une rencontre avec Christopher Schoch.

Cette rencontre-là avait pour but de mettre en lumière de possibles modèles d’entreprise du XXIème siècle et d’en discuter entre nous. C’est en fait l’objet de son livre, Pleine Valeur paru il y a une dizaine d’année.

ManfredMack-Mack03

On parle ici de co-création de valeur, ou comment se rendre mutuellement meilleurs !

Plus précisément, Manfred Mack évoque l’approche développée par Spi-Batignolles dans l’offre Concertance dont l’origine remonte à la réponse à un appel d’offre pour la construction d’une soufflerie pour un consortium regroupant Renault et Peugeot. Non seulement Spi-Batignolles a pu répondre avec un tarif plus bas, mais le coût final s’est même avéré encore moins élevé, sans pour autant hypothèquer la satisfaction du client !

Pour se faire, Concertance s’appuie sur 3 axes :

  • La recherche d’optimisations en amont
  • Un fonctionnement en équipe projet conjointe fournisseur-client
  • La transparence

Les deux derniers points sont réellement à l’encontre de le la culture BTP, comme nous le confirme Manfred !

Le principe est d’avoir toujours : Coût < Prix < Valeur perçue

L’approche managériale est adaptée en conséquence : on demande ainsi aux managers d’être toujours capables de montrer comment et en quoi les plans qu’ils proposent contribuent à la création de valeur.

ManfredMack-assistance03

Les points abordés par Manfred Mack me rapellent beaucoup les principes du Lean tels qu’ils sont mis en oeuvre chez Toyota.

D’ailleurs Spi-Batignolles a fini par élargir cette approche à l’entreprise elle-même : si l’on considère les clients comme des partenaires, pourquoi n’en serait-il pas de même avec les collaborateurs ? C’est ainsi que l’entreprise a mis en place son projet “zéro accident” avec réussite, semble-t-il. Mais au-delà de cet exemple, il est frappant de constater l’influence de ce nouveau mode de pensée sur l’ensemble de l’entreprise.

Comme le dit Manfred Mack : on obtient au final une meilleure performance en abandonnant le focus purement financier pour la création d’une “sur-valeur”.

Le dernier point concerne les conditions initiales nécessaires : Une direction en recherche “d’autre chose” donc un PDG visionnaire.

Le monde du BTP est bien le dernier où j’aurais pensé voir ce type d’approche. Manfred Mack semble en tout cas être extrêmement enthousiaste sur ce qui a été accompli avec Concertance. Il endosse depuis un moment déjà un rôle d’évangéliste dans le monde professionnel comme celui de le formation des futurs diplômés.

Christine Koehler nous a proposé ensuite de discuter par petits groupes de 4, sur 3 questions gravitant autour de cette approche.

ManfredMack-Groupe01

Dans mon groupe, la majorité des participants étaient intéressés par les questions d’intelligence collective et de co-développement. L’idée de “penser autrement” les relations entre client et fournisseur semblait en tout cas une pensée partagée.

Notre second tour de discussion a tourné autour des points importants de cette approche. Plusieurs éléments en vrac:

  • L’importance d’un objectif commun entre client et fournisseur.
  • La nécessité d’établir une confiance.
  • Effacer la notion de rôle telle qu’on l’entends généralement, qui implique un retranchement derrière un périmètre et des responsabilités non partagées.
  • La nécessité de travailler sur ses peurs et les peurs des collaborateurs. Et au contraire valoriser les personnes et les parties prenantes.
  • L’importance de l’expérimentation.
ManfredMack-Groupe02

La 3ème question était plus personnelle : en quoi cette démarche nous concerne plus personnellement ?

Chaque membre du groupe appréhende nécessairement ce point avec sa propre sensibilité, selon ce qui le touche le plus. Ainsi nous avons soulevés des points tels que :

  • La déonthologie par rapport aux clients : travailler pour résoudre les vrais problèmes. Ce ne sont pas nécessairement ceux pour lesquels les clients nous ont appelés.
  • Contribuer au plaisir dans le travail : Accomplir une mission non pas parce que l’on fait un travail que l’on nous a demandé, mais parce qu’on fait quelque chose d’utile, qui aidera réellement ce client en adressant son problème de départ.
  • Gagner en légèreté : Rendre le travail plus agréable et plus efficace.
  • Pouvoir faire plus demain que ce que l’on fait aujourd’hui.

Je vois un fil directeur à travers ces points : notre besoin semble de nous sentir en harmonie avec notre travail, d’assouvir un véritable besoin sinon physiologique, du moins intellectuel.

Pour finir Manfred nous suggère de réfléchir à cette question fondamentale qui guide cette démarche : Qu’est-ce que la valeur ? Pas seulement la valeur financière !

Cette question et d’autres points soulevés par Manfred Mack figurent dans le support que Christine a eu la gentillesse de mettre à disposition.

Pourquoi CloudBees ? avec Sacha Labourey

Le par addinquydans Compte-renduLaisser un commentaire

Sacha Labourey n’est pas un inconnu pour moi. Pour vous non plus peut-être. Soat nous poposait une rencontre avec cette figure marquante du monde Java à la veille de Devoxx France (je sais, ça fait déjà un bail …), je ne pouvais que sauter sur l’occasion.

Pour ceux qui l’ignoreraient, Sacha Labourey fut le CTO de JBoss après le départ de Marc Fleury, mais c’est en tant que fondateur et CEO de CloudBees qu’il se présentait à nous ce soir-là.

En fait de présentation, j’ai hélas rarement mis de photo aussi médiocre sur mon blog, mais c’est ainsi. La voilà.

SachaLabourey01

CloudBees propose une plateforme pour héberger la totalité du cycle de vie d’une application Java sur le cloud. En l’occurrence, il s’agit du cloud d’Amazon, mais ils travaillent activement à rendre leur plateforme indépendante de l’infrastructure du géant de l’e-commerce afin de donner plus de flexibilité au client.

Hardware as a commodity

A la base, il y a la conviction que l’on se dirige vers une commoditifaction (est-ce vraiment un mot ?) du hardware. Sacha Labourey évoque le parallèle avec l’électricité : si à ses débuts, il fallait posséder son propre générateur et gérer les aléas de la régularité de l’alimentation, aujourd’hui nous nous sommes “débarassés” du problème chez des prestataires. Nous n’avons plus que des prises de courant nous délivrant un courant normalisé, le reste est l’affaire de ce prestataire.

Ce mouvement inéluctable : spécialisation -> standardisation -> régulation, Sacha Labourey le voit s’appliquer aujourd’hui à l’infrastructure.

Doit-on aujourd’hui encore s’occuper des machines, de les configurer, gérer les mises à jours système et même les “piles logicielles” ? Existe-t-il une valeur spécifique à se construire sa pile logicielle spécifique ? Si elle existe, elle doit être marginale (du moins dans la plupart des cas) et ne justifie pas les efforts et le détournement de focus de la problématique métier que l’on souhaite adresser.

C’est là la proposition de valeur de CloudBees : rendre l’infrastructure aussi facile à exploiter qu’une prise électrique !

Cloud vs cloud vs cloud

On peut rappeler rapidement les 3 types de cloud proposés, ils sont déjà très connus:

  • IaaS : Ce sont les briques de base de l’IT. On pense à Amazon EC2, Rackspace, …
  • SaaS : Des solutions logicielles standardisées prêtes à l’emploi. Salesforce est probablement le premier nom qui vient à l’esprit.
  • PaaS : Il s’adresse aux développeurs. L’objectif est de ne plus avoir à gérer les serveurs et les services standard fonctionnant dessus : serveur d’application, load balancing, etc..

Le focus est sur le “S” final : voir les facilités comme des services, disponibles sous forme d’API. Cette dématérialisation offre aussi un avantage fort : la possibilité de faire des essais (donc des erreurs) et de commencer petit. On peut ainsi itérer rapidement sans devoir attendre des mises à disposition de serveurs et des installations logicielles. Elles sont prêtes et peuvent être exploitées tout de suite. Et être abandonnées tout aussi rapidement (le serveur ne finit pas à la cave).

Pour Sacha Labourey, une architecture typique d’entreprise serait la suivante :

  • Au niveau back-office : les systèmes “legacy”, très stables, intégrant peu d’innovation.
  • Au niveau front : des applications pour mobile (par exemple) communiquant avec un back-end évoluant très rapidement au rythme des nouvelles fonctionnalités disponibles dans l’appli mobile. Cette partie est peu stable et est le siège de beaucoup d’innovations
  • Une communication front / back selon les protocoles mis à disposition par le back-office

Aujourd’hui la partie front / produit est subordonnée aux frictions entre développeurs et départements “opérations”. Les personnes en charge des opération privilégient la sureté de fonctionnement et renaclent le plus souvent à déployer des solutions logicielles qui n’ont pas été validées en interne, ou en tout cas ne satisfont pas des critères d’acceptabilité.

PaaS et innovation

Pour améliorer la capacité à mettre en ligne, la tendance actuelle est le “devops”, faire travailler ensemble développement et opération et outiller les opérations de déploiement afin de pouvoir pratiquer très souvent des déploiement automatisés. Je fais là un gros raccourcis et ne rends probablement pas justice à ce qu’il y a derrière devops, mais l’idée est là.

CloudBees revendique du “no ops” ! Plusieurs facteurs sont nécessaire pour permettre cela. On verra aussi que c’est un peu une simplification, l’IT ne disparait pas.

  • Standardiser les environnements : à l’image de l’électricité délivrée en voltage et fréquence constants, la standardisation des environnements est un facteur clé. Chez CloudBees, ces environnements standards sont les ClickStacks.
  • Travailler en SLA : pour pouvoir se passer d’ops, il ne faut pas avoir à se soucier de contingences d’infrastructure telles que stockage, clustering, etc… Il faut pouvoir signer un engagement de performance, à charge du prestataire de faire les mises en oeuvre d’infrastructure nécessaires pour garantir cet engagement.

Avec le SLA vient la question du support : une plateforme intégrant des sous-systèmes tiers peut être sujete à des dysfonctionnements (ou des mauvaises utilisation) de n’importe lesquels de ces composants. Il est logique que le support de service intègre complètement le support ou la délégation de support de ces composants.

Bien sûr, cela n’a de sens que si l’on est capable de mettre cela en oeuvre non seulement sur l’environnement de production, mais aussi sur les autres environnements utilisés dans le cycle de développement : environnements de développement, d’intégration, de stagging, etc… Le support du cycle de vie de l’application est donc l’étape suivante logique. L’intégration continue y joue un rôle clé. 

Cycle de vie applicatif et gouvernance

C’est Jenkins qui est au centre du cycle de vie applicatif chez CloudBees. Il faut dire que Kohsuke Kawaguchi, la figure emblématique de ce projet open-source est un des leaders techniques de CloudBees !

Aujourd’hui, la partie faible me semble être toute la partie acceptance testing, AB testing etc… Mais c’est déjà le point faible de pas mal de projets. CloudBees propose quand même un environnement de stagging permettant de tester ses applications en conditions réelles : beescloud.com

Dans cette image que Sacha Labourey nous dresse, nous voyons une entreprise avec de nombreux projets, sur chacun d’eux les développeurs font des choix indépendants transformant le système d’information en gigantesque tour de Babel. Justement ce que l’IT cherche à éviter et lui vaut cette image d’épine dans le pied. Quel doit être le travail et la position du département IT, alors ?

C’est ce que Sacha Labourey appelle l’IT pragmatique : laisser faire, mais rester informés. Puis travailler en consolidation des différents projets ensuite (comment ? mystère …). De toute façon, si on bloque les projets trouveront le moyen de passer quand même !

Donc l’IT ne disparait pas, mais elle cesse de s’occuper d’infrastructure pour se concentrer sur les workflow de données, de services, etc… Elle reste le gardien du temple.

Tirer les leçons

Sacha Labourey a une vision très radicale non pas de l’IT de demain, mais de celle d’aujourd’hui :

  • Passer son IT sur le cloud inquiète toujours. Mais la peur ne peut pas être une stratégie ! Rester organisés à l’ancienne peut nous valoir de voir un département de 20 personnes se faire griller la politesse par “4 punks dans une cave” comme le dit Sacha !
  • Il faut profiter des gains compétitifs que représentent des services prêts à l’emploi.
  • Aujourd’hui, les investissements ne prenant pas en compte le cloud sont déjà de la création de dette ! Méditez là-dessus mes amis…

Ce que j’en vois

Sacha Labourey nous a bien secoué sur une vision du développement se passant dans le cloud, en rupture avec nos habitudes actuelles. Et il est très convainquant sur l’aspect des choses que nous n’avons plus à prendre en charge…

Pour aborder cette rupture, il faut permettre la montée en compétence progressive des équipes. Le ClickStart que propose CloudBees s’apparente surtout à des assistants logiciels. Il faut apprendre à travailler avec son usine logicielle dans le cloud. D’après notre orateur de la soirée, cela va vite. Mais quand même…

Accepter la standardisation : c’est une condition sine qua non. 

On peut avoir un développement produit dans le cloud. Mais qu’en est-il de la communication front-back, si le back-office est dans les murs de l’entreprise ? C’est très probablement un point faible. A moins que le back-office soit lui-même dans le cloud, ce qui est la solution préconisée par Sacha Labourey. Un tel choix nous amène rapidement à des considération de vulnérabilité de notre entreprise, dont les avoir ont quitté les murs pour être localisés … à des endroits que nous ne savons même plus localiser ! Mais ne sommes-nous pas déjà, voir plus, vulnérables avec l’informatique chez nous ? Il y a eu pas mal d’échange avec Sacha Labourey sur ce sujet et j’avoue que ces arguments ne manquent pas de fondements. Je ne vais cependant pas les développer plus avant, cela m’emmènerai trop loin.

La présentation de ce soir-là avait un ciblage très managérial, j’ai un petit regret là-dessus, surtout que notre orateur est un expert de haut niveau. Mais ce point m’était connu à l’avance, je n’ai donc pas de regrets à avoir.

Si vous avez le courage de voir le contenu complet, la video a été mise en ligne par Soat.

Il vous faudra un peu de la persévérance, car la video dure 2h30 … et contrairement à ce que Sacha annonce au début, il oubliera de répéter les questions !

Il me reste à remercier Soat pour cette opportunité d’en savoir plus sur le développement sur le cloud en général et sur Cloudbees en particulier, avec l’un des grands noms du monde Java.

Soat a également mis en ligne sur son blog une présentation plus technique de CloudBees en détaillant les étapes de mise en oeuvre.

4 (bonnes) raisons d’aller au Scrum Boat le 21 Mai

Le par addinquydans Compte-renduLaisser un commentaire

Oyez, oyez !

Le Scrum User Group organise ce 26 Juin un “Scrum Boat”. Qu’est-ce que c’est ? En quelques mots :

  • Une soirée entre agilistes, sur une péniche avec des ateliers (le programme va être publié très prochainement)
  • Un cocktail pour échanger entre nous.
  • Une balade sur la Seine, car nous serons sur une péniche et il serait dommage de ne pas en profiter.
  • Une fin de soirée dansante dont la durée dépendra de votre propre résistance.

Vous voulez en être ? Qu’avez vous à faire ?

J’avais posté quelques photos dans le post que j’avais fait à propos de l’appel à animateurs.

A l’origine prévu pour le 21 Mai, l’évènement a été reporté au 26 Juin.

Dépêchez-vous : le nombre de places est limité !

4 (bonnes) raisons d’aller au Scrum Boat le 21 Mai

SQL Server et l’agilité

Le par addinquydans Compte-renduLaisser un commentaire

Le GUSS, c’est à dire le Groupe des Utilisateurs de SQL Server organisait cette rencontre pour évoquer un sujet qui m’est cher au sein d’une communauté pas franchement reconnue pour son adhésion à l’agilité. Franchement, je ne savais pas à quoi m’attendre !

Déjà un bon point pour le cadre de rencontre convivial, certainement à retenir pour de prochaines Scrum Beer !

GUSS-Avril13-01

Maintenant, arrivons-en au fond. Je ne vais pas laisser trainer le suspens : j’ai passé une excellente soirée !

L’agilité est un sujet jeune dans cette communauté, on n’y trouve pas la touche de suffisance que l’on croise par ici ou le regard blazé que l’on rencontre par là … L’enthousiasme est là, avec l’envie d’avancer , la soif de faire mieux et le questionnement sur ce que l’on fait.

En parlant de questionnement, j’ai été aussi surpris par l’ouverture d’esprit des personnes présentes. J’ai souvent été confronté dans ce milieu à des personnes prisonnières de leur paradigmes, empreintes de dogmes pour ne pas dire de certitudes. Rien de tel ce soir-là.

Il me serait difficile de vous faire un compte-rendu circonstancié des discussions, mais je vais évoquer quelques points qui m’ont marqué. Dans le désordre.

Les limites de l’outillage

On peut aimer les outils qu’on utilise et faire preuve de lucidité à leur égard. La difficulté principale rencontrée par les développeurs BI utilisant Integration Services semble être l’aspect monolithique des solutions SSIS qui rendent inopérants les fonctionnement en branches avec les merges que cela nécessite.

Le second point évoqué est le problème de la resynchronisation des métadonnées qui fonctionne manuellement et nécessite de repasser sur tous les packages. Si on souhaite travailler sur un modèle de manière itérative, on fait face à ce problème très rapidement, et c’est d’autant plus handicapant que le projet est gros…

Le future du BI agile n’est peut-être pas le cube

Travailler sur un cube de manière itérative n’est pas facile. Vraiment. D’abord si on souhaite faire des “sashimi”, on devrait travailler sur un modèle de données évolutif. Or la synchronisation des métadonnées de SSIS est un obstacle à cela.

D’un autre côté, il n’est pas possible de rajouter des dimensions à un cube une fois en production, car cela remet en cause la granularité des faits qui alimentent déjà le cube !

Mes observations et mes réflexions m’amènent à penser que l’avenir du BI et surtout du BI agile réside dans des solutions “sans schémas” adoptées de manière différentes par le monde des bases NoSQL, je pense surtout aux bases orientées colonnes comme Hadoop. Il s’agit là non seulement de la disparition du schéma explicite, mais d’un paradigme différent où la structuration de la données disparait au profit de la capacité à retrouver cette donnée et à la traiter, et souvent de manière scalable. Un aspect prépondérant quand le monde du BI est tiré vers le Big Data.

C’était mieux avant…

Une voix discordante s’est élevée au milieu de ces reflexions agiles.

“Lors d’une itération, on a oublié de décliner des règles métiers sur d’autres tables. Avec un cycle en V, la spécification détaillée aurait pris en compte cela et évité l’erreur.”

Bien sûr l’argument ne tient pas. Notre interlocuteur aurait dû au contraire se féliciter de n’avoir eu à attendre qu’une itération pour corriger un oubli que le cycle en V ne saurait pas plus garantir ! De toute évidence, la contre-argumentation est d’ors et déjà acquise pour nos DBA Agilistes. Que du plaisir !

La difficulté d’un résultat de sprint démontrable

Quand je demande à mes interlocuteurs de m’expliquer leurs découpage en sprint, j’entends un motif recourent : d’abord un sprint de modélisation de base, un ou plusieurs sprints d’alimentation de Sas, puid d’ODS, viennent enfin les sprints de construction de cube puis de présentation !

C’est le moment de prendre mon air horrifié : pourquoi ne pas construire les sprints verticalement, avec une tranche fine allant de la modélisation de la base à la présentation en passant par les différents étages d’alimentation ?

Nous avons donné la réponse plus haut : la difficulté de construire une table de fait dont la granularité se rafinerait au fur et à mesure de l’ajout de dimensions, la pénalité de SSIS aux changements de métadonnées, etc…

Seconde question, donc : mais alors, si vous n’allez pas au bout de la tranche, que démontrez-vous ?

La réponse est bien sûr : ce qu’on peut ! Dans le cas d’un sprint de modélisation, par exemple, ce sera le modèle de données. Sur papier !

Bref, Scrum c’est l’art du possible, mais il y a vraiment matière à progression de ce côté. On en est pas au “vrai Scrum” !

Le poids des cérémonies de Scrum

Autre point évoqué : 2 semaines, c’est court, et en plus il faut ménager du temps pour la démo, la rétro, le planning meeting. Sans compter que ce dernier se trouve souvent pénalisé par la découverte “in situ” des aspects fonctionnels, laissant la portion congrue de la réunion au découpage en tâches et à l’estimation.

Ces problèmes ne sont ni nouveaux, ni spécifiques au BI avec SQL Server. Ce sont des choses que j’ai rencontré avec des équipes de développement Java. De ce côté nous avions amélioré les choses avec quelques pratiques courantes ou non :

  • Découpage en 2 (à quelques jours d’interval) du planning meeting : un volet découverte fonctionnel, et après 2 jours pour réflechir et assimiler, un pur planning meeting plus court.
  • Des workshops de tests d’acceptance regroupant développeur, PO, client final (quand il est différent) et représentant de l’équipe de test (quand il y en a une).
  • Et bien sûr des rétrospectives pour introduire des pratiques, alléger ou faire disparaitre celles qui paraissent inutiles.

En ensuite…

Pas mal d’échanges, l’envie d’aller plus loin … Le GUSS a émis l’idée d’une table ronde, elle me plait bien ! Tout le monde a l’air motivé, donc peut-être d’ici Juin ?

#OMG ! Mon équipe fait son haka en kanban style ! | Soat blog

Le par addinquydans Compte-renduLaisser un commentaire

Je n’ai pas pu assister à la présentation de Laurent Morisseau qui se déroulait de plus dans une salle non filmée !

Cet excellent post résume très bien cette session dans laquelle on retrouvera quelques anti-patterns qui font écho à mes posts et à ma présentation “en finir avec …”

#OMG ! Mon équipe fait son haka en kanban style ! | Soat blog