Ne joignez pas les brûleurs de livres. Ne pensez pas que vous allez cacher des défauts en cachant l’évidence qu’ils n’ont jamais existé. N’ayez pas peur pour entrer dans votre bibliothèque pour lire chaque livre …

Dwight Eisenhower

Publicités

Note de lecture : Storage Virtualization, par Tom Clark

Note : 6 ; Vue aérienne de la virtualisation du stockage

Tom Clarke est un des gourous du SAN, il a déjà plusieurs livres sur le sujet à son actif. Celui-ci est le plus récent, ce qui tombe bien car le sujet évolue à toute vitesse ! Ce livre a une vocation introductive sur le sujet, ce qui tombe bien en ce qui me concerne. La taille tout à fait raisonnable de l’ouvrage (175 pages hors annexes) appuie encore ce point. J’ai d’autant apprécié que le texte soit découpé en 14 chapitres, chacun taillant de 10 à 15 pages. Chaque chapitre aborde un thème particulier de ce sujet, je n’aurais pas imaginé qu’il y en autant ! Malgré cela il reste conseillé de lire ces chapitres dans l’ordre, car ils suivent une progression logique.

Les 3 premiers chapitres posent les bases : fichiers, enregistrements, données et structures RAID. En fait, bien que l’auteur pose clairement les différents concepts, il y a peu de nouveautés.

Cela change avec les chapitres 4 à 8 qui détaillent les principes de la virtualisation : au niveau des serveurs source, au niveau des baies de disque ou au niveau du réseau. Ce milieu de livre constitue véritablement la clé de l’ouvrage et présente les concepts importants. La virtualisation au niveau du réseau étant pour moi la véritable découverte.

La fin du livre présente les différentes facettes « externes » de la virtualisation : périphériques, services ou archivage. Ils complètent utilement la description du paysage.

Un aspect important du livre est la taille et la qualité des annexes. Au sein de celles-ci on notera l’annexe C qui collecte les observations d’intervenants impliqués dans ce domaine.

J’ai apprécié ce livre, suffisamment haut niveau pour un nouveau venu comme moi. Je reste malgré tout un peu frustré par le manque de concret de ce livre introductif. Il est bien difficile d’imaginer une architecture sur la base de l’information distillée ici. Il faudra pour cela se rabattre sur le best seller de Tom Clarke, mais celui-ci date quand même de 7 ans…

storage-virtualization

Référence complète : Storage Virtualization, technologies for simplifying data storage and management – Tom Clark – Addison Wesley 2005 – ISBN : 0-321-26251-4 ; EAN : 9 780321 262516

Storage Virtualization: Technologies for Simplifying Data Storage and Management


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

« Rupture Douce » est sur les rayonnages !

J’avais évoqué l’arrivée de “Rupture Douce” en août sur Leanpub. C’est finalement sur Lulu que l’ouvrage est rendu disponible : deux éditions papier et une édition eBook (PDF). Des versions ePub et mobi (cette dernière pour le Kindle) sont à venir.

J’ai eu le plaisir de faire la relecture finale de quelques une des histoires comprises dans ce volume. Les éléments se sont un peu ligués contre moi pour que je puisse offrir une aide plus importante.

Une partie des royalties du livre sera versée à “La Courte Echelle Collège”, un projet qui vise à sensibiliser les filles de 3ème aux carrières techniques (dont l’informatique) avant qu’elles aient fait leurs choix d’orientation en les mettant au contact de marraines qui seront des “role model”, femmes ayant réussi dans des métiers traditionnellement plutôt masculins.

Pour ma part, ce sera une version papier, car je compte bien me faire dédicacer l’ouvrage par le “chief editor” et peut-être même par certains contributeurs…

rupture-douce

« Rupture Douce » est sur les rayonnages !

Note de lecture : Continuous Integration, par Paul M. Duvall

Note : 3 ; Trop creux !

J’attends incontestablement de la « signature series » d’Addison Wesley qu’elle ne comprenne que des ouvrages de référence. Ce n’est pas le cas ici. Certes, le livre effectue un bon travail pour introduire et convaincre les nouveaux venus des vertus de l’intégration continue, en édictant les principes de base (que j’estime pour ma part connus) et en hésitant pas à les répéter (ce qui est parfois nécessaire).

Cet aspect introductif est en fait l’objet de la première partie, longue de 100 pages. Bien qu’à mon avis la cible de ce type d’ouvrage ne soit pas d’introduire le sujet, mais une expertise sur la mise en pratique, je n’ai rien contre une petite introduction. Mais 20 pages auraient suffi, surtout si l’on considère la teneur. En fait, on y trouve un peu trop de propos de haut niveau, qui me rappellent certains des moins bons volumes de « l’Object Technology series » du même éditeur. Bref, j’arrive à la fin de cette partie, non seulement sans avoir rien appris, mais avec l’impression que j’en sais plus que les auteurs.

La seconde partie est dédiée au traitement en profondeur de l’intégration continue. Le découpage en chapitres est plutôt pertinent : intégration continue des bases de données, tests, inspection, déploiement et feedback. Hélas le traitement des différentes parties manque carrément de profondeur. Les auteurs abordent bien le « ce qu’il faut faire » mais assez peu le « comment faire », hormis quelques exemples de scriptes Ant. À noter, en passant, que la quasi-totalité de l’ouvrage est basée sur le postulat de l’utilisation de Ant et Cruise Control (et de leur équivalent .NET), je suis donc frustré (avec bien d’autres, certainement), moi qui utilise Maven et Hudson (ce dernier outil n’est même pas évoqué dans la liste des outils en annexe, peut-être parce qu’il aspire trop d’utilisateurs de Cruise Control ?).

Bref, on est non seulement déçu par l’absence de recettes concrètes, mais aussi par l’étroitesse des typologies de projets abordés. Je suis déçu également par le discours : n’y a-t-il donc qu’une seule façon d’appréhender l’intégration continue ? Les auteurs posent pourtant de nombreuses questions pertinentes qui sont autant d’obstacles à la mise en œuvre de l’IC, mais leur seule façon d’y répondre est l’objection.  L’expérience nous montre pourtant que l’IC est quelque chose de facile à casser, jamais ce point n’est abordé. Les vraies questions sur la complexité de mise en œuvre de l’IC ne sont jamais évoquées : Commit en deux temps pour les IC cassant trop souvent, cadre technologiques ancien ou hétérogène, équipes nombreuse, build long ou tests volumineux.

Les auteurs se réfèrent souvent à deux textes : le livre de Brad Appleton sur les patterns de gestion de configuration et l’article de Martin Fowler sur l’IC. J’aurais aimé que ce texte ait la profondeur et la pertinence du « Patterns on Configuration Management ». Pour ce qui est de se référer à l’article de Martin Fowler, j’attends simplement mieux d’un livre de 220 pages que de se comparer à un article qui en compte une dizaine.

Donc, grosse déception. Passez votre chemin.

continuous-integration

Référence complète : Continuous Integration, Improving software quality and reducing risk – Paul M. Duvall, with Steve Matyas & Andrew Glover – Addison Wesley / Signature series 2007 – ISBN : 0-321-336338-0 ; EAN : 978 0 321 33638 5

Continuous Integration: Improving Software Quality and Reducing Risk


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

Retours sur l’agile tour Bruxelles 2012

Je m’étais fixé dans mes objectifs sur ce second semestre, de me joindre à la communauté agile Belge à l’occasion de l’agile tour Bruxelles. je n’ai pas hésité longtemps à répondre à l’appel à orateurs de Bruno Sbille. Plusieurs raisons à cela:

  • L’opportunité de faire une présentation en Anglais. Il faut bien garder la forme !
  • L’occasion de rendre la politesse à Bruno qui nous avait fait le plaisir de venir faire une présentation dur la Programmation Neuro Linguistique lors d’une soirée du Scrum User Group.

J’espérais donc bien être retenu. Je l’ai été : merci au comité d’organisation !

L’aller-retour dans la journée, ça fait une grosse journée, mais ça valait le coup.

Pascal Van Cauwenberghe : 11 steps to perfect code

Pascal s’est présenté comme un “recovery bug writter”. Il nous a présenté son processus destiné à éliminer les bugs. Il compte 11 étapes, pas moins.

La qualité dépend-t-elle des testeurs ? La réponse est non. En fait, elle est souvent inversement proportionnel au nombre de testeurs. Cela peut paraitre provocateur, voir choquant. mais réflechissez à l’impact psychologique sur les développeurs d’‘une très importante équipe de testeurs.

1 – Mettre en évidence le bug. Jusqu’ici tout va bien.

2 – Votre réaction : et meeeerde ! Non, justement. Il faut remercier le rapporteur. Pascal nous fera faire l’exercice plusieurs fois durant cette heure: remercier à haute voix: Thank you !

3 – Reproduire le problème. Identifier les conditions sous lesquelles ce bug se manifeste est une simple question de bon sens.

4 – Ajouter (au moins) un test qui échouera suivant ces conditions.

5 – Corriger le problème. Vous suivez toujours ?

Bon ça y est, on a fini. Comment ça “non” ?

6 – Rejouer la totalité des tests unitaires. La correction d’un bug peut introduire une régression. Nous le savons tous. Mais prenons-nous tous la peine de rejouer la totalité des tests ? Bien sûr le but n’est simplement de les rejouer, mais de les rejouer jusqu’à ce qu’ils passent tous !

7 – Faire une analyse causale : pourquoi ce bug n’a pas été intercepté précédemment ? Il faut toujours faire attention aux objectifs que l’on fixe : on risque de les atteindre. Si le but est la couverture du code, est-on certain qu’elle est synonyme de tests associés ? Le véritable objectif n’est pas la couverture du code, mais la qualité de celui-ci.

8 – Améliorer les tests.

Là, ça devrait être terminé. Non, toujours pas ?

9 – Améliorer la façon dont les tests sont écrits. Mais ceci est autre chose, n’est-ce pas plutôt un point qui devrait être remonté en rétrospective ? La rétrospective ce n’est pas pour la fin de sprint. La démo ce devrait être tout le temps.

10 – “Un bug ne voyage jamais seul” : à la recherche des bugs similaires !

11 – Faites que ce bug soit impossible à reproduire !

Traquer les bugs ainsi peut sembler coûteux. En fait, ça l’est au début. Pascal s’appuie sur la théorie des contraintes pour expliquer que cette approche permet finalement de livrer plus vite ! En l’occurrence sur un projet, au bout de 5 mois au lieu de 8 !

Jan De Baere : Kaban at different levels

Jan a choisi de nous présenter Kanban tel qu’il est utilisé réellement dans les projets auxquels il a participé, avec les leçons qui ont accompagné sa mise en oeuvre.

La règle de conduite que nous propose Jan repose sur 3 axes:

  • Visualiser le workflow.
  • Limiter le “work in progress”, en s’appuyant sur l’expérimentation.
  • Mesurer et gérer le workflow.

L’exemple d’une circulation sur une autoroute illustre assez bien ces 3 points, même si les paramètres conduisant à la formation des bouchons sortent des fondements théoriques de Kanban (eh oui, il n’y a pas que la théorie des contraintes…).

Cette session avait pour but de nous exposer cette mise en oeuvre dans différents contextes:

  • Un projet classique.
  • Un projet distribué
  • Le Kanban au niveau individuel
  • la gestion d’un portefeuille de projets.

Plutôt que d’asséner les différents éléments de la présentation je préfère mettre en avant les éléments principaux:

  • Les “expedites”: lorsqu’ils sont trop nombreux, il ya un problème à régler !
  • Mettre en évidence les éléments qui sont attendus. Là encore, ils peuvent stigmatiser des problèmes à régler au niveau organisationnel.
  • Les “buffers”: ils peuvent apparaitre utiles dans le workflow, mais sont à utiliser avec parcimonie. Ce sont des sources de gâchis, au sens Lean.
  • Il y a un lien direct entre le “work in progress” et le “lead time”. Ils croissent de concert.

L’un des grands moments fut certainement la présentation du “kanban portable” (et pliable) réalisé par Jan !

atbru2012-JanDeBaere

Pour ma part, je garderais dans mes notes l’usage du “personnal kanban” avec ses limites de WIP adaptatives:

  • Les tâches “high energy” : la limite de WIP est de … 1 ! Ce sont les tâches qui demandent un haut niveau de concentration.
  • Les tâches “medium”, c’est le travail ordinaire. La limite de WIP est de 2.
  • Les autres tâches, celles qui ne nous donnent pas vraiment de faire un travail correspondant à notre niveau de qualification. Il n’y a pas de limites de WIP pour celles-ci.

Ce peut être du bon sens, mais c’est sans aucun doute un point à garder !

Alan Holtz : Lessons learned from the Scrum Master

J’espère qu’Alan me pardeonnera de ne pas avoir pris de note lors de sa session. J’étais en fait en train de faire l’ultime préparation de la mienne ! Si une photo vaux mieux que de grands discours, en voici donc une !

atbru2012-SMLessonsLearned

Yves Hanoulles : How 146 people made 13 projects

Yves a acquis une grande notoriété dans la communauté agile, par son implication dans de nombreux projets. J’avoue que j’avais du mal à comprendre comment il pouvait mener à bien cette activité débordante. Cette session répond à ces questions.

atbru2012-YvesHanoulles

Comment nait un projet ?

Yves débute simplement un projet par un problème qu’il rencontre et sur lequel il ne trouve pas sur le net de ressources pouvant l’aider.

Comment construire une communauté de contributeur ?

Simplement en demandant autour de lui, mais en s’adressant de manière directe aux intéressés, s’ils peuvent et souhaitent l’aider sur son projet. C’est une question franche et directe qui n’appelle pas obligatoirement de réponse positive : on peut ne pas avoir le temps, ne pas être intéressé par ce projet, etc… Yves accueille de manière factuelle et simple cette réponse.

A partir de là, Yves accorde une complète confiance aux collaborateurs dès le départ, avec complet accès en lecture et écriture aux ressources du projet : la confiance n’est devrait pas être “gagnée”, mais donnée !

Surtout Yves nous rappelle qu’il faut toujours penser à remercier une personne qui se propose de contribuer.

Collaboration et outillage

Tous ces projets se déroulent sans aucune rencontre face à face : tout est mené et coordonné à distance, l’outillage permettant cela est donc important. Les principaux que j’ai noté :

  • Skype
  • email: Oui, bien qu’Yves soit un fervent défenseur de la limitation de l’usage de l’email en entreprise, il reste un média essentiel pour ces projets collaboratifs.
  • Google doc.

Si les projets agiles défendent la co-location, Yves nous rappelle que selon Jim McCarthy, celle-ci n’est pas une nécessité : ce qui est nécessaire, c’est une communication avec une large bande passante.

Who is agile ?

Yves a terminé sa session sur quelques reflexions sur la rédaction d’un livre en mode agile, tel que “who is agile ?” a été rédigé.

  • La rédaction d’un livre en mode agile est possible, intégrant des itérations et du feedback. C’est non seulement possible et même souhaitable. Une plateforme comme Leanpub est un grand facilitateur en ce sens.
  • La lecture d’un livre réalisé en mode agile est pr contre moins sympathique.

Jeff Cumps : How to solve your thoughthests impediments

Jeff nous invitait à une session-atelier sur le A3 problem solving. Un réel challenge d’ailleurs car il ne disposait que d’une heure pour nous exposer les principes et nous permettre de les mettre en oeuvre sur une problématique de notre choix.

Je ne vais pas détailler l’atelier ici. Le timing était un peu serré, mais nous avons pu avoir la satisfaction de bien avancer sur nos exemples. Disons que 1h30 aurait probablement été un créneau plus confortable. Mais peut-être pas plus, non plus !

En fait le point positif du temps limité était d’aller droit à l’essentiel sur l’exercice pour en comprendre les points principaux. Ce que Jeff a fait avec clarté. Une très bonne session pour conclure cette journée !

Ambiance, boissons et rencontres

Chaque conférence agile est l’occasion de croiser ou recroiser des passionnés. L’évènement a été ciblé petit par les organisateurs : 70 personnes, donc volontairement peu de buzz autour de ce premier Agile Tour Bruxelles. Un grand “up” pour les organisateurs à propos de la convivialité et de l’ambiance sur cet Agile Tour Belge. Ca donne vraiment l’envie d’y revenir.

Couleur locale oblige, nous avons conclu la journée autour d’une bière.

Un geste sympathique pour les orateurs : un assortiment très couleur locale une fois encore. Que je vous laisse découvrir.

atbru2012-orateursgifts

Note de lecture : A Requirements Pattern, par Patricia L. Ferdinandi

Note: 2 ; Creux et peu concret!

Tout avait pourtant bien commencé: le titre de l’ouvrage regroupant “pattern” et “requirements”, je ne pouvais l’éviter. Las, l’auteur remplis visiblement son ouvrage en se répétant une multitude de fois, au point que je pense qu’il n’y a de quoi remplir qu’un article. De quoi s’agit-il en fait ? Patricia Fernandini nous expose comment organiser les exigences en une matrice, version élargie du framework de Zachman, selon 3 dimensions représentant: 1) les perspectives, en fait les étapes de raffinement des exigences 2) le focus (qui, quoi, où, pourquoi et comment, plus les contraintes produit et projet) 3) les communautés (IT, business, etc..). L’originalité et l’intérêt de l’approche (celle qui justifie que la note n’est pas zéro) est que l’auteur ne s’arrête pas aux exigences logicielles, mais élargit celles-ci de façon intégré à tous les domaines de l’entreprise qui peuvent être concernés par l’idée ou besoin initial qui est investigué. Malheureusement, en essayant de rendre abstrait cette approche, c’est à dire non dépendante d’une méthodologie de capture des exigences particulière, l’auteur rend intangible la concrétisation de son approche, les exemples donnés en annexe ne nous éclairant guère car il ne s’agit juste que de résumés de retour d’expérience. L’aspect “pattern” est visiblement mal compris de l’auteur qui s’emmêle entre les notions de patterns, méta-patterns, anti-patterns et framework, embrouillant le lecteur au passage. Des patterns d’exigence pour l’internet: il y avait sans problème de quoi faire, mais c’est raté!

requirements-patterns

Référence complète : A Requirements Pattern, Succeeding in the Internet economy – Patricia L. Ferdinandi – Addison Wesley / I.T. series 2002 – ISBN: 0-201-73826-0

A Requirements Pattern


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