Arrivée à Singapour au soleil couchant.
À la guerre il est important de savoir reconnaître l’ennemi. Car, sans ennemi, la guerre est ridicule.
Pierre Desproges
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.
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)
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.
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
Un voyage de mille lieues commence toujours par un premier pas.
Lao Tseu in Tao Te King
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.
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
La folie, c’est se comporter de la même manière et s’attendre à un résultat différent.
Albert Einstein
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 !
Référence complète : The Lean Startup – Eric Ries – Crown Business 2011 – ISBN : 978-0-307-88789-4
Planifier Agile Games 2013
La page du premier Agile Games France est à peine fermée qu’il faut déjà penser à préparer celle de 2013 !
Merci à Thierry Montulé d’avoir ouvert le Doodle pour faire figurer nos préférences de dates.
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 !
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
Software Freethinker 
