Note de lecture : C++ iostream handbook, par Steve Teale

Note : 3 ; Difficile d’accès et même embrouillé, mais une des rares sources d’informations sur le sujet.

Ce très coûteux petit bouquin constitue probablement l’un des seuls (sinon le seul) manuel de référence sur les iostreams, du moins sur les “pré-standard” streams. Personnellement, hors son impression et sa mise en page de qualité très moyenne, je trouve les explications assez succinctes et parfois ambiguës. C’est néanmoins (et de loin) le bouquin de C++ que l’on m’a le plus souvent emprunté. Donc…

Malgrès son aspect sommaire, cet opuscule compte tout de même 355 pages annexes comprises et est structuré en 21 chapitres.

Tout comme « Object Oriented I/O using iostreams » ce livre concerne l’ancienne librairie iostreams. Certains détails ne sont plus d’actualité. Pour la nouvelle librairie IOStreams, vous pourrez vous reporter à l’ouvrage d’Angelika Langer: les utilisateurs du standard ont bien de la chance, car ce dernier ouvrage est, lui, quasi-irréprochable ! Son approche se veut celle d’un tutorial, alors que je l’ai surtout plus ou moins utilisé comme un manuel de référence (à défaut d’autre chose…). Mais même comme tutorial, il ne brille pas par son approche pédagogique. Les textes explicatifs sont très sybillins et franchement incomplets, tout comme les fragments de code. Ce sont pourtant eux qui m’ont servi, ou plus exactement servi de point de départ dans mon utilisation des iostreams ! Mais quelle prose embrouillée, quelle énergie dépensée (et avec quels nervements !) pour arriver à sortir quelque chose de ce texte.

Ce fut vraiment une grande source de frustration de n’avoir eu que ce livre pour m’aider un tant soit peu à utiliser la librairie iostreams pré-standard durant tant d’années. Le livre n’est plus commercialisé, c’est fort logique et c’est tant mieux !

c++-iostream-handbook

Référence complète : C++ iostream handbook – Steve Teale – Addison Wesley 1993 – ISBN: 0-201-59641-5

C++ Iostreams Handbook


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

Publicités

Note de lecture : Découvrir Microsoft SQL Server 2005, par Peter DeBetta

Note : 3 ; Un texte introductif qui déçoit en ratant un peu son sujet

De nouveau une note de lecture un peu ancienne, qui traite d’une version “n – 2” de SQL Server. Je la fais figurer ici par nostalgie …

Lorsque j’ai ouvert ce livre, je n’imaginais pas qu’il fut destiné au lecteur déjà aguerri aux versions précédentes de SQL server et déjà largement initié à l’environnement .NET (pour ne pas parler de Windows server…). Pourtant tout commençait bien, car cet opuscule de 200 pages semblait traiter les différents sous-ensembles de ce SGBD tentaculaire. En fait, les problèmes commencent avec la traduction du titre qui omet le « for developers ». Ceci explique certainement cela…

Les deux premiers chapitres (soit 35 pages) traitent des nouveautés de Transact SQL. Là c’est simple : si vous n’êtes pas un vieux routier du dialecte de Microsoft, le propos est incompréhensible. C’est mon cas. Donc, la suite.

Le chapitre 3 met tout de suite d’avantage l’eau à la bouche. Les possibilités de SQL server vis-à-vis de XML donnent envie d’en savoir plus. C’est cde que j’attends d’un ouvrage introductif. Dommage que les exemples soient (c’est un problème récurent du livre) trop touffu pour ce type de livre. Il est même amusant, sur le seul exemple dépouillé vraiment adapté au texte, de voir l’auteur s’excuser de la simplicité de l’exemple.

La seconde partie, qui pèse 4 chapitres et 80 pages traite de l’intégration CLR. Il était difficile de ne pas traiter le sujet. Là encore, l’auteur se trompe dans la profondeur de traitement du sujet. Mais globalement, on arrive à comprendre comment s’articule le code .NET au sein de SQL server. Dommage que la cinématique globale soit traité de façon si peu claire.

La troisième partie est certainement la plus intéressante, car elle traite des services annexes réellement novateurs de SQL server 2005. Nonobstant le problème récurent des exemples, les différents chapitres donnent vraiment envie d’en savoir plus :

  • Les DTS ne sont pas traités de la façon la plus claire qui soit. Hélas aussi, comme ce livre a été écrit sur la base d’une version bêta de SQL server 2005, il n’intègre pas la substitution de DTS par SSIS ! À revoir, donc… Autre problème récurent de cette troisième partie, on a du mal à comprendre ce qui est géré au sein de SQL server, par du T-SQL ou du code.NET embarqué ou ce qui est géré par une application externe appelant SQL server !
  • Les objets SMO sont clairement abordés, mais auraient probablement du être traité en partie 2.
  • Le support SOAP est traité de façon claire et succincte. Dommage qu’il ait été abandonné dans les versions ultérieures…
  • Les chapitres consacrés au service de notification et au service Broker ne sont pas parfaits, mais traitent quand même leur sujet.
  • Le service de reporting aurait pu être traité plus succinctement sur l’aspect structuration des reports et aborder l’Analysis service en contrepartie.

Globalement, je suis déçu. Déjà, ce livre anticipé est devenu obsolète bien trop vite. D’autre part, il n’est pas à la hauteur des autres livres introductifs de Microsoft press. C’est dommage, car un sujet aussi large que SQL server nécessite absolument ce type de texte pour le nouveau venu.

decouvrir-sqlserver2005

Référence complète : Découvrir Microsoft SQL Server 2005 – Peter DeBetta – Microsoft press 2005 (V.O. : Introducing Microsoft SQL Server 2005 for developers) – ISBN : 2-10-048896-1 (V.O. : 0-7356-1962-X)

Découvrir Microsoft SQL Server 2005


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

Le “Google Earth” de l’univers …

Enfin, pas tout à fait ! Si le potentiel est là, les données collectées par le Sloan Digital Digital Survey ne permettent pas de se déplacer à son grée parmi les 400000 galaxies répertoriées (bientôt 500000). On est encore loin des 500 milliards estimées, mais nous n’avons là que des galaxies effectivement identifiées, répertoriées et catégorisées !

Je pense que l’on pourra sous peu se déplacer dans l’univers comme nous le faisons avec Google Earth grâce aux données du SDSS. En attendant, savourez comme moi ce moment d’émerveillement : un voyage dans l’univers à un million de milliard de fois la vitesse de la lumière !

Note de lecture : Pattern Languages of Program Design vol. 2, Vlissides, Coplien & Kerth edt

Note : 5 ; Quelques bon (et même très bons patterns), toutefois noyés dans nombre de patterns de moindre intérêt.

Ce volume regroupe une sélection des contributions à la seconde conférence PLOP. La formule reste la même que pour le premier volume, avec une sélection de patterns ou de patterns languages regroupés par thèmes. La communauté se développant, la qualité de la matière utile progresse d’autant.

Une nouveauté, la première partie parle désormais d’idiomes, c’est à dire de patterns de bas niveau spécifiques à des langages. Toutefois il n’y a là rien de bien remarquable : les idiomes de Tom Cargill auront du mal à soutenir la comparaison avec ceux de Jim Coplien dans son ouvrage éponyme.

La seconde partie, les « general purpose patterns » regroupent ce que l’ouvrage a de mieux à proposer, avec spécifiquement deux patterns remarquables : Le Shopper de Jim Doble, mais surtout le Command Processor de Peter Sommerlad. Ce dernier n’est pas seulement désormais un classique, il est aussi simple, puissant et élégant.

La troisième partie « special purpose patterns » tait celle consacrée aux domaines métiers dans le volume précédent. On y trouve surtout des pattern languages qui sont intéressants sans être transcendants.

Peu de patterns dans la quatrième partie dédiée aux patterns architecturaux. Juste trois, seul « reflection » de Frank Buschmann retiendra mon attention.

Je ne suis toujours pas fan des patterns organisationnels qui nous sont proposés en cinquième et sixième parties. L’organisational Patterns for Team prélude certaines pratiques agiles. Episodes de Ward Cunningham est souvent référencé d’une part à cause du nom de l’auteur et d’autre part car certains patterns seront repris par Kent Beck dans l’extreme programming.

Le « concurrent programming / distributed systems » de la partie 7 est une excellente fournée. Je citerais juste le « half sync / Half-async » de Douglas C. Schmidt et Charles Cranor.

En comparaison, la partie 8 sur les « reactive systems » m’a parue un peu pauvre.

Si l’ouvrage est loin d’être indispensable, il pourra intéresser à ceux qui portent un intérêt actif aux patterns. Et un nombre non négligeable des patterns présentés sont loin d’être dénués d’intérêt.

PLOPD-vol2

Référence complète : Pattern Languages of Program Design, vol. 2 –  John Vlissides, James Coplien & Norman L. Kerth edt – Addison Wesley 1996 – ISBN : 0-201-89527-7

Pattern Languages of Program Design 2


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

Note de lecture : Object-Oriented SSADM, par Keith Robinson & Graham Berrisford

Note : 4 ; Une vision d’un autre temps….

Je sais ce que vous allez me dire : « quel intérêt en 2012 de faire une note de lecture sur un vieux clou âgé de 18 ans et de toute façon obsolète ? ». L’histoire, mes amis, ceci est l’histoire. Cet ouvrage de 500 pages évoquant une méthode désormais délaissée fait partie de l’histoire des méthodes objet.

SSADM est une approche que l’on pourrait qualifier de « hautement structurée », voir même Tayloriste ! Elle s’appuie sur 3 schémas directeurs :

  • L’Internal Design : qui définit le schéma physique de la base de données, ainsi que les PDIs (process data interfaces).
  • L’External Design : Il comprend les définitions de format de données en I/O et les interfaces et dialogues utilisateurs
  • Le Conceptual Design : Définit les règles métier, le modèle comportemental de l’application et le modèle logique des données.

Les parties 2 à 5 de ce livre viennent étayer cette vision quelque peu complexe de la modélisation des systèmes d’information.

  • La seconde partie du texte « Le besoin d’avoir plus que la modélisation de données » nous présente les concepts classiques de la modélisation orientée objet, bien qu’avec des qualités pédagogiques assez moyennes, pour nous emmener vers la modélisation dynamique, plutôt pauvre d’ailleurs avec SSADM. Bref, ce n’est pas encore ici que l’on va crier au génie.
  • La troisième partie modestement appelée « Le besoin d’avoir plus que la modélisation OO » couvre les concepts classiques de la modélisation OO (encapsulation, héritage, etc..) pour terminer avec les besoins liés aux « grands » systèmes d’information. Chapitre peu convaincant au demeurant. Au suivant, donc.
  • La quatrième partie est consacrée au modèle conceptuel (c’est aussi la plus importante du livre). On y détaille donc finalement la notation SSADM dédiée à cet aspect. On y aborde la réutilisation (quelle blague !) et certains patterns liés à l’entity data modeling qui constitue des règles d’usage de SSADM, même si leur bien-fondé reste en partie assez mystérieux pour moi. L’event modeling qui y est abordé offre certaines perspectives mais me parait aussi assez difficile d’emploi en l’état.
  • La cinquième partie est dédiée à l’external design. Assez curieusement, c’est ici que je trouve le plus d’éléments intéressants, liés à l’utilisation de techniques « RAD » ou d’event-driven interfaces, bien que les notations soient parfois ardues.
  • La sixième partie est quand à elle consacrée aux autres discussions comme les besoins concernant les ateliers de modélisation ou la réutilisation (encore ?) à l’échelle de l’entreprise.

On ne peut reprocher à cet ouvrage le traitement de SSADM, ce qui lui vaut sa note. C’est à SSADM lui-même que l’on peut reprocher des choses : cette vision du développement logiciel appartient à une autre époque, pour autant que cela ait été applicable à une époque donnée ? Ce découpage en tâche avec un formalisme si peu adapté à l’esprit humain ne semble guère convenir. Toutes ces méthodes datant de la fin des années 80 nous packageaient ensemble notation et approche structurée. Qui plus est, ici, cette approche ne s’adapte qu’à des cas identifiés d’architectures logicielles.

Bref, dans le genre, je préfère Bertrand Meyer.

ObjectOriented-SSADM

Référence complète : Object-Oriented SSADM – Keith Robinson & Graham Berrisford – Prentice Hall 1994 – ISBN : 0-13-3094444-8

Object Oriented Ssadm


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

En finir avec le backlog ?

Second volet de mon feuilleton “en finir avec…”. Ma victime du jour est le backlog.

Je rapelle mon mot d’avertissement : J’ai écrit le texte qui suit avec l’intention qu’il soit lu de façon critique. Ne prenez pas ces idées ou ces points de vue pour argent comptant. Utilisez-les comme source de réflexion pour vous forger votre propre réflexion.

C’est bien sûr vrai de tous les textes que l’on peut être amené à lire, mais ça l’est encore plus ici !

De la roadmap au backlog

Lors du premier opus, nous avons vu les conséquences d’une roadmap gérée en tant que portefeuille de projet: plan, stock, frein au changement, etc… Mais ce qui est vrai à grande échelle peut-il l’être à une échelle moindre ? Car le backlog ressemble au portefeuille de projet à plus petite échelle.

Nous considérons naturellement la backlog, brique fondamentale de Scrum, comme un outil agile indispensable. Qui penserait à le remettre en cause ?

Pourtant, dévié de sa bonne utilisation il peut avoir des conséquences néfastes.

Pourtant il peut servir à déguiser les anciennes pratiques.

Pourtant les conséquences évoquées ci-dessus ne sont pas seulement des travers d’usages, elles prennent naissance dans la nature intrinsèque du backlog. C’est un peu abstrait pour l’instant. On va illustrer tout ça.

Je veux un backlog complet

Tout d’abord, c’est quoi un backlog ?

“The backlog represent everything that anyone interested in the product or process has thought is needed or would be a good idea in the product” (1)

En clair toutes les idées qui pourraient s’avérer bonnes sont aptes à y figurer. Cela soulève plusieurs points :

  1. Est-ce que seuls les éléments qui vont être effectivement réalisés doivent figurer dans le backlog ?
  2. Le backlog doit-il comprendre initialialement tout ce qui sera réalisé ?
  3. A-t-on le droit de changer le backlog, et surtout d’y ajouter des choses passée la “phase initiale” ? Vous aurez noté les guillemets.

Ce sont de fausses questions car Scrum y répond. Pourtant j’y reviens car c’est déjà une source de travers.

Le backlog contient des éléments qui vont être effectivement réalisés

Scrum répond “non” à cette question. Il s’agit juste d’une liste de fonctionalités candidates.

D’un autre côté, Scrum nous invite à lister ce que les différents acteurs ont en tête à un moment donné. A créer du stock, aurais-je envie de dire (vous voyez certainement où je veux en venir), mais je reviendrais plus tard sur ce point.

Là où le bât blesse, c’est que ce backlog en son état initial correspond à un périmètre produit. Et le client souhaite souvent avoir une estimation de ce périmètre. En soi, aucun mal à cela. Sauf que le périmètre se transforme souvent en engagement, surtout quand le client n’est pas réellement agile. A partir de ce point, je vous souhaite bonne chance dans le monde merveilleux du suivi budgétaire. Je ne prend même pas la peine d’évoquer l’antagonisme entre le mode “suivi budgétaire” et la gestion du changement …

Le backlog initial est complet

Là aussi Scrum répond clairement “non”.

Sauf que là aussi, si ce backlog sert d’estimation initiale du projet, il vaut mieux ne pas être trop à côté de la plaque. Certes on pourra toujours troquer une fonctionnalité contre une autre… Mais qu’en est-il si les premières étapes du projet mettent en lumière de nouvelles idées, des aspects du fonctionnel qui onté été occulté ? Ou simplement des oublis ? A l’extrême on devrait être en mesure de “pivoter” comme l’on dit en language Lean Startup et c’est un des aspects que l’approche agile en général et Scrum en particulier permettent.

Mais ce backlog que l’on construit à l’avance à souvent tendance à se transformer en carcan.

Notre client pas très agile va arguer “faites des ajustements, mais il faut avoir une idée claire de là où l’on va au départ”. Eh bien non, ce n’est pas obligé. C’est certainement un confort si l’on peut, mais Scrum nous donne la flexibilité qu’il faut le cas échéant. On a quand même donné le bâton pour nous faire batttre avec ce foutu backlog…

Le backlog ne peut pas être changé

Là aussi Scrum est clair : “oui on peut le changer”. C’est même l’essence du processus de tirer profit du feedback pour le faire évoluer !

Oui, mais …

On a constitué cette (longue) liste, un processus coûteux en temps et en énergie. Cela va nous freiner dans une certaine mesure pour opérer des changements qui seront eux-même coûteux dans leur introduction mais aussi dans la remise en cause des items existants !

Bien sûr ce frein sera encore plus important dans le cas d’un changement radical. Il pourra même se transformer en blocage : “remettre en cause ? Alors que l’on a là une liste de fonctionnalités bien établies ?”

Je veux un backlog détaillé

Le backlog “complet” ne suffit même pas toujours pour démarrer un projet, surtout si l’on souhaite utiliser ce backlog pour effectuer une estimation comme je l’ai indiqué plus haut. Il nous faut alors savoir ce qu’il y a derrière chaque item afin d’avoir une idée valable de la complexité de celle-ci ! Vous l’avez probablement remarqué : on a déjà quitté Scrum depuis un certain temps. Mais qu’importe, on parle de backlog ! Tout va bien !

Cette affaire de backlog détaillé m’inspire trois choses.

Détailler

Détailler ou au moins rentrer dans le coeur de chaque fonctionnalité c’est échafauder le système alors que l’on a rien commencé, que rien ne peut nous aider à soutenir notre reflexion ou etayer nos hypothèses. J’ai fait référence au “lean startup” plus haut. Eux nous suggèrent de ne pas oublier que justement ce que nous appelons “expression des besoins” sont en fait des hypothèses. Personnellement, cela me rapelle une citation du “Mythical Man-Month”, elle s’adresse au developpeur mais pourrait aussi concerner celui qui construit le backlog : “Le programmeur, comme le poète, manie des abstractions voisines de la pensée pure. Il construit des cathédrales dans les airs, à partir de l’air lui-même, par le pouvoir de son imagination” (2). Construire des cathédrales dans les airs avec de l’air, c’est pas facile…

Faire mûrir

Ma seconde réflexion va vers ce que l’on apelle parfois le “mûrissement du backlog”. Vous avez peut-être déjà entendu cette expression : “il faut que ça mûrisse” ? Voilà qui nous invite à une petite pause bucolique.

frui-murSmall

Il y a bien sûr un concept derrière ça : c’est que quand une idée est seulement une ébauche, le simple passage du temps va permettre de rafiner l’idée qui tombera alors toute seule tel un fruit mûr ! C’est pas beau ? J’ai bien entendu de gros doutes sur ce processus spontané. Mes seules certitudes à ce propos sont:

  • Si on ne fait rien, il ne se passe rien.
  • La seule conséquence inéluctable du passage du temps, c’est la génération d’un délais.

Il existe des techniques, actives celles-ci, pour développer des idées à l’état d’ébauches :

  • Le brainstorming
  • L’expérimentation, que ce soit sur la base d’un prototype ou non.

On retrouve ces techniques dans les processus de développement orientées vers l’innovations comme le Design Thinking. Mais pour ça, il faut lâcher le backlog 5 minutes …

Backlog a.k.a. “cahier des charges”

Finalement, ce backlog complet et détaillé portait autrefois un nom: le cahier des charges. Par un effet pervers, nous avons reconstitué ici sous une forme certes différente, ce que nous voulions abandonner dans les anciennes approches. Il ne reste plus qu’à en confier la confection à une MOA (auquel on aura donné un autre nom) et on aura fait le tour !

Bien sûr Scrum ne dit pas du tout d’en arriver là. Mais il est tellement facile de glisser progressivement pour en revenir à ce que l’on faisait avant. Tout en se donnant bonne conscience, souvent même de bonne foi, car on apelle cela “backlog”.

L’effet de bord de ce backlog “complet et détaillé” est le délai que cela nécessaire pour en arriver là.

Une phase d’analyse ?

Scrum a poussé le concept d’itération zéro, pour amorcer un projet. Mais pour débuter avec un backlog complet et détaillé, cela ne suffit pas. Aussi voit-on le product owner ou l’équipe PO commencer un travail qui n’est pas seulement exploratoire mais un travail de fond en avance de phase afin que l’équipe de développement puisse débuter son oeuvre avec une matière première solide.

C’est la négation même de l’approche agile dont le fondement est le cycle court et le feedback. C’est en fait la réincarnation de la phase d’analyse !

L’autre conséquence de cette phase d’analyse, outre le délai, est la création d’un stock. J’en ai parlé plus haut et j’ai l’air d’insister, mais en terme “lean”, le stock est assimilé à du gâchis: c’est du travail dont on ne sait s’il va être utilisé et demande une charge d’entretien : relecture, réévaluation régulerière, etc…

Old files

Ma liberté de penser !

Vous finissez un sprint et allez commencer le suivant. Il est temps de choisir les prochains items de backlog à développer.

Qu’est-ce qui importe vraiment ?

Sont-ce les prochains items de backlog selon la priorité qui leur a été attribuée ? Pas vraiment, ou du moins pas comme ça.

Ce qui importe vraiment c’est ce que nous avons appris à la lumière du sprint écoulé : approfondir des fonctionnalités sur lesquelles nous avons travaillé, se diriger vers une direction complètement différente et parfois oui, prendre des items du backlog tel que nous l’avions dressé.

Mais par rapport à ce focus sur le feedback et l’apprentissage le backlog agit régulièrement comme un frein ou plutôt comme un gros élastic que nous aurions dans le dos, qui nous ramène inoxorablement vers la voie que nous avions tracé au départ.

Qu’est-ce qui empêche d’utiliser le backlog pour prendre en compte l’apprentissage et le feedback ? Absolument rien. En fait, il est fait pour ça. Comment l’utilisons-nous dans les faits ? Je vous laisse le soin d’y répondre.

Dans un projet agile, ce qui s’interpose entre vous et le feedback est un problème. Ne laissez pas le backlog devenir un problème, ne le laissez pas entraver votre liberté de penser. Un backlog n’est pas un cahier des charges.

A quoi ça sert vraiment ?

J’ai l’air de dire jusqu’à présent que le backlog est l’oeuvre du malin. Donc est-ce utile ? Voilà un point sur lequel nous allons pouvoir répondre aisément.

S’assurer que l’on fait les choses les plus importantes

Imaginez que vous avez un backlog de 50 items alors que vous n’allez pouvoir en traiter que 3 dans la prochaine itération. A quoi servent donc les 47 autres ? Eh bien essentiellement à s’assurer que l’un des 3 items importants ne se trouve pas parmi ces 47 autres !

Donner de la perspective

Certes, quand on fait un projet hautement innovant, voir de la R&D, construire un backlog a peu ou pas de sens. On est d’ailleurs là en dehors de la zone de Scrum. Mais lorsque cela est possible, en fait assez souvent, avoir du contexte donc une idée de ce qui est considéré comme le périmètre du projet à un instant donné, aide à la réflexion et est plus stimulant pour l’équipe.

Quelle(s) alternative(s) ?

Elles sont essentiellement déterminées (ou limitées) par notre créativité. J’en propose 3. Et je vais tricher un peu.

Arrêtez ça

Ce n’est pas une alternative mais un conseil : ne faites pas le backlog “complet et détaillé”. C’est mal. Arrêtez de faire ça, simplement.

Pas de backlog

Si on n’a plus de backlog, on ne fit plus du Scrum, n’est-ce pas ? Mais certains projets à forte composante exploratoire ne se prêtent pas à cela. Nous sommes alors dans le cas où la backlog va générer plus d’entrave que d’aide. Il est peut-être temps de sortir de Scrum. D’autres approches agiles s’accomodent de l’absence de backlog :

  • Extreme Programming parle juste de User Stories (on s’occupera de leur cas dans un épisode futur) à traiter et ne fige même pas celles-ci pour l’itération en cours. Toutefois XP n’est pas hostile à la présence d’un stock de stories.
  • Kanban n’a pas de backlog, mais des files d’attente. Et celles-ci ont des capacité déterminées et limitées. On a bien du stock dans une certaine mesure, mais celui-ci est limité et contrôlé.
  • Lean Startup ne parle ni de backlog ni de stock de features. En fait, cette approche s’oppose intrinsèquement à ces notions car le focus est ici uniquement sur l’apprentissage scientifique qui est fondamentalement antagoniste avec la présence d’un “stock d’hypothèses”.

Le backlog à géométrie variable

C’est mon préféré. C’est aussi un compromis entre les avantages (donner de la perspective, identifier les fonctionnalités candidates) et les inconvénients (créer du stock, générer de la charge et du délais). Fort heureusement, c’est aussi ce qui est préconisé par de nombreux auteurs, dont Claude Aubry (3).

Dans cette approche on limite le découpage fin des stories et leur détail qu’aux fonctionnalités classées les plus prioritaires. Je ne vais pas entrer dans le détail ici, ce n’est pas le but de ce post. Vous en trouverez la description ailleurs.

Alors le backlog, c’est mal ?

J’utilise des backlogs et j’aime bien ça. Je serais donc bien en peine de dire que c’est mal.

Mais ce n’est pas non plus de la magie. Le backlog est un outil. Mais aussi bénéfique soit-il un outil porte en lui-même les germes de ses propres travers. Je me limiterais à deux conclusions:

  • Ne dénaturez pas le backlog et la façon dont il doit être utilisé.
  • Soyez conscients des inconvénients. Ils joueront contre vous si vous les ignorez.

Références

(1) Agile Software Development with Scrum, Ken Schwaber & Mike Beedle, Prentice Hall 2002 ; p. 33

(2) The Mythical Man-Month anniversary eat, Frederik Brooks, Addison Wesley 1995

(3) Scrum Le guide pratique de la méthode agile la plus populaire 2nd édition ; Claude Aubry ; Dunod 2011 ; p. 67

Note de lecture : Effective Java, second edition, par Joshua Bloch

Note : 8 ; Il fait honneur à la lignée « effective »

Le titre du livre ne laisse guère planer le mystère : il se veut le pendant Java du désormais célèbre « Effective C++ » de Scott Meyers. Eh bien, on peut l’avouer, le contrat est plutôt bien rempli. Il expose 57 items au long de 232 pages découpés en 10 chapitres. La présence d’un tel ouvrage afin de stigmatiser les bons usages du langage était sans nul doute nécessaire, car si Java  (au contraire du C++) passe pour un langage facile, il n’en est de ce fait que plus aisé (et d’ailleurs plus fréquent) de mal l’utiliser !

Le style du texte est sensiblement différent de celui de Scott Meyers. D’abord on n’y retrouve pas la pointe d’humour qui fait le charme de l’ouvrage C++. Il focalise également un peu moins sur le code de bas niveau, même si nombre d’items sont spécifiquement dédiés à ces aspects. Enfin, l’auteur qui fut « chief architecte » d’une bonne partie des librairies Java oriente souvent son propos par rapport à une vision développement de librairies, alors que c’est un biais somme toute marginal, par rapport au développement d’applications !

Malgré ces petits reproches, il ne fait nul doute que ce livre est un incontournable de toute bibliothèque Java un tant soit peu sérieuse, ne serait-ce que pour utiliser correctement les redéfinitions des méthodes dérivées de la classe Object, comprendre convenablement les « nested classes », certains principes de bases inhérents aux exceptions ou à la sérialisation. Le chapitre consacré aux threads est évidemment plus ardu et également moins pointu que le livre de Doug Lea consacré à ce sujet (et qui fait toujours référence).

Parmi les choses que j’apprécie particulièrement dans le texte : le style très clair, même narratif dirais-je car l’auteur nous guide réellement dans l’explication de l’item tel un conteur. Des fragments de code illustrent le texte et sont particulièrement bien pesés : avec assez de contexte pour donner du sens mais assez concis pour ne pas noyer le lecteur ni être ennuyeux. Globalement j’aime le style très « punchy » avec lequel l’auteur aborde chaque problématique pour nous faire tomber des nues sur tel ou tel comportement du langage, qu’il soit justifié ou non.

Cette seconde édition compte 300 pages pour 68 items. Vous aurez vite fait le calcul sur la taille moyenne de chaque item en nombre de pages ! De toute façon, c’est une lecture à laquelle on prend plaisir tout en apprenant.

Le texte fait de nombreuses références au manuel de référence du langage qui est un complément indispensable à ce livre.

effective-java-2edt

Référence complète : Effective Java, second edition – Joshua Bloch – Addison Wesley / Java Series 2001 – ISBN : 0-201-31005-8

Effective Java(tm) Programming Language Guide


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