There is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement within a decade in productivity, in reliability, in simplicity.

Frederick P. Brooks in No Silver Bullet
Publicités

Note de lecture : Pro Full-Text Search in SQL Server 2008, par Michael Coles avec Hilary Cotter

Note : 6 ; Fait le boulot pour être pleinement opération sur le full texte selon SQl Server.

Un livre spécifiquement dédié aux fonctionnalités « full text » de SQL Server ? Cela peut sembler excessif, et d’ailleurs Apress nous a habitué à une qualité assez variable de ces ouvrages. Qu’en est-il de celui-ci ?

Le texte n’est pas exagérément volumineux : 270 pages pour traiter le sujet, 255 hors annexes, divisé en 11 chapitres. D’ailleurs le texte n’est pas non plus particulièrement dense : de nombreuses copies d’écran et listings. On n’atteint pas l’exagération ni pour l’un ni pour l’autre, mais disons que l’on est à la limite, à mon avis.

Le premier chapitre est une introduction aux principes de la recherche plein texte, aux principes de tokenisation de proximité et à l’intégration dans SQL Server. Une introduction plutôt sympathique et pas tellement violente. Mais on apprend 2/3 trucs.

Le second chapitre a trait à l’administration : depuis le setup jusqu’au backup en passant par les différentes options d’installation et de paramétrage. Un peu trop de copies d’écran à mon avis, mais le chapitre a le mérite de ne pas être superficiel.

Au chapitre 3 on attaque réellement les requêtes. On y voit plusieurs façon d’interroger a base sur la recherche plein texte. Les différents mots-clés T-SQL et leurs usages y sont traités. Efficace.

Au chapitre 4, on attaque des choses beaucoup plus compliquées et qui ne serviront pas à tout le monde : la construction d’une application utilisant l’indexation full texte. Il faut s’attendre à construire de complexes procédures, une véritable grammaire avec des cas d’utilisation ! J’avoue que cela dépasse ce que j’escompte faire ! C’est un prélude au chapitre 5 qui lui adresse la recherche multi linguale.

Au contraire, le chapitre 6 me paraît particulièrement utile : il adresse l’indexation full texte des « LOB » qu’ils soient TEXT, BLOB, XML ou filestreams. Je regrette juste le mélange de code T-SQL et de code .NET …

Chapitres 7 et 8 sont en quelques sorte complémentaires. Le premier traite des « stoplistes » permettant de filtrer le bruit généré par certains mots, tandis que le chapitre 8 traite de la gestion des thésaurus. Les possibilités offertes sont simplement étonnantes.

A partir du chapitre 9, on attaque réellement les parties avancées. Ici il s’agit des DMV, du moins celles servant pour le full text. Le chapitre 10 traite des filtres. J’ai un peu décroché, je l’avoue. Il suffit simplement de savoir qu’ils permettent de travailler sur des formats de fichiers spécifiques. Ici encore, le mélange entre T-SQL et .NET m’a quelque peu dérangé.

Le livre termine avec la question des recherches avancées, plus spécifiquement les recherches phonétiques.

Clairement ce livre couvre la question des fonctions « full texte » de SQL Server de manière très convaincante et exhaustive, du moins il me semble. Même si le texte n’est pas enthousiasmant, il fait le boulot pour devenir opérationnel sur le sujet !

pro-full-text-search-in-sql-server-2008

Référence complète : Pro Full-Text Search in SQL Server 2008, Take advantage of the vastly new and improved full-text search feature in SQL Server 2008 – Michael Coles with Hilary Cotter – Apress 2009 – ISBN : 978-1-4302-1594-3

Pro Full-Text Search in SQL Server 2008

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

Retours sur Agile France 2013, 2nd partie (en images)

Nous avons évoqué, il y a peu le début de matinée de la conférence Agile France 2013. Il est temps de reprendre notre bâton de pellerin et de poursuivre plus avant.

Mais avant cela, j’aimerais saleur l’équipe d’organisation. Je n’ai pu les prendre en photo tous. En fait, c’est la photo que j’ai où ils figurent !

agileFrance2013-06Pezziardi02

Grand merci à Eric, Ellène, Stéphanie, Caroline, Damien, Jonathan et Frédéric. Ils essaient tant de se faire discrets qu’il est difficile d’avoir la liste exacte !

Je dois vous avouer une chose : il y a certains orateurs que j’essaie de voir coûte que coûte. Je ne regarde pas le résumé de leur session, en fait je n’en regarde même pas le titre. Je viens sans me poser de question et je n’ai jamais été déçu. Quatre d’entre eux étaient présents sur ces 2 jours, bien répartis : 2 le Jeudi et 2 le vendredi. Coup de chance, pas de chevauchement entre leurs sessions. Vous découvrirez les autres plus tard, mais Pascal est l’un d’entre-eux.

Pascal Van Cauwenberghe : Real options

Quand et comment (ne pas) prendre des décisions

Les options réelles sont le pendant des options financières. Elles permettent :

  • D’exercer un décision à une date future
  • C’est un droit (et non un devoir) d’exercer ce choix à cette date future.
  • Ce droit s’achète cash à l’instant présent (c’est la prime).
  • L’exercice de l’option s’accompagne d’un coût (le prix de l’option) et d’un bénéfice éventuel.

Pour illustrer tout cela, Pascal va nous raconter des histoires. Il y en aura 3.

agileFrance2013-05VanCauwenberghe01

Un choix de design embarrassant

Notre première histoire nous emène dans le monde du jeu video en ligne pour les enfants. La date de sortie est fixée, la période de Noel est cruciale, on ne saurait la rater. Le contenu du jeu est à peu près dans les rails. Mais les créatifs veulent changer d’identité visuelle, mais ils ne sont pas sûrs, mais…

C’est là que rentrent en compte les options réelles : on veut pouvoir décider aussi tard que possible. Mais cela a un prix.

Ici, l’idée consiste à rendre la décision facile à changer. Le prix est donc un refactoring permettant un changement facile du design. Ce prix nous donne droit de retarder le moment ou il faudra arrêter la décision définitive. Une leçon importante à retenir :

Il faut payer le prix pour des options qui ont de la valeur.

Cette démarche débouche sur plusieurs conséquences :

  • La réalisation des tranches fonctionnelles est pensée en terme de rétro-planning par rapport à la date à laquelle on doit opérer le changement de design.
  • Une question pour le développement : est-on obligé d’appliquer le design dès le début ? En fait non. Le développement sera entièrement fait en noir et blanc. En fait, cette situation embarassante aura débouché sur une évolution du processus de développement: dorénavant, tous les développement seront fait en noir et blanc avec application du design à la fin !
  • Nécessité de traquer l’évolution de cette option toutes les deux semaines afin de voir si on dispose de plus d’information quand à son exercice ou non.

Le processus de suivi de ces options est le Real Options Optimal Decision Process décrit dans le livre Commitment.

Set-based development

Dans ce second projet, le challenge est différent : un service doit être développé, le temps est critique (comme toujours). Hélas le choix de la plateforme n’est pas encore arrêté. Mais on ne peut se permettre de mettre le projet en stand-by en attendant ce choix, le projet est trop critique !

Comment faire ?

Il suffit d’implémenter toutes les options ! En clair cela signifie :

  • Faire le développement sur des API isolant la plateforme. Ces API sont mises en places au fur et à mesure de l’avancement du projet.
  • Opérer parallèlement l’implémentation de ces APIs sur toutes les plateformes qui forment l’ensemble de nos option (deux dans le cas présent)

Un effet de bord positif est que cette approche simplifie le test du service, car parallèlement on va implémenter un “test server” qui est en fait un “mock” de la plateforme.

Plus tard le choix de la plateforme est arrêté. On se focalise alors sur l’une des implémentations de l’API.

L’histoire ne s’arrête pas là. Par le jeu des fusions / acquisitions d’éditeurs, l’éditeur de le seconde plateforme rachètera la plateforme A … et demandera à ses clients de migrer vers la plateforme B. Le Set-Based design rendra cela facile !

Plus tard, cet éditeur B sera lui-même … vous m’avez compris !

Une histoire d’intégration

La troisième histoire est celle d’un projet en retard. Le retard est déjà de 3 mois, il en faut encore 6 ! Arrêter ou poursuivre ?

Il y a des décisions à prendre, et celles-ci ne doivent pas tenir compte de l’investissement déjà réalisé : il faut le considérer comme perdu. C’est le Sunk Cost Fallacy. On a pratiquement toujours tendance à surestimer la valeur de ce que l’on a. La valeur n’est pas le coût.

Une histoire d’EDI, une question d’architecture

L’EDI permet d’interconnecter des vendeurs et des fabricants. De chaque côté de la plateforme, vendeurs et fabricants doivent implémenter l’API avant que l’éditeur customise celle-ci.

Malheureusement pour chaque partie prenante, l’implementation de l’API est un gros projet, donc subordonné aux retards qui sont le lot des gros projets. Comme la customisation de la plateforme est tributaire de l’implémentation des API de chaque côté, la planification de ce travail ne sert à rien !

L’intégration dure longtemps, car elle est conséquente et n’intervient qu’une fois que chacun a fait son travail. Que faire ?

Ne plus faire de gros projets ! Au lieu de mettre en production toute une connexion vendeur / fabricant, ne peut-on déployer flux par flux ? Les objets métiers nécessaires à ces flux seront développés de manièreincrémentale, et seulement ceux dont on a besoin pour le flux en cours. Par contre ils pourront être réutilisés pour les flux suivants.

Pour Pascal, changer d’architecture, de plateforme ou de langage implique les points suivants:

  • Faire un prototype pour maitriser le concept ou la technologie.
  • Commencer par les aspects les moins critiques.
  • Garder l’ancien composant.
  • Opérer un déploiement incrémental.

Vous l’aurez peut-être remarqué, cela rejoint certains points de la présentation de Cyrille Martraire (voir mes retours dans la 1ère partie).

Avec l’éclairage des options, Pacal nous soumet ce qu’il juge être les vertus d’une bonne architecture :

  • Elle doit nous permettre de prendre tôt les décisions faciles à changer.
  • Elle doit permettre de prendre tard les décisions difficile à changer. Ou encore : rendre les décisions difficiles à changer pour qu’elles deviennent faciles à changer !
  • Elle permet l’effort minimal, c’est le YAGNI d’extreme programming.
  • Elle créé des options pour l’équipe et/ou pour l’entreprise.
  • Elle se construit et s’améliore tous les jours, à petits pas. Sinon, on crée du legacy !

Il ne faut pas mésestimer la valeur des conditions contrariantes que l’on nous impose. Elles nous servent et nous apprennent souvent quelque chose.

Dans les mauvaises décisions se cachent de bonnes décisions.

Les techniques utiles

Une simple liste des techniques et principes abordées dans cette session :

Pascal avait déjà donné cette présentation lors de Devoxx France, fin Mars. Voici le support de présentation qu’il avait alors utilisé. Le contenu est identique à la présentation faite ici.

Lectures recommandées

Pierre Pezziardi – Agilité : do the wrong thing faster

Pierre Pezziardi n’est pas n’importe qui : co-fondateur d’Octo Technology, puis DSI de la BRED, puis actuellement start-uper, on peut dire qu’il a de l’envergure. C’est aussi un orateur de grande qualité, comme j’avais pu le constater lors d’une soirée organisée par l’institut agile : pertinent, incisif, riche d’enseignements. Je n’ai donc pas vraiment hésité à aller l’écouter.

agileFrance2013-06Pezziardi03

Sans aller jusqu’à m’avouer déçu, je dois dire que la session a été un peu en-deça de mes attentes. L’orateur a voulu cette session interactive, ce qui est en principe une bonne chose. Peut-être les interventions de la salle plus souvent conotées “coach / consultant” que “retour terrain” ont-elles participé à cette impression mitigée ? Honnêtement, j’ai un peu de mal à le dire.

Plutôt que de tenter retracer cette session (ce que je serais bien en peine de faire), je vais plus simplement livrer mon “take away” de cette session.

On peut faire de l’informatique et créer zéro valeur

Qui décide quel projet faire ?

A quel point les vrais utilisateurs sont impliqués ?

Le logiciel qui est produit va-t-il faire la différence chez les utilisateurs ? Hélas pas si souvent que ça…

L’unique mesure de la valeur, c’est le regard de l’usager

Des applications en pré-production que les utilisateurs détournent pour un usage en production. Des utilisateurs déclarant que l’application X a changé leur façon de travailler ou qu’elle leur permet de consacrer leur temps à des tâches plus valorisantes…

Des exemples venus de l’assistance ont permi d’illustrer ce point.

La pensée systémique est différente de la pensée analytique

Pierre a évoqué des grands projets publiques permettant des améliorations … pour une catégorie de population, hélas au prix de plus de souffrances pour d’autres population !

Apporter de la valeur ne doit pas se mesurer localement, il faut prendre en compte l’ensemble de l’écosystème concerné, donc avoir une approche systémique par opposition à l’approche purement analytique.

Etre acteur du changement

Sommes-nous trop petits, trop insignifiants pour pouvoir changer les choses. La réponse de Pierre est claire : Non ! Pierre est engagé dans une démarche entrepreunariale pour changer les choses, mais tout le monde n’est pas dans cette logique là. Et l’on peut tenter des choses, même petites pour les améliorer. Par exemple en collaborant avec des personnes au-delà des frontières organisationnelles. Je citerais Pierre concernant l’alternative:

Tu peux rester où tu es à te plaindre et à souffrir. Dans ce cas, bonne chance car t’as encore 30 ans à tirer !

Je ne rends pas justice à Pierre avec mes notes, car son intervention était bien plus intéressante qu’il n’y parait ici. Soyez certain que je retournerais l’écouter quand j’en aurais l’occasion !

A table !

On est toujours bien reçu à Agile France, et déjeuner autour d’une table avec un vrai repas et un service tranche avec les conférences auxquelles nous sommes habitués. Et puis, ça a de la gueule, jugez-en !

agileFrance2013-07LunchJeudi02

Bien sûr, ce moment de convivialité est l’occasion de nouer des contacts. N’esperez-pas que je vous en dise plus : ça va rester entre moi en mon LinkedIn !

agileFrance2013-07LunchJeudi01

Fin de la pause, retour aux affaires. Ca va parler coaching pour débuter l’après-midi

Jean-François Hélie : Votre nouveau défi, déployer l’agilité dans votre organisation

Votre organisation est-elle agile ?

A cette question on est souvent tenté de répondre “oui” (de toute façon, répondre “non” fait désordre). Souvent parce que l’on a déployé Scrum sur un, plusieurs, voir la totalité des projets. Généralement, ça marche un peu mieux qu’avant. Mais on est loin des améliorations radicales escomptées.

agileFrance2013-08Helie01

Voyons la démarche que Jean-François Hélie nous propose.

Opérer des rapprochements

Si on peut juger de seulement une “petite” amélioration, force est de constater que certains projets stratégiques marchent nettement mieux. Pourquoi ? Essentiellement parce que leur nature stratégique fait qu’ils ont moins de contraintes. Ils ont d’avantage le droit de franchir les frontières organisationnelles.

Tout cela est insuffisant, mais ces projets stratégiques nous donnent des indications :

  • Trop de cloisonnement interne DSI / Marketing / Métier
  • Pas de remise en cause fondamentale du processus projet
  • L’agilité reste cantonnée au niveau de la réalisation
  • Les projets sont mal cadrés et démarrent trop vite.

Sur ce dernier point, enfin tel qu’il est exprimé, je crains de ne pas être d’accord sur le fond. Je pense que Lean Startup a quelque chose à nous enseigner de ce côté. Sans doute devrais-je discuter avec Jean-François précisément là-dessus…

La difficulté fondamentale à faire tomber les cloisonnements a hélas une origine plus profonde.

Comprendre la culture

Comprendre les organisations, c’est comprendre leur culture. Celle-ci est étroitement liée aux niveaux de maturité :

  • De l’équipe
  • De l’organisation

Comme on aime bien les modèles, Jean-François nous propose celui de Richard Barett qui décrit 7 niveaux de conscience. Ce modèle étend en fait la célèbre pyramide de Maslow. La voici.

7levels

Pour Jean-François Hélie, l’agilité se situe au niveau 4, les niveaux au-dessus sont, disons, du bonus ! Pour arriver à ce niveau, 2 challenges :

  • La manager doit devenir facilitateur
  • L’ambition agile : comment se réaliser individuellement, en interaction avec les autres ?

Conjuguer le changement au présent

Jean-François n’a pas d’hésitation à ce propos : Le changement ne s’opère pas en planifiant ce qu’on pourra faire plus tard. Pas plus qu’il ne se construit en regardant ce que l’on a fait dans le passé. L’un sert à rêver, l’autre à se lamenter.

Seul compte l’instant présent, ce que l’on peut faire dans le contexte actuel.

Autre point important : le changement culturel s’amorce par le haut de la pyramide. En fait la dynamique des comités de direction reflète celle de la société.

  • Un comité de direction hésitant, qui ne sait dans quel direction aller donnera une société où les employés sont peu engagés et n’osent pas aller de l’avant.
  • Un comité de direction energique et focalisé engendrera une société dynamique avec des employés volontaires.

D’accord, c’est peut-être un peu caricatural, mais c’est l’idée.

Pour changer les projets, changeons les réunions

C’est le “take away” de cette session. Jean-François Hélie veut partager une de ses convictions avec nous et nous propose ses outils. A l’image de ce que l’on vient de dire pour les comités de direction, les réunions de projet sont le poul du projet.

A l’inverse, on peut agir sur un projet en agissant sur la dynamique des réunions ! Une idée un peu déconcertante pour moi, mais intéressante. En tout cas, je n’y avais jamais pensé. Voyons comment réunions et projets sont les reflets l’un de l’autre :

  • La participation en réunion : Elle reflète l’energie et la motivation sur le projet.
  • La gestion du temps en réunion : Elle caractérise la façon dont est appréhendé le respect des délais.
  • La relation à l’animateur : Elle est un indicateur du respect de la hiérarchie.
  • La gestion des l’espace de la salle de réunion : Elle donne des informations sur les stratégies territoriales des uns et des autres.
  • Le processus de communication au cours de la réunion : Elle est un miroir des circuits d’information (qui parle après qui, etc..)
  • Le désir de quitter la réunion ave un résultat : Il est significatif de ce que peut délivrer le projet.

Pour amorcer les changements en réunion, le premier pas est la prise de conscience à la fin de celle-ci :

  • Qu’est-ce qui a bien fonctionné ?
  • Qu’est-ce qu’on peut améliorer ?
  • Qu’est-ce que l’animateur a bien fait ?

Dans la plupart des réunions “classiques” l’animateur de la réunion :

  • Définit l’objectif de la réunion
  • Dirige la discussion
  • Recadre celle-ci
  • Et la plupart du temps monopolise 80% du temps de parole.

Cela n’est pas très constructif, et en réalité ce genre de réunion est surtout informatif. Les autres participants ne sont pas engagés et en fait participent peu. D’où la généralisation des ordinateurs portables en réunion.

Lorsque l’animateur gère la réunion en mode participatif, les différences sont :

  • L’animateur invite les participants à prendre la parole
  • L’animateur ne garde le temps de parole que 20% du temps.

Dans la version Intelligence Collective (le nirvana des réunions, en quelque sorte), les rôles deviennent distribués :

  • Un facilitateur qui invite à participer et délègue les rôles.
  • Un pousse-décision qui suit les actions arrêtées et incite les participants à conclure une discussion par une action.
  • Un gardien du temps.
  • Un “meta” qui observe la dynamique du groupe et la posture des participants
  • Un leader. C’est toujours un peu le même, celui qui a une autorité naturelle sur le groupe du fait de son charisme ou de sa connaissance du sujet.

Déployer l’agilité dans l’organisation

Jean-François Hélie voit deux approches possibles :

L’approche structurelle : Elle débouche sur de grands efforts pour de petits effets.

L’approche culturelle et systémique : Elle permet d’obtenir de grands effets avec de petits efforts. Pour en résumer les clés :

  • Ne pas chercher à changer la culture en elle-même.
  • Changer la culture dans les réunions
  • Créer et partager une vision
  • Faire participer les collaborateurs

Et c’est tout !

Lecture recommandée

Un seul ouvrage ici :

A suivre…

Nous avons bien avancé dans notre première journée, il nous reste 2 sessions pour la compléter. A très bientôt !

Rupture Douce saison 2 est sur les rayons

Alors je dois l’avouer, je n’ai même pas encore lu la saison 1 ! J’ai bien été relecteur de quelques histoires, mais je n’ai pas encore sorti le livre de son étagère où il prend tranquilement la poussière. Tellement à lire, si peu de temps…

rupture-douce02

Le volume de la saison 1 va bientôt avoir un compagnon de misère : j’ai commandé mon exemplaire de la saison 2, oui même en sachant qu’il risque de s’écouler un petit moment avant que je m’y plonge sérieusement.

Etes-vous comme moi ? Au final peu importe : nous allons y trouver les textes émanant d’intervenants réguliers de la communauté agile française. Nous n’avons pas toujours le temps ou l’opportunité de les voir en conférence. Et même alors nous regrettons de n’avoir au mieux que le support de présentation à notre disposition et pas la substantifique moelle ! Cessons de nous lamenter, rupture douce vient à la rescousse.

Vous pouvez :

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

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.

Note de lecture : Spring in Action 3rd édition, par Craig Walls

Note : 6 ; A la fois plus et moins complet que l’édition précédente.

Spring devient de plus en plus important … de plus en plus gros, même s’il se modularise. Je me demandais bien à quelle sauce on allait être mangé cette fois-ci ! L’édition précédente faisait 700 pages, celle-ci en fait … 380 ! En fait, non seulement cette édition se recentre sur les aspects essentiels du frameworks (certains thèmes ne sont donc plus traités), mais les aspects qui le sont toujours ont été revus et en fait la table des matière a changé de manière non anecdotique. Mon conseil : si vous avez la seconde édition, conservez-là !

Dans la première partie, les déclarations XML sont traitées plus légèrement à la faveur des annotations plus largement décrites, ainsi que du langage d’expression. De même la déclaration d’aspects est traité sur plus d’espace.

Ce qui était dans la précédente édition la seconde partie se retrouve désormais sur deux parties (la 2 et la 3). La plus importante différence réside sans doute dans le « client side Spring » qui a complètement disparu.

La première partie « Core Spring » regroupe 4 chapitre et compte 110 pages. Elle reprend les aspects qui ont fait le succès des éditions précédentes : une bonne introduction à ce qu’est Sprint (en y intégrant dès le début les annotation et les aspects) et un chapitre très solide sur le wiring qui inclut les namespaces de Spring et le langage d’expression SpEL. A cela s’ajoute un chapitre tout nouveau sur la prise en charge de l’injection de dépendances par annotations qui complète celui consacré aux aspects. Tout cela est très didactique et très bien épaulé par des exemples assez courts pour être parlants et de bons schémas.

La seconde partie « Spring Application Essentials » est longue de 140 pages en 5 chapitres. C’est le liens aux couches applicatives qui sont traitées ici. D’abord l’accès aux bases de données. Ce chapitre s’enrichit d’une partie consacrée à JPA, mais hélas les autres frameworks (à l’exception d’Hibernate) sont abandonnés ! Regrettable, spécialement pour iBatis / MyBatis. Une lacune que l’on va retrouver dans le chapitre suivant consacré aux transactions qui fait même l’impasse sur les transactions XA ! Les chapitres dédiés à Spring MVC et Spring Webflow sont repris de l’édition précédente et actualisés. Mais ne cherchez pas l’intégration avec JSP, JSF ou Struts : cela a complètement disparu. Il en va de même pour l’intégration EJB (bon, pour EJB2, j’aurais tendance à comprendre…). Enfin le chapitre consacré à la sécurité est toujours là, ni mieux ni moins bien que dans l’édition précédente.

La dernière partie est consacrée à l’intégration. Les exporters qui sont là depuis la version 1.0 peuvent passer pour de vieux trucs, mais ils sont bien pratiques et ils figurent toujours au menu de cette édition sans en réduire la voilure. Ouf ! Ne pas évoquer le support REST eut été une grosse lacune aujourd’hui : un chapitre complet lui est consacré. On retrouve aussi le support JMS, qui traite aussi de l’intégration ActiveMQ et Lingo. Le chapitre consacré à JMX est très court mais fait le boulot. Et finalement, le dernier chapitre regroupe l’intégration des trucs qui ne vont pas ailleurs. : l’externalisation de la configuration (cela aurait eu plus de sens dans la première partie), le wiring via JNDI, EJB (tiens si, finalement on en parle…), l’envoi d’emails et la planification de tâches. Sur ce dernier aspect on ne parle que du Scheduling natif Spring, mais pas de l’intégration Quartz qui est pourtant plus puissant ! Là encore, ne jetez pas votre édition précédente.

C’est vrai, Spring devient de plus en plus volumineux, mais il devient aussi modulaire car tout le monde n’a pas besoin de tout tout le temps. La ligne éditoriale du livre suit ce principe et un ouvrage de près de 700 pages qui aurait été en route pour en faire 900 se trouve réduit à en faire 380. La qualité de la rédaction est toujours là et les adaptations à Spring 3.0 sont réelles sans que cela soit pour autant des changements en profondeur à bien des égards. Le livre a été profondément restructuré au passage, et cela me paraît plus logique et mieux fait ainsi. Il faudra donc aussi compter désormais avec d’autres volumes pour compléter celui-ci : Spring batch in Action, Spring Integration in Action, etc…

Bref, ne vus dépêchez pas de jeter la seconde édition…

spring-inaction-3edt-manning

Référence complète : Spring in Action, 3rd édition – Craig Walls – Manning 2011 – ISBN : 978-1-935182-35-1

Spring in Action

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

97 Things Every Programmer Should Know

J’avais fait la note de lecture de cet ouvrage il y a un bon moment. Grace à la licence “creative commons”, vous pouvez librement bénéficier de son contenu.

Un Wiki a aussi été créé, justement dans le but de permettre les contributions collectives autour de cet ouvrage.

Kevlin Henney, qui a été le rédacteur en chef de ce volume s’est appuyé sur son contenu pour une Keynote. En voici le support