Un voyage de mille lieues commence toujours par un premier pas.

Lao Tseu in Tao Te King

image
Publicité

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

Valtech Agile Day, le 19 Juin 2012

Valtech propose durant cette journée des présentations et des ateliers participatifs principalement proposés par des consultants Valtech venus des différents bureaux : France, USA, Allemagne, Inde, UK et Suède. Quelques membres éminents de la communauté agile Française complètent le programme.

Quelques sujets attirent particulièrement mon attention, comme le marketing en mode agile ou “innovation needs waste”. De manière générale le programme me semble suffisamment riche pour que je ne perde pas mon temps. Je viendrais donc certainement.

Valtech Agile Day, le 19 Juin 2012

La Scrum Night II @ Google (en images)

Ce 22 Mai s’est déroulé une nouvelle édition de la ScrumNight chez Google !

Mobiliser des animateurs d’ateliers en ce mois de Mai très riche en évènements n’était pas chose facile. Mais suffisamment d’entre eux s’étaient mobilisés pour nous permettre de proposer un programme plus qu’alléchant.

Bienvenue et bon appétit !

J’avais quelque craintes quand à l’affluence dans les locaux de l’avenue de l’Opéra. Nous avions limité les inscriptions en conséquence, faisant hélas pas mal de frustrés. Nous avons réussi à avoir … ce qui s’est avéré être le bon nombre !

La soirée a débuté par un cocktail et de brefs mots d’accueil de Xavier Warzee et de Martin Görner, notre hôte chez Google.

Untitled

Je dois dire que les petis fours proposés par Google étaient somptueux ! En quantité et n qualité. Une fois n’est pas coutume, je me suis calé derrière l’une des tables afin d’attaquer de manière systématique les différents présentoirs durant les mots de bienvenus.

Visiblement cela n’a pas échapé à certains !

Disons toutefois que je n’étais pas seul sur l’affaire …

Untitled

Les sessions !

Je me suis un peu promené durant cette première session. Je me suis rendu tour à tour au Kanban Pizza Game animé par Dragos Dreptate et Luc Dages.

Untitled

Untitled

De son côté Alex Boutin nous a gratifié de son excellent “Big Payoff” que j’avais essayé à Agile Games France il y a peu. En fait, Alex a même improvisé et enchainé sur un second jeu qu’il avait avec lui : “Joli Tableau” pour s’ajuster au timing ! Je reviendrais sur ce point.

Untitled

D’autres ateliers avaient lieu pendant cette première période, les artistes et spécifiers (animé par Cédric Chevalerias), ainsi que le Business Value Game animé par Nicolas Laurent, épaulé au pied levé par Jérôme Guenver (merci Jérôme !)

J’avoue avoir passé beaucoup au “Robot Crash battle” animé avec Brio par Arnaud Villenave ! Des Robots en lego, programmés en Java depuis dces portables s’affrontent lors de combat. Chacune des 3 équipes dispose de 10 minutes pour programmer son Robot. J’ai posté il y a quelque jour une vidéo d’un de ces combats. Arnaud s’est fait u malin plaisir de changer les règles au cours des itrations : combats à deux, puis à trois, réduction du temps d’itération, pénalité en cas de dépassement et pour finir : interversion des programmes des différentes équipes ! L’une des équipes a même eu droit à une mise à jour Windows au milieu de son itération (qu’elle a d’ailleurs remporté).

Untitled

Comme vous pouvez le voir, les équipes ont vraiment fait vraiment travaillé avec acharnement !

Untitled

Lors de la seconde session, j’ai participé à l’atelier de Lan Levy : Scrum Master: qui es-tu ? Quels sont tes défis ? Bien qu’un peu raccorcis, il a donné de bons échanges. Par contre, je n’ai pas de photos à vous montrer de cette période.

En conclusion

Une excellente soirée avec des animateurs de qualité et une communauté toujours encline à participer activement. Visiblement les participants étaient extrêmement contents de leur soirée.

J’étais un peu inquiet des contraintes horaires qui nous étaient imposées, mais elles ne se sont finalement pas montrées pesantes.

Je pense qu’il est maintenant temps de faire évoluer cette formule. J’espère que nous aurons des propositions et des discussions en ce sens sur IdeaScale ! Avoir deux Scrum Night par an est peut-être aussi un peu lourd, en tout cas sur Paris. Personnellement j’aimerais une Scrum Night plus ambitieuse, mais une seule sur Paris. Par ailleurs Grenoble, Bordeaux et peut-être d’autres villes aimeraient aussi avoir une Scrum Night, pensons-y !

Petite confusion aussi au niveau de l’agenda: nous étions convenu d’un timing initial au bureau, avons communiqué avec les animateurs sur la base de ce timing et fianlement c’est un timing différent qui a été affiché. Les ateliers de la première session ont eu un peu de battement (ou de la créativité et de l’improvisation dans le cas d’Alex) tandis que ceux de la seconde session se sont trouvé trop contraints. Nous devons corriger cela !

A bientôt !

C’est certainement notre dernière grosse activité sur Paris d’ici l’été. Nous aurons je l’espère une Scrum Beer (ou deux) et peut-être un Scrum Picnic si la météo est avec nous.

Il va nous falloir commencer à reflêchir à ce que nous projetterons à partir de la rentrée. Il se profile à l’horizon 2013 un évènement de plus grande ampleur que ce que nous avons fait jusqu’à présent : le Scrum Gathering ! Nous devons voir comment nous pourrons assumer cela ainsi que des évènements plus “locaux”.