Note de lecture : Agile Estimating and Planning, par Mike Cohn

Note: 8; La mine d’information de la gestion de projets agile

Déjà auteur d’un ouvrage sur les “User Stories” (et futur auteur d’un autre livre sur la transition vers Scrum) Mike Cohn nous livre ici un texte complet sur les estimations et la planification agile, et c’est vraiment une bonne surprise. A la différence de certains livres qui entretiennent un flou artistique, l’auteur a vraiment fait l’effort de couvrir le terrain du sujet, en découpant le texte en 7 parties, qui totalisent 23 Chapitres (soit 312 pages) !

La première partie “problems and goals” traite des défaillances de la planification classique, pourquoi elle échoue et en quoi l’approche agile est radicalement différente. Les 3 chapitres constituant cette première partie se résument à 32 pages. On débute par la question de l’estimation par le biais du cône d’incertitude. De là, le chapitre 2 aborde les causes d’échec des estimations classiques : multitâche, ignorance des dépendances et estimations se transformant en engagements ! On conclut logiquement cette première partie par un chapitre 3 mettant en relief les vertus de l’approche agile : planification à plusieurs niveaux, boucle de feedback, planification par la valeur métier.

La seconde partie traite de l’estimation. Forte de 5 chapitres totalisant 44 pages, l’auteur a réellement privilégié ici les petits chapitres, condensés et efficaces ! Les deux premiers chapitres expliquent l’approche de l’estimation en “story points” puis en “jours idéaux”, avant d’aborder les techniques collaboratives (planning poker, analogies, wide band delphy, etc.). Plus original, le chapitre 7 évoque la réestimation ! Cette partie se conclut logiquement par une discussion du choix entre story points et jours idéaux.

Prioriser par la valeur est le thème de la troisième partie (50 pages, 4 chapitres). C’est à mon avis la partie la plus ludique de l’ouvrage, car on y découvre l’évaluation par le modèle des cash flows, l’utilisation d’abaques « risque vs valeur » ou encore l’utilisation du modèle de Kano. L’utilisation de ces techniques révèlent parfois certaines user stories comme ambivalentes. Le dernier chapitre de cette partie traite du découpage de ces stories.

Avec la quatrième partie, on aborder le second grand thème du livre : la planification. Il est logique que cette partie soit la plus longue, avec 80 pages découpées en 6 chapitres. Les deux premiers chapitres couvrent les deux niveaux principaux de la planification agile : le release plan, puis la planification d’itération. Les autres aspects couverts dans cette partie sont l’évaluation de la vélocité et les problématiques de synchronisation entre équipes (buffering, planification avec plusieurs équipes). Cette quatrième partie est assez dense, croyez-moi !

C’est au suivi de la réalisation qu’est consacré la cinquième partie. Ce n’est pas un sujet sur lequel l’approche agile met un accent particulier, aussi est-il logique qu’il ne couvre que 34 pages (3 chapitres). Bien entendu, on y parle burndown charts, suivi de l’accomplissement des tâches et communication avec le management.

Les sixième et septièmes parties ne comportent qu’un seul chapitre chacune. Si la sixième partie forme une sorte de conclusion (ou devrais-je dire d’ode) à la planification agile en en listant les qualités, La dernière partie reprend elle l’ensemble des thèmes via une étude de cas. Ce chapitre (assez long) est intéressant car il recolle les morceaux directement en situation, l’ensemble étant narré via des dialogues entre membres d’une équipe de développement, le management et un coach.

On pourrait en douter de prime abord, mais l’estimation et la planification agile couvrent un grand nombre de sujets et de techniques. Le tour de force de l’auteur est de nous présenter une boite à outil très complète de manière concise, efficace et agréable à lire.

C’est tout simplement un incontournable d’une bibliothèque « agile » digne de ce nom!

agile-estimating-planning

Référence complète : Agile Estimating and Planning – Mike Cohn – Prentice Hall 2006 – ISBN: 0-13-147941-5; EAN: 978-0-131- 47941-8

Agile Estimating and Planning


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

Note de lecture : Performance des Architectures IT par Pascal Grojean, Médéric Morel & Guillaume Plouin

Note : 2 ; Pas aussi bien qu’espéré et souvent hors sujet

Voilà bien un sujet qui me touche de près : comment s’assurer qu’une architecture d’entreprise, composée de multiples applications interagissant, déployées sur une infrastructure ad hoc, fonctionne de façon optimale ? Quels sont les points à vérifier et les pièges à éviter ? Comment mesurer l’ensemble et surtout quoi mesurer ? Si j’ai trouvé là parfois des éléments de réponse, le livre m’a largement déçu.

Celui-ci est long de 260 pages découpées en 4 parties comptant au total 16 chapitres. Donc les chapitres ne sont pas trop longs, ce qui est une bonne nouvelle.

La première partie est consacrée à des généralités « problématiques de performance des SI ». On en prend pour 30 pages et 3 chapitres, ce qui est déjà trop car le propos est complètement creux.

La seconde partie (4 chapitres, 90 pages) est moins creuse mais d’avantage hors sujet. J’ai bien aimé les anti-patterns du chapitre 4, mais qui me disent ce que je sais déjà, sans y apporter de solution. Je n’ose même pas parler de la discussion Web Services versus Rest qui est un propos de développeur, pas d’architecte IT. Un architecte IT doit travailler avec le contexte qui s’offre à lui, il n’a pas le luxe de créer le sien. Le reste de cette partie évoque beaucoup SOA, ce qui n’est pas la raison pour laquelle j’ai acheté ce livre, et souvent n traitant des points qui sont plutôt du ressort de l’architecture logicielle (et j’ai passé l’âge de « l’architecture logicielle pour les nuls »).

La troisième partie a enfin trait au sujet du livre (on est quand même page 127). Elle revendique 70 pages sur 5 chapitres. Chaque chapitre est donc succinct, et en fait superficiel. C’est bien dommage car chacun traite d’un volet important qui mériterait que l’on s’y attarde. En fait, j’aurais bien aimé une partie pour chacun de ces chapitres, en faisant table rase du reste du bouquin ! Les sujets traités sont : les réseaux, le stockage, le clustering, les bases de données et les serveurs d’application. Comme je le disais, difficile d‘être pointu quand chaque chapitre compte à peine 15 pages. Là encore, on ne va pas très loin, vous trouverez mieux sur Wikipedia.

La quatrième partie couvre 60 pages sur 4 chapitres et s’intéresse aux sujets suivants : les techniques de programmation (pas éblouissant et hors sujet), les tests de performances (en soi pas inintéressant, mais on a là qu’une introduction), la gestion de la production quelques bonnes idées à prendre concernant le monitoring), la gestion de projet (bien bateau).

Bref, un livre raté. Les auteurs se sont perdus dans des considérations complètement en dehors du sujet. C’est certainement ce qui arrive quand on se pique d’architecture IT alors que votre véritable centre d’intérêt est l’architecture et la conception logicielle. 

Performance des architectures IT
Référence complète : Performance des Architectures IT : Disponibilité, temps de réponse, robustesse, montée en charge – Pascal Grojean, Médéric Morel & Guillaume Plouin – Dunod 2007 – ISBN : 978 2 10 051262 1 (une seconde édition est aujourd’hui disponible)
Performance des Architectures IT


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

Note de lecture : UML 2 par la pratique : études de cas et exercices corrigés 4ème édition, par Pascal Roques

Note : 7 ; Plus qu’une mise à jour !

Déjà la 4ème édition de ce livre ! J’en ai donc raté 2, et j’aurais aussi raté celui-ci si Pascal ne m’en avait pas fait cadeau. L’un des objectifs majeurs de cette nouvelle édition était la mise à jour par rapport à UML 2 : de ce coté l’objectif est atteint. On notera, par exemple, l’utilisation abondante des « frames » (mais pas de l’interaction overview, pourtant si utile). Autre nouveauté majeure, les « composite structure diagram » sont dorénavant présentés, mais avec un traitement peu en mesure avec leur importance. Les « timing diagram », de leur coté, sont juste évoqué en passant mais j’en fais moins de cas, car cette innovation outre sa séparation par rapport aux autres concepts d’UML2, me semble de moins d’importance. Pascal aime beaucoup les diagrammes d’état, aussi leur réserve-t-il traditionnellement une part importante, y compris les trucs quasi-inutiles comme les états historiques. Cette édition suit la tradition et les nouveautés concernant les automates d’état sont extensivement passées en revue. Je continue à trouver surdimensionné l’importance accordée à cet aspect, mais on reconnaitra que celui-ci est au moins traité « in extenso » ! On n’en dira pas autant des diagrammes de communication (les anciens diagrammes de collaboration) : assez peu évoqués, ils sont de plus utilisés avec les stéréotypes Jocobsoniens (déjà présents dans la première édition, à mon grand désarroi, et qui persistent dans cette dernière mouture), je n’en suis pas un grand fan, car ils induisent des choix de modélisation particuliers et rendent la lecture des diagrammes d’autant plus difficile que le lecteur du livre sera généralement débutant en UML. Autre nouveauté : Pascal nous propose une analyse linguistique, si l’exercice est intéressant et bien mené, son intérêt pratique est questionnable, mais comme on dit : c’est bien de le faire au moins une fois.

Au-delà de la mise à jour UML 2, cette nouvelle édition a pris un peu d’ampleur, passant de 290 à 320 pages. On a vu pire, d’autant qu’il faut bien l’avouer : les qualités pédagogiques de l’auteur rendent cela extrêmement digeste. Le principe du livre est toujours le même : la présentation d’UML se fait au travers d’exercices durant les 3 premiers chapitres, ce qui permet de présenter les concepts de façon progressive. La quatrième partie dédiée à la conception s’appuie sure 2 études de cas. Ceux qui connaissent le cours Valtech UML reconnaitront la trame et les exercices. On remarquera au passage les emprunts à l’approche de Craig Larman, au travers des contrats d’opération, entre autre chose.

Si vous cherchez un ouvrage sur UML, vous voici donc face à 3 choix principaux :

L’UML distilled de Martin Fowler : Condensé et efficace, il présente la notation UML aux lecteurs déjà aguerris dans l’utilisation d’un langage de modélisation graphique

L’UML Reference Guide des 3 amigos : C’est la référence sur UML et ne s’adresse pas au débutant, car si le texte est pédagogique, il ne fait grâce d’aucune des subtilités du standard. Le débutant risquera fort d’être noyé.

L’UML par la pratique de Pascal Roques : Un bon moyen (la référence devrai-je plutôt dire) de s’auto former à UML, avec des exercices et une présentation progressive des concepts. Toutefois, le format retenu ne le rend pas tellement pratique pour s’en servir après coup comme un manuel de référence. Ce n’était pas le but de l’auteur, et l’exercice ne parait pas tellement praticable de toute façon.

UML 2 par la pratique

Référence complète : UML 2 par la pratique : études de cas et exercices corrigés, 4ème édition – Pascal Roques – Eyrolles 2005 – ISBN : 2-212-11680-2 (une 7ème édition est aujourd’hui disponible).

Uml 2 Par La Pratique: Études De Cas Et Exercices Corrigés


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

Note de lecture : Urbanisme des SI et gouvernance : Retours d’expérience et bonnes pratiques, par le Club Urba-EA

Note : 2 ; Creux et plat tout à la fois

Bon, je dois être honnête : si j’ai acheté ce livre, c’est parce que je connais deux des projets qui y sont exposés pour y avoir trainé mes guêtres. Comme globalement il s’agissait de vastes pantalonnades aussi pleines de prétentions que vides d’efficacité, ceci associé à une pratique modérée mais réelle des écrits du club « Urba EA », disons que mes attentes ne se situaient pas très haut. Je n’ai pas été déçu : c’est nul.

J’avais tout d’abord choisi comme titre de cette note de lecture : « comment uriner dans son froc efficacement », mais j’ai finalement changé après avoir tourné la dernière page, car ce n’est pas le trait qui m’a le plus marqué. Non, ce que j’en garde comme souvenir, c’est que l’on n’y dit rien. Oh, on couvre bien les plus de 200 pages du livre, mais essentiellement avec des lieux communs, des banalités et aussi peu d’information pertinente et opérationnelle qu’il est possible. En fait, la seule chose que j’y aie apprise est une succincte explication du framework de Zachman. Comptez 3 pages. Bien sûr, vous allez me dire qu’ayant lu toute la littérature sur l’urbanisation du SI (ou presque), il était improbable que je puisse y apprendre quelque chose de nouveau. Erreur. Je pense qu’il y a beaucoup de choses que vous ou moi puissions apprendre malgré la littérature publiée sur le sujet, mais elle n’est pas là.

Le bouquin est trop déprimant pour que je me livre à une analyse chapitre par chapitre (mais il y a 5 parties, OK je veux bien aller jusque là). Si au moins le style était au rendez-vous et en rendait la lecture plaisante malgré son vide abyssal. Même pas, c’est pompeux à souhait, comme certains aiment à penser que doit l’être la littérature sérieuse.

Je passe la première partie (composée de 2 chapitres) destinée à introduire les sujets couverts dans le reste de l’ouvrage. La seconde partie couvre les activités de l’urbaniste. Les 6 chapitres qui composent cette partie, peut-être la moins inintéressante du livre tentent d’expliquer ce qu’est le rôle de l’urbaniste. Deux pathétiques études de cas illustrent le propos. Si vous ne comprenez pas ce que les équipes des études de cas ont vraiment fait, rassurez-vous : moi non plus. Ce chapitre vaut au livre la moitié des points que je lui accorde. L’autre, c’est qu’hélas il existe encore pire que ce livre-ci !

La troisième partie, on y parle de gouvernance. C’est hautement gonflé de prétentions, ridiculement pauvre de contenu, et on a rien appris au final. 7 chapitres pour cela dont 3 études de cas. Mots clés : ROI, valeur, gouvernance, ITIL, Cobit, CMM, etc…

La quatrième partie est consacrée au rapport entre urbanistes et projets. Dans un éclair de lucidité, les membres du club Urba SI on comprit qu’ils devaient, pour justifier leur existence, être en contact des projets. Avec ce qu’on y voit la question est donc : les projets auront-ils envie d’être en contact des urbanistes. De mon point de vue, étant convaincu de l’utilité de l’urbanisation des SI et à la lumière de ce que je lis ici, la réponse sera non. Deux études de cas illustrent ce propos. Mais oui. Je les connais et je n’en dirais pas que les urbanistes y sont au contact des projets.

La cinquième partie est consacrée à la création de valeur (2 chapitres, pas d’étude de cas). Je parlais de lieux communs tout à l’heure ? Cela s’applique bien ici.

Peut-être avez-vous eu le courage de lire ma prose jusqu’au bout. Pour ceux qui, particulièrement fatigués par leur journée de travail ou n’ayant pas encore émergé de la fête outrageusement arrosée d’hier soir, n’auraient pas encore extrapolé mon conseil, le voici exprimé explicitement : ce livre est hautement déconseillé.

urba-si-gouvernance

Référence complète : Urbanisme des SI et gouvernance : Retours d’expérience et bonnes pratiques – Club Urba-EA : Philippe Anquetil, Jean-Christophe Bonne, Denis Carpentier, Laurent Chaigneau, Michel Dardet, Patricia Gotlib, Bruno Guenoden, Alain Legac, Christophe Longépé et René Mandel – Dunod 2006 – ISBN : 2-10-049678-6 ; EAN : 978-2-100-49678-5

Urbanisme des SI et gouvernance : Retours d’expérience et bonnes pratiques


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

Note de lecture : My Job Went to India (and all I go twas this lousy book), 52 ways to save your job par Chad Fowler

Note: 7; Une ligne de conduite pour sauvegarder son employabilité: utile bien au-delà du contexte cite dans le titre, et à reconsulter régulièrement.

Derrière un titre amusant (et une couverture qui ne l’est pas moins), Chad Fowler nous livre un propos tout à fait sérieux et profond: comment rester employable et éviter l’obsolescence. L’approche de l’auteur est à la fois simple et originale: il faut considérer sa carrière comme un produit. Cela conduit à une approche en 5 parties, plus une “supplémentaire”.

Choisir son marché: c’est orienter sa carrière selon ses capacités mais aussi par rapport aux opportunités de marché. C’est aussi garder le contrôle de la direction que l’on souhaite emprunter et éviter de se laisser embarquer dans des voies sans issues.

Investir dans votre produit: c’est définir et mettre en œuvre le plan d’action pour prendre la direction que l’on souhaite.

Exécuter : Ou comment se comporter et agir au jour le jour dans son poste. C’est aussi se remettre en cause continuellement et avoir une idée claire de sa valeur et de la valeur (ou du manque de valeur) de son travail. 

Marketing : comme son nom l’indique, c’est se vendre en mettant en valeur son travail sans penser que l’on sera automatiquement connu et reconnu par la simple production de livrables de qualité. C’est donc aussi savoir être un bon communiquant.

Maintenir son avantage : C’est éviter l’obsolescence en restant en mouvement, en ayant une gestion « agile » de sa carrière.

Si vous ne pouvez les battre… : Ce dernier chapitre adresse la position que l’on peut prendre par rapport à l’offshore, non en essayant de l’éviter, mais en prenant une position forte dans ce processus.

L’auteur est tout à fait aguerri sur son sujet : il a été manager sur la mise en place d’une entité offshore dans son entreprise. Chaque item est traité sur 2 à quatre pages environ, ce qui évite l’ennui, dans un style plutôt agréable et illustré d’exemples, mais dans un anglais parfois un peu sophistiqué qui en complique un peu la lecture. Chaque item se termine par des points de « mise en mouvements », certains sont bons et d’autres un peu forcés. Au final ils sont un peu nombreux, mais on peut utilement piocher dedans.

Un ouvrage qui invite à la réflexion, donc.

job-went-to-india

Référence complète : My Job Went to India (and all I go twas this lousy book), 52 ways to save your job – Chad Fowler – Pragmatic Bookshelf 2005 – ISBN: 0-9766940-1-8 (une seconde édition sous un autre titre existe qui fera l’objet d’une note de lecture ultérieure)

My Job Went to India: And All I Got Was This Lousy Book (Pragmatic Programmers)


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

Note de lecture : Use Case, patterns and blueprints, par Gunnar Övergaard & Karin Palmkvist

Note : 3 ; Des patterns qui n’en ont que le nom et des préoccupations exagérément focalisées sur la structuration.

En voyant le nom du disciple d’Ivar Jacobson en auteur de ce livre, je m’attendais à une vision Jacobsionienne, mais aussi à de bonnes choses. Très curieusement, je n’ai eu aucun des deux points.

Parlons déjà du volet « patterns », pour commencer. Franchement, je ne sais pas pourquoi on a laissé passer ce texte dans la SPS series, car si le livre de Steve Adolph et al. (Patterns for effective use cases) présente bien des patterns, celui-ci fait seulement semblant. Ceux-cis sont mal cadrés, aucune description de problème ne les introduisent, ils ne sont pas compréhensibles, et d’ailleurs ils ne servent en fait que d’introduction à la discussion qui s’en suit. Deux autres parties suivent la partie pattern, une partie « blueprint » qui sont des applications concrètes (en fait plus proches de ce que devraient être des use case patterns), mais toujours de peu d’intérêt, et une partie « mistakes » plus intéressante mais longue de seulement 30 pages (le livre en compte 420) !

Pour ce qui est du fond, ce livre est malheureusement un danger, car il se focalise excessivement sur les relations entre patterns : relations d‘inclusion et d’extension et généralisation, rendant les modèles de cas d’utilisation bien trop techniques et pas assez lisibles. Un véritable danger pour le pratiquant débutant !

Du coté des bonnes nouvelles, le livre intègre (outre les patterns) une introduction à la modélisation des cas d’utilisation assez bien faite et réduite à 100 pages (donc, bien). Si j’agonit de critiques l’excès de structuration, je dois aussi avouer qu’aucun texte ne détaille aussi bien la relation d’extension, et les possibilités offertes par les points d’extension. De même, les auteurs proposent une façon de documenter les cas d’utilisation parent et enfants dans une relation de généralisation qui est plutôt intelligente. Enfin, c’est le seul texte à ma connaissance qui décrive précisément et utilise les instances de cas d’utilisation. Ceci intéressera donc les académiciens d’UML (donc aussi le théoricien qui sommeille en moi).

Globalement, un livre que je déconseille, et qu’il faut absolument mettre hors de portée des non experts.

use-cases-patterns-blueprints

Référence complète : Use Case, patterns and blueprints – Gunnar Övergaard & Karin Palmkvist – Addison Wesley / Software Patterns series 2004 – ISBN: 0-13-145134-0

Use Cases: Patterns and Blueprints


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

Note de lecture : The Art of Readable Code, par Dustin Boswell & Trevor Foucher

Note 3 ; Le contenu est bien maigre…

Je m’en doutais un peu dès le départ en le tenant en main : le contenu serait vite lu. Ce fut bien le cas. Je pensais y trouver des éléments de style auxquels confronter mes propres idées, le bilan est pour le moins mitigé sur ce point. Au départ, l’ouvrage compte 180 avec une structure plutôt aérée et des cartoons humoristiques comme on aimerait en voir plus souvent. L’ensemble est découpé en 15 chapitres, eux-mêmes regroupés en 4 parties. Disons que c’est un bon point de départ.

La première partie « surface level improvements » compte 6 chapitres sur 60 pages. Elle ne parle que de choses simples, pourtant je l’ai trouvée plutôt pas mal. Les sujets qui y sont traités sont principalement nommages, indentation (et mise en page au sens large) et commentaires. J’adhère à beaucoup des idées, mais pas toutes. Les développements autour des commentaires sont probablement les plus intéressants que j’ai pu lire.

La seconde partie « simplifying loops and logic » est développée sur 3 chapitres totalisant un peu moins de 40 pages. On y parle ici de lisibilité du code via le découpage des méthodes ou la simplification des expressions. Certains sujets sont à la limité des questions de lisibilité et touchent plutôt la qualité. Les points abordés le sont bien, mais le sujet n’est plus neuf car il est le pain quotidien des pratiquants du refactoring.

En troisième partie « reorganizing your code », c’est en 35 pages sur 4 chapitres que les auteurs traitent du refactoring à plus grande échelle. La lecture et les exemples sont loin d’être palpitants et l’on peut même dire que le traitement du sujet en est largement superficiel. On préfèrera nettement la lecture du « refactoring to patterns » de Joshua Kerievsky à ce sujet !

La troisième partie « selected topics » est forte de 2 chapitres couvrant 30 pages. Le premier traite de la testabilité et de l’écriture des tests unitaire, là aussi un sujet bien mieux traité dans de nombreux ouvrages, tandis que le chapitre suivant est une sorte d’étude de cas qui ne restera pas gravé dans ma mémoire.

Au final, on peut considérer que ce livre est une sympathique, mais peu consistante distraction. Les illustrations qui émaillent le livre ajoutent à l’agrément. Il reste bien léger et à part les aspects traitant des commentaires, je n’en garderais pas grand chose. Vous pouvez passer votre chemin.

art-readable-code-oreilly

Référence complète : The Art of Readable Code, Simple and practical techniques for Writing better code – Dustin Boswell & Trevor Foucher – O’Reilly 2011 – ISBN : 978-0-596-80229-5

The Art of Readable Code

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

Note de lecture : The Lean Startup, par Eric Ries

Note : 10 ; Le futur de l’agilité ? Book the year 2012 !

Je ne vais pas faire durer le suspens : j’adore ce livre ! C’est vrai, il parle de startups, en principe un sujet un peu éloigné de mes préoccupations quotidiennes. Mais en réalité tout ce qui y est dit ou presque est transposable dans le contexte d’un projet informatique.

Le Lean Startup est déjà un mouvement d’ampleur, que l’on ne peut plus ignorer et ce livre en est le texte emblématique, pour de bonnes raisons que je vais tenter d’expliquer. Tout d’abord, avant de devenir le gourou de ce mouvement Eric Ries était informaticien, et même un grand supporter des méthodes agiles en générale et d’extreme programming en particulier. Lui-même créateur de startups, il a vécu et cherché à dépasser les limites de l’approche agile et a puisé dans le Lean l’essence de ce qu’il souhaitait faire. Ce n’est pas une simple transposition du Lean, mais bel et bien l’esprit du Lean transposé dans le processus startup.

Il y a 5 principes sous-jacents au Lean Startup

  • Les entrepreneurs sont partout : Etre entrepreneur, ce n’est pas forcément être enfermé dans un garage avec 3 copains. On peut être entrepreneur dans une entreprise, ou même sur un projet.
  • L’entreprenariat EST le management : Le Lean Startup est un processus pour les business d’extrême incertitude. Cela requiert un nouveau type de management.
  • Validated Learning : C’est le cœur du Lean Startup. Le processus a pour but d’apprendre, de permettre de valider des hypothèses. Il est facile d’arguer que l’on a appris quelque chose, le but est d’apprendre quelque chose d’utile étayé par des données. Il s’agit donc d’avoir une approche scientifique de la connaissance.
  • Build-Mesure-Learn : C’est le cycle du Lean Startup. Le but d’une startup est de construire un produit à partir d’idées et d’en mesurer l’effet auprès de clients. Puis de produire un nouvel incrément à partir de ce que l’on a appris.
  • Innovation accounting : Ce sont les choses ennuyeuses qui comptent dans le succès d’une startup. Très peu est lié à la vision initiale, car ce que l’on construit finalement n’a pas forcément beaucoup à voir avec l’idée initiale. Ce qui construit le succès, c’est de rester engagé sur les étapes d’évolution, de persévérer ou de pivoter, jour après jour.

Je serais bien en peine de résumer simplement ce livre. Je vais donner les grandes lignes des 3 parties (mais vous trouverez cela sur Amazon de toute façon). Puis j’essaierai de vous dire pourquoi j’aime ce livre.

La première partie, « Vision », nous explique les bases du cycle du Lean Startup : Démarrer, définir, apprendre et expérimenter. On part dune vision, ce que Ries appelle « l’acte de foi ». Mais au lieu de partir gaillardement de l’avant, on s’efforce de valider la ou les hypothèses sous-jacentes en construisant et exposant le plus rapidement possible un MVP (minimal viable product). Contrairement aux approches agiles, le focus se fait sur la vitesse et ce que l’on souhaite apprendre au détriment éventuel de tout le reste !

La seconde partie, « Piloter », évoque le processus dans sa durer : Tester ses idées, les mesurer et savoir interpréter les mesures, en terme d’évolution et non en « mesure de vanité ». Enfin cette partie évoque un des thèmes centraux de l’approche : pivoter.

La troisième partie « Accélérer » traite de tout ce qui permet de raccourcir le temps de cycle : diminution des lots (hérité du Lean), déploiement continu, etc…

J’ai été très (trop) vite à parcourir le contenu du livre et j’ai zappé beaucoup de points importants. Ce n’est pas critique, car vous allez le lire. Le Lean Startup m’apparaît ici comme l’étape qui suit l’agilité.

Une étape où l’on ne se satisfait plus de backlog ou de user stories, mais où l’on va au front pour comprendre et décider de la prochaine étape.

Une étape où il n’y a plus une équipe de développement qui développe (certes en collaboration) avec un utilisateur où un Product Owner, mais simplement un startup qui fait le boulot et où on ne parle plus de rôle.

Une étape où le ne mesure plus la vélocité d’une équipe au nombre de user stories achevées, mais où cette notion même n’a plus de sens et où on se focalise sur le progrès du business.

Eric Ries fait passer dans son livre des concepts forts, étayé par des idées empreintes d’intelligences avec de nombreux exemples à la clé qui en rendent la lecture très agréable. Il n’y a réellement aucune longueur dans ce texte. Au contraire : il m’apparaît que faire le tour de ce sujet en un seul ouvrage n’est pas possible. J’ai eu l’impression d’avoir entre les mains « l’extreme programming » des années 2010, un livre qui engendrera et nécessitera des développements. En fait cela a déjà commencé. La lame de fond « Lean Startup » ne fait que débuter. Elle va impacter de nombreux domaines dans les années à venir et va voir son cercle d’influence s’agrandir, ses idées et ses pratiques se développer.

Je n’ai pas hésité à en faire mon « book of the year » dès maintenant. Nous sommes au mois de Mai et je n’ai guère de doute. Ma question est plutôt : est-ce là mon « book of the décade » ?

Si je n’ai pas été assez clair sur ce que je pense de ce texte et quel est mon conseil : relisez depuis le début, ça ne peut pas vous échapper !

lean-startup

Référence complète : The Lean Startup – Eric Ries – Crown Business 2011 – ISBN : 978-0-307-88789-4

The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses


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

Note de lecture : Agile Adoption Patterns, a roadmap to organisational success, par Amr Elssamadisy

Note : 4 ; Le pattern ne fait pas le moine !

Etant à la fois amateur de patterns et de méthodes agiles, je me faisais un plaisir d’aborder cet ouvrage. De plus, Amir est un excellent ex-collègue que j’ai eu le plaisir de rencontrer. J’ai pu apprécier sa maîtrise du sujet et aussi sa grande humilité. Ce livra n’en reste pas moins une déception.

Les deux premières parties sont dédiées à une présentation générale (mais plutôt agréable) des valeurs et du sens de l’agilité, tandis que la seconde partie est consacrée aux « stratégies d’adoption ». Les deux axes en sont la valeur métier et les « mauvaises odeurs » conduisant à une direction / stratégie d’adoption. Cette partie se conclue par des propositions de roadmaps s’appuyant sur les patterns présentés au long des parties suivantes.

La troisième partie est forte de 38 chapitres couvrant 37 patterns (et un chapitre introductif) construits selon la forme dite « alexandrienne ». Ces patterns couvrent de très nombreux aspects des pratiques agiles, sinon toutes. Depuis la capture des besoins jusqu’aux pratiques de développements en passant par les pratiques supports telles que l’intégration continue, le rythme du projet, etc… Chacun de ces patterns traite de manière réduite (donc concentrée) chaque pratique en mettant l’accent sur les points forts et faibles de celles-ci. J’avoue avoir trouvé difficile de faire le lien entre les patterns, et ce malgré les roadmaps. La partie « sketch » sensée donner un contexte au pattern est hélas à mon goût trop stéréotypé : on croit entrer dans un monde où tout est parfait. Telle n’est pas mon expérience.

Les deux chapitres finaux consacrés aux retours d’expérience valent le détour : il s’agit tout simplement des rapports d’audit et de rétrospective de l’auteur sans aucun habillage ni concession. Outre qu’il met en évidence le travail de consulting de l’auteur il met aussi en lumière la réalité du terrain de l’adoption de l’agilité.

Ma déception face à cet ouvrage est probablement due au fait que ce texte ne s’adresse pas à moi ! J’ai ainsi eu du mal à y fixer mon intérêt. Un nouveau venu dans cet univers aura probablement un autre regard !

agile-adoption-patterns

Référence complète : Agile Adoption Patterns, a roadmap to organisational success – Amr Elssamadisy – Addison Wesley 2008 – ISBN : 0-321-51452-1 ; EAN : 978 032 151452 3

Agile Adoption Patterns: A Roadmap to Organizational Success


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

Note de lecture : MDA en action : Ingénierie logicielle guidée par les modèles, par Xavier Blanc

Note : 7 ; Un très bon livre, pour comprendre les concepts clés de MDA, les métamodèles associés et leurs mécanismes de transformation.

Mon snobisme naturel m’incite généralement à préférer les livres américains à leurs équivalents français. Le fait que je m’intéresse aujourd’hui à un ouvrage bien de chez nous ne doit rien à une quelconque cabale hexagonale, mais bien aux qualités intrinsèques dudit ouvrage.

MDA est un sujet complexe, qui nécessite d’en comprendre les fondements afin de pouvoir saisir les nombreux « buzzwords » que sont OCL, Semantic Actions, et autres CIM, PIM, PSM et MOF ! C’est exactement l’approche de ce livre : après un chapitre de présentation générale de MDA, on aborde tout de suite la pierre angulaire du MDA : le MOF (méta-object facilities) encore appelé méta-métamodèle ! Si il est un sujet ardu dans MDA, c’est bien ce fameux MOF (vous l’avez probablement compris rien qu’en lisant la phrase précédente). Mais l’auteur s’en tire fort bien, de manière exemplaire devrais-je même dire car au chapitre 6, on se plonge même dans la manipulation d’un métamodèle construit à l’aide du framework EMF d’Eclipse (celui-là même qui est au cœur de Rational Software Modeler / Architect) : bravo ! Bien sûr, il vous faudra avoir le goût des métamodèles, mais dans le cas contraire, MDA n’est probablement pas pour vous. UML2 est bien entendu abordé, et si vous n’aviez pas encore compris ce que sont UML infrastructure et superstructure (on ne saurait vous en blâmer) et la fameuse dépendance « merge », l’explication est ici. Je met juste un bémol sur les explications dédiées aux classes du métamodèle UML2 qui sont un peu fastidieuses.

Les standards connexes, si ils sont traités brièvement ne le sont pas moins clairement, avec une mention spéciale pour le traitement de XMI et DI (diagram interchanges) ce dernier sujet n’étant même jamais abordé dans les autres textes. De même, si vous êtes noyés dans les problèmes d’incompatibilités de XMI, la réponse est ici. La clé de voûte de MDA, la transformation de modèles n’est pas en reste, puisque l’auteur développe les 3 approches possibles : transformation par programmation, par « templates » et par règles de programmation, la 1ère et le 3ème approche étant par la suite illustrés dans la prise en compte des plates-formes d’exécution, J2EE et PHP respectivement, la transformation entre 2 métamodèles différent (car l’auteur présente un métamodèle PHP simplifié pour l’occasion) est carrément la cerise sur le gâteau ! On est pas loin du tour de force.

Sur le fond, l’approche de l’auteur (fusion des informations de transformation avec le modèle) s’oppose avec l’approche de Kleppe & Warmer qui est de séparer les informations de transformation du modèle. Personnellement je préfère cette dernière approche. Cela ne retranche rien à la qualité de cet ouvrage, que je conseille à la condition que vous recherchiez l’approche « en profondeur » et soyez friand de métamodèles !

L’étude cas et la présentation de deux outils MDA (Rational Software Architect et Objecteering MDA Modeler) ne sont pas la meilleure partie de l’ouvrage, mais elles complètent utilement celui-ci en donnant une illustration concrète.

Voilà donc un livre solide et complet sur MDA. Il requiert un peu e motivation pour aborder le sujet sous l’angle métamodèle, mais il équilibre de façon fort heureuse les principes et la pratique, le tout dans un volume raisonnable, puisque le livre compte 260 pages.

MDA en Action

Référence complète : MDA en action : Ingénierie logicielle guidée par les modèles – Xavier Blanc – Eyrolles 2005 – ISBN : 2-212-11539-3

MDA en Action


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