Note de lecture : XForms, par T.V. Raman

Le par addinquydans Notes de lectureLaisser un commentaire

Note: 5 ; Un tutorial dont l’intérêt principal est d’un abord plus pratique que le texte de la norme, mais qui échoue à prendre de la distance par rapport à celle-ci.

Ce texte est sans aucun doute plus didactif, plus lisible et plus introductif que la norme XForms elle-même. La structure XForms, ses différents éléments et son fonctionnement sont clairement expliqués, l’auteur fournit au passage les liens sur les différents textes normatifs sur lesquels XForms s’appuie. Etant un des rédacteurs de la norme, l’auteur nous donne également les raisons qui ont amener les rédacteurs à penser la norme telle qu’elle est actuellement. Je pense que cet aspect est une aide, notamment pour permettre aux utilisateurs de réaliser des formulaires de bonne qualité. Deux fondements sont entre autre bien expliqués, quoi que pauvrement illustrés : la modélisation par l’intention (afin de construire des formulaires multimodaux) et le support de l’accessibilité, c’est à dire l’accès au personnes handicapés (un aspect auquel l’auteur est sensible, étant lui-même aveugle). Ce dernier point a certainement justifié un chapitre spécifiquement dédié à l’accessibilité, d’ailleurs plutôt bien fait.

L’ouvrage en lui-même compte 220 pages, découpés en 11 chapitres, eux-mêmes regroupés en 3 grandes parties (welcome, components et next generation web). La plus importante aussi bien en taille qu’en contenu étant la seconde.

J’ai plutôt apprécié ce livre, car il m’a fait comprendre XForms, et me permet de construire des formulaires testables avec X-Smiles. C’est un bon tutorial permettant de se jeter dans le bain. Toutefois je pense qu’il lui manque une valeur ajoutée en terme de patterns de conception : modélisation orientée présentation des fragments XML (j’ai des doutes sur l’utilisation telle quelle d’une modélisation métier, au moins dans tous les cas), utilisation des binders, utilisation des instances pour servir de tables de références, chargement des « instances de références » dynamiquement, etc… Bref, j’ai tendance à penser que ce livre colle trop à la norme et n’apporte pas assez d’originalité par lui-même, même si le texte est clair et les exemples suffisamment simples pour être facilement compréhensibles.

Au titre des regrets, je note également que le livre manque un peu d’illustrations (les écrans ne sont présentés que sous forme de fragments, des schémas descriptifs auraient souvent été utiles, surtout pour expliquer les aspects dynamiques), et malheureusement, la troisième partie, celle qui devrait nous faire rêver, sur les aspects futur de la norme et de l’utilisation de la norme, est ratée. Je n’ai pas perdu mon temps en lisant ce livre, loin de là, mais j’aurais bien attendu des livres plus murs, en espérant que la norme ait du succès… Nous savons aujourd’hui que ce ne sera pas le cas.

xforms-powered-web-forms

Référence complète : XForms, XML Powered Web Forms – T.V. Raman – Addison Wesley 2004 – ISBN: 0-321-15499-1

Xforms: XML Powered Web Forms

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

Scaling Lean & Agile Development, par Craig Larman

Le par addinquydans PresentationLaisser un commentaire

Cette présentation de Craig Larman illustre le propos qu’il a développé dans son livre éponyme. C’est une bonne illustration de certaines pratiques qui y sont exposées au sein d’un projet mené en offshore en Inde.

Stoos Connect (4/4)

Le par addinquydans Compte-renduLaisser un commentaire

Voici enfin le dernier opus du Stoos Connect 2013. Je vous rappelle que vous pouvez trouver mes posts concernant cet évènement ici:

Session 4

Il y avait 5 interventions sur cette dernière session, mais pour des questions d’horaire nous n’avons pu assister qu’à 3 d’entre-elles.

Jurgen Appelo : Merit Money, compensation based on common sense

Jurgen commence fort en relativisant un peu les interventions un peu stratosphériques de haut niveau traitant du “paradigme shift” pour revenir aux questions d’argent : comment évaluer la rémunération, les augmentations et les bonus ?

Le modèle du bonus de fin d’année ne fonctionne pas, car il génère plus de frustration que de maturation. Il en est de même du modèle de rémunération “égalitaire” sans bonus, dans lequel les employés s’estiment injustement payés.

Jurgen Appelo nous propose un modèle d’évaluation et de rémunération basé sur:

  • L’évaluation de pair entre employés.
  • L’usage d’une monnaie virtuelle (l’orateur les appelle ici des “câlins”). Ils sont le moyen par lequel les appréciations mutuelles sont échangées.
  • Un compte d’épargne-bonus qui est utilisé en cours d’année à des moments non prévus à l’avance. A ce moment, on peut échanger des “câlins” contre du bonus.

Le système de rémunération présenté ici est basé sur le mérite. Il me semble osé à mettre en place et les risques de détournements par ailleurs évoqués dans la présentation me semblent réels. Pas sûr que j’oserais m’y aventurer… En fait, Jurgen évoque bien ce point.

On ne peut probablement pas mettre cela en place du jour au lendemain. Mais on peut commencer, et certes il existe des risques liés à cela.

Steve Denning : Toward the tipping point in leadership & management

L’intervention de Steve Denning était sans aucun doute l’une des plus attendues. C’est certainement pour cela qu’elle fut une des dernières. Hélas, ce ne fut pas la meilleure, et de loin !

Cette intervention s’inscrit dans la série des “speech motivationnels” où il est question de “tipping point”, mais hélas pas tellement d’actions concrètes. Bref, une déception.

Joe Justice : Agile Human Resources

Joe Justice est le Team Lead de Wikispeed. Basé sur le volontariat, Wikispeed a pour but de changer de manière radicale l’industrie automobile en produisant à faible coût des véhicules “verts”.

Wikispeed fonctionne entièrement en mode agile, en utilisant Scrum.

A chaque sprint, l’entreprise organise une rétrospective à l’échelle de la totalité de l’entreprise, regroupant plus de 100 personnes.

Au niveau du fonctionnement interne, les principes du “radical management” de Steve Denning sont appliqués. Product Owner et Scrum Master sont des rôles et non des titres.

La présentation était un peu menée tambour battant et je crains de ne pas avoir retenu toute la substance que j’aurais dû. Dommage…

Autres ressources

Voilà pour mon tour d’Horizon de cette première conférence Stoos Connect. Vous trouverez d’autres articles de blog en Français, entre autre :

Note de lecture : Pattern Languages of Program Design vol. 3 – Robert Martin, Dirk Rhiele & Frank Buschmann edt.

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 8 ; Une compilation de patterns de très bonne qualité.

Ce troisième volume de la série PLOP-D a complètement redynamisé la série ! Alors que je reprochais aux volumes précédents la portion de matériel utile, il n’y a rien de tel ici : la substance utilisable directement dans nos projets y est importante. J’ai trouvé la sélection clairement orientée vers les patterns de conception, ce qui n’est pas pour me déplaire. Cependant, même les patterns organisationnels peuvent s’avérer utiles ou inspirants, tel que le “Patterns for pattern writters”. Malgré cette orientation, le volume est quand même découpé en plusieurs parties, en fait plus de parties même que les opus précédents, car on en compte 10 ici, mais elles sont aussi plus finement ciblées. Il était aussi question d’opérer un découpage valable pour un livre qui compte maintenant 575 pages.

La première partie traite des patterns à usage généraux. Cette première partie n’est certainement pas à ignorer. On y trouve le très utile « null object », l’excellent « extension object » qui est une des très rares contributions d’Erich Gamma. Le « manager » de Peter Sommerlad a plutôt une coloration historique, car c’est le pattern universellement utilisé aujourd’hui pour les DAO.

La seconde partie couvre des variations sur les patterns. Elle va d’avantage intéresser le praticien expérimenté. Les trois sont intéressants, les variations sur le state pattern peuvent être utilisées presque tel quel dans une formation.

J’ai trouvé les deux patterns architecturaux qui forment la troisième partie du même nom assez peu convainquants. Tant pis.

La quatrième partie est consacrée aux patterns liés aux architectures distribuées. Les 5 patterns qui la constituent sont plutôt musclés. Ma préférence va au très élégant « asynchronous completion token ». L’ « acceptor connector » vaut certainement le détour, mais il est quelque peu complexe et la présentation à l’aide diagramme en notation Booch n’aide pas.

Ce sont deux patterns qui constituent la cinquième partie consacrée à la persistance. Le « serializer » a surtout un intérêt documentaire, tandis que « accessing relational database » bien que bien construit n’offre plus qu’un intérêt mitigé aujourd’hui.

On ne trouve qu’un seul pattern dans la sixième partie qui cible les interfaces utilisateur. Il s’agit plutôt d’un pattern language d’ailleurs, mais je lui ai trouvé peu d’intérêt.

La septième partie traite de patterns de programmation et il ne faut pas la rater, même si elle ne contient que deux de ces patterns (presque des idiomes). Le premier d’entre eux est le désormais célèbre « double-check locking », tandis que l’« external polymorphism » qui s’apparente beaucoup au décorateur n’est pas dénué d’intérêt.

Je n’ai jamais vraiment été soulevé d’enthousiasme par les « business patterns ». Peu d’entre-eux trouvent grâce à mes yeux. Cette huitième partie en contient 3 et j’avoue qu’ils ne m’ont pas marqué.

On n’échappe pas facilement aux « process patterns ». Nous en avons 4 dans cette neuvième partie. Le « pattern for evolving frameworks » est un pattern language qui met bien en exergue les aspects fondamentaux de la conception d’un framework. Le « pattern for designing in teams » contient les frémissements de l’avènement d’XP. Le « pattern for system testing » est le plus intéressant du lot, à mon avis. Là encore un pattern language qui mérite la lecture.

Si vous vous sentez l’âme d’un auteur, le « pattern language for patterns writing » sera votre amis. Il est le seul membre de cette dixième partie consacrée aux « patterns on patterns ». Ecrire un pattern, le soumettre (et être accepté) en conférence n’est pas si simple, j’en ai l’expérience. Rétrospectivement, je trouve qu’il s’agit-là d’un bon guide.

On ne peut espérer un score de 100% de matière utile à une compilation de patterns issus d’une conférence. Cela dit la sélection est vraiment très bonne, c’est un très bon livre, je ne l’ai pas lu en pensant « vivement que cela finisse » que cela a été parfois le cas avant. Je garde précieusement ce volume et le recommande.

PLOPD-vol3

Référence complète : Pattern Languages of Program Design, vol. 3 – Robert Martin, Dirk Rhiele, Frank Buschmann edt. – Addison Wesley / Software Patterns series 1998 – ISBN: 0-201-31011-2

Pattern Languages of Program Design 3

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

Stoos Connect 2013 (3/4)

Le par addinquydans Compte-renduLaisser un commentaire

Session 3

Je vous avais quitté à la pause diner, à la fin de la session 2. Il est temps de reprendre le collier. Un petit rappel des épisodes précédents:

Voici la suite du programme.

Olav Maassen : Managing Change, Leading the status quo

Comment fonctionne une tribu ? Les tribu aborigène australienne n’ont pas de leaders ! Elles ont bien des “anciens” qui possèdent une expérience, mais ils n’en sont pas les leaders pour autant. La tribu a toutefois un objectif partagé: leur survie.

Olav Maasen rêve d’organisations sans leaders, ou plutôt d’organisations où chacun est un leader en puissance. Mais qu’est-ce qu’un leader ? Le leader est le gardien du futur, tandis que le manager est le gardien du processus. Mais il croit aussi en la nécessité d’avoir des managers. Un manager qui aura sein de son groupe différentes personnes capable d’être leader sur différents aspects de l’activité. Le rôle du manager est alors de s’assurer que la bonne personne (le bon leader) mène l’équipe au moment adéquat.

Autre perspective, celle du changement. Le manager est l’agent du changement … tandis que le leader est l’agent du status quo. Le rôle du leader est d’entrainer l’équipe et de la faire progresser.

Lisa Earle McLeod : Selling with noble purpose : why we thought we knew about sales is wrong

Lisa Earle McLeod nous parle d’un sujet qui est également le sujet de son livre : peut-on concilier “noble” et “vente”. Nos postulats à ce sujets sont faux. Pour comprendre cela, Mme McLeod a passé 6 ans à analyser ce qui fait la différence entre les “top performers” et disons, le gros de la troupe des commerciaux. La différence se fait dans l’état d’esprit. Alors que la plupart des commerciaux sont focalisés sur le revenu, les top performers sont axés sur la finalité du produit, ils veulent faire une différence pour leurs clients ! Hélas, il y a un fossé entre les motivations de ces excellents commerciaux et les sociétés qui les emploient, car elles focalisent uniquement leurs forces commerciales sur les chiffres et non sur les motivations qui leur permettraient réellement de se dépasser ! La façon dont nous parlons de nos clients transparait dans la façon dont nous les considérons quand nous leur faisons face. L’état d’esprit doit être sincère : si nous traitons nos clients comme de simples nombres, ils nous retourneront la faveur ce qui conduira à une “synergie de la médiocrité”. Les métriques quantitatives ne touchent pas les personnes. Elles ne font pas la différence. Lisa Earl McLeod conclut de manière assez surprenante : la force commerciale d’une entreprise est le meilleur point de départ pour entamer le changement de cette entreprise, lui insuffler le sens du but. 

J’ai bien aimé cette intervention à la fois pleine de fraicheur et d’énergie et qui porte un regard neuf sur le volet commercial des entreprises.

Dawna Jones : 3 mistakes companies make when managing their business cultures

En tant que facilitatrice professionnelle, Dawna Jones a noté un modèle récurrent de changement des entreprises. Nombre de celles qui s’engagent dans un changement font, à un moment donné, marche arrière, mais pour revenir à un point différent de celui de départ.

Erreur n°1 : Echouer dans la gestion de la culture d’entreprise

L’entreprise se focalise le plus souvent sur l’aspect comportemental. Mais les modèles comportementaux impactent directement ce que penseront les employés de l’entreprise, plus que ne le feront les déclarations d’intention.

Erreur n°2 : Essayer de changer les comportements

On ne peut pas “contrôler” les personnes, leur imposer qu’elles changent. Le mode “contrôle” doit faire place au mode “support”.

Erreur n°3 : Sous-estimer la puissance de l’esprit humain

Là je décroche un peu, car Dana nous parle de compagnies ayant une conscience écologique, à l’image de Novo Nordisk…

Merci au passage à Dana pour le néologisme “TweetAway” qui est une contraction de “Tweet” and “Take away” !

Frank Röôsli : From exploitation of resources to unfolding human potential

Franz Röösli est un des instigateurs du mouvement Stoos, il nous livre ici sa vision personnelle du devenir de ce mouvement.

Le manifeste Stoos parle de “réseau apprenant d’individus”. Pour Röösli, l’idée de former une communauté tout en agissant en tant qu’individus est importante. Il s’en réfère pour cela à notre ascendance Homo Sapiens Sapiens.

Le modèle actuel des entreprises est basé sur la maximisation des profits. Il utilise pour cela la structure hiérarchique centralisée héritée du modèle de Taylor et des processus de control / commande permettant le contrôle budgétaire ainsi que le préconise McKinsey. Mais selon Drucker, ce modèle est un mythe, car le but d’une entreprise se trouve au-delà d’elle-même en tant que partie d’un ensemble, dans sa contribution pour la société.

Passer de ce modèle au modèle “Stoosien” signifie abandonner la structure hiérarchique pour un modèle en réseau décentralisé et quitter le fonctionnement en contrôle / commande pour adopter un processus adaptatif.

Cette intervention dans le style “speech motivationnel” ne m’a guère convaincue. Les grandes lignes ne sont pas une surprise mais les actions sous-jacentes sont floues pour autant qu’elles soient identifiées…

Bjarte Bakke : The four most important things in life

Créer de la valeur pour les actionnaires doit-elle être la raison d’être des entreprises ? Ne devraient-elles pas désservir un but plus grand ? Les choses les plus importantes ? Pour Bjarte, elles sont au nombre de 4.

  1. La santé : Elle nous donne la capacité de mener à bien ce que nous voulons faire.
  2. Les relations : C’est l’élément qui nous donne les plus fortes émotions positive, amis, famille, etc…
  3. Valeur et rêves : Ils nous projettent dans la vie que nous avons envie de vivre.
  4. Une appréciation positive de soi-même : Cela nous permet de nous accepter pour ce que nous sommes et de prendre nos propres décisions.

Ne pas focaliser l’entreprise sur la valeur pour les actionnaire, c’est créer une entreprise qui donne de la valeur également pour ses employés et ses clients, comprendre ce qui importe le plus pour eux et garder à l’esprit les 4 valeurs fondamentales.

Voilà pour aujourd’hui. A très bientôt pour la dernière ligne droite !

Note de lecture : Agile Analytics, par Ken Collier

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; L’agilité expliquée aux praticiens du décisionnel

Lorsque j’ai acquis ce livre, j’escompté en savoir plus sur l’adaptation et les spécificités de la mise en œuvre de l’agilité dans le monde du BI. Beaucoup de choses y sont différentes par rapport aux projets de développement : les outils, l’architecture et la cinématiques des applications, l’environnement et la culture. Pourtant, il m’apparaît évident qu’un mode de travail collaboratif et fortement itératif est particulièrement adapté aux projets décisionnels, alors que le mode de travail généralement admis dans le milieu emprunte au « cycle en V » avec sa litanie de phase de spécification, de modélisation et de recettage et sa structuration en MOA / MOE.

En fait, ce n’est pas l’angle du livre. Celui-ci s’adresse au praticien du projet décisionnel, justement celui qui est un habitué du projet mené à l’ancienne. Si, comme moi, vous êtres déjà un habitué des principes et pratiques agiles dans un projet classique mais êtes désireux de connaître comment celles-ci se déclinent dans le monde du BI, ce texte n’est pas pour vous !

Il n’en demeure pas moins que l’auteur connaît son affaire, aussi bien sur le volet agile que sur les projets décisionnels. Pour ce qui est du volet agile, ses deux mentors sont Jim Highsmith et Scott Ambler. J’approuve pour le premier, moins pour le second. Quoi qu’il en soit, ses sources d’inspiration sont très visibles au long de l’ouvrage. Mais il est temps de passer au livre lui-même.

Le texte compte environ 300 pages, divisées en 10 chapitres, eux-mêmes regroupés au sein de 2 parties : Mangement methods (140 pages) et technical methods (le reste).

Toute la première partie, constituée des 5 premiers chapitres, reprend les principes de base de l’agilité. On y trouve peu de matériel qui soit une déclinaison des principes agiles adaptés au monde du décisionnel. Le chapitre 1 qui compte 24 pages est une introduction qui répond à la question du « pourquoi » de l’application d’agile au monde du BI.

Le chapitre 2, long d’une trentaine de pages, traite de gestion de projets agile. Elle reprends pratiquement point pour point, les principes du même noms énoncés par Jim Highsmith dans « agile project management », avec notamment le cycle « envision / explore ». Le lecteur déjà familier avec la prose de Jim Highsmith ne sera pas perdu par le texte. Mais on peut aussi noter que Ken Collier possède bien son sujet et le traite fort bien.

Au chapitre 3 traite de la collaboration, qui n’est pas là non plus un sujet de première fraicheur pour les agilistes, mais les points importants y sont bien traités. J’ai bien aimé le modèle « doers / planners / customers » dans cette partie.

Ce sont les users stories et l’estimation qui forment la matière du chapitre 4. Le sujet n’est plus guère original, pas plus que je n’ai trouvé d’éléments d’adaptation au monde du décisionnel.

Cette première partie se conclut par le chapitre 5 consacré à l’auto-organisation des équipes. Parmi les éléments intéressants, j’ai relevé le « 6 hats of thinking » que j’emploierais à l’occasion pour mes rétrospectives. Le reste est bel et bien du classique. Cette première section me laisse bien sur ma faim, même si j’ai pu en picorer quelques éléments intéressants par ci par là…

La seconde partie est aussi formée de 5 chapitres et s’avère plus prometteuse sur le papier. On commence par le chapitre 6 « evolving excellent design » qui compte quand même 50 pages. L’auteur y expose son modèle d’architecture décisionnelle incrémentale basée sur du message queue. C’est intéressant mais on est hors sujet par rapport au livre ! L’auteur peut être certainement fier de sa réalisation, mais ne peut-on appliquer agile dans le BI que par le biais de cette architecture ?

Le TDD et le Data Warehouse est le sujet du chapitre 7. C’est hélas très abstrait et peut d’élément pour la mise en œuvre. Sauf peut-être une petite astuce technique avec Microsoft SQL Server Integration Services. Ca tombe bien, c’est mon ETL ! Mais comment font les autres ?

Nous arrivons au chapitre 8 qui traite du versionning. Il nous dit qu’il faut versionner (grande nouvelle), en utilisant … Subversion ! Après nous avoir expliqué qu’il faut versionner les sources et non les produits générés (ce que je sais depuis pas loin de 20 ans), eh bien on est arrivé au bout du chapitre !

On se rapproche doucement de la fin : le chapitre 9 traite de l’automatisation, mais là encore si on a un peu d’éléments sur ce qui est une séquence de build typique sur un projet BI, le reste traite d’outils qui ne sont plus de prime jeunesse … comme Ant !

L’ouvrage se termine au chapitre 10 avec des propos plus généraux comme la conduite du changement en milieu décisionnel.

Bref, ce livre m’a déçu, en grande partie parce que je n’étais pas le bon public. Cela se reflète sur la note, mais c’est la règle du jeu. Comme je l’ai dit au début, l’auteur connaît sa matière, ses matières devrais-je dire et il est parfaitement crédible pour traiter le sujet. La prose tend à tirer un peu trop en longueur, ce qui est dit sur 300 pages pourrait l’être sur 220 pages sans nécessiter de sacrifices sur le contenu. Le fil rouge du case study vécu est généralement rafraichissant, mais il est raté ici : les épiques sont trop longues et ne servent pas correctement le sujet.

Faites attention à être la bonne cible avent de débuter cette lecture. Sinon, celle-ci risque d’être frustrante.

Agile Analytics

Référence complète : Agile Analytics, a value-driven approach to business intelligence and data warehousing – Ken Collier – Addison Wesley / ASD series 2012 – ISBN : 978-0-321-50481-4

Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing


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